On Tue, 2012-08-21 at 01:29 +0200, Laurent Pinchart wrote: > Hi Tomi, > > On Monday 20 August 2012 14:39:30 Tomi Valkeinen wrote: > > On Sat, 2012-08-18 at 03:16 +0200, Laurent Pinchart wrote: > > > Hi Tomi, > > > > > > mipi-dbi-bus might not belong to include/video/panel/ though, as it can be > > > used for non-panel devices (at least in theory). The future mipi-dsi-bus > > > certainly will. > > > > They are both display busses. So while they could be used for anything, > > I find it quite unlikely as there are much better alternatives for > > generic bus needs. > > My point is that they could be used for display devices other than panels. > This is especially true for DSI, as there are DSI to HDMI converters. > Technically speaking that's also true for DBI, as DBI chips convert from DBI > to DPI, but we can group both the DBI-to-DPI chip and the panel in a single > panel object. Ah, ok. I thought "panels" would include these buffer/converter chips. I think we should have one driver for one indivisible hardware entity. So if you've got a panel module that contains DBI receiver, buffer memory and a DPI panel, let's just have one "DBI panel" driver for it. If we get lots of different panel modules containing the same DBI RX IP, we could have the DBI IP part as a common library, but still have one panel driver per panel module. But how do you see the case for separate converter/buffer chips? Are they part of the generic panel framework? I guess they kinda have to be. On one side they use the "panel" API control the bus they are connected to, and on the other they offer an API for the connected panel to use the bus they provide. Did you just mean we should have a separate directory for them, while still part of the same framework, or...? Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
