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