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. With my PM hat on, the most important part of an omap_hwmod is that it also defines lots of details about the PM register and capabilities of a given IP block. Part of omap_hwmod is the data (which is now auto-generated for current and future OMAPs), and the other part is the code. In the code, the omap_hwmod layer also provides an API so that functionality common to all IP blocks (clock management, power states, idle modes, resets, etc.) can be handled in a common way. Drivers do not interact directly with omap_hwmod and it is considered OMAP core code. In other threads, you've seen a little bit of the omap_device layer. The omap_device layer encapsulates the omap_hwmod layer. An omap_device consists of at least one (but possibly several) omap_hwmods. Drivers do not interact directly with omap_device either, but instead use runtime PM to trigger the custom bus code which would call omap_device_* which in turn would call into omap_hwmod_*. Also, from the omap_hwmod data, platform_devices are generated (including resources) so drivers get the common data in standard ways. So, with that background, we're going through some major work in several OMAP drivers to convert them to work across multiple OMAP SoCs (OMAP2, 3 and 4.) To make the drivers more general, this means adding the hwmod data for the device IP, building the omap_device for the device and converting the driver to use runtime PM instead of direct clock management. 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. Kevin -- 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
