| Message ID | 20211124150757.17929-1-noralf@tronnes.org |
|---|---|
| Headers | show |
| Series | drm/tiny/st7735r: Match up with staging/fbtft driver | expand |
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(-) >
Den 24.11.2021 23.03, skrev David Lechner: > 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? > Apart from width, height, porches, freq and gamma, no not directly, they configure voltage levels, op-amps (charge pumps?), dividers and such. > 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.) > There is no other reason, the purpose is simplicity for the end user, which is one of the reasons for fbtft's success. > 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. > Yes, one command can have several 8-bit parameters and often configures multiple things even within one parameter. >> >> >> 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." > That's a good reason :) > Do all displays have "frmctr1" or only sitronix displays? > ILI9341 also has that command but with only 2 parameters. ST7789V calls it FRCTRL2 but has only one parameter. The FPA and BPA fields from "frmctr1" looks like they're set using other commands on ILI9341 and ST7789v. I looked at several datasheets some years back to see if I could see some kind of pattern, but I couldn't back then at least. Someone with initimate hw knowledge of these controllers could probably describe a controller using more generic properties. This would defeat the purpose of this exercise which is to make it easy to use any panel. Generic properties would require a set of formulas in order to go from the init sequence provided by the display manufcaturer to the generic properties. The whole point of this patchset is to see if something like the ssd1307 binding can still be done in mainline making it easy for users. If this doesn't work out, we can start removing drivers from staging/fbtft since some of them haven't been removed even if the native panel is supported in drm because they can support any panel through the init property. Noralf. > > [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(-) >> >
Hi, On Wed, Nov 24, 2021 at 04:03:07PM -0600, David Lechner wrote: > On 11/24/21 9:07 AM, Noralf Trønnes wrote: > > 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. You're right, but we have two sets of problems that we want to solve, and so far the discussion has only been to address one while ignoring the other. The solution you suggested works great for the problem the kernel is facing: we want a solution that is easy to maintain over the long run, while being reliable. Thus, we want to introduce a compatible for each panel, that will allow us to describe the panel in the DT without exposing too much data, the data being in the kernel. This works great over the long run because we can update and fix any problem we might have had, send them to stable, etc. It's awesome, but it's mostly centered on us, the developers and maintainers. The problem that fbtft (and this series) wants to fix is completely different though: it wants to address the issue the users are facing. Namely, you get a cheap display from wherever, connect it to your shiny new SBC and wants to get something on the display. In this situation, the user probably doesn't have the knowledge to introduce the compatible in the kernel in the first place. But there's also some technical barriers there: if they use secure boot, they can't change the kernel (well, at least the knowledge required is far above what we can expect from the average user). If the platform doesn't allow access to the DT, you can't change the DT either. Let's set aside those constraints for a moment though. For most of these devices, you wouldn't even be able to come up with a proper compatible. All of those displays are typically a panel and a controller glued together, and the exact initialization sequence depends on both. The panel is never really mentioned, neither is its manufacturer, or its exact product id. In other words, we wouldn't be able to come up with a good compatible for them. Let's now assume we do have access to all those info and can come up with a good, upstreamable, compatible. We now require the user to contribute it upstream, and then expect them to wait for 1-2 years for that patch to show up in their distribution of choice. And then, if we were to get those patches, chances are we don't really want them anyway since we would be drowning in those small patches no-one really wants to review. So yeah, the solution we have is probably a good solution for "real" panels, glued to a device (and even then, the recent discussion around panel-edp shows that it has a few shortcomings). But it's a *terrible* solution for all parties involved when it comes to those kind of displays. I agree that it doesn't really fit in the DT either though. Noralf, what kind of data do we need to setup a display in fbtft? The init sequence, and maybe some enable/reset GPIO, plus some timing duration maybe? There's one similar situation I can think of: wifi chips. Those also need a few infos from the DT (like what bus it's connected to, enable GPIO, etc) and a different sequence (firmware), sometimes different from one board to the other. Could we have a binding that would be something like: panel@42 { compatible = "panel-spi"; model = "panel-from-random-place-42"; enable-gpios = <&...>; } And then, the driver would request the init sequence through the firmware mechanism using a name generated from the model property. It allows to support multiple devices in a given system, since the firmware name wouldn't conflict, it makes a decent binding, and users can adjust the init sequence easily (maybe with a bit of tooling) Would that work? Maxime
Hi Maxime, On Mon, Nov 29, 2021 at 11:17 PM Maxime Ripard <maxime@cerno.tech> wrote: > The problem that fbtft (and this series) wants to fix is completely > different though: it wants to address the issue the users are facing. > Namely, you get a cheap display from wherever, connect it to your shiny > new SBC and wants to get something on the display. > > In this situation, the user probably doesn't have the knowledge to > introduce the compatible in the kernel in the first place. But there's > also some technical barriers there: if they use secure boot, they can't > change the kernel (well, at least the knowledge required is far above > what we can expect from the average user). If the platform doesn't allow If you can change the DT, you can introduce a vulnerability to change the kernel ;-) > access to the DT, you can't change the DT either. How do people connect a cheap display from wherever to their shiny new SBC and make it work, without modifying DT? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Geert, On Tue, Nov 30, 2021 at 09:13:45AM +0100, Geert Uytterhoeven wrote: > On Mon, Nov 29, 2021 at 11:17 PM Maxime Ripard <maxime@cerno.tech> wrote: > > The problem that fbtft (and this series) wants to fix is completely > > different though: it wants to address the issue the users are facing. > > Namely, you get a cheap display from wherever, connect it to your shiny > > new SBC and wants to get something on the display. > > > > In this situation, the user probably doesn't have the knowledge to > > introduce the compatible in the kernel in the first place. But there's > > also some technical barriers there: if they use secure boot, they can't > > change the kernel (well, at least the knowledge required is far above > > what we can expect from the average user). If the platform doesn't allow > > If you can change the DT, you can introduce a vulnerability to change > the kernel ;-) Indeed > > access to the DT, you can't change the DT either. > > How do people connect a cheap display from wherever to their shiny > new SBC and make it work, without modifying DT? Through overlays, usually. I guess it would still qualify as "DT", but it's not the main DT And the other issues remain the same: while the DT could be "easily" patched, the kernel certainly isn't and we need both with the current expectations. Maxime
Den 29.11.2021 10.39, skrev Maxime Ripard: > Hi, > > On Wed, Nov 24, 2021 at 04:03:07PM -0600, David Lechner wrote: >> On 11/24/21 9:07 AM, Noralf Trønnes wrote: >>> 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. > > You're right, but we have two sets of problems that we want to solve, > and so far the discussion has only been to address one while ignoring > the other. > > The solution you suggested works great for the problem the kernel is > facing: we want a solution that is easy to maintain over the long run, > while being reliable. Thus, we want to introduce a compatible for each > panel, that will allow us to describe the panel in the DT without > exposing too much data, the data being in the kernel. > > This works great over the long run because we can update and fix any > problem we might have had, send them to stable, etc. It's awesome, but > it's mostly centered on us, the developers and maintainers. > > > The problem that fbtft (and this series) wants to fix is completely > different though: it wants to address the issue the users are facing. > Namely, you get a cheap display from wherever, connect it to your shiny > new SBC and wants to get something on the display. > > In this situation, the user probably doesn't have the knowledge to > introduce the compatible in the kernel in the first place. But there's > also some technical barriers there: if they use secure boot, they can't > change the kernel (well, at least the knowledge required is far above > what we can expect from the average user). If the platform doesn't allow > access to the DT, you can't change the DT either. > Like Geert I wondered about this statement, since you need to change the DT to use such a display. But if you count overlays as not changing the DT, ok. > Let's set aside those constraints for a moment though. For most of these > devices, you wouldn't even be able to come up with a proper compatible. > All of those displays are typically a panel and a controller glued > together, and the exact initialization sequence depends on both. The > panel is never really mentioned, neither is its manufacturer, or its > exact product id. In other words, we wouldn't be able to come up with a > good compatible for them. > > Let's now assume we do have access to all those info and can come up > with a good, upstreamable, compatible. We now require the user to > contribute it upstream, and then expect them to wait for 1-2 years for > that patch to show up in their distribution of choice. > > And then, if we were to get those patches, chances are we don't really > want them anyway since we would be drowning in those small patches > no-one really wants to review. > > > So yeah, the solution we have is probably a good solution for "real" > panels, glued to a device (and even then, the recent discussion around > panel-edp shows that it has a few shortcomings). But it's a *terrible* > solution for all parties involved when it comes to those kind of > displays. > Really good writeup of the situation Maxime! > > I agree that it doesn't really fit in the DT either though. Noralf, what > kind of data do we need to setup a display in fbtft? The init sequence, > and maybe some enable/reset GPIO, plus some timing duration maybe? > > There's one similar situation I can think of: wifi chips. Those also > need a few infos from the DT (like what bus it's connected to, enable > GPIO, etc) and a different sequence (firmware), sometimes different from > one board to the other. > > Could we have a binding that would be something like: > > panel@42 { > compatible = "panel-spi"; > model = "panel-from-random-place-42"; > enable-gpios = <&...>; > } > > And then, the driver would request the init sequence through the > firmware mechanism using a name generated from the model property. > > It allows to support multiple devices in a given system, since the > firmware name wouldn't conflict, it makes a decent binding, and users > can adjust the init sequence easily (maybe with a bit of tooling) > > Would that work? > I really like this idea. An added benefit is that one driver can handle all MIPI DBI compatible controllers avoiding the need to do a patchset like this for all the various MIPI DBI controllers. The firmware will just contain numeric commands with parameters, so no need for different controller drivers to handle the controller specific command names. The following is a list of the MIPI DBI compatible controllers currently in staging/fbtft: ili9341, hx8357d, st7735r, ili9163, ili9163, ili9163, ili9163, ili9486, ili9481, tinylcd, s6d02a1, s6d02a1, hx8340bn, ili9340. The compatible needs to be a bit more specific though since there are 2 major SPI protocols for these display: MIPI DBI and the one used by ILI9325 and others. The full binding would be something like this: panel@42 { compatible = "panel-mipi-dbi-spi"; model = "panel-from-random-place-42"; /* The MIPI DBI spec lists these powers supply pins */ vdd-supply = <&...>; vddi-supply = <&...>; /* Optional gpio to drive the RESX line */ reset-gpios = <&...>; /* * D/CX: Data/Command, Command is active low * Abcense: Interface option 1 (D/C embedded in 9-bit word) * Precense: Interface option 3 */ dc-gpios = <&...>; /* * If set the driver won't try to read from the controller to see * if it's already configured by the bootloader or previously by * the driver. A readable controller avoids flicker and/or delay * enabling the pipeline. * * This property might not be necessary if we are guaranteed to * always read back all 1's or 0's when MISO is not connected. * I don't know if all setups can guarantee that. */ write-only; /* Optional ref to backlight node */ backlight = <&...>; } Many of these controllers also have a RGB interface option for the pixels and only do configuration over SPI. Maybe the compatible should reflect these 2 options somehow? Noralf.
Hi Noralf, On Tue, Nov 30, 2021 at 03:30:11PM +0100, Noralf Trønnes wrote: > Den 29.11.2021 10.39, skrev Maxime Ripard: > > On Wed, Nov 24, 2021 at 04:03:07PM -0600, David Lechner wrote: > >> On 11/24/21 9:07 AM, Noralf Trønnes wrote: > > I agree that it doesn't really fit in the DT either though. Noralf, what > > kind of data do we need to setup a display in fbtft? The init sequence, > > and maybe some enable/reset GPIO, plus some timing duration maybe? > > > > There's one similar situation I can think of: wifi chips. Those also > > need a few infos from the DT (like what bus it's connected to, enable > > GPIO, etc) and a different sequence (firmware), sometimes different from > > one board to the other. > > > > Could we have a binding that would be something like: > > > > panel@42 { > > compatible = "panel-spi"; > > model = "panel-from-random-place-42"; > > enable-gpios = <&...>; > > } > > > > And then, the driver would request the init sequence through the > > firmware mechanism using a name generated from the model property. > > > > It allows to support multiple devices in a given system, since the > > firmware name wouldn't conflict, it makes a decent binding, and users > > can adjust the init sequence easily (maybe with a bit of tooling) > > > > Would that work? > > I really like this idea. An added benefit is that one driver can handle > all MIPI DBI compatible controllers avoiding the need to do a patchset > like this for all the various MIPI DBI controllers. The firmware will > just contain numeric commands with parameters, so no need for different > controller drivers to handle the controller specific command names. > > The following is a list of the MIPI DBI compatible controllers currently > in staging/fbtft: ili9341, hx8357d, st7735r, ili9163, ili9163, ili9163, > ili9163, ili9486, ili9481, tinylcd, s6d02a1, s6d02a1, hx8340bn, ili9340. > > The compatible needs to be a bit more specific though since there are 2 > major SPI protocols for these display: MIPI DBI and the one used by > ILI9325 and others. > > The full binding would be something like this: > > panel@42 { > compatible = "panel-mipi-dbi-spi"; > model = "panel-from-random-place-42"; > > /* The MIPI DBI spec lists these powers supply pins */ > vdd-supply = <&...>; > vddi-supply = <&...>; > > /* Optional gpio to drive the RESX line */ > reset-gpios = <&...>; > > /* > * D/CX: Data/Command, Command is active low > * Abcense: Interface option 1 (D/C embedded in 9-bit word) > * Precense: Interface option 3 > */ > dc-gpios = <&...>; > > /* > * If set the driver won't try to read from the controller to see > * if it's already configured by the bootloader or previously by > * the driver. A readable controller avoids flicker and/or delay > * enabling the pipeline. > * > * This property might not be necessary if we are guaranteed to > * always read back all 1's or 0's when MISO is not connected. > * I don't know if all setups can guarantee that. > */ > write-only; > > /* Optional ref to backlight node */ > backlight = <&...>; > } It looks decent to me. We'll want Rob to give his opinion though, but it looks in a much better shape compared to what we usually have :) > Many of these controllers also have a RGB interface option for the > pixels and only do configuration over SPI. > Maybe the compatible should reflect these 2 options somehow? I think we'll want a "real" panel for RGB, with its own compatible though. We have a few of these drivers in tree already, so it's better to remain consistent. Maxime
On 12/1/21 8:52 AM, Maxime Ripard wrote: > Hi Noralf, > > On Tue, Nov 30, 2021 at 03:30:11PM +0100, Noralf Trønnes wrote: >> Den 29.11.2021 10.39, skrev Maxime Ripard: >>> On Wed, Nov 24, 2021 at 04:03:07PM -0600, David Lechner wrote: >>>> On 11/24/21 9:07 AM, Noralf Trønnes wrote: >>> I agree that it doesn't really fit in the DT either though. Noralf, what >>> kind of data do we need to setup a display in fbtft? The init sequence, >>> and maybe some enable/reset GPIO, plus some timing duration maybe? >>> >>> There's one similar situation I can think of: wifi chips. Those also >>> need a few infos from the DT (like what bus it's connected to, enable >>> GPIO, etc) and a different sequence (firmware), sometimes different from >>> one board to the other. >>> >>> Could we have a binding that would be something like: >>> >>> panel@42 { >>> compatible = "panel-spi"; >>> model = "panel-from-random-place-42"; >>> enable-gpios = <&...>; >>> } >>> >>> And then, the driver would request the init sequence through the >>> firmware mechanism using a name generated from the model property. >>> >>> It allows to support multiple devices in a given system, since the >>> firmware name wouldn't conflict, it makes a decent binding, and users >>> can adjust the init sequence easily (maybe with a bit of tooling) >>> >>> Would that work? >> >> I really like this idea. An added benefit is that one driver can handle >> all MIPI DBI compatible controllers avoiding the need to do a patchset >> like this for all the various MIPI DBI controllers. The firmware will >> just contain numeric commands with parameters, so no need for different >> controller drivers to handle the controller specific command names. >> >> The following is a list of the MIPI DBI compatible controllers currently >> in staging/fbtft: ili9341, hx8357d, st7735r, ili9163, ili9163, ili9163, >> ili9163, ili9486, ili9481, tinylcd, s6d02a1, s6d02a1, hx8340bn, ili9340. >> >> The compatible needs to be a bit more specific though since there are 2 >> major SPI protocols for these display: MIPI DBI and the one used by >> ILI9325 and others. >> >> The full binding would be something like this: >> >> panel@42 { >> compatible = "panel-mipi-dbi-spi"; >> model = "panel-from-random-place-42"; >> >> /* The MIPI DBI spec lists these powers supply pins */ >> vdd-supply = <&...>; >> vddi-supply = <&...>; >> >> /* Optional gpio to drive the RESX line */ >> reset-gpios = <&...>; >> >> /* >> * D/CX: Data/Command, Command is active low >> * Abcense: Interface option 1 (D/C embedded in 9-bit word) >> * Precense: Interface option 3 >> */ >> dc-gpios = <&...>; >> >> /* >> * If set the driver won't try to read from the controller to see >> * if it's already configured by the bootloader or previously by >> * the driver. A readable controller avoids flicker and/or delay >> * enabling the pipeline. >> * >> * This property might not be necessary if we are guaranteed to >> * always read back all 1's or 0's when MISO is not connected. >> * I don't know if all setups can guarantee that. >> */ >> write-only; >> >> /* Optional ref to backlight node */ >> backlight = <&...>; >> } > > It looks decent to me. We'll want Rob to give his opinion though, but it > looks in a much better shape compared to what we usually have :) > >> Many of these controllers also have a RGB interface option for the >> pixels and only do configuration over SPI. >> Maybe the compatible should reflect these 2 options somehow? > > I think we'll want a "real" panel for RGB, with its own compatible > though. We have a few of these drivers in tree already, so it's better > to remain consistent. > > Maxime > I'm on board with the idea of the init sequence as firmware as well. It looks like Rob might have missed this thread, so maybe just apply the acked patches and submit a v2 with the firmware implementation?
Den 06.12.2021 16.26, skrev David Lechner: > On 12/1/21 8:52 AM, Maxime Ripard wrote: >> Hi Noralf, >> >> On Tue, Nov 30, 2021 at 03:30:11PM +0100, Noralf Trønnes wrote: >>> Den 29.11.2021 10.39, skrev Maxime Ripard: >>>> On Wed, Nov 24, 2021 at 04:03:07PM -0600, David Lechner wrote: >>>>> On 11/24/21 9:07 AM, Noralf Trønnes wrote: >>>> I agree that it doesn't really fit in the DT either though. Noralf, >>>> what >>>> kind of data do we need to setup a display in fbtft? The init sequence, >>>> and maybe some enable/reset GPIO, plus some timing duration maybe? >>>> >>>> There's one similar situation I can think of: wifi chips. Those also >>>> need a few infos from the DT (like what bus it's connected to, enable >>>> GPIO, etc) and a different sequence (firmware), sometimes different >>>> from >>>> one board to the other. >>>> >>>> Could we have a binding that would be something like: >>>> >>>> panel@42 { >>>> compatible = "panel-spi"; >>>> model = "panel-from-random-place-42"; >>>> enable-gpios = <&...>; >>>> } >>>> >>>> And then, the driver would request the init sequence through the >>>> firmware mechanism using a name generated from the model property. >>>> >>>> It allows to support multiple devices in a given system, since the >>>> firmware name wouldn't conflict, it makes a decent binding, and users >>>> can adjust the init sequence easily (maybe with a bit of tooling) >>>> >>>> Would that work? >>> >>> I really like this idea. An added benefit is that one driver can handle >>> all MIPI DBI compatible controllers avoiding the need to do a patchset >>> like this for all the various MIPI DBI controllers. The firmware will >>> just contain numeric commands with parameters, so no need for different >>> controller drivers to handle the controller specific command names. >>> >>> The following is a list of the MIPI DBI compatible controllers currently >>> in staging/fbtft: ili9341, hx8357d, st7735r, ili9163, ili9163, ili9163, >>> ili9163, ili9486, ili9481, tinylcd, s6d02a1, s6d02a1, hx8340bn, ili9340. >>> >>> The compatible needs to be a bit more specific though since there are 2 >>> major SPI protocols for these display: MIPI DBI and the one used by >>> ILI9325 and others. >>> >>> The full binding would be something like this: >>> >>> panel@42 { >>> compatible = "panel-mipi-dbi-spi"; >>> model = "panel-from-random-place-42"; >>> >>> /* The MIPI DBI spec lists these powers supply pins */ >>> vdd-supply = <&...>; >>> vddi-supply = <&...>; >>> >>> /* Optional gpio to drive the RESX line */ >>> reset-gpios = <&...>; >>> >>> /* >>> * D/CX: Data/Command, Command is active low >>> * Abcense: Interface option 1 (D/C embedded in 9-bit word) >>> * Precense: Interface option 3 >>> */ >>> dc-gpios = <&...>; >>> >>> /* >>> * If set the driver won't try to read from the controller to see >>> * if it's already configured by the bootloader or previously by >>> * the driver. A readable controller avoids flicker and/or delay >>> * enabling the pipeline. >>> * >>> * This property might not be necessary if we are guaranteed to >>> * always read back all 1's or 0's when MISO is not connected. >>> * I don't know if all setups can guarantee that. >>> */ >>> write-only; >>> >>> /* Optional ref to backlight node */ >>> backlight = <&...>; >>> } >> >> It looks decent to me. We'll want Rob to give his opinion though, but it >> looks in a much better shape compared to what we usually have :) >> >>> Many of these controllers also have a RGB interface option for the >>> pixels and only do configuration over SPI. >>> Maybe the compatible should reflect these 2 options somehow? >> >> I think we'll want a "real" panel for RGB, with its own compatible >> though. We have a few of these drivers in tree already, so it's better >> to remain consistent. >> >> Maxime >> > > I'm on board with the idea of the init sequence as firmware as well. > > It looks like Rob might have missed this thread, so maybe just apply > the acked patches and submit a v2 with the firmware implementation? > Yes, that's my plan. Noralf.
Den 24.11.2021 16.07, skrev Noralf Trønnes: > 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 ]; > > > 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. > > 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 Patches 1-3 applied, thanks for reviewing. The change to the driver has been replaced by a new generic driver panel-mipi-dbi. Noralf. > 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(-) >
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 ]; 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. 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(-)