Message-ID: <87y63vav01.fsf@ti.com>
Date:	Thu, 31 Mar 2011 13:35:26 -0700
From:	Kevin Hilman <khilman@...com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	"Russell King - ARM Linux" <linux@....linux.org.uk>,
	Ingo Molnar <mingo@...e.hu>, Nicolas Pitre <nico@...xnic.net>,
	david@...g.hm, Linus Torvalds <torvalds@...ux-foundation.org>,
	Tony Lindgren <tony@...mide.com>,
	David Brown <davidb@...eaurora.org>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-arm-kernel@...ts.infradead.org, linux-omap@...r.kernel.org,
	Catalin Marinas <catalin.marinas@....com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [GIT PULL] omap changes for v2.6.39 merge window

Arnd Bergmann <arnd@...db.de> writes:

> On Thursday 31 March 2011, Kevin Hilman wrote:
>> Some SoCs families (like OMAP) have huge amount of diversity even within
>> the SoC family, so better abstractions and generic infrastrucure
>> improvements are an obvious win, even staying within the SoC.
>
> But that's the point. The incentive is there for managing the infrastructure
> within the SoC, but not across SoCs. 

OK, but the rest of my thread went on to describe how at least a few ARM
SoC maintainers are actually actively working infrastructure that is
cross SoC, like runtime PM.  It might start because of an abstraction
within an SoC family like supporting both SH and SH-mobile, or
OMAP[12345], but it does sometimes result in not only cross-SoC code but
cross-platform frameworks.

Admiteddly, the percentage of ARM SoC developers actively working on
these common, cross-platform infrastructure layers is rather small, but
at least it is non-zero. :)    

> Allow me to use OMAP as a bad example while pointing out that it's
> really one of the best supported platforms we currently have, while
> the others are usually much worse in terms of working with the
> community (or at least they are behind on the learning curve but
> getting there):
>
> * OMAP2 introduced the hwmod concept as an attempt to reduce duplication
 >   between board code, but the code was done on the mach-omap2 level
>   instead of finding a way to make it work across SOC vendors, or using
>   an existing solution.

Well, before deciding whether something like hwmod should be a cross-SoC
abstraction, it's important to be clear about what level of abstraction
is needed, or practical for a given feature.  For power management, we
already have (and use) existing abstractions for the drivers.  The clock
framework, system PM and runtime PM framework are all existing
abstraction layers for drivers.

Remember that power management is one of those areas that ARM SoC
vendors like to "differentiate" on, so the hardware is vastly different
between ARM vendors.  Having worked on embedded Linux power management
for a while now, I currently do not think any cross-SoC abstractions
below the clock framework or runtime PM are worth it.  I'm certainly
willing to be pursuaded otherwise, but currently don't see the
usefulness.

With that as background, hwmod was never inteded as something to be
cross-SoC.  If you look at the data that's in an omap_hwmod, it's
entirely OMAP hardware specific, and mostly focused on power management
hardware details, register descriptions, feature capabilities etc.  This
allows the OMAP PM core code to be generalized and work across all SoCs
in the OMAP family.  But again, it was intended for OMAP PM core code.
At that level, there really isn't much to share with other SoCs since
the PM hardware for the various SoC vendors is so "differentiated"
(a.k.a fsck'd up in extremely different ways.)

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists