07.12.2021 15:40, Sameer Pujar пишет:
You have a shared power domain. Since power domain can be turned off
On 12/7/2021 5:35 PM, Dmitry Osipenko wrote:
External email: Use caution opening links or attachmentsHow the reload case would be different? Can you please specify more
07.12.2021 15:00, Sameer Pujar пишет:
On 12/7/2021 3:52 PM, Dmitry Osipenko wrote:If you'll reload the driver module, then h/w won't be reset.
07.12.2021 09:32, Sameer Pujar пишет:Yes the power-domain is shared with display. As mentioned above,
HDA regression is recently reported on Tegra194 based platforms.The power domain is shared with the display, AFAICS. The point of reset
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.
is to bring h/w into predictable state. It doesn't make sense to me to
skip the reset.
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.
details if you are referring to a particular scenario?
only when nobody keeps domain turned on, you now making reset of HDA
controller dependent on the state of display driver.
Do you want to have
inconsistent h/w reset behaviour depending on the runtime state of
display driver?