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

[Paul Cercueil]

Hi Emil,

Le mar. 16 juin 2020 à 18:47, Emil Velikov <emil.l.velikov at 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.

Actually the DSI type is not equal to zero, it's BIT(0) so 1. Right now 
in the patch, I added a WARN in mipi_dsi_attach() that checks that 
bus_type is non-zero.

-Paul

> 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.?
> 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)?
> 
> - 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.
> -Emil
> 
> [1] 
> https://lists.freedesktop.org/archives/dri-devel/2020-May/266079.html