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?
