[PATCH v3 1/3] AM35x: voltage: Basic initialization

Hi Abhilash,

"Koyamangalath, Abhilash" [off-list ref] writes:

On Fri, Sep 23, 2011 at 4:00 AM, Hilman, Kevin wrote:

quoted

Hi Abhilash, Abhilash K V [off-list ref] writes:

quoted

This patch adds the basic initialization of voltage layer for
AM35x. Since AM35x doesn't support voltage scaling,

I must admit to still being confused by this series.  This patch
says AM35x doesn't support voltage scaling, and the next patch adds
PMIC support, and registers it with the voltage layer.  However,
with each voltdm->scalable flag set to false, none of the PMIC
values will ever be used (by the current voltage layer.)  Do you
have more patches on top of this that extend the voltage layer to
directly use the PMIC instead of using VC or VP?  I'm assuming we
have some more assumptions in our current voltage layer about the
presence of VC/VP that are wrong and need to be fixed.  Now that the
big voltage layer cleanup is done, I am *very* interested in getting
rid of any more assumptions we have in that code about how devices
are hooked up with PMICs.  Can you summarize how these devices are
using (or want to use) the voltage layer?

[Abhilash K V] Your concerns are grave and am trying to address most,
however these are the only points I can make outright:

- AM35x has just one voltage domain, so I tried having only one entry
in voltagedomains_omap3[ ] ( and calling it "mpu_core", maybe or "mpu"
or "core" ?).  

Based the TRM, it's called core.

Either ways, some power-domain, say mpu_pwrdm would try
looking for the "mpu_iva" volt-domain and return error, this happens
for most powerdomains as their constituent volt-domains are hard-coded
(and so unavailable on am35xx). Changing the code (which will be
massive) there going against our initial premise that am35xx is still
a "type of" omap3 SoC.

While the AM35x is similar to the OMAP3 in many ways, in terms of power,
there are some significant differences that we need to model properly.

The problem with the current approach is it's trying to trick the core
code into thinking an AM35x is like an OMAP34xx by creating voltage
domains that don't exist in hardware.  

The point of these voltage/power/clock domain data files is to represent
*exactly* what is in hardware.

Looking closer at SPRUGR0B, I don't think you should be directly using
the 34xx powerdomains as a starting point.  There are a few reasons:

- not all 34xx powerdomains exist on AM35x (at least cam, iva2, USB host
  are missing)
- AM35x powerdomains are in different voltage domains
- AM35x powerdomains do not support retention or off (only on and inactive
  according to SPRUGR0B)

- TPS65023 PMIC code was originally included as a starting point to
support a omap34xx (with SR disabled maybe) with power supplied by a
TPS65023. Yes,I agree that since this looks more of like hypothetical
scenario right now and so we can do without the addition of file
pmic_tps65023.c for now as it doesn't provide any support for scaling.

I see now.

Adding support for that PMIC to the kernel is fine, I just don't think
it makes sense in context of this series for this device, since it does
not support voltage scaling, and AFAICT, this PMIC is for DVS uses.

Kevin