All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@ti.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: "G, Manjunath Kondaiah" <manjugk@ti.com>,
	Tony Lindgren <tony@atomide.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: Thu, 21 Jul 2011 16:53:04 -0700	[thread overview]
Message-ID: <87r55j5gyn.fsf@ti.com> (raw)
In-Reply-To: <CACxGe6uzyxf35WDg6COnPVt3dhQv1H80L1svALxp4naySx2BcA@mail.gmail.com> (Grant Likely's message of "Sat, 16 Jul 2011 23:13:17 -0600")

Grant Likely <grant.likely@secretlab.ca> writes:

[...]

> 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.

I agree with #2, and I think we need to go down this de-coupling route
also.

I just sent an RFC series that starts down this path to at least
demonstrate that it's possible.

Kevin


WARNING: multiple messages have this Message-ID (diff)
From: khilman@ti.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/4] dt: omap3: add generic board file for dt support
Date: Thu, 21 Jul 2011 16:53:04 -0700	[thread overview]
Message-ID: <87r55j5gyn.fsf@ti.com> (raw)
In-Reply-To: <CACxGe6uzyxf35WDg6COnPVt3dhQv1H80L1svALxp4naySx2BcA@mail.gmail.com> (Grant Likely's message of "Sat, 16 Jul 2011 23:13:17 -0600")

Grant Likely <grant.likely@secretlab.ca> writes:

[...]

> 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.

I agree with #2, and I think we need to go down this de-coupling route
also.

I just sent an RFC series that starts down this path to at least
demonstrate that it's possible.

Kevin

  parent reply	other threads:[~2011-07-21 23:53 UTC|newest]

Thread overview: 60+ 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:57     ` Grant Likely
2011-07-13 22:58     ` Grant Likely
2011-07-13 22:58       ` Grant Likely
2011-07-14  3:51       ` G, Manjunath Kondaiah
2011-07-14  3:51         ` G, Manjunath Kondaiah
2011-07-14  3:34     ` 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 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-13 23:15     ` Grant Likely
2011-07-14  8:53     ` [PATCH] omap2+: Use Kconfig symbol in Makefile instead of obj-y Tony Lindgren
2011-07-14  8:53       ` 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-16 20:07           ` G, Manjunath Kondaiah
2011-07-17  5:13           ` Grant Likely
2011-07-17  5:13             ` Grant Likely
2011-07-18  9:07             ` Tony Lindgren
2011-07-18  9:07               ` Tony Lindgren
2011-07-19 21:34               ` Grant Likely
2011-07-19 21:34                 ` Grant Likely
2011-07-21  7:18                 ` Tony Lindgren
2011-07-21  7:18                   ` Tony Lindgren
2011-07-21  8:55                 ` Rajendra Nayak
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:09                       ` Felipe Balbi
2011-07-21  9:33                       ` Rajendra Nayak
2011-07-21  9:33                         ` Rajendra Nayak
     [not found]                         ` <4E27F264.4040409-l0cyMroinI0@public.gmane.org>
2011-07-21  9:39                           ` Felipe Balbi
2011-07-21  9:39                             ` Felipe Balbi
2011-07-28 18:20                   ` Cousson, Benoit
2011-07-28 18:20                     ` Cousson, Benoit
2011-07-18 10:15             ` G, Manjunath Kondaiah
2011-07-18 10:15               ` G, Manjunath Kondaiah
2011-07-19 21:36               ` Grant Likely
2011-07-19 21:36                 ` Grant Likely
2011-07-19  5:58             ` G, Manjunath Kondaiah
2011-07-19  5:58               ` G, Manjunath Kondaiah
2011-07-19 21:37               ` Grant Likely
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 10:24                     ` G, Manjunath Kondaiah
2011-07-21 23:53             ` Kevin Hilman [this message]
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-13 23:20     ` Grant Likely
2011-07-28 17:34     ` Cousson, Benoit
2011-07-28 17:34       ` Cousson, Benoit
2011-07-28 21:32       ` Grant Likely
2011-07-28 21:32         ` Grant Likely
2011-08-03 12:56         ` Cousson, Benoit
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=87r55j5gyn.fsf@ti.com \
    --to=khilman@ti.com \
    --cc=ben-linux@fluff.org \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=manjugk@ti.com \
    --cc=tony@atomide.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 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.