Hi, On 2012-11-22 23:45, Laurent Pinchart wrote: > From: Laurent Pinchart <laurent.pinchart+renesas@xxxxxxxxxxxxxxxx> > > Signed-off-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> > --- > drivers/video/display/Kconfig | 4 + > drivers/video/display/Makefile | 1 + > drivers/video/display/mipi-dbi-bus.c | 228 ++++++++++++++++++++++++++++++++++ > include/video/display.h | 5 + > include/video/mipi-dbi-bus.h | 125 +++++++++++++++++++ > 5 files changed, 363 insertions(+), 0 deletions(-) > create mode 100644 drivers/video/display/mipi-dbi-bus.c > create mode 100644 include/video/mipi-dbi-bus.h I've been doing some omapdss testing with CDF and DSI, and I have some thoughts about the bus stuff. I already told these to Laurent, but I'll write them to the mailing list also for discussion. So with the current CDF model we have separate control and video buses. The control bus is represented as proper Linux bus, and video bus is represented via custom display_entity. This sounds good on paper, and I also agreed to this approach when we were planning CDF. However, now I doubt that approach. First, I want to list some examples of devices with different bus configurations: 1) Panel without any control, only video bus 2) Panel with separate control and video buses, e.g. i2c for control, DPI for video 3) Panel with the same control and video buses, like DSI or DBI. The first one is simple, it's just a platform device. No questions there. The second one can be a bit tricky. Say, if we have a panel controlled via i2c, and DSI/DBI used for video. The problem here is that with the current model, DSI/DBI would be represented as a real bus, for control. But in this case there's only the video path. So if all the DSI/DBI bus configuration is handled on the DSI/DBI control bus side, how can it be handled with only the video bus? And if we add the same bus configuration to the video bus side as we have on control bus side, then we have duplicated the API, and it's also somewhat confusing. I don't have any good suggestion for this. Third one is kinda clear, but I feel slightly uneasy about it. In theory we can have separate control and video buses, which use the same HW transport. However, I feel that we'll have some trouble with the implementation, as we'll then have two more or less independent users for the HW transport. I can't really point out why this would not be possible to implement, but I have a gut feeling that it will be difficult, at least for DSI. So I think my question is: what does it give us to have separate control and video buses, and what does the Linux bus give us with the control bus? I don't see us ever having a case where a device would use one of the display buses only for control. So either the display bus is only used for video, or it's used for both control and video. And the display bus is always 1-to-1, so we're talking about really simple bus here. I believe things would be much simpler if we just have one entity for the display buses, which support both video and (when available) control. What would be the downsides of this approach versus the current CDF proposal? Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
