[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ee648994-b296-2ac4-a676-ddcac463a428@gmail.com>
Date: Mon, 21 Feb 2022 23:10:37 +0300
From: Dmitry Osipenko <digetx@...il.com>
To: Mikko Perttunen <cyndis@...si.fi>,
Mikko Perttunen <mperttunen@...dia.com>,
thierry.reding@...il.com, jonathanh@...dia.com, joro@...tes.org,
will@...nel.org, robh+dt@...nel.org, robin.murphy@....com
Cc: linux-tegra@...r.kernel.org, dri-devel@...ts.freedesktop.org,
iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 8/9] drm/tegra: vic: Implement get_streamid_offset
21.02.2022 14:44, Mikko Perttunen пишет:
> On 2/19/22 20:54, Dmitry Osipenko wrote:
>> 19.02.2022 21:49, Dmitry Osipenko пишет:
>>> 18.02.2022 14:39, Mikko Perttunen пишет:
>>>> +static int vic_get_streamid_offset(struct tegra_drm_client *client)
>>>> +{
>>>> + struct vic *vic = to_vic(client);
>>>> + int err;
>>>> +
>>>> + err = vic_load_firmware(vic);
>>>
>>> You can't invoke vic_load_firmware() while RPM is suspended. Either
>>> replace this with RPM get/put or do something else.
>
> Why not, I'm not seeing any HW accesses in vic_load_firmware? Although
> it looks like it might race with the vic_load_firmware call in
> vic_runtime_resume which probably needs to be fixed.
It was not clear from the function's name that h/w is untouched, I read
"load" as "upload" and then looked at vic_runtime_resume(). I'd rename
vic_load_firmware() to vic_prepare_firmware_image().
And yes, technically lock is needed.
Powered by blists - more mailing lists