On 30/03/17 16:46, Mathieu Poirier wrote: > On 29 March 2017 at 19:59, Leo Yan <leo.yan@xxxxxxxxxx> wrote: >> On Wed, Mar 29, 2017 at 10:55:35AM -0600, Mathieu Poirier wrote: >> >> [...] >> >>>> So this is why add "idle_constraint" as a central place to control >>>> power domain for CPU debug purpose and I also think this is more >>>> friendly for hardware design, e.g. some platforms can enable partial >>>> low power states to save power and avoid overheat after using this >>>> driver. >>>> >>>> How about you think for this? >>> >>> Like Sudeep pointed out we should concentrate on doing the right thing, >>> that is work with EDPRSR.PU, EDPRCR.COREPURQ and EDPRCR.CORENPDRQ. >> >> Agree, and I think we have aligned for this. >> >>> Anything outside of that becomes platform specific and can't be handled in >>> this driver. >> >> Sorry I argue a bit for this just want to make things more clear and >> if can have better method. >> >> Though the issue is platform specific, but the code is to seek common >> method to handle them. So the driver has no any platform specific code. > > Seeking a common way to handle platform specific problems doesn't > scale and will never be encompassing. There will always be a quirk > somewhere to deal with, hence the idea of keeping things separate. > I completely agree and just responded to the original patch. >> >> I read again for Suziki's suggestion: "4) Should document the fact that, >> on some platforms, the user may have to disable CPUidle explicitly to >> get the driver working. But let us not make it the default. The user >> with a not so ideal platform could add "nohlt" and get it working." > > Suzuki and I are expressing the same view using different words. > +1, as I just mentioned on the patch, we can warn user to take action when this feature gets enabled to get desired result and *nothing more* than that. Please drop all these pm_qos stuff. -- Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
