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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Emil,

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


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




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux