If the ADSP fail during the probe after the ADSP component is
registered, the ADSP component will not be unregistered and this will
cause the kernel to crash when attempting to the probe the component.
Furthermore, if the removal of the ADSP device, the component and codec
register by the ADSP driver are not removed. Fix these items by ensuring
the the ADSP component and codec are removed as necessary during the
probe failure path and driver removal.
Finally, clean-up some of the prints in the driver probe to drop the
unnecessary print when the netlink is created and use the dev_xxx
functions instead of the pr_xxx functions.
Bug 200458098
Change-Id: I4b51949e1c10c86952008ebe5676832e381a68f4
Signed-off-by: Jonathan Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1974520
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svc-mobile-misra <svc-mobile-misra@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: Hariharan Sivaraman <hariharans@nvidia.com>
Reviewed-by: Dipesh Gandhi <dipeshg@nvidia.com>
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
- Copied the adsp driver from tegra-alt to tegra-virt-alt
- Modified tegra-virt-alt Kconfig and Makefile to make it
dependent on SND_SOC_TEGRA_VIRT_T210REF_PCM and
TEGRA_NVADSP
- Make the drivers exclusive with respect to device tree
node compatibility
- Remove all the code guarded under SND_SOC_TEGRA_VIRT_IVC_COMM
from tegra-alt ADSP driver .
- Remove all the #ifdefs from the tegra-virt-alt ADSP driver.
- Change ADSP drv name used by dai_links
- Update dai_links with new name
- add -EPROBE_DEFER on sound card register failure. This may
be required if we decide to remove virt drivers from
/etc/modules and /etc/modprobe.d/blacklist.conf
- Cleanup in case of deferred probe
Jira: EMA-904
Jira: EMA-1158
Change-Id: I0e707eca1bfa27b3f1814e367baa16e97bf464e5
Signed-off-by: Niranjan Dighe <ndighe@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1966030
GVS: Gerrit_Virtual_Submit
Reviewed-by: Hariharan Sivaraman <hariharans@nvidia.com>
Reviewed-by: Uday Gupta <udayg@nvidia.com>
Reviewed-by: Viraj Karandikar <vkarandikar@nvidia.com>
Reviewed-by: Nitin Pai <npai@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reading the mixer RX Gain always returns 0 and this is because
the function to return the gain setting has not been implemented
completely. Fix this by returning the programmed gain value in the
function tegra210_mixer_get_format().
Bug 2438553
Change-Id: I4e6e5a6fe3373982cbb063ce3276428e0a1a2c1a
Signed-off-by: Jonathan Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1945622
GVS: Gerrit_Virtual_Submit
Reviewed-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
For start of any usecase, the DMA and AHUB blocks
should be enabled in the order from sink to source.
For stop, blocks should be disabled from source
to sink.
Previously, DMA was triggered first then ADMAIF
enable/disable messages were done. Fixed order to:
Start:
- send start playback IVC
- trigger DMA by sending active state msg to ADSP
- send start capture IVC
Stop:
- send stop capture IVC
- trigger DMA by sending inactive state msg to ADSP
- send stop playback IVC
Bug 2407746
Change-Id: Icf25422eccb16af8fa40357910f79320dbd92a0f
Signed-off-by: Hariharan Sivaraman <hariharans@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1932277
(cherry picked from commit efead3a657c2b38ec359ad19573d0b3f20e8fb49)
Reviewed-on: https://git-master.nvidia.com/r/1938889
GVS: Gerrit_Virtual_Submit
Reviewed-by: Dipesh Gandhi <dipeshg@nvidia.com>
Reviewed-by: Uday Gupta <udayg@nvidia.com>
Reviewed-by: Viraj Karandikar <vkarandikar@nvidia.com>
Reviewed-by: Nitin Pai <npai@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Add support for secure audio playback in adsp driver
- Add Secure Mode control to set whether an APM memory will be APR or not.
- Send message for all the plugins within apm to allocate apr memory before
the start of pcm/compress playback.
Bug 200235401
Change-Id: I0aba7197b10a4aab05fff5564e33c529cd2f68f5
Signed-off-by: Mohan Kumar <mkumard@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1602237
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
enable dma_set_mask_and_coherent call even
if CONFIG_SND_SOC_TEGRA210_ADSP_ALT
is not enabled, This will allow pcm
driver to start allocations start from the
specified address and downwards.
Bug 200423087
Change-Id: Ib1a2f2361f15d1191258fbb0ca4a620d1b2a7c8b
Signed-off-by: Dara Ramesh <dramesh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1809568
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Not all platforms have to support modules such as AMX, ADX, MVC, and
etc, so selecting all the audio modules by default is wasting memory
for them.
This patch drops DMIC, AMX, ADX, AFC, MVC, OPE and ADSP from CONFIG
SND_SOC_TEGRA_T210REF_MOBILE_ALT, and keeps only essential ones. In
order not to break any exisiting use case, these CONFIGs will be set
to "def_tristate" so all platforms build them as usual. This means
anyone who does not need them will need to specifically disable them
in the defconfig.
Meanwhile, this patch adds IS_ENABLED() check at corresponding files.
Bug 2284925
Change-Id: I2e3853b5499046fc8de7256899c30d764160aebe
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1803446
Reviewed-by: Dara Ramesh <dramesh@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Ravindra Lokhande <rlokhande@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Suspending all the DAI links for Tegra on entering suspend is taking
between 1-2 seconds which is far too long. To ensure that any active
audio playback and/or capture resumes following suspend, it is only
necessary to suspend the DAI links for ADMAIF and it is safe to set
the '.ignore_suspend' flag for all the other DAI links.
With this change the min/ave/max time for executing the 'snd_soc_suspend()'
function is reduced from 419ms/1056ms/2021ms to 49ms/287ms/766ms. This is
measured using the ftrace function graph feature to measure the total time
for 'snd_soc_suspend()' to execute.
Bug 200390943
Change-Id: I498643eb069a1bc72d72b86930ab5b6e54e44b76
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1799943
GVS: Gerrit_Virtual_Submit
Reviewed-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
The Tegra machine driver controls and widgets are generic and can be
used by any board that uses the generic machine driver. Therefore
consolidate the controls and widgets used for all boards.
This also fixes a problem for the Tegra194 Rey platform which does not
have an on-board RT5658 codec and so the generic controls and widgets
are not populated. These controls and widgets are still needed for
testing I2S, DMIC and DSPK.
Finally, to improve the readability don't use 'snd_soc_tegra_card' in
the function dai_link_setup() and just use the 'card' pointer instead.
Bug 200417361
Change-Id: I863a0d5c03a61fe5b9e36fdfd5356900aac9d456
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1775296
Reviewed-by: Sameer Pujar <spujar@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Dara Ramesh <dramesh@nvidia.com>
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Tested-by: Bibek Basu <bbasu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Mono playback via the RT5658 codec on the Jetson TX1/TX2/Xavier is
distorted. Although the RT5658 codec is configured for standard I2S
timings (implying 2 channels), the Tegra XBAR should convert the mono
audio track from one channel to two channels. The problem is caused
because the 'CHANNEL_BIT_CNT' field in the I2S Timing Register is
being configured incorrectly. For mono playback in I2S mode (or LRCK
mode) the CHANNEL_BIT_CNT is being set to 31 instead of 15 by fixing
this mono playback works as expected.
Please note that the 'bitcnt' value programmed into the I2S Timing
Register is verified to see that it is not bigger than the mask for
the CHANNEL_BIT_CNT field. However, this is done before we shift the
bitcnt by 1 for I2S mode. Therefore, ensure the bitcnt is shifted by
1 before we do the check.
Mono playback has been tested by playing the following audio clip ...
aplay -D hw:1,0 /usr/share/sounds/alsa/Front_Center.wav
Bug 2257806
Change-Id: I4d306ccef891282e96c300d90bad2a5b6efc9968
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1777096
Reviewed-by: Sameer Pujar <spujar@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
The Tegra186 ARAD driver lists the TEGRA186_ARAD_LANE_ENABLE register
as volatile implying that the register has status bits that may change
automatically. The ARAD Lane Enable register for both Tegra186 and
Tegra194 have 6 bits which are enable bits and no status bits.
Therefore, this register is not volatile and should not be listed as
volatile. Furthermore, during overnight stress testing, I sometimes see
one of the ARAD lanes become enabled randomly (by diff'ing the ALSA
state, as shown below, before and after running a test that is not using
ARAD). So far after making the ARAD Lane Enable register non-volatile
this has no longer been seen.
Now that jack-detection across suspend for the RT565x has been fixed in
the RT565x codec driver, we no longer need to call the
'trigger_jack_status_check' function from the Tegra machine driver.
Bug 2208756
Change-Id: I79961f9eb99c629eaace9ca35f8bb8a984c4dd38
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1758197
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
For Tegra194 Galen there can be multiple RT565x codecs if the audio
supermodule is connected and therefore, the RT565x sound card can
have multiple jacks. Add support for multiple jacks by allocating
the jack structure dynamically and creating the jack mixer control
dynamically.
Bug 2187533
Change-Id: Ia17cf4ddb1bb971e0973ea5b03f0c2cd6d9b1d5e
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1748233
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
For debug/testing purposes the Tegra audio machine driver creates a
'Jack-state' mixer control to allow the user to query/set the jack
state. Currently, the machine driver assumes that there is only one
jack, but on Galen there can be two jacks if the supermodule is used.
Therefore, add a helper function to create the 'Jack-state' mixer
control dynamically and append the codec prefix-name to the mixer
control name so that it has a unique name.
Bug 2187533
Change-Id: Iac4351c319944e3d2c01d053fce9ea390c3f8db1
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1748232
Reviewed-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
The function 'tegra_machine_ext_codec_init()' is used for initialising
the RT565x codec. However, it is called even if the RT565x codec is not
present which is not necessary. Therefore, only call this function when
an RT565x is present and simplify the machine driver by moving the code
to set the jack detect to this function. Finally, update the name of
the function to be RT565x specific.
This change is required for supporting boards such as Galen that can
have multiple codecs and hence multiple jacks because it simplifies
the code for configuring the jack.
Bug 2187533
Change-Id: I43518f09a114678861ddface5a59861bb62dc2d9
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1748230
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Linux jack detection for the generic Tegra machine driver is handled via
the sound soc-jack framework which registers the jack as an input device
with the kernel. Jack events are communicated to userspace via the
'jack_switch_types' definitions in 'sound/core/jack.c'.
Given that we no longer use the switch interface for communicating jack
events, simplify the mixer control code for the 'Jack-state' by aligning
the jack states with the 'snd_jack_types' enum and removing references
to the SWITCH_STATE definitions. This also allow us to completely remove
the jack notifier because we no longer need to convert the jack state
definitions.
Tested on Tegra186 Jetson-TX2 and Tegra194 Galen.
Bug 2187533
Change-Id: I61fdd32d79a1ec345578ebad57faf705e57343bd
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1746207
Reviewed-by: Dara Ramesh <dramesh@nvidia.com>
Reviewed-by: Viswanath L <viswanathl@nvidia.com>
Reviewed-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
The supermodule is not currently working on the Tegra194 Rey board.
The supermodule is detected correctly by the plugin manager, but the
card controls and DAPM widgets are not being populated correctly. The
reason the card controls and DAPM widgets are not being populated is
because Rey does not have an on-board RT5658 codec and so the codec
link 'rt565x-playback' does not exist. The codec link for using the
supermodule on Rey is 'rt565x-codec-sysclk-bclk1' and so update the
Tegra machine driver to populated the card controls and DAPM widgets
if this codec link is present.
Bug 200417361
Change-Id: I558146d8252da583e1ec86544a61a50fb567d77d
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1735932
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: Sameer Pujar <spujar@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
For mystique, after firmware is loaded on iM501, a message needs
to be sent to iM501 to enable hardware bypass mode when a raw
capture is required. This message should be sent after DMIC/PDM
clock is enabled and before actual capture starts (DMIC is enabled).
Since iM501 driver is a module, add a calllback function support.
iM501 driver registers a callback function on boot. DMIC driver
calls this function at the beginning of each capture session.
Bug 200404157
Change-Id: I49e81837232eec0393f4e8720f456a5d8137d945
Signed-off-by: Viraj Karandikar <vkarandikar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1725785
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Ravindra Lokhande <rlokhande@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
If audio playback/capture is running when the system suspends, then an
xrun event is reported by the kernel on entering suspend.
The problem is that userspace tasks are frozen before the kernel space
sound core is suspended. This means that the DMA is still running after
userspace has been frozen and hence the CPU has stopped updating the DMA
audio buffer. Hence, when the DMA reaches the end of the buffer an XRUN
event occurs. Depending on the sample rate the length of time before
this XRUN event occurs will vary and the worse case would be around 5ms
(for 192kHz with 16 channels @ 16-bits). There is no way to ensure that
the sound core is stopped within 5ms of freezing userspace and so the
only solution is to ensure that the sound core is suspend before
userspace by calling snd_soc_suspend() from the Linux PM prepare
handler.
Bug 2113333
Change-Id: Ie9da77ee99f74fded4b34cb4ba665da26e9c5e94
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1719611
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Add support for the E2614 supermodule on the Tegra194 Galen and Rey
platforms. Note that on Galen and Rey, because the 'aud_mclk' is not
available on the 40-pin header and the clock available on the 40-pin
header, 'extperiph4', cannot generate the frequencies needed for the
various sampling rates supported, we use the I2S bit-clock to drive
the RT565x codec PLL. Hence, the name of the DAI link for the codec
is 'rt565x-codec-sysclk-bclk1' to indicate that we need to configure
the codec to use BCLK1 to drive the codec's internal PLL.
Bug 2101552
Change-Id: Idd3acb6b3276e5598365ec5e655e75afc3e0bbde
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1670425
Reviewed-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Initialise snd_soc_dapm_update struct with NULL
to avoid kernel panic
Commit e411b0b5eb9b ("ASoC: dapm: Support second
register for DAPM control updates") introduced a
2nd register set into the snd_soc_dapm_update struct
and if the 'has_second_set' is not initialised
then it tries to access bogus register.
bug 200406253
Change-Id: Ic18ba2bb990c1c13f595305a05e4fc60a4b0baee
Signed-off-by: Dara Ramesh <dramesh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1697229
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: Jonathan Hunter <jonathanh@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Ravindra Lokhande <rlokhande@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Certain platform requirement needs all the dmic controller
clocks to be in phase due to external hardware requirement.So
keeping this in mind changing parent rate to dmic clk rate to make
sure there is not phase difference between dmic controller's output
clocks as the dmick controller divider value will be 1 and it's a bypass.
Bug 200373630
Change-Id: Ie0016fe01c130efe4c45132c50b0783e8ee6404b
Signed-off-by: Mohan Kumar <mkumard@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1686105
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Viraj Karandikar <vkarandikar@nvidia.com>
Tested-by: Viraj Karandikar <vkarandikar@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>
To validate I2S TDM modes (such as dsp-a and dsp-b) on the Jetson TX2
we can jumper wire the I2S1 interface to the I2S2 interface and use
one I2S interface as the master and one as the slave. However, to test
TDM modes we need to re-configure both the I2S framing mode (dsp-a,
dsp-b, etc) as well as the I2S bit-clock and frame-sync master/slave
settings from userspace. Add kcontrols for re-configuring the frame
mode and master mode settings for I2S1 and I2S2 on the Jetson TX2.
Bug 2046053
Bug 1993721
Bug 200356303
Change-Id: Ifab626e9c92bf8e80a1797ea8f0f56d2232e8073
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1676733
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: Sameer Pujar <spujar@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
On Tegra194 the PEQ gain and shift settings are not maintained across
AUD powergate transitions. Simply by reading the gain/shift settings
from userspace via amixer/tinymix continuously causing the AUD powergate
to power cycle the settings can be seen to continuously change.
Commit bc4166782c07 ("tegra-alt: Enable ahubram prog. in hw_params")
partially fix the problem by re-configuring the gain/shift settings to
their default settings each time the PEQ is in-use, however, even with
this change, if the user changes the settings, they are not preserved.
On Tegra186 the PEQ gain and shift settings are not preserved after
transitioning to low power states such as SC7. There is a difference
between the PMC on Tegra186 and Tegra194, such that Tegra194 no longer
supports SRAM retention for the AUD powergate which explains why the
device behave slightly differently.
To ensure that the PEQ gain and shift settings are preserved for all
devices add save and restore helpers and invoke them from the OPE
runtime-pm handlers.
Bug 2072802
Bug 200375657
Change-Id: Ic867bcfd355a50eba8ba538a9471722b824df3c5
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1679636
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Asha Talambedu <atalambedu@nvidia.com>
Reviewed-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
When using the ALSA 'alsactl' tool to save and restore mixer settings
the following of errors are observed for the following ARAD mixer
controls ...
alsactl: set_control:1461: Cannot write control '2:0:0:Lane1 Ratio Int:0' : Operation not permitted
alsactl: set_control:1461: Cannot write control '2:0:0:Lane1 Ratio Frac:0' : Operation not permitted
alsactl: set_control:1461: Cannot write control '2:0:0:Lane2 Ratio Int:0' : Operation not permitted
alsactl: set_control:1461: Cannot write control '2:0:0:Lane2 Ratio Frac:0' : Operation not permitted
alsactl: set_control:1461: Cannot write control '2:0:0:Lane3 Ratio Int:0' : Operation not permitted
alsactl: set_control:1461: Cannot write control '2:0:0:Lane3 Ratio Frac:0' : Operation not permitted
alsactl: set_control:1461: Cannot write control '2:0:0:Lane4 Ratio Int:0' : Operation not permitted
alsactl: set_control:1461: Cannot write control '2:0:0:Lane4 Ratio Frac:0' : Operation not permitted
alsactl: set_control:1461: Cannot write control '2:0:0:Lane5 Ratio Int:0' : Operation not permitted
alsactl: set_control:1461: Cannot write control '2:0:0:Lane5 Ratio Frac:0' : Operation not permitted
alsactl: set_control:1461: Cannot write control '2:0:0:Lane6 Ratio Int:0' : Operation not permitted
alsactl: set_control:1461: Cannot write control '2:0:0:Lane6 Ratio Frac:0' : Operation not permitted
The problem is that these mixer controls are defined using the
SOC_SINGLE_EXT macro which does not defined the access type. If the
access is not defined then it is presumed to be READWRITE (see
snd_ctl_new1) but there is no 'put' handler specified for these
controls. Hence, when alsactl attempts to restore these mixer controls
is fails with permission denied. Fix this by making these mixer
controls read-only.
Bug 2058979
Change-Id: I0abd0604257510f13ac768ab6a954554cab14dd6
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1675099
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
When using the ALSA 'alsactl' tool to save and restore mixer settings
the following type of errors are observed ...
alsactl: set_control:1461: Cannot write control '2:0:0:ADMAIF1 Channels:0' : Invalid argument
...
alsactl: set_control:1461: Cannot write control '2:0:0:AMX1 Output Channels:0' : Invalid argument
...
alsactl: set_control:1461: Cannot write control '2:0:0:RX1 Channels:0' : Invalid argument
...
alsactl: set_control:1461: Cannot write control '2:0:0:TX1 Channels:0' : Invalid argument
...
alsactl: set_control:1461: Cannot write control '2:0:0:TX5 Channels:0' : Invalid argument
...
alsactl: set_control:1461: Cannot write control '2:0:0:SFC1 Channels:0' : Invalid argument
...
alsactl: set_control:1461: Cannot write control '2:0:0:MVC1 Bits:0' : Invalid argument
These are just a few examples but these errors are seen for all
instances of the devices. The problem is that the 'put' handler for
the above mixer controls treats '0' as an invalid setting and so if
the default value is '0', then when we try to restore the setting to
'0' it fails because this is consider an 'invalid argument'. However,
'0' is not a invalid argument, it simply means that we are not
overriding this setting from userspace.
Furthermore, if someone happens to set an of the above mixer controls
to a non-zero value, then it is not possible to set it back to '0'
again.
Fix this by allowing userspace to set the above mixer controls to '0'.
Bug 2058979
Change-Id: Icd543c2ea956cb0690238d9a1f184c144a572029
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1675098
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
The Tegra DMIC 'Boost Gain' control shows an upper limit of '25600'.
nvidia@tegra-ubuntu:~$ amixer -c 1 sget "DMIC3 Boost Gain"
Simple mixer control 'DMIC3 Boost Gain',0
Capabilities: volume volume-joined
Playback channels: Mono
Capture channels: Mono
Limits: 0 - 25600
Mono: 0 [0%]
However, if a user attempts to set it to this the following error is
seen ...
[ 314.961362] tegra210-dmic tegra210-dmic.2: Boost Gain overflow
[ 314.970917] tegra210-dmic tegra210-dmic.2: Boost Gain overflow
Software only allows a max value of '25599' to be written to this
control and so fix this.
Bug 2069481
Change-Id: Ibdfa6f2c43e3855c72d2ec6fed6848f1395ccef8
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1673437
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-by: Viswanath L <viswanathl@nvidia.com>
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Overriding the device name for the Tegra RT565x machine driver is
preventing UDEV rules for Systemd and L4T from detecting the sound
card. The sysfs path for the sound card is
'/sys/devices/sound/sound/card1' but by changing the device name
the systemd-udev service is looking for the sound card under
'/sys/devices/tegra-snd-t186ref-mobile-rt565x/sound/card1' which
does not exist. This is seen by checking the systemd log ...
ubuntu@tegra-ubuntu:~$ sudo journalctl -b | grep rt565x
...
Feb 28 16:30:22 tegra-ubuntu systemd-udevd[2934]: error opening \
ATTR{/sys/devices/tegra-snd-t186ref-mobile-rt565x/sound/card1/controlC1/../uevent} \
for writing: No such file or directory
This prevents ...
1. The systemd udev rule '/lib/udev/rules.d/78-sound-card.rules'
from detecting the card and setting the udev enviroment variable
'SOUND_INITIALIZED' for the card. This in turn prevents pulseaudio
from seeing the card.
2. The L4T udev rule '/etc/udev/rules.d/90-alsa-asound-tegra.rules'
from detecting the card and setting the initial state of the
sound card.
Fix this by removing the code that overrides the device name for
the Tegra RT565x machine driver.
Bug 2019300
Bug 2067653
Bug 2067087
Bug 200382657
Change-Id: Ie371c1b3211cc4742d2e35c8e6976b01e1c23c31
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1666573
Reviewed-by: Sameer Pujar <spujar@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
