Messages in this thread | | | Subject | Re: [PATCH v5 6/9] coresight: add support for CPU debug module | From | Sudeep Holla <> | Date | Thu, 30 Mar 2017 17:04:42 +0100 |
| |
On 30/03/17 16:46, Mathieu Poirier wrote: > On 29 March 2017 at 19:59, Leo Yan <leo.yan@linaro.org> 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
| |