Skip to content

Remove unused voltagedomain data for AM33xx

Nishanth Menon linux-arm-kernel linux-omap 1 version New

Get series with b4
b4 am 20130614131457.GA7569@kahuna

Versions newest first

  1. v1 Latest0 of 2 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 2 patches the cover letter announces are in this archive.

Reviews trailers per patch

PatchNishanth Menon
SeriesA-b

Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.

Read the v1 thread

Cover letter [PATCH 0/2] Remove unused voltagedomain data for AM33xx
Quoted 10 lines · Paul Walmsley

cc Kevin, Vaibhav

Quoted 6 lines · Rajendra Nayak

The powerdomain framework today expects to always have a voltagedomain associated with a given powerdomain. We already have AM33xx which has no Voltage Controller/Voltage Processor as part of PRCM. There are more SoCs' to follow starting with AM437x and DRA7xx which do not have VC/VP.

Quoted 6 lines
Quoted 3 lines

Instead of adding dummy voltage domain data files, make the powerdomain framework aware of the fact that some SoCs' might not really have scalable voltage domains.

Fine with me in principle if AM335x doesn't support voltage scaling. Vaibhav, if this is okay for you, please ack it.

just a nitpick :)
There is no VFSM auto scaling to retention voltage, nor is VC-VP IP available here, but that does not mean DVFS voltage scaling does not exist - it is done with traditional regulator framework using regular shared I2C.

We now seem to be moving to a generation of SoCs where VC-VP has been dumped in favor of allowing integration with PMIC which may talk SPI/I2C over standard interfaces - this allows us to reach better product options, but gives up on extreme low power scenarios we had seen in the past on OMAP.
Overall, I love this idea.

Quoted 3 lines

Then, in terms of merging, probably Kevin would be the right person for this since he's done much of the voltagedomain work.

Signature · 2 lines
Regards,
Nishanth Menon