Re: [PATCH 0/5] OMAP: McSPI: Implement McSPI in HWMOD way
On Fri, Sep 10, 2010 at 03:15:35PM -0700, Kevin Hilman wrote: Grant Likely grant.lik...@secretlab.ca writes: On Thu, Aug 19, 2010 at 05:56:43PM -0700, Kevin Hilman wrote: Grant Likely grant.lik...@secretlab.ca writes: On Fri, Aug 13, 2010 at 8:05 AM, Charulatha V ch...@ti.com 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? The discussion is certainly worthwhile, and I would love to participate. As with everything, the devil is in the details. And I'm afraid that while at a high-level, describing one SoC or another might look similar, when it gets down to the details, there will be *tons* of things that are unique to each SoC. For example, if you look into the omap_hwmod code and data structures, you will see that most of the stuff described in there is extremly OMAP specific (mostly clock/power related), and only ever visible to OMAP specific code. The question to me is what is the end goal of having a common infrastructure to model SoC-unique features that are only touched by SoC-specific code? And who would maintain such an infrastructure? You're right, there is no point generalizing stuff that is truly SoC specific. I'm interested in identifying the bits and techniques that are useful to other SoCs and architectures. I'm happy to maintain any infrastructure if need be. Personally, I would rather keep focus on infrastructure efforts that would actually be common across SoCs (common kernel binaries, etc.) and visible to drivers (PM frameworks like CPUidle, runtime PM, etc.) All the gory SoC specifics should be hidden by the SoC-specific implementations of these frameworks, and maintained by folks who really understand the SoC. Yes, I agree. So, all that that I question the need for a common framework to define SoC internals. Well for an example, we've talked a lot about the platform_bus_type. Associativity between devices (parent/child) is a core part of the Linux device model, and it is a common problem to know what the device topology is for handing init and PM ordering. I'd like to know what topology you need to describe for the OMAP SoCs. Does the Linux driver model topology provide any of the information you need, or does OMAP HWMOD implement its own topology infrastructure? What is missing from the driver model that requires a lookaside to HWMOD to obtain the SoC topology? I'm certainly not arguing that all SoC specific infrastructure needs to be generalized. Rather I want to find common features and techniques that can be used by SoC specific code. That being said, I'm totally in favor of the direction that the FDT is going in, and very much support the ways it will unify much of the hardware description. However, I think it has limits. Of course it does; it's only a data structure! :-D It can encode data about the hardware; but it cannot describe operating system behaviour. And at least for OMAP, I envision using the device tree to describe connections at the board level, but continuing to use omap_hwmod to describe the SoC itself. At the very least, the structure of the SoC probably needs to be reflected in the device tree. A lot of the time nodes for internal SoC devices end up becoming 'handles' to describe attachments to external hardware. ie. i2c device nodes hanging off an SoC i2c controller, or interrupt connections. Since those nodes have to be there anyway, it is useful (and less confusing) to have them
Re: [PATCH 0/5] OMAP: McSPI: Implement McSPI in HWMOD way
Grant Likely grant.lik...@secretlab.ca writes: [...] What I'm thinking about doing at the embedded microconf is asking a few people (you included) to speak briefly about what they are doing to describe their platforms, and see if any common functionality bubbles to the top. Sounds great. I think it is to easy to get focused on our own problem domain and miss that others are working on very similar problems in isolation. Completely agree. Looking forward to LPC. 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
Re: [PATCH 0/5] OMAP: McSPI: Implement McSPI in HWMOD way
Grant Likely grant.lik...@secretlab.ca writes: On Thu, Aug 19, 2010 at 05:56:43PM -0700, Kevin Hilman wrote: Grant Likely grant.lik...@secretlab.ca writes: On Fri, Aug 13, 2010 at 8:05 AM, Charulatha V ch...@ti.com 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? The discussion is certainly worthwhile, and I would love to participate. As with everything, the devil is in the details. And I'm afraid that while at a high-level, describing one SoC or another might look similar, when it gets down to the details, there will be *tons* of things that are unique to each SoC. For example, if you look into the omap_hwmod code and data structures, you will see that most of the stuff described in there is extremly OMAP specific (mostly clock/power related), and only ever visible to OMAP specific code. The question to me is what is the end goal of having a common infrastructure to model SoC-unique features that are only touched by SoC-specific code? And who would maintain such an infrastructure? Personally, I would rather keep focus on infrastructure efforts that would actually be common across SoCs (common kernel binaries, etc.) and visible to drivers (PM frameworks like CPUidle, runtime PM, etc.) All the gory SoC specifics should be hidden by the SoC-specific implementations of these frameworks, and maintained by folks who really understand the SoC. So, all that that I question the need for a common framework to define SoC internals. That being said, I'm totally in favor of the direction that the FDT is going in, and very much support the ways it will unify much of the hardware description. However, I think it has limits. And at least for OMAP, I envision using the device tree to describe connections at the board level, but continuing to use omap_hwmod to describe the SoC itself. 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
RE: [PATCH 0/5] OMAP: McSPI: Implement McSPI in HWMOD way
-Original Message- From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behalf Of Grant Likely Sent: Saturday, August 14, 2010 4:15 AM To: Varadarajan, Charulatha Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com; p...@pwsan.com; Cousson, Benoit; t...@atomide.com; dbrown...@users.sourceforge.net; spi-devel-gene...@lists.sourceforge.net; Nayak, Rajendra; Basak, Partha; Raja, Govindraj Subject: Re: [PATCH 0/5] OMAP: McSPI: Implement McSPI in HWMOD way On Fri, Aug 13, 2010 at 8:05 AM, Charulatha V ch...@ti.com 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? The following link could be of some help: http://omappedia.org/wiki/HWMOD#Steps_involved_in_HWMOD Thanks, g. This patch series is created on origin/pm-wip/hwmods-omap4 with McSPI slave mode patches (url given below) on top of it. https://patchwork.kernel.org/patch/79677/ Updated McSPI slave mode patches will be posted shortly by Govindraj. McSPI slave mode patches were already discussed on open source mailing list and they are almost towards the end of final rebased version. Hence hwmod patches are created on top of McSPI slave mode patch series to avoid major rework later on. Benoit Cousson (1): OMAP4 HWMOD: Add mcspi hwmods. Charulatha V (3): OMAP2420: McSPI: Add mcspi hwmod OMAP2430 : McSPI: Add mcspi hwmod data OMAP3 HWMOD: Add mcspi hwmods. Govindraj.R (1): OMAP McSPI: Adapt McSPI driver to use omap hwmod arch/arm/mach-omap2/clock3xxx_data.c | 4 + arch/arm/mach-omap2/devices.c | 233 + --- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 138 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 196 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 252 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 244 + arch/arm/plat-omap/include/plat/mcspi.h | 27 +++ drivers/spi/omap2_mcspi.c | 273 + --- 8 files changed, 1034 insertions(+), 333 deletions(-) -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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
Re: [PATCH 0/5] OMAP: McSPI: Implement McSPI in HWMOD way
Grant Likely grant.lik...@secretlab.ca writes: On Fri, Aug 13, 2010 at 8:05 AM, Charulatha V ch...@ti.com 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] OMAP: McSPI: Implement McSPI in HWMOD way
This patch series implements McSPI Module in HWMOD FW way and use the runtime PM layer. This patch series is created on origin/pm-wip/hwmods-omap4 with McSPI slave mode patches (url given below) on top of it. https://patchwork.kernel.org/patch/79677/ Updated McSPI slave mode patches will be posted shortly by Govindraj. McSPI slave mode patches were already discussed on open source mailing list and they are almost towards the end of final rebased version. Hence hwmod patches are created on top of McSPI slave mode patch series to avoid major rework later on. Benoit Cousson (1): OMAP4 HWMOD: Add mcspi hwmods. Charulatha V (3): OMAP2420: McSPI: Add mcspi hwmod OMAP2430 : McSPI: Add mcspi hwmod data OMAP3 HWMOD: Add mcspi hwmods. Govindraj.R (1): OMAP McSPI: Adapt McSPI driver to use omap hwmod arch/arm/mach-omap2/clock3xxx_data.c |4 + arch/arm/mach-omap2/devices.c | 233 +--- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 138 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 196 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 252 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 244 + arch/arm/plat-omap/include/plat/mcspi.h| 27 +++ drivers/spi/omap2_mcspi.c | 273 +--- 8 files changed, 1034 insertions(+), 333 deletions(-) -- 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
Re: [PATCH 0/5] OMAP: McSPI: Implement McSPI in HWMOD way
On Fri, Aug 13, 2010 at 8:05 AM, Charulatha V ch...@ti.com 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? Thanks, g. This patch series is created on origin/pm-wip/hwmods-omap4 with McSPI slave mode patches (url given below) on top of it. https://patchwork.kernel.org/patch/79677/ Updated McSPI slave mode patches will be posted shortly by Govindraj. McSPI slave mode patches were already discussed on open source mailing list and they are almost towards the end of final rebased version. Hence hwmod patches are created on top of McSPI slave mode patch series to avoid major rework later on. Benoit Cousson (1): OMAP4 HWMOD: Add mcspi hwmods. Charulatha V (3): OMAP2420: McSPI: Add mcspi hwmod OMAP2430 : McSPI: Add mcspi hwmod data OMAP3 HWMOD: Add mcspi hwmods. Govindraj.R (1): OMAP McSPI: Adapt McSPI driver to use omap hwmod arch/arm/mach-omap2/clock3xxx_data.c | 4 + arch/arm/mach-omap2/devices.c | 233 +--- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 138 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 196 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 252 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 244 + arch/arm/plat-omap/include/plat/mcspi.h | 27 +++ drivers/spi/omap2_mcspi.c | 273 +--- 8 files changed, 1034 insertions(+), 333 deletions(-) -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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
