The device data for a given driver must be set before enabling
runtime-pm otherwise this could results in a crash if the runtime-pm
callback is called before the device data is set where it is expected
that the device data has been initialised.
Furthermore, most drivers will directly call the runtime-pm callback
to power-up the device if runtime-pm is not enabled in the kernel
config and so many drivers would crash if runtime-pm is not enabled.
Fix this by setting the device data early in the driver probe.
Bug 2478690
Change-Id: I5beb1607aa4715651cf4b9ac8e8068e7f8e3a2a7
Signed-off-by: Jonathan Hunter <jonathanh@nvidia.com>
(cherry picked from commit 9d656fcc96e85d38d120a430f83f2b734e19fe07)
Reviewed-on: https://git-master.nvidia.com/r/1991204
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>
This patch fixes compile errors for kernel 4.9. Kernel 4.9 has two
changes, struct snd_soc_codec_driver is modified and changed PCM
runtime array to a list from struct snd_soc_card.
Bug 1856400
Change-Id: I32d0d6d5d2cb79a3af27b81786d4e288d1be4d2d
Signed-off-by: Ravindra Lokhande <rlokhande@nvidia.com>
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
(cherry picked from commit 9528e52063467df94bc37fe2ad10d74a1c573848)
Reviewed-on: https://git-master.nvidia.com/r/1533079
GVS: Gerrit_Virtual_Submit
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
There are a couple issues with system suspend handling in the Tegra
ASoC codec drivers which are:
1. Most drivers the system suspend callback does nothing and this
means that if the codec device is active when suspend occurs then
the codec will not be suspended correctly. This has been seen to
cause system crashes in the I2S driver when the system is suspended
and resuming while audio playback is active.
2. The codec suspend handlers may be called twice when entering
suspend. Suspend handlers should only be called once, but currently
they are called twice; once by the PM core and once when the APE
power-domain is turned off (if it is on when suspend occurs).
Fix the above two problems by:
a). Adding proper system suspend and resume handlers for all codec
drivers, to suspend and resume the device if not runtime PM
suspended on entering suspend.
b). Remove the code to call the PM callbacks from the APE power-domain
code.
Finally, make the system suspend callbacks for these codec drivers
late suspend callbacks to ensure that the sound core has suspended
any on-going activity, before we attempt to suspend these codec
devices.
Bug 200275736
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: http://git-master/r/1488953
(cherry picked from commit 610f30df70a790733ed25a1be250e08cce19f368)
Change-Id: Ia0893c8373721ed16787a6c8243dca49f9672d34
Reviewed-on: https://git-master/r/1509428
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Linux runtime PM automatically handles the runtime resuming and
suspending of a parent device and therefore, it is not necessary
for a child device to explicitly runtime resume or suspend the
parent.
The various Tegra ASoC codec drivers explicitly runtime resume
and suspend the parent device from within their runtime PM callback
handler. This should not be necessary.
Furthermore, currently the various Tegra ASoC codec drivers are
not suspended correctly if active when system suspend occurs. During
system suspend it is common to directly call the runtime PM callbacks
to suspend and resume the device if active from the system suspend
callbacks. However, the APIs, pm_runtime_get/put(), cannot be called
during system suspend and so the runtime PM callbacks for these codec
drivers cannot be called from the context of the system suspend
callbacks.
Remove the calls to runtime resume and suspend the parent device from
the runtime PM callbacks for the various Tegra ASoC drivers. This will
allow us to fix suspending and resuming of the Tegra ASoC drivers
across system suspend.
Bug 200275736
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: http://git-master/r/1487805
(cherry picked from commit 60de6c68787ac100773a9f300d665266db25907c)
Change-Id: I67d429e779e84ad4c1978303ad08c4b89b95fb69
Reviewed-on: https://git-master/r/1509427
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Following updates:
- "input bit format" ctl to set RX CIF bit-width
- 100x scaling to "Vol" ctl for more granularity
- Fixes in mixer ctl "get" functions so that current value is read
- Fix in "Curve Type" ctl so that default volume gets set
Bug 1936284
Change-Id: Ib54b17266c7c3a3e9e42cab13195389c5fa1fbe7
Signed-off-by: Viswanath L <viswanathl@nvidia.com>
Reviewed-on: http://git-master/r/1497628
Reviewed-by: Automatic_Commit_Validation_User
GVS: Gerrit_Virtual_Submit
Reviewed-by: Ravindra Lokhande <rlokhande@nvidia.com>
Below are the hypothetical scenarios
- Drivers are in suspend state while reboot and PCM Open call from
userspace is received after driver shutdown [APE is power gated
already]
- PM domain handling doesn't ensure proper functionality after driver
shutdown is called
The change handles with the below fix
- ALSA PCM Open API first executes runtime resume of each driver.
So need to prevent any reg access in runtime resume of drivers.
- ALSA PCM Open executes ADMAIF startup after runtime resume of
each driver. If ADMAIF startup returns failure based on shutdown,
PCM Open operation will fail, this will break PCM Open path and
will ensure no further ALSA APIs/Callbacks are called.
Bug 200289815
Change-Id: Ia03e035569375f37ae4b0faa1a4593ce121d2354
Signed-off-by: Mohan Kumar <mkumard@nvidia.com>
Reviewed-on: http://git-master/r/1475208
(cherry picked from commit 3361e95850563f3009a428bb1c01941ed069a7b0)
Reviewed-on: http://git-master/r/1492664
Reviewed-by: svccoveritychecker <svccoveritychecker@nvidia.com>
Reviewed-by: Automatic_Commit_Validation_User
GVS: Gerrit_Virtual_Submit
Reviewed-by: Dipesh Gandhi <dipeshg@nvidia.com>
Reviewed-by: Ravindra Lokhande <rlokhande@nvidia.com>
Certain usecase requires different audio and client channels settings
inside ahub, so this needs to be handled with dedicated Channels mixer
control for each module.
This change will introduce channels mixer control and cif controls to
admaif,dmic,i2s and all other internal module is control with a single
channel control.
-Support mono channel SFC
-Support mono channel Mixer
-Cleanup drivers
Bug 1839027
Change-Id: Id997519ebdc9f518c83debc2d4cd58fde34e79b6
Signed-off-by: Mohan Kumar <mkumard@nvidia.com>
Reviewed-on: http://git-master/r/1258877
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
add check for context pointer before accessing it in suspend.
Also move setting of driver data at the end of probe function.
Change-Id: I5724ee810dd3ca409412aa21d61d35519b1432a3
Signed-off-by: Ravindra Lokhande <rlokhande@nvidia.com>
Reviewed-on: http://git-master/r/921743
GVS: Gerrit_Virtual_Submit
Reviewed-by: Sharad Gupta <sharadg@nvidia.com>
Reviewed-by: Dipesh Gandhi <dipeshg@nvidia.com>
Reviewed-by: Nitin Kumbhar <nkumbhar@nvidia.com>
- added mixer contols to set curve type,
cif channels and number of bits.
- modified volume control to increase/decrease
volume by 1dB for every step (for linear curve)
- changed default curve type to linear
- fixed check on number of channels
Bug 1694107
Change-Id: Ibad07ff2f61fef73e84f5193991b092afaf8db8c
Signed-off-by: Gaurav Tendolkar <gtendolkar@nvidia.com>
Reviewed-on: http://git-master/r/828227
Reviewed-on: http://git-master/r/834971
Reviewed-by: Automatic_Commit_Validation_User
GVS: Gerrit_Virtual_Submit
Reviewed-by: Nitin Pai <npai@nvidia.com>
1. Remove replicate bit and add fifo_size_downshift bit
in cif
2. Update mask value for dma_fifo_size, dma_fifo_start_addr
and dma_fifo_threshold in admaif driver
3. Update the copyright
4. Add run time check function to detect FPGA
Bug 1582514
Bug 1582510
Change-Id: I40a8172ebc3713ead4cb5764f291f04d548c7a75
Signed-off-by: Junghyun Kim <juskim@nvidia.com>
Reviewed-on: http://git-master/r/751602
Reviewed-by: Arun Shamanna Lakshmi <aruns@nvidia.com>
Tested-by: Arun Shamanna Lakshmi <aruns@nvidia.com>
- removed snd_soc_codec_set_cache_io function
- use snd_soc_kcontrol_codec instead of snd_kcontrol_chip
- use codec->component.val_bytes instead of codec->val_bytes
- use devm_ioremap_resource instead of devm_request_and_ioremap
- snd_soc_dapm_mux_update_power prototype is changed
Change-Id: Ieb699a0e8a12b341c6823337ef2deb0d99292240
Signed-off-by: Ravindra Lokhande <rlokhande@nvidia.com>
Set default register values for AHUB modules in regmap. This will
ensure after runtime suspend/resume AHUB register POR values
does not get reset to 0.
Bug 200039212
Change-Id: I38e4c04721450b7511404c0db2911b314b68a880
Signed-off-by: Sumit Bhattacharya <sumitb@nvidia.com>
Reviewed-on: http://git-master/r/603339
Set idle_bias_off for all t210 xbar modules to ensure module runtime
suspend/resume works when module is idle.
Ensure regcache is synced back to hardware during runtime resume so
that register content does not get lost if it is written during
runtime suspend state.
Add suspend APIs for all module to mark regcache dirty while device
goes into suspend to ensure register values does not get lost across
system suspend/resume.
Change-Id: I2828beeed859df4f8084dd70bbcde5ed62f2525c
Signed-off-by: Sumit Bhattacharya <sumitb@nvidia.com>
Reviewed-on: http://git-master/r/555028
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Arun Shamanna Lakshmi <aruns@nvidia.com>
GVS: Gerrit_Virtual_Submit
Instead of using duplicate clock of "d_audio" for all AHUB modules
get/put runtime pm reference of the parent module from runtime_pm
suspend/resume routine of all AHUB modules. This will ensure AHUB
xbar is up before other drivers tries to access any register. Also
it will ensure both d_audio and APE clocks are enabled when needed.
Bug 200042312
Change-Id: I0346728f15b135bb619de40fbd3fc440a5505940
Signed-off-by: Sumit Bhattacharya <sumitb@nvidia.com>
Reviewed-on: http://git-master/r/554863
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Arun Shamanna Lakshmi <aruns@nvidia.com>
GVS: Gerrit_Virtual_Submit
When using RBTREE cache, there can be allocations the first time
a register is accessed. This can cause an attempt to schedule while
atomic in the case that the regmap is using a spinlock. This can be
resolved by using a flat cache.
Bug 200041820
Change-Id: Id69592cd5fadbb5ad9ccfdbb1f184733a332512c
Signed-off-by: Arun Shamanna Lakshmi <aruns@nvidia.com>
Reviewed-on: http://git-master/r/552940