On Wed, Jul 03, 2013 at 12:52:37PM +0200, Sebastian Hesselbarth wrote: > But honestly, I see no way around it and it is the only way > to allow to even have the decision for one or two cards at all. > There is no way for auto-probing the users intention... It's not _just_ about the users intention - for get that, because really it's to do with solving a much bigger question, and that question is: How do we know when all the components are present? In other words, how do we know that we have LCD0 and LCD1 connected to the DCON, which is connected to a LCD and/or a HDMI tranceiver. How do we know that the on-board VGA DACs are wired up and to be used? How do we know which I2C bus the VGA port is connected to, and whether to expect an I2C bus? Let's look at the Cubox setup (sorry, but you _will_ have to use a fixed-width font for this): CPU bus | +-I2C -------------TDA998X --(HDMI)--> Display | | | (RGB888+clock+sync) +-LCD0 ---------. / +--------------DCON ---(VGA)---> not wired +-LCD1 (unused)-' DCON can allegedly route the data from LCD0 or LCD1 to the parallel interface which the TDA998x sits on, and/or the VGA interface. In the case of other setups, the TDA998x may be a LCD panel. The OLPC setup (which seems to be the more common case in terms of the on-SoC device structure): CPU bus | +-LCD ---(RGB666+clock+sync)----> LCD panel and I believe an HDMI tranceiver somewhere. In the above diagrams, "LCD" and "LCD0"/"LCD1" are essentially all the same basic IP block, so they should use the same driver code. Moreover, each named element is a separate platform device. In the first, to drive that correctly, you need the following before "loading" the display system: 1. LCD0, and optionally LCD1 and DCON to be found and known to display driver. 2. I2C driver to be probed and available for use. 3. TDA998x to be found and known to display driver. Only once you have all those components can you allow display to "load". Now consider the case where the TDA998x is not present but the parallel interface is connected directly to a LCD panel. This then becomes: 1. LCD0, and optionally LCD1 and DCON to be found and known to display driver. 2. LCD panel details known to display driver. If the VGA port is being used, then both of these cases need to be supplemented with: N. I2C bus for VGA DDC to be probed and available for use. N+1. DCON must be known to the display driver. N+2. LCD1 required if different display modes on the devices are required. In the OLPC case, it's just: 1. LCD to be found and known to display driver. 2. LCD panel details known to display driver. What you should be getting from the above is that the platform devices which are required for any kind of display subsystem driver to initialize is not really a function of the "software" use case, but how (a) the board hardware has been designed and put together, and (b) the internal structure of the SoC. Moreover, the problem which we're facing is this: how does a display driver know which platform devices to expect from a DT description to make the decision that all parts required for the physical wiring of the board are now present. Consider this too: what if you have a LCD panel on your RGB888 interface which is also connected to a HDMI transceiver which can do scaling and re-syncing (basically format conversion - the TDA998x appears to have this capability), and you drive it with a mode suitable for HDMI but not the LCD panel because the driver doesn't know that there's a LCD panel also connected? This is why I feel that the hotplug idea is actually rather unsafe, and if we go down that path we're building in that risk. (And I think the OLPC guys may be have exactly that kind of setup...) -- Russell King _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
