Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1244930 > unrolled thread

[PATCH RFC 1/2] dt-bindings: simplefb: Support a list of regulator supply properties

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH RFC 1/2] dt-bindings: simplefb: Support a list of regulator supply properties Chen-Yu Tsai <wens@csie.org> - 2015-10-12 19:10 +0200
    Re: [PATCH RFC 1/2] dt-bindings: simplefb: Support a list of  regulator supply properties Mark Rutland <mark.rutland@arm.com> - 2015-10-12 19:20 +0200
      Re: [PATCH RFC 1/2] dt-bindings: simplefb: Support a list of  regulator supply properties Chen-Yu Tsai <wens@csie.org> - 2015-10-13 04:30 +0200
        Re: [PATCH RFC 1/2] dt-bindings: simplefb: Support a list of  regulator supply properties Hans de Goede <hdegoede@redhat.com> - 2015-10-13 09:10 +0200
          Re: [PATCH RFC 1/2] dt-bindings: simplefb: Support a list of  regulator supply properties Mark Brown <broonie@kernel.org> - 2015-10-14 12:40 +0200

#1244930 — [PATCH RFC 1/2] dt-bindings: simplefb: Support a list of regulator supply properties

The physical display tied to the framebuffer may have regulators
providing power to it, such as power for LCDs or interface conversion
chips.

The number of regulators in use may vary, but the regulator supply
binding can not be a list. Work around this by adding a "num-supplies"
property to communicate the number of supplies, and a list of 0 ~ N
"vinN-supply" properties for the actual regulator supply.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 .../devicetree/bindings/video/simple-framebuffer.txt       | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
index 4474ef6e0b95..0cc43e1be8b5 100644
--- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -47,10 +47,14 @@ Required properties:
   - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
 
 Optional properties:
-- clocks : List of clocks used by the framebuffer. Clocks listed here
-           are expected to already be configured correctly. The OS must
-           ensure these clocks are not modified or disabled while the
-           simple framebuffer remains active.
+- clocks : List of clocks used by the framebuffer.
+- num-supplies : The number of regulators used by the framebuffer.
+- vinN-supply : The N-th (from 0) regulator used by the framebuffer.
+
+  The above resources are expected to already be configured correctly.
+  The OS must ensure they are not modified or disabled while the simple
+  framebuffer remains active.
+
 - display : phandle pointing to the primary display hardware node
 
 Example:
@@ -68,6 +72,8 @@ chosen {
 		stride = <(1600 * 2)>;
 		format = "r5g6b5";
 		clocks = <&ahb_gates 36>, <&ahb_gates 43>, <&ahb_gates 44>;
+		num-supplies = <1>;
+		vin0-supply = <&reg_dc1sw>;
 		display = <&lcdc0>;
 	};
 	stdout-path = "display0";
-- 
2.5.3

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

[toc] | [next] | [standalone]

#1244936 — Re: [PATCH RFC 1/2] dt-bindings: simplefb: Support a list of regulator supply properties

On Tue, Oct 13, 2015 at 01:04:17AM +0800, Chen-Yu Tsai wrote:
> The physical display tied to the framebuffer may have regulators
> providing power to it, such as power for LCDs or interface conversion
> chips.
> 
> The number of regulators in use may vary, but the regulator supply
> binding can not be a list. Work around this by adding a "num-supplies"
> property to communicate the number of supplies, and a list of 0 ~ N
> "vinN-supply" properties for the actual regulator supply.

This is getting more complicated by the minute...

> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
>  .../devicetree/bindings/video/simple-framebuffer.txt       | 14 ++++++++++----
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> index 4474ef6e0b95..0cc43e1be8b5 100644
> --- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> @@ -47,10 +47,14 @@ Required properties:
>    - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
>  
>  Optional properties:
> -- clocks : List of clocks used by the framebuffer. Clocks listed here
> -           are expected to already be configured correctly. The OS must
> -           ensure these clocks are not modified or disabled while the
> -           simple framebuffer remains active.
> +- clocks : List of clocks used by the framebuffer.
> +- num-supplies : The number of regulators used by the framebuffer.
> +- vinN-supply : The N-th (from 0) regulator used by the framebuffer.

I don't see why you need num-supplies. Why not just try probing
vin${N}-supply until such a property isn't present in the DT?

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

[toc] | [prev] | [next] | [standalone]

#1245291 — Re: [PATCH RFC 1/2] dt-bindings: simplefb: Support a list of regulator supply properties

On Tue, Oct 13, 2015 at 1:10 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Tue, Oct 13, 2015 at 01:04:17AM +0800, Chen-Yu Tsai wrote:
>> The physical display tied to the framebuffer may have regulators
>> providing power to it, such as power for LCDs or interface conversion
>> chips.
>>
>> The number of regulators in use may vary, but the regulator supply
>> binding can not be a list. Work around this by adding a "num-supplies"
>> property to communicate the number of supplies, and a list of 0 ~ N
>> "vinN-supply" properties for the actual regulator supply.
>
> This is getting more complicated by the minute...

Yeah...

I considered "backlight" and "panel" properties, but that seems to need
more effort to parse. Regulators seemed easier.

>
>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> ---
>>  .../devicetree/bindings/video/simple-framebuffer.txt       | 14 ++++++++++----
>>  1 file changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>> index 4474ef6e0b95..0cc43e1be8b5 100644
>> --- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>> @@ -47,10 +47,14 @@ Required properties:
>>    - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
>>
>>  Optional properties:
>> -- clocks : List of clocks used by the framebuffer. Clocks listed here
>> -           are expected to already be configured correctly. The OS must
>> -           ensure these clocks are not modified or disabled while the
>> -           simple framebuffer remains active.
>> +- clocks : List of clocks used by the framebuffer.
>> +- num-supplies : The number of regulators used by the framebuffer.
>> +- vinN-supply : The N-th (from 0) regulator used by the framebuffer.
>
> I don't see why you need num-supplies. Why not just try probing
> vin${N}-supply until such a property isn't present in the DT?

That's doable. Though I'd add a hard limit on it. Does 16 seem reasonable?

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

[toc] | [prev] | [next] | [standalone]

#1245392 — Re: [PATCH RFC 1/2] dt-bindings: simplefb: Support a list of regulator supply properties

Hi,

On 13-10-15 04:22, Chen-Yu Tsai wrote:
> On Tue, Oct 13, 2015 at 1:10 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>> On Tue, Oct 13, 2015 at 01:04:17AM +0800, Chen-Yu Tsai wrote:
>>> The physical display tied to the framebuffer may have regulators
>>> providing power to it, such as power for LCDs or interface conversion
>>> chips.
>>>
>>> The number of regulators in use may vary, but the regulator supply
>>> binding can not be a list. Work around this by adding a "num-supplies"
>>> property to communicate the number of supplies, and a list of 0 ~ N
>>> "vinN-supply" properties for the actual regulator supply.
>>
>> This is getting more complicated by the minute...
>
> Yeah...
>
> I considered "backlight" and "panel" properties, but that seems to need
> more effort to parse. Regulators seemed easier.
>
>>
>>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>>> ---
>>>   .../devicetree/bindings/video/simple-framebuffer.txt       | 14 ++++++++++----
>>>   1 file changed, 10 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>>> index 4474ef6e0b95..0cc43e1be8b5 100644
>>> --- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>>> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>>> @@ -47,10 +47,14 @@ Required properties:
>>>     - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
>>>
>>>   Optional properties:
>>> -- clocks : List of clocks used by the framebuffer. Clocks listed here
>>> -           are expected to already be configured correctly. The OS must
>>> -           ensure these clocks are not modified or disabled while the
>>> -           simple framebuffer remains active.
>>> +- clocks : List of clocks used by the framebuffer.
>>> +- num-supplies : The number of regulators used by the framebuffer.
>>> +- vinN-supply : The N-th (from 0) regulator used by the framebuffer.
>>
>> I don't see why you need num-supplies. Why not just try probing
>> vin${N}-supply until such a property isn't present in the DT?

+1 for this.

> That's doable. Though I'd add a hard limit on it. Does 16 seem reasonable?

I would not add a hard limit to the binding, you can use a fixed array in
the code to make the code simpler. I would say 8 should be sufficient, since
the limit will only be in the code we can always bump it when we need to.

Regards,

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

[toc] | [prev] | [next] | [standalone]

#1246499 — Re: [PATCH RFC 1/2] dt-bindings: simplefb: Support a list of regulator supply properties

[Multipart message — attachments visible in raw view] — view raw

On Tue, Oct 13, 2015 at 09:08:46AM +0200, Hans de Goede wrote:
> On 13-10-15 04:22, Chen-Yu Tsai wrote:
> >On Tue, Oct 13, 2015 at 1:10 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> >>On Tue, Oct 13, 2015 at 01:04:17AM +0800, Chen-Yu Tsai wrote:

> >>>+- num-supplies : The number of regulators used by the framebuffer.
> >>>+- vinN-supply : The N-th (from 0) regulator used by the framebuffer.

> >>I don't see why you need num-supplies. Why not just try probing
> >>vin${N}-supply until such a property isn't present in the DT?

> +1 for this.

Even better would be to just enumerate all the properties on the node
and request anything with a FOO-supply name.  That way we can keep
using standard regulator bindings that name the supplies after their
actual names on the device.

> > That's doable. Though I'd add a hard limit on it. Does 16 seem
> > reasonable?

> I would not add a hard limit to the binding, you can use a fixed array in
> the code to make the code simpler. I would say 8 should be sufficient, since
> the limit will only be in the code we can always bump it when we need
> to.

Or just dynamically allocate the array and resize as needed if it starts
to get to be a problem.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web