On Thu, 04 Jul 2013 10:36:53 +0530, Viresh Kumar wrote: > Hi Lukasz, > > Sorry for being late. Actually I didn't had an answer to your mail > and wanted to go through it with some fresh mind. This is my > first mail this morning, lets see if I can bring something good > into the discussion. > > On 1 July 2013 13:45, Lukasz Majewski <l.majewski@xxxxxxxxxxx> wrote: > > Does anybody have any idea here? As written above, thermal is > > suitable to disable boost. > > See, one thing is very clear. User space applications aren't > responsible for enabling boost again and again. There has to be a > internal mechanism inside kernel for that. > > > I'd like to bring those three options under discussion: > > > > 1. boost attr is always exported -> do not enable boost > > automatically when disabled by thermal (as it was proposed at v4). > > So, that's a problem. I see one more solution to that. > - Create another Macro in cpufreq.c which would contain the time > after which we will autoenable boost. > - So, suppose thermal disabled it due to high temperature (Lets not > change value of sysfs variable boost_enable, but create another > variable like: skip_boost: which means skip boost temporarily). > - Thermal would enable this variable skip_boost. > - Then we will continue to get requests for next frequency and will > check eveytime if we have exceeded time for autoenabling boost. > - If yes, then we disable this variable and start boosting again.. > - Then thermal can disable it again later. > > This variable (time for autoenable) looks to be more platform > dependent for now, but lets don't make it like that unless somebody > needs it. > > > 2. boost attr is always exported -> find a way to enable boost after > > emergency disablement when thermal detects overheating (newest > > proposition). > > My solution above probably. This is a possible solution, but I've already modified thermal code a bit and found a solution for the problem. I use thermal workqueue (which is already in place anyway) to enable the boost again. Due to that I can provide behaviour similar to HW controlled boost. Patches with this solution are already prepared. I will post them in a few hours. Ok? > > > 3. boost attr only exported at x86 (when supported) > > boost attr NOT exported via sysfs for SW controlled boost (e.g. > > Exynos ARM). > > > > Then we only enable/disable boost at kernel and don't need to > > take care of the user space interaction. This scenario is my use > > case. I hadn't planned to expose boost to userspace and use it with > > LAB as a kernel API. > > Userspace must have control of this feature after kernel is built. > That kernel image may run for ever without changing in a product. > > @Rafael: How crazy do you think my solution is? :) -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
