Initial register settings in Device Tree?

Initial register settings in Device Tree?

[Noralf Trønnes]

I have some framebuffer drivers [1] for LCD controllers with onboard 
RAM, targeted at small displays (<10").
I'm now going to rewrite these drivers from scratch and add DT support.

The controllers have many registers that controls various parameters to 
match the attached panel.
Since a controller can be used with a whole lot of panels, I wonder if I 
can put the register initialization sequence in the Device Tree?

Currently I have a module parameter: init=, which can override the 
default init sequence in the driver if needed.
A challenge is that the register depth often varies among the registers 
(the number of values a register holds). Some also doesn't have a value, 
they're called commands.
This has led me to add markers in my module parameter:
Sainsmart 1.8" (ST7735R)
init=-1,0x01,-2,150,-1,0x11,-2,500,-1,0xB1,0x01,0x2C,0x2D,-1,0xB2,0x01,0x2C,0x2D,-1,0xB3,0x01,0x2C,0x2D,0x01,0x2C,0x2D,-1,0xB4,0x07,-1,0xC0,0xA2,0x02,0x84,-1,0xC1,0xC5,-1,0xC2,0x0A,0x00,-1,0xC3,0x8A,0x2A,-1,0xC4,0x8A,0xEE,-1,0xC5,0x0E,-1,0x20,-1,0x36,0xC0,-1,0x3A,0x05,-1,0xE0,0x0f,0x1a,0x0f,0x18,0x2f,0x28,0x20,0x22,0x1f,0x1b,0x23,0x37,0x00,0x07,0x02,0x10,-1,0xE1,0x0f,0x1b,0x0f,0x17,0x33,0x2c,0x29,0x2e,0x30,0x30,0x39,0x3f,0x00,0x07,0x03,0x10,-1,0x29,-2,100,-1,0x13,-2,10,-3

Markers:
-1: next value is a register, followed by zero or more values
-2: next value is a delay in milliseconds
-3: end marker

 From reading a post by Grant Likely, I understand that 
write-delay-write in the DT is out of the question.
I believe delays mostly have to do with power state transitions and 
display on/off anyway, so I assume it can be handle by the driver for 
all panels.

I see two possibilities:
* add a special marker value to separate the registers, as I do now
* add a flag to indicate a register number. So far I've only seen 8 and 
16-bit register number widths: register 20h could thus be written as 
10000020, 1000020, 100020 or 10020

Example (skipped state changes from previous example):
<100B1 01 2C 2D
  100B2 01 2C 2D
  100B3 01 2C 2D 01 2C 2D
  100B4 07 C0 A2 02 84
  100C1 C5 C2 0A 00
  100C3 8A 2A
  100C4 8A EE
  100C5 0E
  10020
  10036 C0
  1003A 05
  100E0 0f 1a 0f 18 2f 28 20 22 1f 1b 23 37 00 07 02 10
  100E1 0f 1b 0f 17 33 2c 29 2e 30 30 39 3f 00 07 03 10>

Is this a viable solution?



Noralf Tronnes


[1] https://github.com/notro/fbtft

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Initial register settings in Device Tree?

[Arnd Bergmann]

On Sunday 22 June 2014 19:37:56 Noralf Trønnes wrote:
> 
> I see two possibilities:
> * add a special marker value to separate the registers, as I do now
> * add a flag to indicate a register number. So far I've only seen 8 and 
> 16-bit register number widths: register 20h could thus be written as 
> 10000020, 1000020, 100020 or 10020
> 
> Example (skipped state changes from previous example):
> <100B1 01 2C 2D
>   100B2 01 2C 2D
>   100B3 01 2C 2D 01 2C 2D
>   100B4 07 C0 A2 02 84
>   100C1 C5 C2 0A 00
>   100C3 8A 2A
>   100C4 8A EE
>   100C5 0E
>   10020
>   10036 C0
>   1003A 05
>   100E0 0f 1a 0f 18 2f 28 20 22 1f 1b 23 37 00 07 02 10
>   100E1 0f 1b 0f 17 33 2c 29 2e 30 30 39 3f 00 07 03 10>
> 
> Is this a viable solution?

We normally use high-level descriptions of the timings that the driver
then converts into register-level settings. See
Documentation/devicetree/bindings/video/display-timing.txt and
other files in that directory for how existing drivers handle this.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Initial register settings in Device Tree?

[Noralf Trønnes]

Den 22.06.2014 20:18, skrev Arnd Bergmann:
> On Sunday 22 June 2014 19:37:56 Noralf Trønnes wrote:
>> I see two possibilities:
>> * add a special marker value to separate the registers, as I do now
>> * add a flag to indicate a register number. So far I've only seen 8 and
>> 16-bit register number widths: register 20h could thus be written as
>> 10000020, 1000020, 100020 or 10020
>>
>> Example (skipped state changes from previous example):
>> <100B1 01 2C 2D
>>    100B2 01 2C 2D
>>    100B3 01 2C 2D 01 2C 2D
>>    100B4 07 C0 A2 02 84
>>    100C1 C5 C2 0A 00
>>    100C3 8A 2A
>>    100C4 8A EE
>>    100C5 0E
>>    10020
>>    10036 C0
>>    1003A 05
>>    100E0 0f 1a 0f 18 2f 28 20 22 1f 1b 23 37 00 07 02 10
>>    100E1 0f 1b 0f 17 33 2c 29 2e 30 30 39 3f 00 07 03 10>
>>
>> Is this a viable solution?
> We normally use high-level descriptions of the timings that the driver
> then converts into register-level settings. See
> Documentation/devicetree/bindings/video/display-timing.txt and
> other files in that directory for how existing drivers handle this.
>
> 	Arnd
>
OK, that takes care of the timings. But what about power control, and 
gamma registers?

The power registers usually have bitfields that map to voltages, factors 
(0.7x, 1x,..) and levels (low,medium,high).

Should all these bitfiels have their own property in DT?
For some controllers this would be 20+ properties.

Should the properties have the same name as the register and bitfield 
from the datasheet?
st7735r,pwctr1-avdd
st7735r,pwctr1-vrhp
st7735r,pwctr1-vrhn
st7735r,pwctr1-mode

Should the value map directly to the bitfield or should a string be used?
st7735r,pwctr1-avdd = <6> /* 5.1v - Power pin for analog circuits */
st7735r,pwctr1-avdd = "5.1"

Or should each register have it's own property?
st7735r,pwctr1 = <C5 C2 0A 00>


The gamma registers have several values that control a resistor network 
that sets grayscale values.
Would this suffice?
st7735r,gamma-positive = <0f 1a 0f 18 2f 28 20 22 1f 1b 23 37 00 07 02 10>
st7735r,gamma-negative = <0f 1b 0f 17 33 2c 29 2e 30 30 39 3f 00 07 03 10>


Usually when buying these displays, they come with an initialization 
sequence.
Having register values in the DT, a user will be up and running in 
minutes with a new display.
If one has to read the datasheet and map the register values to 
bitfields and properties, it takes a lot of time and not the least, it's 
error prone.


Noralf.


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Initial register settings in Device Tree?

[Arnd Bergmann]

On Sunday 22 June 2014 21:27:52 Noralf Trønnes wrote:
> Den 22.06.2014 20:18, skrev Arnd Bergmann:
> > On Sunday 22 June 2014 19:37:56 Noralf Trønnes wrote:
> >> I see two possibilities:
> >> * add a special marker value to separate the registers, as I do now
> >> * add a flag to indicate a register number. So far I've only seen 8 and
> >> 16-bit register number widths: register 20h could thus be written as
> >> 10000020, 1000020, 100020 or 10020
> >>
> >> Example (skipped state changes from previous example):
> >> <100B1 01 2C 2D
> >>    100B2 01 2C 2D
> >>    100B3 01 2C 2D 01 2C 2D
> >>    100B4 07 C0 A2 02 84
> >>    100C1 C5 C2 0A 00
> >>    100C3 8A 2A
> >>    100C4 8A EE
> >>    100C5 0E
> >>    10020
> >>    10036 C0
> >>    1003A 05
> >>    100E0 0f 1a 0f 18 2f 28 20 22 1f 1b 23 37 00 07 02 10
> >>    100E1 0f 1b 0f 17 33 2c 29 2e 30 30 39 3f 00 07 03 10>
> >>
> >> Is this a viable solution?
> > We normally use high-level descriptions of the timings that the driver
> > then converts into register-level settings. See
> > Documentation/devicetree/bindings/video/display-timing.txt and
> > other files in that directory for how existing drivers handle this.
> >
> > 	Arnd
> >
> OK, that takes care of the timings. But what about power control, and 
> gamma registers?
>
> The power registers usually have bitfields that map to voltages, factors 
> (0.7x, 1x,..) and levels (low,medium,high).
> 
> Should all these bitfiels have their own property in DT?
> For some controllers this would be 20+ properties.

In some cases, it can make sense to group several values into one
multi-cell property.

> Should the properties have the same name as the register and bitfield 
> from the datasheet?
> st7735r,pwctr1-avdd
> st7735r,pwctr1-vrhp
> st7735r,pwctr1-vrhn
> st7735r,pwctr1-mode
> 
> Should the value map directly to the bitfield or should a string be used?
> st7735r,pwctr1-avdd = <6> /* 5.1v - Power pin for analog circuits */
> st7735r,pwctr1-avdd = "5.1"
> 
> Or should each register have it's own property?
> st7735r,pwctr1 = <C5 C2 0A 00>

Each user-serviceable property should be abstract and use the normal
units that you'd expect to see in a data sheet: milivolts, nanoseconds,
etc. See if some other display controller already has picked names
for these properties, then use the same. If nobody has done this
before, try to use property names that would also make sense on a
different controller. If we get a couple of these, we can split out
the property parsing code into a separate helper module.

> The gamma registers have several values that control a resistor network 
> that sets grayscale values.
> Would this suffice?
> st7735r,gamma-positive = <0f 1a 0f 18 2f 28 20 22 1f 1b 23 37 00 07 02 10>
> st7735r,gamma-negative = <0f 1b 0f 17 33 2c 29 2e 30 30 39 3f 00 07 03 10>
>
> Usually when buying these displays, they come with an initialization 
> sequence.
> Having register values in the DT, a user will be up and running in 
> minutes with a new display.
> If one has to read the datasheet and map the register values to 
> bitfields and properties, it takes a lot of time and not the least, it's 
> error prone.

Can you describe how this works for arbitrary combinations of controllers
and displays? Are the initialization sequences specific to some controller?

An alternative to listing all the settings in DT might be to have a list
of supported displays in the controller driver and pick the display
by name, but that only works if there are a small number of possible
displays that can be connected to each controller.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Initial register settings in Device Tree?

[Noralf Tronnes]

Den 23.06.2014 15:38, skrev Arnd Bergmann:
> On Sunday 22 June 2014 21:27:52 Noralf Trønnes wrote:
>> Den 22.06.2014 20:18, skrev Arnd Bergmann:
>>> On Sunday 22 June 2014 19:37:56 Noralf Trønnes wrote:
>>>> I see two possibilities:
>>>> * add a special marker value to separate the registers, as I do now
>>>> * add a flag to indicate a register number. So far I've only seen 8 and
>>>> 16-bit register number widths: register 20h could thus be written as
>>>> 10000020, 1000020, 100020 or 10020
>>>>
>>>> Example (skipped state changes from previous example):
>>>> <100B1 01 2C 2D
>>>>     100B2 01 2C 2D
>>>>     100B3 01 2C 2D 01 2C 2D
>>>>     100B4 07 C0 A2 02 84
>>>>     100C1 C5 C2 0A 00
>>>>     100C3 8A 2A
>>>>     100C4 8A EE
>>>>     100C5 0E
>>>>     10020
>>>>     10036 C0
>>>>     1003A 05
>>>>     100E0 0f 1a 0f 18 2f 28 20 22 1f 1b 23 37 00 07 02 10
>>>>     100E1 0f 1b 0f 17 33 2c 29 2e 30 30 39 3f 00 07 03 10>
>>>>
>>>> Is this a viable solution?
>>> We normally use high-level descriptions of the timings that the driver
>>> then converts into register-level settings. See
>>> Documentation/devicetree/bindings/video/display-timing.txt and
>>> other files in that directory for how existing drivers handle this.
>>>
>>> 	Arnd
>>>
>> OK, that takes care of the timings. But what about power control, and
>> gamma registers?
>>
>> The power registers usually have bitfields that map to voltages, factors
>> (0.7x, 1x,..) and levels (low,medium,high).
>>
>> Should all these bitfiels have their own property in DT?
>> For some controllers this would be 20+ properties.
> In some cases, it can make sense to group several values into one
> multi-cell property.
>
>> Should the properties have the same name as the register and bitfield
>> from the datasheet?
>> st7735r,pwctr1-avdd
>> st7735r,pwctr1-vrhp
>> st7735r,pwctr1-vrhn
>> st7735r,pwctr1-mode
>>
>> Should the value map directly to the bitfield or should a string be used?
>> st7735r,pwctr1-avdd = <6> /* 5.1v - Power pin for analog circuits */
>> st7735r,pwctr1-avdd = "5.1"
>>
>> Or should each register have it's own property?
>> st7735r,pwctr1 = <C5 C2 0A 00>
> Each user-serviceable property should be abstract and use the normal
> units that you'd expect to see in a data sheet: milivolts, nanoseconds,
> etc. See if some other display controller already has picked names
> for these properties, then use the same. If nobody has done this
> before, try to use property names that would also make sense on a
> different controller. If we get a couple of these, we can split out
> the property parsing code into a separate helper module.
I found this example that uses regulators to specify voltage:
Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
- dsi: display serial interface
- avdd-dsi-supply: phandle of a supply that powers the DSI controller

If I should use regulators, I would need to have a controller driver and
a panel driver, so to avoid that I just specify the millivolt/factor 
directly.
This way the DT controller node will contain the panel description.
(I could add a generic panel driver if regulators is the way to go)

This is how the setup could be for a ST7735R controller:

st7735r,avdd-millivolt = <4900> /* 4.9v */
st7735r,vrhp-millivolt = <4600> /* 4.6v */
st7735r,vrhn-millivolt = <4600> /* -4.6 */
st7735r,pwr-mode = <2> /* 0=2x, 1=3x, 2=auto (the datasheet doesn't say 
what this is) */
st7735r,vgh25-millivolt = <2400>
st7735r,vgh-factor = <1> /* 0=2*AVDD+VGH25, 1=3*AVDD, 2=3*AVDD+VGH25 */
st7735r,vgl-millivolt = <10000> /* -10v */
/* ap,sap,pwr-freqX have to do with power consumption vs. image quality. */
st7735r,ap-factor = <1> /* Current in source driver op-amp: 0=small, 
1=medium low, 2=medium, 3=medium high, 4=large */
st7735r,sap-factor = <0> /* Current in source driver op-amp: 0=small, 
1=medium low, 2=medium, 3=medium high, 4=large */
/* Booster circuit Step-up cycle in Normal mode/ full colors */
st7735r,pwr-freq1-factor-normal = <1> /* BCLK/{1, 1.5, 2, 4} */
st7735r,pwr-freq2-factor-normal = <1>
st7735r,pwr-freq3-factor-normal = <1>
st7735r,pwr-freq4-factor-normal = <1>
st7735r,vcom-millivolt = <775> /* -0.775v */
st7735r,rotation = <0> /* Display rotation: 0,90,180,270 */
st7735r,gamma-positive = <0f 1a 0f 18 2f 28 20 22 1f 1b 23 37 00 07 02 10>
st7735r,gamma-negative = <0f 1b 0f 17 33 2c 29 2e 30 30 39 3f 00 07 03 10>


For a ILI9325 controller:

ili9325,gamma-ap-factor = <100> /* Gamma driver amplifiers constant 
current ratio: 0=1.00, 1=0.75, 2=0.50 */
ili9325,source-ap-factor = <75> /* Source driver amplifiers constant 
current ratio: 0=1.00, 1=0.75, 2=0.50 */
ili9325,vgh-factor = <4> /* Vci1 x {4,5,6} */
ili9325,vgl-factor = <3> /* -Vci x {3,4,5} */
ili9325,vci1-factor = <100> /* Vci x {1.00 - 0.70} */
ili9325,pwr-freq1-factor = <1> /* Fosc / {1, 2, 4, 8, 16, 32, 64} */
ili9325,pwr-freq2-factor = <4> /* Fosc / {4, 8, 16, 32, 64, 128, 256} */
ili9325,vci-internal /* use internal 2.5V for Vci reference, default is 
Vci pin */
ili9325,vreg1out-factor = <160> /* Vci x {1.60 - 2.00} */
ili9325,vcom-amplitude-factor = <100> /* VREG1OUT x {0.70 - 1.24} */
ili9325,vcomh-factor = <> /* VREG1OUT x {0.685 - 1.000} */
ili9325,rotation = <0> /* Display rotation: 0,90,180,270 */
ili9325,gamma-positive = <10 values>
ili9325,gamma-negative = <10 values>

Then we have some other registers:
Display Control 1 (R07h) : GON and DTE Set the output level of gate 
driver G1 ~ G320
Gate Scan Control (R60h, R61h, R6Ah) : various gate driver line setup
Panel Interface Control 1 (R90h) : DIVI[1:0]: Sets the division ratio of 
internal clock frequency

(I see now, that I can't use 0 as a property value, since this has to be
the default value if I'm going to support platform_data.)

>> The gamma registers have several values that control a resistor network
>> that sets grayscale values.
>> Would this suffice?
>> st7735r,gamma-positive = <0f 1a 0f 18 2f 28 20 22 1f 1b 23 37 00 07 02 10>
>> st7735r,gamma-negative = <0f 1b 0f 17 33 2c 29 2e 30 30 39 3f 00 07 03 10>
>>
>> Usually when buying these displays, they come with an initialization
>> sequence.
>> Having register values in the DT, a user will be up and running in
>> minutes with a new display.
>> If one has to read the datasheet and map the register values to
>> bitfields and properties, it takes a lot of time and not the least, it's
>> error prone.
> Can you describe how this works for arbitrary combinations of controllers
> and displays? Are the initialization sequences specific to some controller?
Each controller has it's own way of setting the operational parameters 
for a panel.
A controller can also support panels with different resolutions.
The panel can also be connected to the controller in different ways 
(gate lines).
Then each panel has it's own needs. I'm no expert in this, so I can't 
tell how
different the many panels are which are used in the huge number of chinese
displays on ebay and with other more longterm suppliers.

Here's the voltage abilities of the ILI9325 controller:

Low operating power supplies:
IOVcc = 1.65V ~ 3.3 V (interface I/O)
Vcc = 2.4V ~ 3.3 V (internal logic)
Vci = 2.5V ~ 3.3 V (analog)
LCD Voltage drive:
Source/VCOM power supply voltage
DVDH - GND = 4.5V ~ 6.0
VCL – GND = -2.0V ~ -3.0V
VCI – VCL <= 6.0V
Gate driver output voltage
VGH - GND = 10V ~ 20V
VGL – GND = -5V ~ -15V
VGH – VGL <= 32V
VCOM driver output voltage
VCOMH = 3.0V ~ (DDVDH-0.5)V
VCOML = (VCL+0.5)V ~ 0V
VCOMH-VCOML <= 6.0V

In practice however, most of the users of my drivers just use the 
defaults in
the driver (max power). They connect a 3.3V display to the Raspberry Pi, and
the default voltage setup and gamma curves gives a good enough image for 
hobby use.

> An alternative to listing all the settings in DT might be to have a list
> of supported displays in the controller driver and pick the display
> by name, but that only works if there are a small number of possible
> displays that can be connected to each controller.
I'm afraid there are too many panels to make that work.
Panel drivers might be used though.
But I'm a layman that does this for fun, if I where in the business I would
know more about the panel side of this is issue.

Currently I have drivers for 17 controllers in my project, with 3 more 
in the pipeline.
That number can easily be doubled to account for other displays 
currently avilable.


Thank you for your help.


Noralf.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Initial register settings in Device Tree?

[Arnd Bergmann]

On Tuesday 24 June 2014 18:52:52 Noralf Tronnes wrote:
> Den 23.06.2014 15:38, skrev Arnd Bergmann:
> > On Sunday 22 June 2014 21:27:52 Noralf Trønnes wrote:
> >> Den 22.06.2014 20:18, skrev Arnd Bergmann:
> >>> On Sunday 22 June 2014 19:37:56 Noralf Trønnes wrote:
> >> Or should each register have it's own property?
> >> st7735r,pwctr1 = <C5 C2 0A 00>
> > Each user-serviceable property should be abstract and use the normal
> > units that you'd expect to see in a data sheet: milivolts, nanoseconds,
> > etc. See if some other display controller already has picked names
> > for these properties, then use the same. If nobody has done this
> > before, try to use property names that would also make sense on a
> > different controller. If we get a couple of these, we can split out
> > the property parsing code into a separate helper module.
> I found this example that uses regulators to specify voltage:
> Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
> - dsi: display serial interface
> - avdd-dsi-supply: phandle of a supply that powers the DSI controller
> 
> If I should use regulators, I would need to have a controller driver and
> a panel driver, so to avoid that I just specify the millivolt/factor 
> directly.
> This way the DT controller node will contain the panel description.
> (I could add a generic panel driver if regulators is the way to go)
> 
> This is how the setup could be for a ST7735R controller:
> 
> st7735r,avdd-millivolt = <4900> /* 4.9v */
> st7735r,vrhp-millivolt = <4600> /* 4.6v */
> st7735r,vrhn-millivolt = <4600> /* -4.6 */
> st7735r,pwr-mode = <2> /* 0=2x, 1=3x, 2=auto (the datasheet doesn't say 
> what this is) */
> st7735r,vgh25-millivolt = <2400>
> st7735r,vgh-factor = <1> /* 0=2*AVDD+VGH25, 1=3*AVDD, 2=3*AVDD+VGH25 */
> st7735r,vgl-millivolt = <10000> /* -10v */
> /* ap,sap,pwr-freqX have to do with power consumption vs. image quality. */
> st7735r,ap-factor = <1> /* Current in source driver op-amp: 0=small, 
> 1=medium low, 2=medium, 3=medium high, 4=large */
> st7735r,sap-factor = <0> /* Current in source driver op-amp: 0=small, 
> 1=medium low, 2=medium, 3=medium high, 4=large */
> /* Booster circuit Step-up cycle in Normal mode/ full colors */
> st7735r,pwr-freq1-factor-normal = <1> /* BCLK/{1, 1.5, 2, 4} */
> st7735r,pwr-freq2-factor-normal = <1>
> st7735r,pwr-freq3-factor-normal = <1>
> st7735r,pwr-freq4-factor-normal = <1>
> st7735r,vcom-millivolt = <775> /* -0.775v */
> st7735r,rotation = <0> /* Display rotation: 0,90,180,270 */
> st7735r,gamma-positive = <0f 1a 0f 18 2f 28 20 22 1f 1b 23 37 00 07 02 10>
> st7735r,gamma-negative = <0f 1b 0f 17 33 2c 29 2e 30 30 39 3f 00 07 03 10>
> 
> 
> For a ILI9325 controller:
> 
> ili9325,gamma-ap-factor = <100> /* Gamma driver amplifiers constant 
> current ratio: 0=1.00, 1=0.75, 2=0.50 */
> ili9325,source-ap-factor = <75> /* Source driver amplifiers constant 
> current ratio: 0=1.00, 1=0.75, 2=0.50 */
> ili9325,vgh-factor = <4> /* Vci1 x {4,5,6} */
> ili9325,vgl-factor = <3> /* -Vci x {3,4,5} */
> ili9325,vci1-factor = <100> /* Vci x {1.00 - 0.70} */
> ili9325,pwr-freq1-factor = <1> /* Fosc / {1, 2, 4, 8, 16, 32, 64} */
> ili9325,pwr-freq2-factor = <4> /* Fosc / {4, 8, 16, 32, 64, 128, 256} */
> ili9325,vci-internal /* use internal 2.5V for Vci reference, default is 
> Vci pin */
> ili9325,vreg1out-factor = <160> /* Vci x {1.60 - 2.00} */
> ili9325,vcom-amplitude-factor = <100> /* VREG1OUT x {0.70 - 1.24} */
> ili9325,vcomh-factor = <> /* VREG1OUT x {0.685 - 1.000} */
> ili9325,rotation = <0> /* Display rotation: 0,90,180,270 */
> ili9325,gamma-positive = <10 values>
> ili9325,gamma-negative = <10 values>

This doesn't feel right to me at all, though I have a hard time
coming up with the correct solution since I still don't understand
enough of the subject matter.

If you are driving the same display from the ST7735R and the ILI9325
controllers, the DT properties should be the same high-level properties
and the interpretation done in the driver. It sounds like you have
a good overview of the settings that panels may require

> Then we have some other registers:
> Display Control 1 (R07h) : GON and DTE Set the output level of gate 
> driver G1 ~ G320
> Gate Scan Control (R60h, R61h, R6Ah) : various gate driver line setup
> Panel Interface Control 1 (R90h) : DIVI[1:0]: Sets the division ratio of 
> internal clock frequency
> 
> (I see now, that I can't use 0 as a property value, since this has to be
> the default value if I'm going to support platform_data.)

I don't see a problem with platform_data here. I'd normally recommend
not use platform_data at all these days, since most of the platforms
we support are DT only. If you still need platform_data, there is
no requirement to keep the format the same as for the DT properties,
or to use zero as a default.

> >> The gamma registers have several values that control a resistor network
> >> that sets grayscale values.
> >> Would this suffice?
> >> st7735r,gamma-positive = <0f 1a 0f 18 2f 28 20 22 1f 1b 23 37 00 07 02 10>
> >> st7735r,gamma-negative = <0f 1b 0f 17 33 2c 29 2e 30 30 39 3f 00 07 03 10>
> >>
> >> Usually when buying these displays, they come with an initialization
> >> sequence.
> >> Having register values in the DT, a user will be up and running in
> >> minutes with a new display.
> >> If one has to read the datasheet and map the register values to
> >> bitfields and properties, it takes a lot of time and not the least, it's
> >> error prone.
> > Can you describe how this works for arbitrary combinations of controllers
> > and displays? Are the initialization sequences specific to some controller?
> Each controller has it's own way of setting the operational parameters 
> for a panel.
> A controller can also support panels with different resolutions.
> The panel can also be connected to the controller in different ways 
> (gate lines).
> Then each panel has it's own needs. I'm no expert in this, so I can't 
> tell how
> different the many panels are which are used in the huge number of chinese
> displays on ebay and with other more longterm suppliers.
> 
> Here's the voltage abilities of the ILI9325 controller:
> 
> Low operating power supplies:
> IOVcc = 1.65V ~ 3.3 V (interface I/O)
> Vcc = 2.4V ~ 3.3 V (internal logic)
> Vci = 2.5V ~ 3.3 V (analog)
> LCD Voltage drive:
> Source/VCOM power supply voltage
> DVDH - GND = 4.5V ~ 6.0
> VCL – GND = -2.0V ~ -3.0V
> VCI – VCL <= 6.0V
> Gate driver output voltage
> VGH - GND = 10V ~ 20V
> VGL – GND = -5V ~ -15V
> VGH – VGL <= 32V
> VCOM driver output voltage
> VCOMH = 3.0V ~ (DDVDH-0.5)V
> VCOML = (VCL+0.5)V ~ 0V
> VCOMH-VCOML <= 6.0V
> 
> In practice however, most of the users of my drivers just use the 
> defaults in
> the driver (max power). They connect a 3.3V display to the Raspberry Pi, and
> the default voltage setup and gamma curves gives a good enough image for 
> hobby use.

I still don't see how you get from a panel data sheet list of acceptable
settings to the register-level settings for a given controller. It sounds
like you do have to do that manually for each combination of display and
controller, whereas I was expecting this to be done by the display
controller driver.

> > An alternative to listing all the settings in DT might be to have a list
> > of supported displays in the controller driver and pick the display
> > by name, but that only works if there are a small number of possible
> > displays that can be connected to each controller.
> I'm afraid there are too many panels to make that work.
> Panel drivers might be used though.
> But I'm a layman that does this for fun, if I where in the business I would
> know more about the panel side of this is issue.
> 
> Currently I have drivers for 17 controllers in my project, with 3 more 
> in the pipeline.
> That number can easily be doubled to account for other displays 
> currently avilable.

Ok.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Initial register settings in Device Tree?

[Noralf Tronnes]

Den 25.06.2014 12:06, skrev Arnd Bergmann:
> On Tuesday 24 June 2014 18:52:52 Noralf Tronnes wrote:
>> Den 23.06.2014 15:38, skrev Arnd Bergmann:
>>> On Sunday 22 June 2014 21:27:52 Noralf Trønnes wrote:
>>>> Den 22.06.2014 20:18, skrev Arnd Bergmann:
>>>>> On Sunday 22 June 2014 19:37:56 Noralf Trønnes wrote:
>>>> Or should each register have it's own property?
>>>> st7735r,pwctr1 = <C5 C2 0A 00>
>>> Each user-serviceable property should be abstract and use the normal
>>> units that you'd expect to see in a data sheet: milivolts, nanoseconds,
>>> etc. See if some other display controller already has picked names
>>> for these properties, then use the same. If nobody has done this
>>> before, try to use property names that would also make sense on a
>>> different controller. If we get a couple of these, we can split out
>>> the property parsing code into a separate helper module.
>> I found this example that uses regulators to specify voltage:
>> Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
>> - dsi: display serial interface
>> - avdd-dsi-supply: phandle of a supply that powers the DSI controller
>>
>> If I should use regulators, I would need to have a controller driver and
>> a panel driver, so to avoid that I just specify the millivolt/factor
>> directly.
>> This way the DT controller node will contain the panel description.
>> (I could add a generic panel driver if regulators is the way to go)
>>
>> This is how the setup could be for a ST7735R controller:
>>
>> st7735r,avdd-millivolt = <4900> /* 4.9v */
>> st7735r,vrhp-millivolt = <4600> /* 4.6v */
>> st7735r,vrhn-millivolt = <4600> /* -4.6 */
>> st7735r,pwr-mode = <2> /* 0=2x, 1=3x, 2=auto (the datasheet doesn't say
>> what this is) */
>> st7735r,vgh25-millivolt = <2400>
>> st7735r,vgh-factor = <1> /* 0=2*AVDD+VGH25, 1=3*AVDD, 2=3*AVDD+VGH25 */
>> st7735r,vgl-millivolt = <10000> /* -10v */
>> /* ap,sap,pwr-freqX have to do with power consumption vs. image quality. */
>> st7735r,ap-factor = <1> /* Current in source driver op-amp: 0=small,
>> 1=medium low, 2=medium, 3=medium high, 4=large */
>> st7735r,sap-factor = <0> /* Current in source driver op-amp: 0=small,
>> 1=medium low, 2=medium, 3=medium high, 4=large */
>> /* Booster circuit Step-up cycle in Normal mode/ full colors */
>> st7735r,pwr-freq1-factor-normal = <1> /* BCLK/{1, 1.5, 2, 4} */
>> st7735r,pwr-freq2-factor-normal = <1>
>> st7735r,pwr-freq3-factor-normal = <1>
>> st7735r,pwr-freq4-factor-normal = <1>
>> st7735r,vcom-millivolt = <775> /* -0.775v */
>> st7735r,rotation = <0> /* Display rotation: 0,90,180,270 */
>> st7735r,gamma-positive = <0f 1a 0f 18 2f 28 20 22 1f 1b 23 37 00 07 02 10>
>> st7735r,gamma-negative = <0f 1b 0f 17 33 2c 29 2e 30 30 39 3f 00 07 03 10>
>>
>>
>> For a ILI9325 controller:
>>
>> ili9325,gamma-ap-factor = <100> /* Gamma driver amplifiers constant
>> current ratio: 0=1.00, 1=0.75, 2=0.50 */
>> ili9325,source-ap-factor = <75> /* Source driver amplifiers constant
>> current ratio: 0=1.00, 1=0.75, 2=0.50 */
>> ili9325,vgh-factor = <4> /* Vci1 x {4,5,6} */
>> ili9325,vgl-factor = <3> /* -Vci x {3,4,5} */
>> ili9325,vci1-factor = <100> /* Vci x {1.00 - 0.70} */
>> ili9325,pwr-freq1-factor = <1> /* Fosc / {1, 2, 4, 8, 16, 32, 64} */
>> ili9325,pwr-freq2-factor = <4> /* Fosc / {4, 8, 16, 32, 64, 128, 256} */
>> ili9325,vci-internal /* use internal 2.5V for Vci reference, default is
>> Vci pin */
>> ili9325,vreg1out-factor = <160> /* Vci x {1.60 - 2.00} */
>> ili9325,vcom-amplitude-factor = <100> /* VREG1OUT x {0.70 - 1.24} */
>> ili9325,vcomh-factor = <> /* VREG1OUT x {0.685 - 1.000} */
>> ili9325,rotation = <0> /* Display rotation: 0,90,180,270 */
>> ili9325,gamma-positive = <10 values>
>> ili9325,gamma-negative = <10 values>
> This doesn't feel right to me at all, though I have a hard time
> coming up with the correct solution since I still don't understand
> enough of the subject matter.
I found this driver that has the same kind of initialization that I need:
Documentation/devicetree/bindings/panel/samsung,ld9040.txt
drivers/gpu/drm/panel/panel-ld9040.c

I guess I'll do something similar.

Thanks for your time Arnd.


Noralf.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html