[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1bfa2b93-301f-22ff-7208-b337b8f3820d@arm.com>
Date: Fri, 6 Sep 2019 15:45:11 +0100
From: Steven Price <steven.price@....com>
To: Mark Brown <broonie@...nel.org>
Cc: David Airlie <airlied@...ux.ie>,
Tomeu Vizoso <tomeu.vizoso@...labora.com>,
dri-devel <dri-devel@...ts.freedesktop.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm/panfrost: Fix regulator_get_optional() misuse
On 06/09/2019 11:55, Mark Brown wrote:
[...]
>>> However you're probably better off hiding all this stuff with the
>>> generic OPP code rather than open coding it - this already has much
>>> better handling for this, it supports voltage ranges rather than single
>>> voltages and optional regulators already. I'm not 100% clear why this
>>> is open coded TBH but I might be missing something, if there's some
>>> restriction preventing the generic code being used it seems like those
>>> sohuld be fixed.
>
>> To be honest I've no idea how to use the generic OPP code to do this. I
>> suspect the original open coding was cargo-culted from another driver:
>> the comments in the function look like they were lifted from
>> drivers/devfreq/rk3399_dmc.c. Any help tidying this up would be appreciated.
>
> Yes, there's a lot of cargo culting of bad regulator API usage in
> the DRM subsystem for some reason, I keep having to do these
> periodic sweeps and there's always stuff in there. I think a lot
> of it comes from BSP code that just gets dropped in without
> review and then cut'n'pasted but I've not figured out why DRM is
> so badly affected.
I've been working on tidying up the devfreq usage in Panfrost. From what
I can see your patch is correct and I just needed to work out how to fix
my DT.
Steve
Powered by blists - more mailing lists