> -----Original Message-----
> From: Menon, Nishanth
> Sent: Thursday, February 24, 2011 12:14 AM
> To: Premi, Sanjeev
> Cc: linux-omap@xxxxxxxxxxxxxxx
> Subject: Re: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
>
> On Wed, Feb 23, 2011 at 23:28, Sanjeev Premi <premi@xxxxxx> wrote:
> > Add glue logic to hook-up AM35x processors
> > with TPS65023.
> >
> > Signed-off-by: Sanjeev Premi <premi@xxxxxx>
>
> [...]
> > +/**
> > + * TBD: Just a copy of OMAP3 PMIC info.
> > + * Many fields below don't make much sense for AM3517,
> > + * but keeping them as is for now.
> > + */
> > +static struct omap_volt_pmic_info am3517_volt_info = {
> > + .slew_rate = 4000,
> > + .step_size = 25000,
> > + .on_volt = 1200000,
> > + .onlp_volt = 1000000,
> > + .ret_volt = 975000,
> > + .off_volt = 600000,
> > + .volt_setup_time = 0xfff,
> > + .vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
> > + .vp_vstepmin = OMAP3_VP_VSTEPMIN_VSTEPMIN,
> > + .vp_vstepmax = OMAP3_VP_VSTEPMAX_VSTEPMAX,
> > + .vp_vddmin = OMAP3430_VP2_VLIMITTO_VDDMIN,
> > + .vp_vddmax = OMAP3430_VP2_VLIMITTO_VDDMAX,
> > + .vp_timeout_us = OMAP3_VP_VLIMITTO_TIMEOUT_US,
> > + .i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
> > + .pmic_reg = OMAP3_VDD_CORE_SR_CONTROL_REG,
> > + .vsel_to_uv = tps65023_vsel_to_uv,
> > + .uv_to_vsel = tps65023_uv_to_vsel,
> > +};
> I see your point in http://marc.info/?l=linux-omap&m=129847126805656&w=2
> "Check the definition of omap_volt_pmic_info and omap_volt_data.
>
> Just to "hack" support we can fill *don't care* values for the
> fields not supported and wrap processing under if (cpu_is_....())
> checks; but this doesn't appear to be a good solution"
> PMIC specific data:
> > + .slew_rate = 4000,
> > + .step_size = 25000,
>
> SoC specific data + PMIC limits:
> > + .on_volt = 1200000,
> > + .onlp_volt = 1000000,
> > + .ret_volt = 975000,
> > + .off_volt = 600000,
>
> I dont like the following at all!
> > + .volt_setup_time = 0xfff,
>
> SOC specific
> > + .vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
> > + .vp_vstepmin = OMAP3_VP_VSTEPMIN_VSTEPMIN,
> > + .vp_vstepmax = OMAP3_VP_VSTEPMAX_VSTEPMAX,
> > + .vp_vddmin = OMAP3430_VP2_VLIMITTO_VDDMIN,
> > + .vp_vddmax = OMAP3430_VP2_VLIMITTO_VDDMAX,
> > + .vp_timeout_us = OMAP3_VP_VLIMITTO_TIMEOUT_US,
>
> PMIC speciic
> > + .i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
> > + .pmic_reg = OMAP3_VDD_CORE_SR_CONTROL_REG,
> > + .vsel_to_uv = tps65023_vsel_to_uv,
> > + .uv_to_vsel = tps65023_uv_to_vsel,
>
> Yeah they ought to be split properly IMHO.
[sp] Gr8. Good abstraction of PMIC functions and SoC functions
related to VC/PC would be necessary. More importantly
keeping the interfaces pluggable for different PMICs.
~sanjeev
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
