lkml.org 
[lkml]   [2021]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 1/3] ALSA: hda/tegra: Skip reset on BPMP devices
    From
    Date


    On 12/14/2021 7:26 PM, Dmitry Osipenko wrote:
    > 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.
    >>> 1. Enable display
    >>> 2. Play audio over HDMI
    >>> 3. 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.

    OK. I will prepare a v2 by just skipping the invalid reset for Tegra194.


    >
    >> 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.

    There seems to be multiple issues. I will work on this separately and
    send a separate series. Presently basic function is broken on Tegra194
    and will first send v2 to fix the regression. Thanks for review.

    \
     
     \ /
      Last update: 2021-12-20 11:32    [W:2.828 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site