[PATCH 00/17] coresight: next v4.12-rc4

[Kim Phillips]

On Thu, 15 Jun 2017 15:02:21 +0100
Suzuki K Poulose <Suzuki.Poulose at arm.com> wrote:

> On 15/06/17 14:40, Kim Phillips wrote:
> > On Thu, 15 Jun 2017 14:08:09 +0100
> > Suzuki K Poulose <Suzuki.Poulose at arm.com> wrote:
> >
> >> On 14/06/17 07:22, Leo Yan wrote:
> >>> Hi Kim,
> >>>
> >>> On Tue, Jun 13, 2017 at 04:17:12PM -0500, Kim Phillips wrote:
> >>>
> >>> [...]
> >>>
> >>>>>> Also, do the current juno platforms not have CPU debug modules?  I'd
> >>>>>> like to test the new driver.
> >>>>>
> >>>>> By all means - Leo pointed out the patch adding the CPU debug entries in
> >>>>> the DT  file for Juno.
> >>>>
> >>>> Thanks, I applied it, was able to
> >>>> toggle /sys/kernel/debug/coresight_cpu_debug/enable, but wasn't sure
> >>>> how to trigger the cpu debug output...
> >>>
> >>> You could trigger panic flow with command, then can see CPU debug output:
> >>> echo c > /proc/sysrq-trigger
> >>
> >> I think, may be we should provide a handle to trigger the CPU debug dump
> >> manually, rather than using it only for panic. Something like :
> >>
> >> echo 1 > /sys/kernel/debug/coresight_cpu_debug/trigger
> >>
> >> Thoughts ?
> >
> > what's the use-case?  I just wanted to do a simple test, and although
> > it halted my machine, the sysrq-trigger switch did the job.
> 
> Get the CPU dump without crashing the system, when the CPU is looping
> indefinitely (with interrupts disabled) ? sysrq-t doesn't tell you where
> the task/CPU is at if it is in running state. This can augment the details
> by providing the PC. Sure, you can also do this by crashing the system
> as above. But it doesn't hurt to provide the same without the crash.

Can sysrq-t be amended, or another sysrq- dump mechanism - like 'v'
which apparently causes an ETM buffer dump [ARM-specific] - be used
instead?

> > I'm personally not a huge fan of adding more switches, rather for doing
> > the right thing on behalf of the user in the first place.  E.g., in the
> > case of cpu debug, if configured =y, I don't think it would necessarily
> > harm the simple user to have it always be enabled, at boot time and
> > beyond, thereby doing away with the .../coresight_cpu_debug/enable
> 
> The reasoning behind this is to avoid keeping the debug power domain on
> until someone really wants it enabled, so that one can use a single kernel
> image in production/development and be able to switch things on at runtime.

OK, thanks for explaining the trade-off.

> > switch and kernel command line option.  If there are users that want to
> > turn it on and off dynamically, that can be done by loading and
> > unloading the module.
> 
> Sure, if someone is building it as a module, they have the luxury. But
> this may not be always useful, e.g, crashes at early boot.

the thinking was that one could set it to =y at that point, but, yes,
point taken.

Kim