On Wed, Apr 27, 2011 at 12:49, Colin Cross <ccross@xxxxxxxxxx> wrote: +l-o > I'm a little confused about the design for this, and OPP as well. OPP > matches a struct device * and a frequency to a voltage, which is not a > generically useful pairing, as far as I can tell. On Tegra, it is > quite possible for a single device to have multiple clocks that each > have different voltage requirements, for example the display block can > have an interface clock as well as a pixel clock. Simplifying this to > dev + freq = voltage seems very OMAP specific, and will be difficult > or impossible to adapt to Tegra. We have the same requirements as well(iclk,fclk,pixclk etc..)! We group them under voltage domains in OMAP ;). if your issue was a ability to have a single freq to a OPP, it is upto SoC to do the proper mapping. Concept of an OPP still remains consistent - which is for a voltage, there is only so much freq you can drive that specific module to. > Moreover, from a silicon perspective, there is always a simple link > from a single frequency to a minimum voltage for a given circuit. > There is no need to group them into OPPs, which seem to have a group > of clocks and their frequencies that map to a single voltage. That is > an artifact of the way TI specifies voltages. > > I don't think DVFS is even the right place for any sort of governor. > DVFS is very simple - to increase to a specific clock speed, the > voltage must be immediately be raised, with minimum or no delay, to a > specified value that is specific to that clock. When the frequency is > lowered, the voltage should be decreased. There is a tiny bit of > policy to determine when to delay dropping the voltage in case the > frequency will immediately be raised again, but nowhere near the > complexity of what is shown here. > > I proposed in a different thread on LKML that DVFS be handled within > the generic clock implementation. Platforms would register a > regulator and a table of voltages for each struct clock that required > DVFS, and the voltages would be changed on normal clk_* requests. > This maintains compatibility with existing clk_* calls. It is upto SoC frameworks to implement the transitions. E.g. lets look at scalability: How'd the mechanism proposed work with temperature variances: Example: I dont want to hit 1.5GHz if temp >70C - wont it be an SoC specific hack I'd need to introduce? All OPP framework does is store that maps, and leaves it to users to choose regulators, clock framework variances, SoC temperature sensors or what ever mechanisms they choose to allow through a transition. > There is a place for a GPU, etc., frequency governor, but it is a > completely separate issue from DVFS, and should not be mixed in. I > could have a GPU that is not voltage scalable, but could still benefit > from lowering the frequency when it is not in use. A devfreq > interface sounds perfect for this, as long as it only ends up calling > clk_* functions, and those functions handle getting the voltage > correct. Regards, Nishanth Menon PS: https://lists.linux-foundation.org/pipermail/linux-pm/2011-April/031113.html for start of thread -- 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
