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