From mboxrd@z Thu Jan 1 00:00:00 1970 From: kim.phillips@arm.com (Kim Phillips) Date: Thu, 15 Jun 2017 09:45:15 -0500 Subject: [PATCH 00/17] coresight: next v4.12-rc4 In-Reply-To: References: <1496693718-9191-1-git-send-email-mathieu.poirier@linaro.org> <20170609175339.28d1d4d5a6c91a9e16c16bf7@arm.com> <20170613161712.f1f3cac734939d8728c7ed77@arm.com> <20170614062229.GA28496@leoy-ThinkPad-T440> <20170615084006.e72662514e1d5b85e7af8ada@arm.com> Message-ID: <20170615094515.62864944acaf7271817d2544@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, 15 Jun 2017 15:02:21 +0100 Suzuki K Poulose wrote: > On 15/06/17 14:40, Kim Phillips wrote: > > On Thu, 15 Jun 2017 14:08:09 +0100 > > Suzuki K Poulose 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