Re: [PATCH 0/6] drm/tiny/st7735r: Match up with staging/fbtft driver

["Noralf Trønnes" <noralf@tronnes.org>]

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.