linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: "G, Manjunath Kondaiah" <manjugk@ti.com>,
	Kevin Hilman <khilman@ti.com>,
	devicetree-discuss@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
	ben-linux@fluff.org
Subject: Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
Date: Mon, 18 Jul 2011 02:07:10 -0700	[thread overview]
Message-ID: <20110718090710.GZ5783@atomide.com> (raw)
In-Reply-To: <CACxGe6uzyxf35WDg6COnPVt3dhQv1H80L1svALxp4naySx2BcA@mail.gmail.com>

* Grant Likely <grant.likely@secretlab.ca> [110716 22:08]:
> 
> The way I see it, you've got two options:
> 
> 1) modify the of_platform_bus_create() to call some kind of
> of_platform_bus_create_omap() for devices that match "ti,omap3-device"
> or something.
> 
> 2) Leave of_platform_bus_create(), and instead us a notifier to attach
> hwmod data to normal platform devices.  omap_device_build() is
> actually pretty simple.  It allocated a device, it attaches
> platform_data and hwmod pointers to the device and registers it.
> omap_device_register() is just a wrapper around
> platform_device_register().
> 
> My preference is definitely #2, but there is a wrinkle in this
> approach.  Unfortunately omap_devices are not simply plain
> platform_devices with extra data attached, an omap_device actually
> embeds the platform_device inside it, which cannot be attached after
> the fact.  I think I had talked with Kevin (cc'd) about eliminating
> the embedding, but I cannot remember clearly on this point.  As long
> as platform_device remains embedded inside struct omap_device, #2
> won't work.
> 
> In either case, looking up the correct hwmod data should be easy for
> any device provided the omap code maintains a lookup table of
> compatible strings and base addresses of devices (much like auxdata).
> In fact, I'd be okay with extending auxdata to include OMAP fields if
> that would be easiest since the whole point of auxdata is to ease the
> transition to DT support.  When a matching device is created, the
> hwmod pointer can easily be attached.  This should work transparently
> for all omap devices, not just the i2c bus.

Well we should be able to automgagically build the omap_device for
each device tree entry.

And then the device driver probe and runtime PM should be able to take
care of the rest for the driver. And then there's no more driver
specific platform init code needed ;)

How about if we just have the hwmod code call omap_device_build for
each device tree entry?

Regards,

Tony

  reply	other threads:[~2011-07-18  9:07 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-13 22:06 [PATCH 0/4] dt: omap3: add device tree support G, Manjunath Kondaiah
2011-07-13 22:06 ` [PATCH 1/4] dt: omap3: add SoC file for handling i2c controllers G, Manjunath Kondaiah
2011-07-13 22:57   ` Grant Likely
2011-07-13 22:58     ` Grant Likely
2011-07-14  3:51       ` G, Manjunath Kondaiah
2011-07-14  3:34     ` G, Manjunath Kondaiah
2011-07-13 22:06 ` [PATCH 2/4] dt: OMAP3: Beagle board: set clock freq for i2c devices G, Manjunath Kondaiah
2011-07-13 23:04   ` Grant Likely
2011-07-13 22:06 ` [PATCH 3/4] dt: omap3: add generic board file for dt support G, Manjunath Kondaiah
2011-07-13 23:15   ` Grant Likely
2011-07-14  8:53     ` [PATCH] omap2+: Use Kconfig symbol in Makefile instead of obj-y Tony Lindgren
     [not found]     ` <CACxGe6sELS=C==16TZ2pfrxJDDyqjS_qOwJUfwzwMO8hqo8Xag-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-07-16 19:54       ` [PATCH 3/4] dt: omap3: add generic board file for dt support G, Manjunath Kondaiah
2011-07-16 20:07         ` G, Manjunath Kondaiah
2011-07-17  5:13           ` Grant Likely
2011-07-18  9:07             ` Tony Lindgren [this message]
2011-07-19 21:34               ` Grant Likely
2011-07-21  7:18                 ` Tony Lindgren
2011-07-21  8:55                 ` Rajendra Nayak
     [not found]                   ` <4E27E967.7090501-l0cyMroinI0@public.gmane.org>
2011-07-21  9:09                     ` Felipe Balbi
2011-07-21  9:33                       ` Rajendra Nayak
     [not found]                         ` <4E27F264.4040409-l0cyMroinI0@public.gmane.org>
2011-07-21  9:39                           ` Felipe Balbi
2011-07-28 18:20                   ` Cousson, Benoit
2011-07-18 10:15             ` G, Manjunath Kondaiah
2011-07-19 21:36               ` Grant Likely
2011-07-19  5:58             ` G, Manjunath Kondaiah
2011-07-19 21:37               ` Grant Likely
     [not found]                 ` <20110719213737.GQ6848-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2011-07-21 10:24                   ` G, Manjunath Kondaiah
2011-07-21 23:53             ` Kevin Hilman
2011-07-13 22:06 ` [PATCH 4/4] dt: i2c-omap: Convert i2c driver to use device tree G, Manjunath Kondaiah
2011-07-13 23:20   ` Grant Likely
2011-07-28 17:34     ` Cousson, Benoit
2011-07-28 21:32       ` Grant Likely
2011-08-03 12:56         ` Cousson, Benoit

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=20110718090710.GZ5783@atomide.com \
    --to=tony@atomide.com \
    --cc=ben-linux@fluff.org \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=khilman@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=manjugk@ti.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).