lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4c75fc51-fbfd-158f-a096-d4f178921ee3@nvidia.com>
Date:   Mon, 10 Feb 2020 12:22:56 +0000
From:   Jon Hunter <jonathanh@...dia.com>
To:     Sameer Pujar <spujar@...dia.com>,
        Dmitry Osipenko <digetx@...il.com>
CC:     <perex@...ex.cz>, <tiwai@...e.com>, <robh+dt@...nel.org>,
        <broonie@...nel.org>, <lgirdwood@...il.com>,
        <thierry.reding@...il.com>, <alsa-devel@...a-project.org>,
        <devicetree@...r.kernel.org>, <linux-tegra@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <sharadg@...dia.com>,
        <mkumard@...dia.com>, <viswanathl@...dia.com>,
        <rlokhande@...dia.com>, <dramesh@...dia.com>,
        <atalambedu@...dia.com>
Subject: Re: [PATCH v2 6/9] ASoC: tegra: add Tegra186 based DSPK driver


On 10/02/2020 11:15, Sameer Pujar wrote:
> 
> 
> On 2/7/2020 11:52 PM, Dmitry Osipenko wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> 07.02.2020 14:26, Sameer Pujar пишет:
>>>
>>> On 2/6/2020 10:45 PM, Dmitry Osipenko wrote:
>>>> External email: Use caution opening links or attachments
>>>>
>>>>
>>>> 30.01.2020 13:33, Sameer Pujar пишет:
>>>>> +static const struct dev_pm_ops tegra186_dspk_pm_ops = {
>>>>> +     SET_RUNTIME_PM_OPS(tegra186_dspk_runtime_suspend,
>>>>> +                        tegra186_dspk_runtime_resume, NULL)
>>>>> +     SET_LATE_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
>>>>> +                                  pm_runtime_force_resume)
>>>>> +};
>>>> Could you please explain why drivers need the "late" system sleep?
>>> It was done to ensure core drivers are suspended first and defer the
>>> codec driver suspend
>> Suspend order is opposite to the drivers registration order. If there is
>> no real problem with that, then you should use the default suspend
> 
>> level. Please don't try to fix a non-existent problems.
> 
> No. This was done specifically to allow sound core to first stop any
> ongoing audio activity during normal suspend and ensure a safe suspend
> of AHUB devices by doing a LATE suspend.

What Dmitry is saying is that if the DSPK driver is registered after the
sound core then we will not need to suspend in the late phase. The DSPK
device should only be registered once the sound core is loaded, because
otherwise we should fail to register it with the sound core. So I don't
think we need this to be late afterall.

Jon

-- 
nvpublic

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ