[lkml]   [2019]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] drm/panfrost: Fix regulator_get_optional() misuse
On 05/09/2019 09:21, Rob Herring wrote:
> +Steven
> On Wed, Sep 4, 2019 at 1:30 PM Mark Brown <> wrote:
>> The panfrost driver requests a supply using regulator_get_optional()
>> but both the name of the supply and the usage pattern suggest that it is
>> being used for the main power for the device and is not at all optional
>> for the device for function, there is no meaningful handling for absent
>> supplies. Such regulators should use the vanilla regulator_get()
>> interface, it will ensure that even if a supply is not described in the
>> system integration one will be provided in software.
> I guess commits e21dd290881b ("drm/panfrost: Enable devfreq to work
> without regulator") and c90f30812a79 ("drm/panfrost: Add missing check
> for pfdev->regulator")
> in -next should be reverted or partially reverted?

Ah, I didn't realise that regulator_get() will return a dummy regulator
if none is provided in the DT. In theory that seems like a nicer
solution to my two commits. However there's still a problem - the dummy
regulator returned from regulator_get() reports errors when
regulator_set_voltage() is called. So I get errors like this:

[ 299.861165] panfrost e82c0000.mali: Cannot set voltage 1100000 uV
[ 299.867294] devfreq devfreq0: dvfs failed with (-22) error

(And therefore the frequency isn't being changed)

Ideally we want a dummy regulator that will silently ignore any
regulator_set_voltage() calls.


 \ /
  Last update: 2019-09-05 11:38    [W:0.070 / U:8.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site