Hi Felipe, Felipe Balbi <ba...@ti.com> writes:
> On Mon, Feb 14, 2011 at 04:15:10PM -0800, Kevin Hilman wrote: >> Hema HK <hem...@ti.com> writes: >> >> > Using omap_device_build API instead of platform_device_register for >> > OMAP2430,OMAP34xx and OMAP4430 musb device registration. >> > The device specific resources defined in centralized >> > database will be used. >> >> Except for AM35x. >> >> NACK, for same reasons as previous version of this patch. > > Does it really make sense to hold on omap2plus HWMOD conversion because > of AM35x ? I mean, I understand it would be better to get all fixed up, > but loose another merge window for that ? > > Can we get omap2plus in and AM35x on the next merge window ? At least > omap2plus would have been converted to hwmod and would be using > pm_runtime as we want. Well, you get to decide as you're the maintainer of this stuff. ;) If you merge it, I suggest at least fixing the changelog to make it clear that not all devices are using hwmod. That being said, how difficult is it to add the hwmod data for the AM35x OTG block? Just added it to the exising OMAP3 data using CHIP_IS* to marke it as AM35x, and you can at least get rid of the base address and IRQ number hacks for AM35x in this code. Separating out the pdata function pointer hooks is a different matter which is also ugly, but I don't feel as strongly about. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
