On Sun, Feb 20, 2022 at 10:32:25PM +0100, Sam Ravnborg wrote: > 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 :-( From a user point-of-view, nothing prevents the overlays and the firmware to be in the same package, provided by whatever distro or build-system they would use. The only case where it's a bit less efficient is for a panel that isn't supported already, but it's just a documentation and tooling issue, and Noralf has an awesome track record for both. And the DT syntax throw so much people off that I'm not sure it's such a benefit :) Maxime
Attachment:
signature.asc
Description: PGP signature
