Thread (1 message) 1 message, 1 author, 2012-08-21

Re: Binding together tegradrm & nvhost

From: Stephen Warren <hidden>
Date: 2012-08-21 21:57:25

On 08/21/2012 12:35 AM, Terje Bergström wrote:
On 21.08.2012 09:12, Mark Zhang wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help