Re: [RFC PATCH 0/4] DSI/DBI and TinyDRM driver

[Paul Cercueil <paul@crapouillou.net>]

Hi Emil,

Le mar. 16 juin 2020 à 18:47, Emil Velikov <emil.l.velikov@gmail.com> 
a écrit :
> Hi all,
> 
> Allow me to compare this approach with some work Linus W [1] did a
> while back, which I've just noticed.
> 
> Pauls' approach:
> 
>  - Perhaps the shortest one possible
> Porting an existing DSI panel to DBI is 3 lines of code - compat line
> in the SPI/DSI bridge, a bus_type and
> mipi_dsi_maybe_register_tiny_driver() call
> The clever use of the DSI type (equal to zero) means that things will
> work w/o updating existing dsi hosts and devices in panel/. Yet in the
> very unlikely case that the panel does not support DSI, we will still
> allow it.

Is there such a case? I assumed that all current DSI device and host 
drivers are for DSI panels.

> Although thinking about the type I wonder if it can accommodate all 
> use-cases:
> Since we can have a device (panel) capable of DSI+SPI it makes sense
> for it to expose the type bitmask, not the host. Although, what if the
> host itself supports DSI+SPI.?

Yes, hosts can support more than one type (mine does), so it should 
expose a bitmask. As for the panel, even though some can do DSI, SPI 
and I8080 DBI, as far as I know the bus used is always set in hardware 
(with specific pins set to VCC/GND to select the mode), so this is not 
something the host can select. Therefore, the panel driver should 
register the mipi_dsi_device with one particular bus type. Note that 
the panel driver could very well infer the bus type from the compatible 
string.

If the bus type can be changed at runtime (and there's a need for 
that), then we would need a bitmask on the panel driver side too, along 
with a 'set bus' callback, but I'm not sure it will be required.

> Now we can extrapolate that with a host (say fimd/exynos I think)
> which supports a SPI panel (s6e63m0) while having
> of_graph_get_port_by_id(0)?

I'm not sure I understand, if there is a port #0 in the panel node, 
then the tinyDRM driver is not created, and the SPI panel will be 
registered with the fimd/exynos host driver. So that should already 
work fine.

> - Strange (ab)use of the DSI bus for DBI (SPI, 6800, 8080 etc)
> We care about existing users (DT) and it sounds unlikely (based on
> previous discussion) that DBI + SPI/6800... will make it into DT. So
> the current approach seems quite reasonable IMHO.
> 
> 
> Linus' approach:
> - Clear separation of DSI/SPI
> Compat strings are still duplicated, although in separate files
> 
> - Minor code motion and slightly more invasive porting overall
> Much of the boilerplate can be reduced via helper lib and macros. Even
> then it's unlikely we'll reach the 3 line delta as with Paul's
> approach.
> 
> - Does not handle tiny-dsi (dummy) drm driver
> It seems doable, with minor changes
> 
> 
> Personally I'm on the fence and a deciding factor for me is if Paul's
> approach can handle all the combinations of host/device type support.
> That said, the input from people likely to do the work would be highly
> appreciated.
> 
> Once a decision is made, an illustrative series + todo entry would be
> great to have.

Sure. Thanks for the feedback!

Cheers,
-Paul

> -Emil
> 
> [1] 
> https://lists.freedesktop.org/archives/dri-devel/2020-May/266079.html


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel