On Tue, Aug 21, 2012 at 03:57:25PM -0600, Stephen Warren wrote: > On 08/21/2012 12:35 AM, Terje Bergström wrote: > > On 21.08.2012 09:12, Mark Zhang wrote: > >> OK, thank you. In current version, all devices are created by > >> "of_platform_populate" in board init function. So if we still need to > >> define devices in dt, what's the benefit that we put these device > >> creation works into host1x's probe function? I don't see any difference > >> although create device in host1x probe() sounds more reasonable... > > > > Until I have managed to integrate nvhost to tegradrm, the devices > > creation should be done as it is done now. With nvhost, we will need > > extra data per device, so we'll need to create the devices in nvhost. > > I don't believe that has any impact on how the devices need to be created. > > Both the following should be equally workable: > > a) > > * Each device gets instantiated as a platform device through simple > of_platform_populate. > > * Each driver parses the device node for any information needed by a > host1x client. This parsing could be implemented via a helper function. > > The driver can then register the device with host1x, passing in the > host1x-client-information parsed from DT. > > b) > > * host1x driver enumerates all the clients (sub-nodes) manually. > > * As part of the enumeration, the host1x driver parses information from > the client nodes in order to create the device. > > * Drivers for host1x devices get probed based on the devices created in > the previous step. > > (a) sounds a heck of a lot simpler, because we don't end up creating a > new bus types etc., which in previous conversations you'd mentioned > ended up duplicating a lot of the logic already in the platform bus driver. The former is what I've implemented in the latest series. host1x will obviously be probed before any of the child devices because it is their parent. Client drivers rely on the parent-child relationship to obtain a reference to the host1x and register themselves with a call to the host1x_register_client() function. Each struct host1x_client is required to have some fields prefilled by the driver, like .ops or .dev. An extra field for the channel can easily be added. I think we previously agreed that sync points could be allocated on an as-needed basis, so that assignment can happen in host1x_register_client(). I find this implementation very lightweight and it is very close to how other subsystems (input, fb, I2C, SPI, ...) work. And after all, host1x isn't anything else than a small subsystem. Thierry
Attachment:
pgpMnfs2xtWgT.pgp
Description: PGP signature
