| Message ID | 1444669458-5588-2-git-send-email-wens@csie.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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 = <®_dc1sw>; display = <&lcdc0>; }; stdout-path = "display0";
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(-)