[PATCH 3/3] OMAP2+: voltage: reorganize, split code from data

Paul Walmsley paul at pwsan.com
Mon Feb 21 13:53:27 EST 2011


Hello

On Mon, 21 Feb 2011, Gulati, Shweta wrote:

> On Mon, Feb 21, 2011 at 7:38 AM, Paul Walmsley <paul at pwsan.com> wrote:
> > diff --git a/arch/arm/mach-omap2/opp3xxx_data.c b/arch/arm/mach-omap2/opp3xxx_data.c
> > index 0486fce..3c7f0c0 100644
> > --- a/arch/arm/mach-omap2/opp3xxx_data.c
> > +++ b/arch/arm/mach-omap2/opp3xxx_data.c

...

> > +/* VDD2 */
> > +struct omap_volt_data omap36xx_vddcore_volt_data[] = {
> > +       VOLT_DATA_DEFINE(OMAP3630_VDD_CORE_OPP50_UV, OMAP3630_CONTROL_FUSE_OPP50_VDD2, 0xf4, 0x0c),
> > +       VOLT_DATA_DEFINE(OMAP3630_VDD_CORE_OPP100_UV, OMAP3630_CONTROL_FUSE_OPP100_VDD2, 0xf9, 0x16),
> > +       VOLT_DATA_DEFINE(0, 0, 0, 0),
> > +};
> > +
> The definition of "VOLT_DATA_DEFINE" is there in voltage.h
> I think its better to move these Volt_data to voltagedomains files
> rather than in
> OPP layer files

opp*_data.c is currently where process/wafer/die-variable parameters go.  
The struct omap_volt_data also consists mostly[1] of 
process/wafer/die-variable parameters.  So it made sense to group it 
there.

In comparison, voltagedomains*_data.c files consist of 
process/wafer/die-invariant data, such as register layouts, voltage domain 
partitioning, etc.  This is data that we don't expect to ever change over 
the lifetime of a production design.

You are correct in that there seems to be little point leaving the 
VOLT_DATA_DEFINE macro in voltage.h, so I have moved this to 
omap_opp_data.h.


- Paul

1. The SCM register offsets in the struct omap_volt_data don't technically 
belong in the process/wafer/die-variable parameters.  It probably would 
make sense to replace these with SCM OPP IDs, and then to create an 
interface in the SCM code to fetch the SR data from the SCM, given an OPP 
ID.


More information about the linux-arm-kernel mailing list