Nishanth Menon wrote:
> Linus Walleij had written, on 09/16/2010 07:19 AM, the following:
>> 2010/9/15 Kevin Hilman <khil...@deeprootsystems.com>:
>>
>>> OMAP SOCs have a standard set of tuples consisting of frequency and
>>> voltage pairs that the device will support per voltage domain. These
>>> are called Operating Performance Points or OPPs.
>>> (...)
>>> This introduces a common handling OPP mechanism accross all OMAPs.
>>> As a start this is used for OMAP3.
>> OPPs are a generic concept, it's in silicon construction textbooks and all.
>> Should this code not be made generic instead? You wouldn't make
>> regulators or even DMA platform-specific these days, so why should
>> OPPs be?
> As far as I see this patch :
> hwmod[1] which is omap specific which inturn depends on omap_device. -
> this impacts opp_add function in the opp layer.
Then wrap your local OPP in some clever way:
struct omap_opp {
struct hwmod foo;
struct opp opp;
};
container_of() is your friend.
Alternatively and not as elegant is to provide an
void *private_data; in the generic opp struct.
And similar design patterns for code and other
platform-specific hooks. Overridable struct opp_ops
for example, the same way we just abstracted the
l2x0 operations for example.
It's not like there are no precedents in the linux kernel
on how to handle a superclass of some struct, so
how hard can it be?
The fact that a single struct member is OMAP-specific doesn't
nix the fact that the major part of this OPP framework
is generic code.
Yours,
Linus Walleij
--
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
