Re: [PATCH 1/3] ALSA: hda/tegra: Skip reset on BPMP devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 12/7/2021 7:37 PM, Dmitry Osipenko wrote:
07.12.2021 15:40, Sameer Pujar пишет:

On 12/7/2021 5:35 PM, Dmitry Osipenko wrote:
External email: Use caution opening links or attachments


07.12.2021 15:00, Sameer Pujar пишет:
On 12/7/2021 3:52 PM, Dmitry Osipenko wrote:
07.12.2021 09:32, Sameer Pujar пишет:
HDA regression is recently reported on Tegra194 based platforms.
This happens because "hda2codec_2x" reset does not really exist
in Tegra194 and it causes probe failure. All the HDA based audio
tests fail at the moment. This underlying issue is exposed by
commit c045ceb5a145 ("reset: tegra-bpmp: Handle errors in BPMP
response") which now checks return code of BPMP command response.

The failure can be fixed by avoiding above reset in the driver,
but the explicit reset is not necessary for Tegra devices which
depend on BPMP. On such devices, BPMP ensures reset application
during unpowergate calls. Hence skip reset on these devices
which is applicable for Tegra186 and later.
The power domain is shared with the display, AFAICS. The point of reset
is to bring h/w into predictable state. It doesn't make sense to me to
skip the reset.
Yes the power-domain is shared with display. As mentioned above,
explicit reset in driver is not really necessary since BPMP is already
doing it during unpowergate stage. So the h/w is already ensured to be
in a good state.
If you'll reload the driver module, then h/w won't be reset.
How the reload case would be different? Can you please specify more
details if you are referring to a particular scenario?
You have a shared power domain. Since power domain can be turned off
only when nobody keeps domain turned on, you now making reset of HDA
controller dependent on the state of display driver.

I don't think that the state of display driver would affect. The HDA driver itself can issue unpowergate calls which in turn ensures h/w reset. If display driver is already runtime active, HDA driver runtime resume after this would be still fine since h/w reset is already applied during display runtime resume. Note that both HDA and display resets are connected to this power-domain and BPMP applies these resets during unpowergate.

Do you want to have
inconsistent h/w reset behaviour depending on the runtime state of
display driver?

Of course no.




[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux