Hi Mauro, On Wednesday 10 October 2012 10:45:22 Mauro Carvalho Chehab wrote: > Em Wed, 10 Oct 2012 14:54 +0200 Laurent Pinchart escreveu: > > > Also, ideally OF-compatible (I2C) drivers should run with no platform > > > data, but soc-camera is using I2C device platform data intensively. To > > > avoid modifying the soc-camera core and all drivers, I also trigger on > > > the > > > BUS_NOTIFY_BIND_DRIVER event and assign a reference to the dynamically > > > created platform data to the I2C device. Would we also want to do this > > > for > > > all V4L2 bridge drivers? We could call this a "prepare" callback or > > > something similar... > > > > If that's going to be an interim solution only I'm fine with keeping it in > > soc-camera. > > I'm far from being an OF expert, but why do we need to export I2C devices to > DT/OF? On my understanding, it is the bridge code that should be > responsible for detecting, binding and initializing the proper I2C devices. > On several cases, it is impossible or it would cause lots of ugly hacks if > we ever try to move away from platform data stuff, as only the bridge > driver knows what initialization is needed for an specific I2C driver. In a nutshell, a DT-based platform doesn't have any board code (except in rare cases, but let's not get into that), and thus doesn't pass any platform data structure to drivers. However, drivers receive a DT node, which contains a hierarchical description of the hardware, and parse those to extract information necessary to configure the device. One very important point to keep in mind here is that the DT is not Linux- specific. DT bindings are designed to be portable, and thus must only contain hardware descriptions, without any OS-specific information or policy information. For instance information such as the maximum video buffers size is not allowed in the DT. The DT is used both to provide platform data to drivers and to instantiate devices. I2C device DT nodes are stored as children of the I2C bus master DT node, and are automatically instantiated by the I2C bus master. This is a significant change compared to our current situation where the V4L2 bridge driver receives an array of I2C board information structures and instatiates the devices itself. Most of the DT support work will go in supporting that new instantiation mechanism. The bridge driver doesn't control instantiation of the I2C devices anymore, but need to bind with them at runtime. > To make things more complex, it is expected that most I2C drivers to be arch > independent, and they should be allowed to be used by a personal computer > or by an embedded device. Agreed. That's why platform data structures won't go away anytime soon, a PCI bridge driver for hardware that contain I2C devices will still instantiate the I2C devices itself. We don't plan to or even want to get rid of that mechanism, as there are perfectly valid use cases. However, for DT-based embedded platforms, we need to support a new instantiation mechanism. > Let me give 2 such examples: > > - ir-i2c-kbd driver supports lots of IR devices. Platform_data is needed > to specify what hardware will actually be used, and what should be the > default Remote Controller keymap; That driver isn't used on embedded platforms so it doesn't need to be changed now. > - Sensor drivers like ov2940 is needed by soc_camera and by other > webcam drivers like em28xx. The setup for em28xx should be completely > different than the one for soc_camera: the initial registers init sequence > is different for both. As several registers there aren't properly > documented, there's no easy way to parametrize the configuration. Such drivers will need to support both DT-based platform data and structure- based platform data. They will likely parse the DT node and fill a platform data structure, to avoid duplicating initialization code. Please note that the new subdevs instantiation mechanism needed for DT will need to handle any instantiation order, as we can't guarantee the I2C device and bridge device instantiation order with DT. It should thus then support the current instantiation order we use for PCI and USB platforms. > So, for me, we should not expose the I2C devices directly on OF; it should, > instead, see just the bridge, and let the bridge to map the needed I2C > devices using the needed platform_data. We can't do that, there will be no platform data anymore with DT-based platforms. As a summary, platform data structures won't go away, I2C drivers that need to work both on DT-based and non-DT-based platforms will need to support both the DT and platform data structures to get platform data. PCI and USB bridges will still instantiate their I2C devices, and binding between the I2C devices and the bridge can either be handled with two different instantiation mechanisms (the new one for DT platforms, with runtime bindings, and the existing one for non-DT platforms, with binding at instantiation time) or move to a single runtime binding mechanism. It's too early to know which solution will be simpler. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
