On Wed, Oct 26, 2011 at 3:36 AM, Richard Zhao <richard.z...@linaro.org> wrote:
> On 26 October 2011 14:39, Amit Kucheria <amit.kuche...@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/eb92dfe7893e23d004baf7758514768c49486d98?hp=5e3396894b50697b84db559c1589b4b7ce893b15
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
>>
>>
>
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
