Add config based header inclusion for AHC driver. The ASRC and ARAD
drivers are not POR for L4T releases and also AHC driver is not yet
up with Kernel OOT. For now, ensure ASRC and ARAD functionality
without dependency on AHC driver. Later if there is a requirement
test functionality with AHC module.
Bug 3583581
Change-Id: I5e586886ae91b1dcaa9e3aa945364dc21a23f281
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2774432
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: Sharad Gupta <sharadg@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
This is inspired from following upstream commit:
------------------------------------------------------------------------
commit 189364872fba07291db7f68fe0161f97e5b61bb1
Author: Takashi Iwai <tiwai@suse.de>
Date: Mon Aug 2 09:28:09 2021 +0200
ASoC: tegra: Use managed buffer allocation
As the standard buffer allocation helper supports WC pages now, we can
convert imx-pcm-rpmsg driver to use that. This allows us to remove
lots of superfluous code.
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210802072815.13551-10-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
------------------------------------------------------------------------
Above is required to avoid build errors related to non existent
callbacks in 'snd_soc_component_driver' structure.
Bug 3583581
Change-Id: Id1a930db0e41a51be35813aed67183974d1eec57
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2774431
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: Sharad Gupta <sharadg@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
OOT drivers cannot directly access private headers of core kernel.
This is a standard policy adopted by kernel distributors and to
workaround this problem copy headers to OOT path. Update the usage
references as well.
Bug 3583581
Change-Id: I1b99e17c60294a1cb257eb5b80837faa896d3f8d
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2774429
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: Sharad Gupta <sharadg@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Kernel OOT POR is for Tegra234 and later. BW manager code for legacy
chips causes build error with Kernel OOT and Tegra234 uses interconnect
based BW requests. Since Tegra194 (and earlier) support is not needed,
remove the legacy code.
Bug 3583581
Change-Id: I04c6ca0bc58dad4de9daa6ab65b04ee01553724d
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2774428
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: Sharad Gupta <sharadg@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
snd_soc_of_parse_daifmt() is removed from later kernel versions and this
causes complilation error. Use asoc_simple_parse_daifmt() helper to
parse DAI format.
asoc_simple_canonicalize_platform() has a different signature now and
thus update the helper usage accordingly.
Bug 3583581
Change-Id: I9a99fc71849ddf460040f980aea7d4b9f8f80011
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2774427
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: Sharad Gupta <sharadg@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
WARNING: modpost: /home/mbhardwaj/kernel_only/out/
embedded-linux-generic-release/nvidia/kernel-rt_patches-nvidia-oot/
nvidia-oot/drivers/virt/tegra/tegra_hv.o (.exit.text+0x34): Section
mismatch in reference from the function cleanup_module() to the
function .init.text:tegra_hv_cleanup()
The function __exit cleanup_module() references a function __init
tegra_hv_cleanup(). This is often seen when error handling in the
exit function uses functionality in the init path. The fix is often
to remove the __init annotation of tegra_hv_cleanup() so it may be
used outside an init section.
Signed-off-by: Manish Bhardwaj <mbhardwaj@nvidia.com>
Change-Id: Ie3fb2875c0acc732d5673e7618593e67e412851f
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2784195
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Kernel OOT model is a combination of core kernel (coming from mainline)
and NVIDIA kernel modules which are built out of tree using core kernel
headers. With this new model no additional patches will be accepted in
core kernel (for downstream use) unless it comes via upstream path.
Audio drivers upstream is WIP and the upstream drivers are not feature
complete yet. Tegra234 is soon switching to kernel OOT model and it is
expected to have all the features.
Given above, copy kernel-5.10 ASoC drivers to nvidia-oot and enable
these on Tegra234. In parallel, work on making upstream drivers
feature complete. Once a driver is 100% upstreamed, get rid of OOT
version.
Upstream version of Tegra PCM driver and CIF header file are used
and rest of the drivers are copied to nvidia-oot.
Note: This just copies required ASoC drivers to nvidia-oot and does
not ensure build sanity. It will be tracked in subsequent commits.
While copying the git history is pulled as well.
Bug 3583581
Change-Id: I25a28d8ecb8d77772895c357e9e7fcbe0e541118
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Make sure to call pm_runtime_enable() before the
of_platform_populate() which will ensure ahub runtime
resume would be called to enable ahub clock before accessing
any ahub modules registers in modules probe. Calling
of_platform_populate() in parent driver probe results in all
of its child device probe to be completed before it exits the
parent probe call.
The issue caught during MVC child device probe tries to access a
register in probe call which depends on the ahub clock that gets
enabled during AHUB RPM resume. But ahub RPM resume not called as
pm_runtime_enable() in ahub parent driver happens after the
of_platform_populate(). This was observed when drivers were built
as part of kernel image.
Bug 3752938
Change-Id: Ifeb4085961d89877f79ff521adb6dfdf4e51907c
Signed-off-by: Mohan Kumar <mkumard@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.10/+/2762027
Reviewed-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Sharad Gupta <sharadg@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
commit a4e37950c9e9b126f9cbee79b8ab94a94646dcf1 upstream.
The kcontrol put callback is expected to return 1 when there is change
in HW or when the update is acknowledged by driver. This would ensure
that change notifications are sent to subscribed applications. Update
the AHUB driver accordingly.
Fixes: 16e1bcc2caf4 ("ASoC: tegra: Add Tegra210 based AHUB driver")
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Suggested-by: Jaroslav Kysela <perex@perex.cz>
Suggested-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/1637219231-406-12-git-send-email-spujar@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d6202a57e79d102271d38c34481fedc9d4c79694 upstream.
The kcontrol put callback is expected to return 1 when there is change
in HW or when the update is acknowledged by driver. This would ensure
that change notifications are sent to subscribed applications. Update
the DSPK driver accordingly.
Fixes: 327ef6470266 ("ASoC: tegra: Add Tegra186 based DSPK driver")
Suggested-by: Jaroslav Kysela <perex@perex.cz>
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/1637219231-406-11-git-send-email-spujar@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a347dfa10262fa0a10e2b1970ea0194e3d4a3251 upstream.
The kcontrol put callback is expected to return 1 when there is change
in HW or when the update is acknowledged by driver. This would ensure
that change notifications are sent to subscribed applications. Update
the DMIC driver accordingly.
Fixes: 8c8ff982e9e2 ("ASoC: tegra: Add Tegra210 based DMIC driver")
Suggested-by: Jaroslav Kysela <perex@perex.cz>
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/1637219231-406-10-git-send-email-spujar@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f21a9df3f7cb0005947679d7b9237c90574e229a upstream.
The kcontrol put callback is expected to return 1 when there is change
in HW or when the update is acknowledged by driver. This would ensure
that change notifications are sent to subscribed applications. Update
the I2S driver accordingly.
Fixes: c0bfa98349d1 ("ASoC: tegra: Add Tegra210 based I2S driver")
Suggested-by: Jaroslav Kysela <perex@perex.cz>
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/1637219231-406-9-git-send-email-spujar@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e2b87a18a60c02d0dcd1de801d669587e516cc4d upstream.
The kcontrol put callback is expected to return 1 when there is change
in HW or when the update is acknowledged by driver. This would ensure
that change notifications are sent to subscribed applications. Update
the ADMAIF driver accordingly.
Fixes: f74028e159bb ("ASoC: tegra: Add Tegra210 based ADMAIF driver")
Suggested-by: Jaroslav Kysela <perex@perex.cz>
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/1637219231-406-8-git-send-email-spujar@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Due to a shortage of RT5658 codec parts, search was going on for an
alternative codec. As a replacement, RT5640 codec is finalized now.
The upcoming Concord boards (EB3 to begin with) will have this codec.
This commit adds required support in the machine driver.
Machine driver update is needed for following reasons:
* The RT5640 codec driver expects sysclk configuration from machine
driver. This requirement is similar to what we have today for
RT5658 codec. This handling is done under "rt5640-playback" DAI
link name.
* RT5640 DAI link init is added for jack setup. Since it is mostly
similar to RT5658 handling, the existing init helper function is
re-used. The component driver jack setup callback is used to make
this simple.
Bug 200766032
Change-Id: I41ee0022c22fd50e9baf80aa765b2b3ede4e85c7
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.10/+/2625064
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: Viswanath L <viswanathl@nvidia.com>
Reviewed-by: Sharad Gupta <sharadg@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
- MBDRC status register should be defined as volatile.
- MBDRC master volume control was not working for
expected volume range. Updated the control so that it can
work for -256dB to 255dB gain. Control can take values
from 0 to 512 that is mapped to -256 to 256dB. The dB
info is added as metadata of control.
kcontrol defination will look like below:
amixer -c 1 cget name='OPE1 mbdrc master volume'
numid=1187,iface=MIXER,name='OPE1 mbdrc master volume'
; type=INTEGER,access=rw---R--,values=1,min=0,max=512,step=0
: values=256
| dBminmax-min=-256.00dB,max=255.00dB
Bug 200753407
Signed-off-by: Sheetal <sheetal@nvidia.com>
Change-Id: I707a89074342083b71f906f15ead243ee317a43b
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.10/+/2601115
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Sharad Gupta <sharadg@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
Earlier hardcoded pll base rates were leading to fractional divider
values for i2s multichannel config while deriving i2s bclk.
Hence updated clock rates and logic for >2 channel configs for t186ref
and higher boards such that the dynamic range between max plla and min plla
is < 35 MHz. Also, if desired bclk is above limit, the case will be
declared as not supported. Note that new facility will be used only in l4t
machine driver.
Bug 200702569
Change-Id: I83aba425f6dde30a1f29f85b16a1bbbebba14198
Signed-off-by: Asha Talambedu <atalambedu@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2491744
(cherry picked from commit e0fe51d5e7ced073eb618e19836f88a023f70bdc)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.10/+/2613507
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
- Added mutex protection for init_done flag reads in
mixer control callbacks relevant to "ADSP init". Otherwise
during shutdown sequence that includes alsa store service,
this leads to inconsistent behaviour
- Shutdown callback is added to deinit ADSP OS during
abrupt shutdown.
- In case ADSP OS is crashed during boot/boot has not
started yet, shutdown does not issue OS deinit as
init is not complete yet
Bug 3391964
Change-Id: I207e2141af9386f5914e07a8dd231d0fcd803a6e
Signed-off-by: Asha Talambedu <atalambedu@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.10/+/2607727
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Sharad Gupta <sharadg@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
There was a plan to deprecate master volume control since it was thought
that per channel control will be sufficient and master volume application
can be emulated in user space by programming same volume to all channels.
But this means we would not really use a HW feature which has a provision
to automatically apply CH0 volume settings to all remaining channels.
HW has a per channel control bit, based on which it decides to apply a
channel specific setting or a common setting across all channels. Driver
has both master volume and per channel volume mixer controls. Based on
the control user updates, enable or disable the per channel control.
Use below scheme for volume updates:
* If master volume mixer control is updated, disable per channel control
and only CH0 volume register is programmed. SW can store same volume
across all channels.
* If a channel specific control is updated, enable per channel control
and program specific channel volume register.
Above applies to mute/unmute functions as well and thus corresponding
control blocks are similarly updated.
The volume settings are stored in SW and the same is used for the user
space queries via mixer controls. But mute settings are not stored in
SW and are always directly read from HW since it belongs to a volatile
register. The mute control read function is modified to return proper
settings when queried from user space.
Bug 200766084
Change-Id: Iad8b5c09c424731e841863bfd5ce32d07ff9e684
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.10/+/2599601
Reviewed-by: Sheetal . <sheetal@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Asha Talambedu <atalambedu@nvidia.com>
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: Sharad Gupta <sharadg@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
In current production software we support DAI link params from DT.
This is useful when operating Tegra in hostless mode, where params
(sample rate, channels and sample format) passed from DT are applied
to the DAI links. In this way DT can provide control to operate DAI
links in a required config.
For dev-main it was on hold since there was plan to use upstream
machine driver where upstream bindings can provide similar control.
Since this feature is required for a near customer release, it is
now ported to the dev-main driver.
Bug 200713904
Bug 200775355
Change-Id: I333cc60addc26ffc433f08b410fa076dc102282e
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.10/+/2594849
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Viswanath L <viswanathl@nvidia.com>
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: Sharad Gupta <sharadg@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
- The issue was happening because dapm core was not deallocating
the hw contraints rules memory.
Memory leak backtrace from cat /sys/kernel/debug/kmemleak:
[<0000000046fdaf4f>] slab_post_alloc_hook+0x6c/0x3e0
[<00000000989dfc0e>] __kmalloc_track_caller+0x1b8/0x400
[<00000000505e39ec>] krealloc+0xe8/0x160
[<000000009cc82a21>] snd_pcm_hw_rule_add+0x164/0x1a0
[<00000000aa77851e>] snd_pcm_hw_constraint_list+0x28/0x30
[<000000009b2cd5c6>] tegra210_ahub_write_ram+0xa8/0xb60
[<00000000a61d7069>] snd_soc_dai_startup+0x40/0xa0
[<00000000a7452879>] snd_soc_dai_link_event+0x334/0x600
[<000000008c5771de>] dapm_seq_check_event+0x120/0x330
[<00000000be740a3d>] dapm_seq_run_coalesced+0xb0/0x250
[<0000000003732007>] dapm_seq_run+0xf0/0x510
[<00000000cbb85eb0>] dapm_power_widgets+0x58c/0xac0
[<00000000b96c5548>] snd_soc_dapm_stream_event+0x128/0x170
[<0000000027bb14bc>] soc_pcm_prepare+0x70/0x110
[<00000000d44b9075>] snd_pcm_do_prepare+0x34/0x50
[<000000005664d4d5>] snd_pcm_action_single+0x4c/0xa0
- For BE dais HW constraints won't take any impact and only for FE
dais it is required. So added it in component driver open callback.
Bug 200773796
Signed-off-by: Sheetal <sheetal@nvidia.com>
Change-Id: Ic4c1bf881b914bda03bda8e97816cf1c6dee4052
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.10/+/2596443
Reviewed-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: Viswanath L <viswanathl@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Sharad Gupta <sharadg@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
- Fix the issues with 24KHz and 64KHz sample rate.
- In machine driver, 24KHz and 64KHz were not supported, add
the rates into the list.
- 24KHz is not supported by ALSA, to support it mentioned dai rates
as SNDRV_PCM_RATE_KNOT. Using KNOT chip can support unconventional rates,
defined in hw constraints list.
- The change is added for FE links only, for BE links its not required as
it will be taken care by FE links.
Bug 200757915
Change-Id: I348368420316ba78b303cd27a413048b6cab2dd7
Signed-off-by: sheetal <sheetal@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.10/+/2571687
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
OPE enable is not happening even though the DAPM path is complete.
This seems to happen because ASoC core does not use correct regmap
interface for the DAPM route listed by driver. The driver makes use
of multiple regmap interfaces (one each for OPE, PEQ and MBDRC).
The core populates component regmap using dev_get_regmap(), which
actually returns the last registered interface in the OPE driver
probe() call.
Since the same callback function is not available in later versions
of kernel for component driver, use component probe() call to setup
the regmap.
Bug 200750067
Jira EMA-393
Change-Id: Ib509a9f95f4c152c2210f88975a1f7572d79ba08
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-on: http://git-master/r/1318570
(cherry picked from commit 545ee019fc4a7c5b0b92a488cd3d16dbbcefbba9 in
partial and updated logic for it to work on newer kernel)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.10/+/2558375
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: Sheetal . <sheetal@nvidia.com>
Reviewed-by: Sharad Gupta <sharadg@nvidia.com>
Reviewed-by: Viswanath L <viswanathl@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: Sheetal . <sheetal@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
Tegra Audio HW subsystem has many I/O module instances and currently a
single PLL source is used for all these modules. Any I2S configuration
is supported now by dynamically updating PLL base rate. But as of today
this has few limitations.
- AUD_MCLK factor is not considered while updating PLL base rate.
- Two module instances can request conflicting PLL base rate and
the last request overrides existing session. This would also mean
simultaneous 8x and 11x configurations are not possible.
- Tegra210 has problems with specific PLL requests.
Multiple PLLs would be required if concurrent audio sessions need to be
supported and dynamic rate update is needed to support any configuration.
But this has few limitions too.
- Since number of available PLLs for modules are limited, specific PLL
cannot be dedicated to a module. The PLL would be shared and may
cause problems when there are simultaneous conflicting requirements.
- Logic for runtime distribution of PLLs to modules and rate updates
has to be managed in module drivers only as machine driver does not
have intelligence to know for which audio path exactly the hw_param()
call comes. This can make the code complicated and buggy where each
module driver tries to control specific PLL.
Instead the problem can be simplified by fixing PLL rates in DT. User
can employ one or more PLLs to realize their design. Of course this won't
support all configurations simultaneously since this is not what users
require generally. They have specific requirements which can be addressed
via DT configurations. For example,
- Some users may use single PLL and decide on compatible set of audio
configurations for their use cases.
- Some users may want to use two PLLs, one each for 8x and 11x. Then
via DT specific modules can use specific PLL sources to realize
simultaneous 8x and 11x configurations. In fact two PLLs can be
used when there are conflicting requirements which cannot be met
by a single PLL source.
To realize above add new DT property "fixed-pll" and bypass PLL rate
updates from the driver. Users can populate this in their platform
sound DT node, whenever static configurations are preferred.
Bug 200726704
Change-Id: I0416f201fd26c49bb6c09594d86394c46a0bbad2
(cherry-picked from commit 0c84a3fe1e2e40d20ddb449a948da6fdebd85efe)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2548361
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Change-Id: I51d5b502f728baee2d6d075951dc186503cbf76f
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.10/+/2556536
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
The simple-card helper asoc_simple_parse_daifmt() expects "bitclock-master"
and "frame-master" DT properties in DAI link node with phandle references
or supports legacy style in codec subnode. Current platforms describe these
properties in DAI link subnode which are not in expected style and thus
these are not taking any effect.
It can be addressed by updating platform DT files. But since audio-graph
is planned in future, it is simpler to keep current bindings as they are
and just fix driver to work with current style. This can be achieved by
using ASoC core helper, instead of simple-card helper, for parsing the DAI
format.
Bug 200749671
Change-Id: I86564321bb41344ef9d5c1c26aeaf363e67cc666
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.10/+/2556106
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Sharad Gupta <sharadg@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
