On Thu, Aug 19, 2010 at 05:56:43PM -0700, Kevin Hilman wrote: > Grant Likely <grant.likely@xxxxxxxxxxxx> writes: > > > On Fri, Aug 13, 2010 at 8:05 AM, Charulatha V <charu@xxxxxx> wrote: > >> This patch series implements McSPI Module in HWMOD FW way > >> and use the runtime PM layer. > > > > Hi Charulatha, > > > > I'll go through and review the patches, but I'm unfamiliar with HWMOD. > > Is there a description of HWMOD that you can point me at? > > Hi Grant, > > If you want to skip my rambling, the source for omap_hwmod is in mainline: > > arch/arm/mach-omap2/omap_hwmod.c > arch/arm/plat-omap/include/plat/omap_hwmod.h > > omap_hwmod is short for OMAP hardware module. It is essentially a > central way of describing each IP block in an OMAP SoC, and the way they > are connected together to make an SoC. An omap_hwmod for a given IP > block contains base address, IRQs, DMA channels etc. (as would a device > tree node) but also includes information on any master/slave interfaces > to model how IP blocks are connected on the SoC and many other details. Hi Kevin, This seems to be a common issue for more than just OMAP SoCs, and I've seen a number of approaches to solving it; both internal to the kernel (AMBA bus, HWMOD, ad-hoc pdata, etc) and via external data (FDT, SFI). It doesn't seem like there is a lot of cross-pollination going on either. I'm thinking about scheduling a discussion in the embedded microconference at Plumbers to talk about the encoding and handling of SoC and machine interconnection data. There should be enough examples now that we can agree on some common infrastructure for handling these kinds of things without inventing new infrastructure from scratch for each SoC family. What do you think? [...] > You see all these changes happening in a single patch because the are > quite dependent on one another. This driver seems to have needed pretty > significant cleanup as well, so I agree that this last patch should be > broken up into parts. > > I think it could be broken up into at least two parts: > cleanup/restructure work to handle more data coming via platform_data, > followed by the conversion to runtime PM. Yes, I like to see refactoring work separated from functional changes as much as possible. g. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
