RE: [PATCH 1/1] OMAP3: PM: Fix compilation issue of omap3_pm_init_opp_table

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



________________________________________

>there are multiple ways to use SR -> Not all of them can use OMAP chip
>registers. certain class of devices would need to use PMICs,
Even then you do not need OPP layer. For PMIC based solutions you need
to use I2C to get the voltage. So this should be abstracted. OPP layer is just for
CPU FREQ.
> further SRF
>or it's equivalent will need to query the table for knowing what voltage
>corresponds to frequency, 
Why should you know the voltage for a frequency other than your current
frequency when you do not scale the frequency of your CPU? Clock framework
will give you the current freq. For voltage, we already discussed above.


>DSPBRidge needs to report to the baseimage
>what voltage corresponds to the frequency for the baseimage's load
>balancing/power decision logic etc.. in short when dynamic voltage
>scaling is needed, we need OPP layer a.k.a CONFIG_PM needs opp layer -
>not just cpufreq.
Please understand CONFIG_PM is not for any kind of __cpufreq or dspfreq__.
It is for suspend resume and few other stuff. So why should CONFIG_PM need
OPP layer?



--
Regards,
Nishanth Menon--
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

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux