On Wed, Oct 26, 2011 at 7:46 AM, Mike Turquette <mturque...@linaro.org> wrote: > 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?
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: > 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
