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>
The Tegra sound machine driver only set the TDM slots for DSP-A mode.
The TDM slots also need to be set for DSP-B mode so update the
machine driver to set the slots for DSP-B mode as well.
The 'tx_mask' and 'rx_mask' for for TDM modes is the same and will
always be the same. So simplify the code by having a single mask
variable.
Finally, remove unnecessary initialisation of 'err'.
Bug 2025176
Change-Id: I98630772432c2083bf4b4cf37bdfaf2f4c4514e5
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1656600
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>
To test internal loopback on any I2S interface using various different
sampling frequencies, it is necessary to be able to override the bit
clock ratio. However, rather than adding a kcontrol for each audio
link supported by the machine driver, add a global kcontrol that when
set will control the bit clock ratio for all I2S links.
Bug 2025176
Change-Id: I46ec949d36f0fe34967b9ed718d2189b539a1a37
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1602528
(cherry picked from commit 08afde21c1041db7d926b094cc9822402b73524f)
Reviewed-on: https://git-master.nvidia.com/r/1655983
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
The functions tegra_machine_get_bclk_ratio() and
tegra_machine_get_bclk_ratio_t18x() have a return type of unsigned int
but can return a negative error code on failure. This may cause users
of this function to get a very large bit clock ratio. Although it is
improbable that the bit clock ratio will ever be large enough to
overflow a signed integer, it is best to avoid changing the type of
the bit clock ratio variable. Therefore, return the bit clock ratio
via a pointer passed to the functions tegra_machine_get_bclk_ratio()
and tegra_machine_get_bclk_ratio_t18x().
Bug 2025176
Change-Id: Ia6e9a1ef68f53ebb594746f812de65a18269925f
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1655982
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
h2w switch state is updated for mic only jack detection. This is needed
for intel HDA header support, where only mic jack insertion is possible
and corresponding change is needed in WiredAccessoryManager.java for
android to switch routing to jack capture.
Following are the h2w switch state values,
0 - nothing connected
1 - both mic and hp jacks connected
2 - hp jack connected
3 - mic jack connected
Changed enum names for clarity.
Note: WiredAccessoryManager.java on Android uses these switch values for
identifying the jack type and hence these values should not be altered
independently.
Bug 200360770
Change-Id: I326b2704bdf68698ebad67ebab77ab07de743214
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1642236
Reviewed-by: Jonathan Hunter <jonathanh@nvidia.com>
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: Viswanath L <viswanathl@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Sharad Gupta <sharadg@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
This patch is being added for Android to avoid high suspend latency
resulting from commit bedf87fbcd537a5cc7b5d972c34a92cce9414f93. For
android, system cannot go to suspend when audio playback is running.
Thus issue mentioned in above commit is not applicable to Android.
CONFIG_ANDROID is used to selectively ignore suspend.
Bug 2061442
Change-Id: Id536920cb857e6d7a614d2a742012e17eac5f14f
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1659720
GVS: Gerrit_Virtual_Submit
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: Ravindra Lokhande <rlokhande@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
For I2S right-justified mode, the Tegra210 I2S driver assumes that
the bclk rate is 64*fs and the data is always 16-bit and therefore
sets the data offset to 16. However, the Tegra TRM states ...
"In RJ mode, data starts (r/2 – n) SCLKs after the LRCK edge
(offset = r/2 – n, where r = number of SCLKs per LRCK,
n = number of bits/sample)."
Therefore, the Tegra I2S driver should set the data position
depending on the bit-clock ratio setting and the data format
(16-bit or 32-bit) that is used.
Bug 2027259
Change-Id: Ic87b33aa19f956f4ac35c1444e4cd4148fe0ba4d
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1649565
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>
If audio capture/playback is active when the device enters system
suspend then the sound core does not correctly suspend capture/playback
and so when the system is resumed, audio capture/playback does not
continue. The problem is that the various DAI links have the property
'ignore_suspend' set and this causes the sound core to skip suspending
any active PCM streams and hence, the DMA controller is not
stopped/paused as it should be on entering suspend or started/resumed
as it should be on exiting suspend. Fix this by removing the
'ignore_suspend' properties for the various DAI links.
Bug 200363507
Change-Id: I80cd74e3bc86532c8920bd25326a31aec7396560
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1636471
Reviewed-on: https://git-master.nvidia.com/r/1636473
(cherry picked from commits 22a85acf56e34c369abed6f274a566594def78df
and 4de9dbcf256cad12387fb5307a855632543d3f66)
Reviewed-on: https://git-master.nvidia.com/r/1648638
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
codec suspend/resume does not happen when using intel HD header. To allow MIC
jack detection to work always, some supply widgets are kept On during probe.
This does not allow codec to perform suspend/resume cycle when system goes to
low power mode. So any jack plug/unplug during SC7 will not be detected, as
IRQs are disabled during this period.
Though codec resume path checks for the jack state, but the resume call does
not happen because of above mentioned reason. Hence in current patch, machine
driver can check the jack state during it resume callback.
Bug 200383009
Change-Id: I78dc982df1da633d8eec1cd48a1c9a00ab06bbff
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1649452
GVS: Gerrit_Virtual_Submit
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>
DT defines dap active and in-active states. The dap states were
added to dynamically program the pinmux registeres. If these
properites are missed in DT driver module can report warnings.
Reduced the log level to debug as these properties are not always
mandatory.
Bug 200376047
Change-Id: I48d7ab07e25af4ce8f12c8788582f9633d2d0671
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1643337
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
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>
When using ADMAIF9/10 channels for audio playback/capture on Tegra210,
the soft-reset of the ADMAIF is failing when playback finishes ...
Playing WAVE 'rec.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
[ 260.094969] tegra210-ape-admaif tegra210-admaif: Failed at ADMAIF0_TX sw reset
There are a couple issues here ...
1. The ADMAIF that fails is reported as 'ADMAIF0' although in the above
test ADMAIF9 is being used. This is purely an error in the driver
which is using 'dev-id' as the ADMAIF ID instead of 'dai->id'. Hence
the above error message is misleading.
2. The soft reset fails because the regmap configuration for the ADMAIF
registers on T210 is incorrect. In the function,
tegra210_admaif_volatile_reg(), only the ADMAIF registers between
offset 0x000 and 0x500 are considered volatile. The problem is that
the ADMAIF channel registers for T210 actually span 0x000-0x280 (for
RX) and 0x300-0x580 (for TX). This means that for TX, the ADMAIF9/10
channel registers are not considered volatile and hence, polling the
soft reset register is failing.
Fix the above two issues by correcting the ADMAIF ID reported for any
soft reset failures, and correct the address range for ADMAIF volatile
registers.
Bug 2037162
Change-Id: If22eba754ab4bf2bf5acc3c9da51388b7208c749
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1620448
(cherry picked from commit 1cd55ec115b7235343f09ec524a2c4cb2253ef33)
Reviewed-on: https://git-master.nvidia.com/r/1642335
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 error path of the Tegra210 rt565x machine driver does not
unregister the headset switch on failure.
Failure to unregister the headset switch on failure prevents causes
subsequent calls to register a switch to fail because one is already
registered. Hence, if the probe of the rt565x machine driver is
deferred, for example because the codec is not register yet, this
will cause subsequent probe attempts to fail because a switch is
already registered.
Fix the above issues by unregistering the switch in the error path
of the Tegra210 rt565x machine driver probe. Finally ensure the
switch is unregistered in the removal of the rt565x machine driver.
Bug 2044665
Change-Id: Iaeb6f7ae30b6fdff46b0a8679003674804399a99
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1634166
(cherry picked from commit 1a9cea0e8e97c5b042088d5988184c81db85ea6a)
Reviewed-on: https://git-master.nvidia.com/r/1642330
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>
DAP's which shared pins with other peripherals need
to have entry in dt for dynamic pinmux configuration.
All DAP's are not required to be configured dynamically.
Thus pinctrl for all dap's are not needed to be defined
in device-tree. For these cases state not defined should
not be treated as warning. Thus updating log level to dbg.
Bug 200377288
Change-Id: I8c222577d4bcdcfb7fde49a6c264c157baae28d1
Signed-off-by: Dipesh Gandhi <dipeshg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1633690
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: Uday Gupta <udayg@nvidia.com>
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Nitin Pai <npai@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
For t19x nvidia,tegra194-amx compatibility is used and the device name
is not properly populated and this results in sound card registration
failures. This change uses DRV_NAME and id, to populate the name. Same
approach can be extended later to other drivers as well.
Bug 200373426
Change-Id: I5c98c61be1044a6253b2b8e06b3f902ddbb4fe3a
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1619875
Reviewed-by: Automatic_Commit_Validation_User
GVS: Gerrit_Virtual_Submit
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: Ravindra Lokhande <rlokhande@nvidia.com>
Reviewed-by: Alex Waterman <alexw@nvidia.com>
Tested-by: Alex Waterman <alexw@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
This adds arad as part of xbar dai link, which acts as dummy link.
This is required for dapm path completion and cif configuration.
Since there will be conflicts, similar arad link code is removed
from auto machine drivers.
Bug 200364103
Change-Id: I55245c3d6f9efac0d3ea8ef9d485080e106adbac
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1609942
Reviewed-by: Dipesh Gandhi <dipeshg@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Mohan Kumar D <mkumard@nvidia.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
