15:20 <tomeu> hi, was wondering what imx people think of the proposed clk_set_ceiling/floor_rate API addition

15:20 <tomeu> the idea would be that thermal and devfreq drivers would set ceilign and floor rates, respectively

15:21 <tomeu> and also allow other drivers to influence the final freq rate of, for example, the memory bus

15:22 <tomeu> people working on tegra and exynos have showed interest, but was wondering about what other hw could make use of this in the short/medium term

16:03 <jnettlet> tomeu, do you have a reference email about it?

16:04 <jnettlet> I probably have an opinion as I just spent a bunch of time with the FSL bus_freq/cpu_freq addition

16:04 <jnettlet> and I am still unhappy with current thermal limiting

16:04 <tomeu> jnettlet: yup: http://thread.gmane.org/gmane.linux.ports.ppc.embedded/72052

16:05 <tomeu> my longer term goal is to allow for misc drivers to register their bandwidth needs and have the bus clock take that into account

16:05 <jnettlet> tomeu, I was thinking about an interface where a device could specify a thermal delta for various device clock speeds

16:06 <jnettlet> much like we specify a platform latency for cpu_idle states

16:08 <tomeu> jnettlet: can you extend on that? I'm not really familiar nor with thermal nor cpufreq yet

16:09 <tomeu> have only read a bit of code when looking for more users of this API

16:15 <jnettlet> sorry, distracted

16:18 <jnettlet> my thoughts are that given a cpu/gpu/voltage step provide an estimated thermal delta. Then rather than ramping up and then having to cut back we can make the decision to hold performance to keep the temperature more stable

16:19 <tomeu> that's interesting, but isn't actually related, right?

16:19 <tomeu> thermal would be one more user of this API, but would be setting a ceiling rather than the final, effective clock rate

16:26 <tomeu> jnettlet: do you have a link to your current work?

16:29 <jnettlet> tomeu, I haven't done any actually coding on this. It was just something I was working on.

16:30 <tomeu> jnettlet: oh, was thinking of the bus_freq/cpu_freq addition

16:30 <jnettlet> my FSL kernel patches upgraded to the 3.14LTS kernel will be posted within the hour

16:30 <tomeu> ok, cool

16:31 <jnettlet> it is a combination of the upstream and the FSL 3.10.17-ga

16:31 <jnettlet> although I am still working out some of the powersavings bits.

16:37 <kroon> jnettlet, FSL kernel patches for 3.14 ? Does that include the gpu drivers by any chanse ?

16:41 <jnettlet> kroon, yes. I am pushing the rough tree now. I haven't applied any of my GPU patches yet. That will be the next step.

16:41 <jnettlet> probably later tonight.

16:41 <kroon> jnettlet, that is really neat. do you host it on github somewhere ?

16:41 <jnettlet> this is most aimed at the SolidRun hardware but with a new device-tree should work with most MX6 hardware

16:42 <jnettlet> kroon, yep. one sec.

16:42 <jnettlet> kroon, what hardware are you running?

16:43 <kroon> jnettlet, the wandboards. but I think I know how to modify the dts files

18:43 <jnettlet> tomeu, let me digest your patches a bit. I see they are aimed at ppc.embedded, but touch ARM a bit. What platforms/architectures have you tested them on?