Hi Amit,
Is there anyone working on a SoC bus framework? The bus framework can manage the bus fabric, ddr, OCRAM clocks. When a device driver become working, it tells bus framework, cpu may access me (ip bus and related bus fabric on), I'm also a bus master, may access ddr (ddr dma access +1 ). For bus framework, if ddr dma access request is zero, ddr clk can be disabled in WFI/wait mode. The bus framework manage the SoC bus topology. If a bus switch use count is zero, it can be disabled. It may even adjust the bus freq dynamically according to bus request.
Thanks Richard
On Wed, Oct 26, 2011 at 9:40 AM, Richard Zhao richard.zhao@linaro.org wrote:
Hi Amit,
Is there anyone working on a SoC bus framework? The bus framework can manage the bus fabric, ddr, OCRAM clocks. When a device driver become working, it tells bus framework, cpu may access me (ip bus and related bus fabric on), I'm also a bus master, may access ddr (ddr dma access +1 ). For bus framework, if ddr dma access request is zero, ddr clk can be disabled in WFI/wait mode. The bus framework manage the SoC bus topology. If a bus switch use count is zero, it can be disabled. It may even adjust the bus freq dynamically according to bus request.
There is a PM QoS framework still in proposal I guess, not really sure if the above requirements can be addressed though.
On 11 Oct 26, Richard Zhao wrote:
Hi Amit,
Is there anyone working on a SoC bus framework? The bus framework can manage the bus fabric, ddr, OCRAM clocks. When a device driver become working, it tells bus framework, cpu may access me (ip bus and related bus fabric on), I'm also a bus master, may access ddr (ddr dma access +1 ). For bus framework, if ddr dma access request is zero, ddr clk can be disabled in WFI/wait mode. The bus framework manage the SoC bus topology. If a bus switch use count is zero, it can be disabled. It may even adjust the bus freq dynamically according to bus request.
Why can't this be handled in the PM runtime framework? Bus runtime drivers retain the logic for enabling/disabling the clocks and regulators required for the bus.
/Amit
On 26 October 2011 14:39, Amit Kucheria amit.kucheria@linaro.org wrote:
On 11 Oct 26, Richard Zhao wrote:
Hi Amit,
Is there anyone working on a SoC bus framework? The bus framework can manage the bus fabric, ddr, OCRAM clocks. When a device driver become working, it tells bus framework, cpu may access me (ip bus and related bus fabric on), I'm also a bus master, may access ddr (ddr dma access +1 ). For bus framework, if ddr dma access request is zero, ddr clk can be disabled in WFI/wait mode. The bus framework manage the SoC bus topology. If a bus switch use count is zero, it can be disabled. It may even adjust the bus freq dynamically according to bus request.
Why can't this be handled in the PM runtime framework? Bus runtime drivers retain the logic for enabling/disabling the clocks and regulators required for the bus.
Yes, I think it could be part of PM runtime framework. I just need the function described above. Can we do that now?
Regards Richard
/Amit
On Wed, Oct 26, 2011 at 3:36 AM, Richard Zhao richard.zhao@linaro.org wrote:
On 26 October 2011 14:39, Amit Kucheria amit.kucheria@linaro.org wrote:
On 11 Oct 26, Richard Zhao wrote:
Hi Amit,
Is there anyone working on a SoC bus framework? The bus framework can manage the bus fabric, ddr, OCRAM clocks. When a device driver become working, it tells bus framework, cpu may access me (ip bus and related bus fabric on), I'm also a bus master, may access ddr (ddr dma access +1 ). For bus framework, if ddr dma access request is zero, ddr clk can be disabled in WFI/wait mode. The bus framework manage the SoC bus topology. If a bus switch use count is zero, it can be disabled. It may even adjust the bus freq dynamically according to bus request.
Why can't this be handled in the PM runtime framework? Bus runtime drivers retain the logic for enabling/disabling the clocks and regulators required for the bus.
Yes, I think it could be part of PM runtime framework. I just need the function described above. Can we do that now?
I think we need to gather more requirements first. PM Runtime makes good sense for enabling/disabling clocks. On chips like OMAP there is lots of hardware auto-clock gating, so that makes less sense for us.
On the other hand I think we all need to control bus speed. If you have some performance counters then maybe you can use devfreq for this, or if you are able to express your needs from drivers then PM QoS starts to look appropriate.
Paul Walmsley has brought up this issue before and I've CC'd him. In the past some ideas have been for two devices and a throughput value to be used in an API that might look something like:
pm_qos_tput_constraint(struct device *from, struct device *to, unsigned long tput);
So I think separate needs have been identified: 1) clock enable/disable for a bus a) pm runtime is probably a good idea for this 2) clock rate change/dvfs for a bus a) devfreq makes sense if you are relying on performance counters/governor to change bus rate i) see http://git.infradead.org/users/kmpark/linux-2.6-samsung/commitdiff/eb92dfe78... b) pm qos makes sense if you want drivers to express their needs via an API
Just food for thought.
Regards, Mike
Regards Richard
/Amit
On Wed, Oct 26, 2011 at 7:46 AM, Mike Turquette mturquette@linaro.org wrote:
On Wed, Oct 26, 2011 at 3:36 AM, Richard Zhao richard.zhao@linaro.org wrote:
On 26 October 2011 14:39, Amit Kucheria amit.kucheria@linaro.org wrote:
On 11 Oct 26, Richard Zhao wrote:
Hi Amit,
Is there anyone working on a SoC bus framework?
Hi all,
I thought I'd bring this topic back from the dead and CC Jean Pihet. Jean has been working on various aspects of PM QoS including per-device constraints. Device/bus throughput is of interest to him so I thought I'd make introductions.
Regards, Mike
The bus framework can manage the bus fabric, ddr, OCRAM clocks. When a device driver become working, it tells bus framework, cpu may access me (ip bus and related bus fabric on), I'm also a bus master, may access ddr (ddr dma access +1 ). For bus framework, if ddr dma access request is zero, ddr clk can be disabled in WFI/wait mode. The bus framework manage the SoC bus topology. If a bus switch use count is zero, it can be disabled. It may even adjust the bus freq dynamically according to bus request.
Why can't this be handled in the PM runtime framework? Bus runtime drivers retain the logic for enabling/disabling the clocks and regulators required for the bus.
Yes, I think it could be part of PM runtime framework. I just need the function described above. Can we do that now?
I think we need to gather more requirements first. PM Runtime makes good sense for enabling/disabling clocks. On chips like OMAP there is lots of hardware auto-clock gating, so that makes less sense for us.
On the other hand I think we all need to control bus speed. If you have some performance counters then maybe you can use devfreq for this, or if you are able to express your needs from drivers then PM QoS starts to look appropriate.
Paul Walmsley has brought up this issue before and I've CC'd him. In the past some ideas have been for two devices and a throughput value to be used in an API that might look something like:
pm_qos_tput_constraint(struct device *from, struct device *to, unsigned long tput);
So I think separate needs have been identified:
- clock enable/disable for a bus
a) pm runtime is probably a good idea for this 2) clock rate change/dvfs for a bus a) devfreq makes sense if you are relying on performance counters/governor to change bus rate i) see http://git.infradead.org/users/kmpark/linux-2.6-samsung/commitdiff/eb92dfe78... b) pm qos makes sense if you want drivers to express their needs via an API
Just food for thought.
Regards, Mike
Regards Richard
/Amit
-
Amit Kucheria -
Eric Miao -
Mike Turquette -
Richard Zhao