On 11/24/21 9:07 AM, Noralf Trønnes wrote:

Hi,

This patchset adds a missing piece for decommissioning the
staging/fbtft/fb_st7735r.c driver namely a way to configure the
controller from Device Tree.

All fbtft drivers have builtin support for one display panel and all
other panels using that controller are configured using the Device Tree
'init' property. This property is supported by all fbtft drivers and
provides a generic way to set register values or issue commands
(depending on the type of controller).

It is common for these types of displays to have a datasheet listing the
necessary controller settings/commands or some example code doing the
same.

This is how the panel directly supported by the fb_st7735r staging
driver is described using Device Tree with that driver:

     width = <160>;
     height = <128>;

     init = <0x1000001
             0x2000096
             0x1000011
             0x20000ff
             0x10000B1 0x01 0x2C 0x2D
             0x10000B4 0x07
             0x10000C0 0xA2 0x02 0x84
             0x10000C1 0xC5
             0x10000C2 0x0A 0x00
             0x10000C5 0x0E
             0x100003a 0x55
             0x1000036 0x60
             0x10000E0 0x0F 0x1A 0x0F 0x18 0x2F 0x28 0x20 0x22
                       0x1F 0x1B 0x23 0x37 0x00 0x07 0x02 0x10
             0x10000E1 0x0F 0x1B 0x0F 0x17 0x33 0x2C 0x29 0x2E
                       0x30 0x30 0x39 0x3F 0x00 0x07 0x03 0x10
             0x1000029
             0x2000064>;


This is how the same panel is described using the st7735r drm driver and
this patchset:

     width = <160>;
     height = <128>;

     frmctr1 = [ 01 2C 2D ];
     invctr = [ 07 ];
     pwctr1 = [ A2 02 84 ];
     pwctr2 = [ C5 ];
     pwctr3 = [ 0A 00 ];
     vmctr1 = [ 0E ];
     madctl = [ 60 ];
     gamctrp1 = [ 0F 1A 0F 18 2F 28 20 22 1F 1B 23 37 00 07 02 10 ];
     gamctrn1 = [ 0F 1B 0F 17 33 2C 29 2E 30 30 39 3F 00 07 03 10 ];

Do these setting correspond to actual physical properties of the display?

What is the advantage of this compared to just adding a new compatible
string if a new display requires different settings? (Other than being
able to use a new display without compiling a new kernel/module.)

It is nice for the driver implementation to be able to use the byte
arrays from the binding directly, but it doesn't really make sense from
a "device tree describes the hardware" point of view.

For example, looking at the data sheet, frmctr1 looks like it is actually
multiple properties, the 1-line period, front porch and back porch.

Back when the fbtft drivers were added to staging I asked on the DT
mailinglist if it was OK to use the 'init' property but it was turned
down. In this patchset I'm trying the same approach used by the
solomon,ssd1307fb.yaml binding in describing the attached panel. That
binding prefixes the properties with the vendor name, not sure why that
is and I think it looks strange so I try without it.

Because [1] says so?

"DO use a vendor prefix on device-specific property names. Consider if
properties could be common among devices of the same class. Check other
existing bindings for similar devices."

Do all displays have "frmctr1" or only sitronix displays?


[1]: https://www.kernel.org/doc/html/latest/devicetree/bindings/writing-bindings.html

Noralf.


Noralf Trønnes (6):
   dt-bindings: display: sitronix,st7735r: Fix backlight in example
   dt-bindings: display: sitronix,st7735r: Make reset-gpios optional
   dt-bindings: display: sitronix,st7735r: Remove spi-max-frequency limit
   dt-bindings: display: sitronix,st7735r: Add initialization properties
   drm/mipi-dbi: Add device property functions
   drm: tiny: st7735r: Support DT initialization of controller

  .../bindings/display/sitronix,st7735r.yaml    | 122 ++++++++++++++-
  drivers/gpu/drm/drm_mipi_dbi.c                | 139 ++++++++++++++++++
  drivers/gpu/drm/tiny/st7735r.c                |  87 +++++++++--
  include/drm/drm_mipi_dbi.h                    |   3 +
  4 files changed, 334 insertions(+), 17 deletions(-)