14.12.2021 10:22, Sameer Pujar пишет: ...
How the reset behavior is different? At this point when HDA driver is loaded the HW is already reset during display ungate. What matters, during HDA driver load, is whether the HW is in predictable state or not and the answer is yes. So I am not sure what problem you are referring to. Question is, if BPMP already ensures this, then why driver needs to take care of it.
- Enable display
- Play audio over HDMI
- HDA hardware now is in dirty state
Why this would be a dirty state? It is rather a functional state. Isn't it? Power-domain is ON while all this happens.
In general state should be a functional, but we shouldn't assume that. There is always a possibility for a subtle bug in a driver that may put h/w into a bad state. Full hardware reset is encouraged by users.
Another point is, with present logic the reset is not applied for every runtime PM resume of HDA device, which is confusing. It depends on the state of 'chip->running' flag and I don't see this getting cleared anywhere. Would you say subsequent HDA playback happen under a dirty state?
This is a good point. There should be another potential problem in the HDA driver for newer SoCs because apparently we don't re-initialize HDA controller properly after runtime PM resume.
See hda_tegra_first_init() that is invoked only during driver probe, it configures FPCI_DBG_CFG_2 register on T194, which isn't done by hda_tegra_init(), and thus, this register may be in reset state after resume from RPM suspend. It should be a bug in the HDA driver that needs to be fixed.
On older SoCs: HDA resides in the APB power domain which could be disabled only across system suspend/resume. HDA is only clock-gated during runtime PM suspend.
On newer SoCs: HDA power state could be lost after RPM suspend/resume, depending on the state of display. I'm wondering whether HDMI playback works after DPMS on T194+, I assume this case was never tested properly.
It looks like it should be safe to reset HDA on runtime PM resume regardless of the chip->running, and thus, we could remove that check and reset HDA unconditionally. Will great if you could check/test and improve this in the driver.
I'm also wondering whether snd_power_change_state() should be moved into RPM callbacks and whether this function does anything practically useful on Tegra at all.