On Mon, Sep 9, 2019 at 11:22 AM Steven Price wrote:
>
> On 09/09/2019 16:41, Rob Herring wrote:
> > On Fri, Sep 6, 2019 at 4:23 PM Steven Price wrote:
> >>
> >> On 04/09/2019 13:30, Mark Brown wrote:
> >>> The panfrost driver requests a supply using regulator_get_optional()
> >>> but both the nam
On 09/09/2019 16:41, Rob Herring wrote:
> On Fri, Sep 6, 2019 at 4:23 PM Steven Price wrote:
>>
>> On 04/09/2019 13:30, 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
On Fri, Sep 6, 2019 at 4:23 PM Steven Price wrote:
>
> On 04/09/2019 13:30, 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 i
On 04/09/2019 13:30, 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
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
On Fri, Sep 06, 2019 at 11:00:53AM +0100, Steven Price wrote:
> On 05/09/2019 17:34, Mark Brown wrote:
> > that information, I'd recommend eliminating individual OPPs if some are
> > supported or just never doing any regulator configuration if none can be
> > set.
> The problem on the Hikey960 is
(+CC Rob - I'm not sure why he was dropped)
On 05/09/2019 17:34, Mark Brown wrote:
> On Thu, Sep 05, 2019 at 02:02:38PM +0100, Steven Price wrote:
>> On 05/09/2019 13:40, Mark Brown wrote:
>
>>> Is that safe? You can't rely on being able to change voltages even if
>>> there's a physical regulato
On Thu, Sep 05, 2019 at 02:02:38PM +0100, Steven Price wrote:
> On 05/09/2019 13:40, Mark Brown wrote:
> > Is that safe? You can't rely on being able to change voltages even if
> > there's a physical regulator available, system constraints or the
> > results of sharing the regulator with other us
On 05/09/2019 15:02, Steven Price wrote:
> On 05/09/2019 13:40, Mark Brown wrote:
>> On Thu, Sep 05, 2019 at 10:37:53AM +0100, Steven Price wrote:
>>
>>> 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
>>>
On 05/09/2019 13:40, Mark Brown wrote:
> On Thu, Sep 05, 2019 at 10:37:53AM +0100, Steven Price wrote:
>
>> 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 sti
On Thu, Sep 05, 2019 at 10:37:53AM +0100, Steven Price wrote:
> 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
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 de
+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 f
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. Su
14 matches
Mail list logo
