14.12.2021 10:22, Sameer Pujar пишет:
...
In general state should be a functional, but we shouldn't assume that.Why this would be a dirty state? It is rather a functional state. Isn'tHow the reset behavior is different? At this point when HDA driver is1. Enable display
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.
2. Play audio over HDMI
3. HDA hardware now is in dirty state
it? Power-domain is ON while all this happens.
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 everyThis is a good point. There should be another potential problem in the
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?
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.