Hi Noralf,

On Sun, Feb 20, 2022 at 04:59:34PM +0100, Noralf Trønnes wrote:
> 
> 
> Den 19.02.2022 23.10, skrev Sam Ravnborg:
> > Hi Noralf,
> > On Fri, Feb 18, 2022 at 04:11:10PM +0100, Noralf Trønnes wrote:
> >> Add a driver that will work with most MIPI DBI compatible SPI panels.
> >> This avoids adding a driver for every new MIPI DBI compatible controller
> >> that is to be used by Linux. The 'compatible' Device Tree property with
> >> a '.bin' suffix will be used to load a firmware file that contains the
> >> controller configuration.
> > A solution where we have the command sequences as part of the DT-overlay
> > is IMO a much better way to solve this:
> > - The users needs to deal only with a single file, so there is less that
> >   goes wrong
> > - The user need not reading special instructions how to handle a .bin
> >   file, if the overlay is present everything is fine
> > - The file that contains the command sequences can be properly annotated
> >   with comments
> > - The people that creates the command sequences has no need for a special
> >   script to create the file for a display - this is all readable ascii.
> > - Using a DT-overlay the parsing of the DT-overlay can be done by
> >   well-tested functions, no need to invent something new to parse the
> >   file
> > 
> > 
> > The idea with a common mipi DBI SPI driver is super, it is the detail
> > with the .bin file that I am against.
> > 
> 
> The fbtft drivers has an init= DT property that contains the command
> sequence. Example for the MZ61581 display:
> 
>                               init = <0x10000b0 00
>                                       0x1000011
>                                       0x20000ff
>                                       0x10000b3 0x02 0x00 0x00 0x00
>                                       0x10000c0 0x13 0x3b 0x00 0x02 0x00 0x01 
> 0x00 0x43
>                                       0x10000c1 0x08 0x16 0x08 0x08
>                                       0x10000c4 0x11 0x07 0x03 0x03
>                                       0x10000c6 0x00
>                                       0x10000c8 0x03 0x03 0x13 0x5c 0x03 0x07 
> 0x14 0x08 0x00 0x21 0x08
> 0x14 0x07 0x53 0x0c 0x13 0x03 0x03 0x21 0x00
>                                       0x1000035 0x00
>                                       0x1000036 0xa0
>                                       0x100003a 0x55
>                                       0x1000044 0x00 0x01
>                                       0x10000d0 0x07 0x07 0x1d 0x03
>                                       0x10000d1 0x03 0x30 0x10
>                                       0x10000d2 0x03 0x14 0x04
>                                       0x1000029
>                                       0x100002c>;
> 
> Parsed here:
> https://elixir.bootlin.com/linux/latest/C/ident/fbtft_init_display_from_property
> 
> Before fbdev was closed for new drivers I looked at fixing up fbtft for
> proper inclusion and asked on the Device Tree mailinglist about the init
> property and how to handle the controller configuration generically.
> I was politely told that this should be done in the driver, so when I
> made my first DRM driver I made a driver specifically for a panel
> (mi0283qt.c).
> 
> Later I found another post that in clear words stated that setting
> random registers from DT was not acceptable.
Understood and thanks for the explanation.
It is a shame that the users loose here :-(

        Sam

Reply via email to