From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: "Terje Bergström" <tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: Mark Zhang <markz-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
Thierry Reding
<thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Subject: Re: Binding together tegradrm & nvhost
Date: Tue, 21 Aug 2012 15:57:25 -0600 [thread overview]
Message-ID: <50340445.6010908@wwwdotorg.org> (raw)
In-Reply-To: <50332C22.7090009-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
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.
next prev parent reply other threads:[~2012-08-21 21:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-20 13:01 Binding together tegradrm & nvhost Terje Bergström
[not found] ` <50323513.3090606-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-08-20 13:18 ` Thierry Reding
[not found] ` <20120820131800.GA13785-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2012-08-20 13:33 ` Terje Bergström
2012-08-21 3:50 ` Dennis Gilmore
2012-08-21 5:39 ` Mark Zhang
2012-08-21 5:42 ` Thierry Reding
[not found] ` <20120821054256.GA5325-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2012-08-21 6:16 ` Mark Zhang
2012-08-21 6:21 ` Thierry Reding
2012-08-21 14:57 ` Thierry Reding
[not found] ` <20120821145709.GA701-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2012-08-22 2:29 ` Mark Zhang
2012-08-22 8:42 ` Terje Bergström
[not found] ` <50349B58.4000809-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-08-22 10:33 ` Thierry Reding
[not found] ` <20120822103309.GB31448-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2012-08-22 11:42 ` Terje Bergström
2012-08-21 4:57 ` Mark Zhang
2012-08-21 5:40 ` Terje Bergström
[not found] ` <50331F32.4040903-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-08-21 6:12 ` Mark Zhang
2012-08-21 6:35 ` Terje Bergström
[not found] ` <50332C22.7090009-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-08-21 7:12 ` Mark Zhang
2012-08-21 21:57 ` Stephen Warren [this message]
[not found] ` <50340445.6010908-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-08-22 5:54 ` Thierry Reding
2012-08-21 21:53 ` Stephen Warren
[not found] ` <50340343.1050206-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-08-22 6:49 ` Thierry Reding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50340445.6010908@wwwdotorg.org \
--to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=markz-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.