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 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. > > So I'm not strong to resist and if this is alignment yet, I should > document well for this but doesn't handle it in driver (keep driver > simple). > > Thanks, > Leo Yan -- 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
