On 22/08/13 00:07, Laurent Pinchart wrote: Thanks for the comments! >> The exception to the above are DSI and DBI. DSI and DBI are combined control >> and video busses, but the use of the busses for control purposes is not >> independent of the video stream. Also, the the busses are, in practice, >> one-to-one links. And last, DSI and DBI display entities are often also >> controllable via, say, i2c. For these reasons there is no real Linux bus >> for DSI and DBI and thus the DSI and DBI devices are either platform >> devices or i2c devices. > > That's something I'm less convinced about, but I don't have a too strong > feeling. The best implementation should get to mainline, I won't nack this > architecture just for theoretical reasons. Ok. I posted a response to your DBI bus patch about the issues I see. >> DSI Module ID >> ============= >> >> On OMAP4 we have two DSI modules. To configure the clock routing and pin >> muxing, we need to know the hardware module ID for the DSI device, i.e. is >> this Linux platform device DSI1 or DSI2. The same issue exists with other >> SoCs with multiple outputs of the same kind. >> >> With non-DT case, we used the platform device's ID directly. With DT, that >> doesn't work. I don't currently have a good solution for this, so as a >> temporary solution the DSI driver contains a table, from which it can find >> the HW module ID by using the device's base address. > > You could add two output ports to the DSS, one for each DSI, and link the DSI > modules to the DSS output ports in DT. That would represent the hardware > topology, and would allow the DSI driver to know its ID based on the DSS > output port it's connected to. It's still a bit hackish in the sense that the > DSI driver will use information provided by the DSS (the output port number), > but not more than the current method. Hmm, yep. That's kind of the same as having an explicit 'module-id' property in the DSI node. I had implemented that solution at some point, but considered it too ugly. But I agree that deducing the module-id from the DSS output port is a bit cleaner, as it doesn't need any special properties. And it's maybe also better than the address table I have now, as the address table requires special code for each SoC. I have to try the V4L2 ports to understand fully how to use them. In the end, I hope to get rid of the module-id totally. It's really not a DSI-thing at all. The DSI hardware does not use the module-id for anything, it's more about how the DSI module is glued in the DSS/SoC. >> I have some ideas how to deduce the DSS version by poking to certain DSS >> registers, but it is not yet tested so I don't know if it will work. > > That might be a stupid question, but can't you just encode the version in the > compatible string of the DSS DT node (the one currently compatible with > "ti,omap[34]-dss") ? That would require having separate DT files for each revision. For example, we have Beagle boards with different OMAP reversions. It's fine to have the version encoded in the compatible string for major versions, but having all minor revisions encoded there could result in a mess. > Version information might also need to be split/duplicated in several of the > DSS DT nodes. A quick grep through the driver source code shows that the > version is used by the submodules to infer SoC glue information. For instance > dsi_get_channel() uses the version to find the DSI module channel ID. That > information could possibly be retrieved from the links between the DSS DT > nodes. Hmm, yes. Well. The DISPC has multiple output channels: LCD, LCD2, LCD3, TV (depending on the SoC). These outputs go to encoders, and the routing can be configured. If we consider only DSI encoders on OMAP4, the LCD2 output can be configured to go to DSI1 or DSI2 modules. LCD1 output can be configured to go to DSI1 (but not to DSI2). Because the routing has restrictions like mentioned above, it's somewhat difficult to allocate the DISPC output channels during runtime in a totally dynamic manner. Say, if we happened to allocate LCD2 for DSI1, and later we'd want to use DSI2, there would be no DISPC output to use. That's why we currently have them hardcoded in the driver, and it works ok in all the use cases we have now. However, some board could need to setup the channels in some other way for some particular use case. So, I'm not totally comfortable with hardcoding the DISPC output - DSS encoder connections in the DT data. While it'd work for most cases, it doesn't work for all. Then again, if the connections in the DT data would be considered more like a default set of connections, and they could be changed later from the kernel/userspace, then it'd be fine. >> Some of the DSS modules are actually a combination of multiple smaller >> modules. For example, the DSI module contains DSI protocol, DSI PHY and DSI >> PLL modules, each in their own address space. These could perhaps be >> presented as separate DT nodes and Linux devices, but I am not sure if that >> is a good approach or not. > > What are the chances that one of those block will be upgraded and/or replaced > independently of the others in the future (I know it's a tricky question) ? It > might not be worth it going to a too fine-grained approach at the moment, but > we need to make sure that the DT bindings will allow an easy path forward if > needed. For DSI, I believe the chances are quite small. But for HDMI, we already have this case for OMAP4 and OMAP5, and we're currently working on splitting the HDMI core, PHY and PLL properly. I think it makes sense to do the same for DSI also at the same time, especially as the PLL for DSI and HDMI is the same (afaik). >> If we shouldn't add the bindings as unstable, when should the bindings be >> added? Wait until CDF is in the mainline, and use that? > > What about using the CDF bindings, without waiting for CDF to be in mainline ? > I believe the bindings should be upstreamed as unstable to start with anyway. Yes, I think that makes sense. And that's what I've been aiming at. I'm just missing the ports-stuff. Then again, I see opinions that the old bindings should be supported (e.g. the mails with Tony in this same thread). If so, using CDF bindings without CDF being in the mainline is a bit risky, as the bindings could well change. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
