Re: [PM-WIP/voltdm_c][PATCH 06/11] OMAP4: PM: VC: fix channel bit offset for MPU

[Kevin Hilman <khilman@ti.com>]

"Menon, Nishanth" <nm@ti.com> writes:

[...]

>>
>>> to handle this on the fly, add a structure to describe this
>>> and use the structure for vc44xx mpu definition. use the
>>> default for rest of the domains.
>>
>> IMO, while it makes us generate a few more struct in the data, I think
>> it's cleaner to not treat this as an exception.  IOW, just define
>> the channel struct(s) in each data file, so every VC has one associated
>> with it.  Probably also need a WARN() and graceful failure during init
>> if a channel doesn't have a channel config defined.
> ..
>
>>
>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>> ---
>>>  arch/arm/mach-omap2/vc.c          |   35 +++++++++++++++++++----------------
>>>  arch/arm/mach-omap2/vc.h          |   33 +++++++++++++++++++++++++++++++++
>>>  arch/arm/mach-omap2/vc44xx_data.c |   10 ++++++++++
>>>  3 files changed, 62 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
>>> index f8185d2..2add945 100644
>>> --- a/arch/arm/mach-omap2/vc.c
>>> +++ b/arch/arm/mach-omap2/vc.c
> [..]
>>>
>>> +     /* if there is an exception case, use the exception data */
>>> +     if (!vc->cfg_ch_data)
>>> +             cfg_channel_data = &cfg_channel_common;
>>> +     else
>>> +             cfg_channel_data = vc->cfg_ch_data;
>>
>> Based on the above,  this block could be dropped, and...
>
> Except I will have to replicate this for OMAP3 and 4 - which is
> possible.. but replicated data which is needed only during init

Yes, but remember we are trying to keep data separated from code.
Eventually, much of this data will likely be migrated to the device
tree, so we want to be sure our data is cleanly separated from code.

> :( did not want vc pointer to contain __initdata pointer (dangling
> ones after boot)

Yes, so far, we're not using initdata for per-SoC stuff, and there have
been proposals around that.  However, moving to device tree will largely
solve the per-SoC bloat issues around that.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html