[PATCH v5 6/9] coresight: add support for CPU debug module

Sudeep Holla sudeep.holla at arm.com
Thu Mar 30 09:04:42 PDT 2017



On 30/03/17 16:46, Mathieu Poirier wrote:
> On 29 March 2017 at 19:59, Leo Yan <leo.yan at 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



More information about the linux-arm-kernel mailing list