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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
