Mailing List Archive: Linux: Kernel

[RFC][PATCH v3 1/3] runtime interpreted power sequences

1 2 3

View All

Index | Next | Previous | View Threaded

broonie at opensource

Aug 2, 2012, 11:11 AM

Post #51 of 56 (60 views)
Permalink

Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences [In reply to]

On Thu, Aug 02, 2012 at 10:21:57AM +0200, Thierry Reding wrote:
> On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex Courbot wrote:

> > The problem is, how do we turn these phandles into the resource of
> > interest. The type of the resource can be infered by the name of the
> > property. The hard part is resolving the resource from the phandle -
> > it seems like the API just does not allow to do this. GPIO has
> > of_get_named_gpio, but AFAIK there are no equivalent for regulator
> > consumer and PWM: the only way to use the DT with them is through
> > get_regulator and get_pwm which work at the device level.

> > Or is there a way that I overlooked?

> No, you are right. Perhaps we should add exported functions that do the
> equivalent of of_pwm_request() or the regulator_dev_lookup() and
> of_get_regulator() pair.

I missed some of the earlier bits of the thread here but why can't we do
device based lookups?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

acourbot at nvidia

Aug 2, 2012, 6:15 PM

Post #52 of 56 (61 views)
Permalink

Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences [In reply to]

On Fri 03 Aug 2012 03:11:12 AM JST, Mark Brown wrote:
> On Thu, Aug 02, 2012 at 10:21:57AM +0200, Thierry Reding wrote:
>> On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex Courbot wrote:
>
>>> The problem is, how do we turn these phandles into the resource of
>>> interest. The type of the resource can be infered by the name of the
>>> property. The hard part is resolving the resource from the phandle -
>>> it seems like the API just does not allow to do this. GPIO has
>>> of_get_named_gpio, but AFAIK there are no equivalent for regulator
>>> consumer and PWM: the only way to use the DT with them is through
>>> get_regulator and get_pwm which work at the device level.
>
>>> Or is there a way that I overlooked?
>
>> No, you are right. Perhaps we should add exported functions that do the
>> equivalent of of_pwm_request() or the regulator_dev_lookup() and
>> of_get_regulator() pair.
>
> I missed some of the earlier bits of the thread here but why can't we do
> device based lookups?

That is because the phandles would not be properties of the device node
but rather of its sub-nodes:

backlight {
compatible = "pwm-backlight";
...
power-on-sequence {
step@0 {
regulator = <&backlight_reg>;
enable;
};

So here simply using regulator_get on the backlight device would not work.

Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

broonie at opensource

Aug 4, 2012, 7:12 AM

Post #53 of 56 (51 views)
Permalink

Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences [In reply to]

On Fri, Aug 03, 2012 at 10:15:46AM +0900, Alex Courbot wrote:
> On Fri 03 Aug 2012 03:11:12 AM JST, Mark Brown wrote:

> >I missed some of the earlier bits of the thread here but why can't we do
> >device based lookups?

> That is because the phandles would not be properties of the device
> node but rather of its sub-nodes:

> backlight {
> compatible = "pwm-backlight";
> ...
> power-on-sequence {
> step@0 {
> regulator = <&backlight_reg>;
> enable;
> };
>

> So here simply using regulator_get on the backlight device would not work.

Ah, right. DT isn't being terribly helpful here... I think the thing
I'd expect to work here is that you have a reference back to the supply
property of the backlight device rather than direct to the regulator so
you end up writing "enable supply X" rather than "enable regulator X".

Not quite sure how exactly you'd accomplish that - I guess if
regulator_get() would recursively follow phandles until it hits a node
that'd do the trick?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

acourbot at nvidia

Aug 5, 2012, 7:27 PM

Post #54 of 56 (47 views)
Permalink

Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences [In reply to]

On 08/04/2012 11:12 PM, Mark Brown wrote:
> On Fri, Aug 03, 2012 at 10:15:46AM +0900, Alex Courbot wrote:
>> On Fri 03 Aug 2012 03:11:12 AM JST, Mark Brown wrote:
>
>>> I missed some of the earlier bits of the thread here but why can't we do
>>> device based lookups?
>
>> That is because the phandles would not be properties of the device
>> node but rather of its sub-nodes:
>
>> backlight {
>> compatible = "pwm-backlight";
>> ...
>> power-on-sequence {
>> step@0 {
>> regulator = <&backlight_reg>;
>> enable;
>> };
>>
>
>> So here simply using regulator_get on the backlight device would not work.
>
> Ah, right. DT isn't being terribly helpful here... I think the thing
> I'd expect to work here is that you have a reference back to the supply
> property of the backlight device rather than direct to the regulator so
> you end up writing "enable supply X" rather than "enable regulator X".
>
> Not quite sure how exactly you'd accomplish that - I guess if
> regulator_get() would recursively follow phandles until it hits a node
> that'd do the trick?

Do you mean that regulator_get() would parse sub-nodes looking for a
match? That seems rather dangerous and error-prone, especially if one
has actual devices within the sub-nodes - their regulators could be
stolen by the parent device.

I think we only have two choices for this:

1) Stick to the scheme where resources are declared at the device level,
such as they can be referenced by name in the sub-nodes (basically what
I did in this patch):

backlight {
compatible = "pwm-backlight";
...
backlight-supply = <&backlight_reg>;

power-on-sequence {
step@0 {
regulator = "backlight";
enable;
};

This would translate by a get_regulator(dev, "backlight") in the code
which would be properly resolved.

2) Export a lower-level DT API for resolving phandles directly from a
property, similar to of_get_named_gpio. We would then have
of_get_named_regulator and of_get_named_pwm.

If 2) is deemed acceptable, then I think we should go for it as it would
provide the most compact and readable DT syntax. Otherwise 1) is still
acceptable IMHO, as it should at least make sense to people already
familiar with how the DT works.

Opinions from DT experts?

Alex.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

swarren at wwwdotorg

Aug 6, 2012, 9:16 AM

Post #55 of 56 (52 views)
Permalink

Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences [In reply to]

On 08/05/2012 08:27 PM, Alex Courbot wrote:
> On 08/04/2012 11:12 PM, Mark Brown wrote:
>> On Fri, Aug 03, 2012 at 10:15:46AM +0900, Alex Courbot wrote:
>>> On Fri 03 Aug 2012 03:11:12 AM JST, Mark Brown wrote:
>>
>>>> I missed some of the earlier bits of the thread here but why can't
>>>> we do
>>>> device based lookups?
...
> I think we only have two choices for this:
>
> 1) Stick to the scheme where resources are declared at the device level,
> such as they can be referenced by name in the sub-nodes (basically what
> I did in this patch):
>
> backlight {
> compatible = "pwm-backlight";
> ...
> backlight-supply = <&backlight_reg>;
>
> power-on-sequence {
> step@0 {
> regulator = "backlight";
> enable;
> };
>
> This would translate by a get_regulator(dev, "backlight") in the code
> which would be properly resolved.

Yes, upon reflection, that scheme does make sense. I withdraw the
comments I made re: whether it'd be better to just stick the phandles
into the steps.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

acourbot at nvidia

Aug 6, 2012, 10:10 PM

Post #56 of 56 (50 views)
Permalink

Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences [In reply to]

On 08/07/2012 01:16 AM, Stephen Warren wrote:
> On 08/05/2012 08:27 PM, Alex Courbot wrote:
>> On 08/04/2012 11:12 PM, Mark Brown wrote:
>>> On Fri, Aug 03, 2012 at 10:15:46AM +0900, Alex Courbot wrote:
>>>> On Fri 03 Aug 2012 03:11:12 AM JST, Mark Brown wrote:
>>>
>>>>> I missed some of the earlier bits of the thread here but why can't
>>>>> we do
>>>>> device based lookups?
> ...
>> I think we only have two choices for this:
>>
>> 1) Stick to the scheme where resources are declared at the device level,
>> such as they can be referenced by name in the sub-nodes (basically what
>> I did in this patch):
>>
>> backlight {
>> compatible = "pwm-backlight";
>> ...
>> backlight-supply = <&backlight_reg>;
>>
>> power-on-sequence {
>> step@0 {
>> regulator = "backlight";
>> enable;
>> };
>>
>> This would translate by a get_regulator(dev, "backlight") in the code
>> which would be properly resolved.
>
> Yes, upon reflection, that scheme does make sense. I withdraw the
> comments I made re: whether it'd be better to just stick the phandles
> into the steps.

Right - having the phandles directly in the sequences has its merits,
but logically speaking resources are related to a device, so this
declarative approach is probably closer to reality anyway.

I will revise the patch according to all the feedback received and
submit a new version soon.

Thanks,
Alex.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

1 2 3

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads