From mboxrd@z Thu Jan 1 00:00:00 1970 From: khilman@ti.com (Kevin Hilman) Date: Thu, 21 Jul 2011 16:53:04 -0700 Subject: [PATCH 3/4] dt: omap3: add generic board file for dt support In-Reply-To: (Grant Likely's message of "Sat, 16 Jul 2011 23:13:17 -0600") References: <1310592975-25773-1-git-send-email-manjugk@ti.com> <1310592975-25773-4-git-send-email-manjugk@ti.com> Message-ID: <87r55j5gyn.fsf@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Grant Likely 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