Hello,
Good morning Mike,
I am currently travelling and as such won't be able to look at your email until Monday the 13th.
Sure thing.
Mike, thanks for the detailed answer. I'm currently in a need of a well defined kernel API for enabling a source and a sink. Generally, i need a similar functionality that sysfs provides, only in a form of kernel-mode API. I need to enable a source from everywhere in the kernel(to keep it simple, non-atomic context), and disable it. Also, enable a sink and *keep it enabled *even if a source is no longer enabled. Mike, so i understand this kind of feature isn't planned. I'm thinking about doing it myself... are Coresight patches welcomed? Is there an "easier" way of achieving what i want?
Thanks, Mike.
On Fri, Aug 10, 2018 at 4:43 PM, Mathieu Poirier <mathieu.poirier@linaro.org
wrote:
Good morning Mike,
I am currently travelling and as such won't be able to look at your email until Monday the 13th.
Thanks, Mathieu
On Fri, 10 Aug 2018 at 05:24, Mike Leach mike.leach@linaro.org wrote:
Hello,
On 7 August 2018 at 14:43, Mike Bazov mike@perception-point.io wrote:
Greetings,
I'm trying to enable the Coresight ETMv4 trace from kernel mode. I saw
there
is no documentation on how to do this, except using the sysfs user mode interface and perf.
To overcome this i looked a little bit in the coresight.h header file,
and
came to these APIs:
extern int coresight_enable(struct coresight_device *csdev); extern void coresight_disable(struct coresight_device *csdev);
And the sysfs implementation uses these APIs when enabing/disabling the trace code, so i thought this could suit my needs. The next problem was actually getting the coresight devices data structures, which aren't exported and are actually provided internally to perf and sysfs. So i exported the coresight bus type:
struct bus_type coresight_bustype = { .name = "coresight", }; EXPORT_SYMBOL(coresight_bustype);
And enumerated the bus and just looked for the type CORESIGHT_DEV_TYPE_SOURCE, since the only source on my board is ETMv4,
there
isn't any conflicts so i should get only ETMv4s.
This worked, and indeed i collected a coresight device for every CPU,
and
enabled the trace successfully while being in non-atomic context.
The problem is, i must enable the trace in atomic context
synchronously on
the current thread's CPU(i can't issue a work-queue to enable the
trace for
me). So.. i got many BUG() errors because of non-atomic API usage, for example, the allocation of the TMC-ETR buffer:
dma_alloc_coherent(drvdata->dev, etr_buf->size, &flat_buf->daddr, GFP_KERNEL);
So my questions are:
- Is there a more documented way of enabling coresight from kernel
mode? i
believe i achieved this using cheats.
Not at present. The perf and sysfs methods are those supported for users to get at trace.
- I see there is no exported kernel API to config the coresight trace
attributes(for example, filter EL0). I can only do so from sysfs.. am i missing something?
Additional kernel APIs are obviously feasible - assuming there is a need for them and resource to implement them. Evidently you have a use cases that satisfy the first condition.
We are planning updates to the system to handle complex configuration
- i.e. where muliple configurable filters / sequencers / counters need
setting from the kernel / sysfs - possibly in the form of a configuration file or some such method. This is in part to avoid having to massively overload the perf command line options to set up these configurations.
Once this is in play then this should make it easier for general configuration within the kernel.
- Are there any plans to make the Coresight infrastructure
atomic-context
friendly? If there are, is the development in progress? if not.. how would you
suggest
tackling the issues i've described in this message?
Again - no plans at present - though the lack of a more formal kernel API may have resulted in this not being considered to date. Currently enabling an ETM will result in enabling of all devices in the path to the sink being used - and with the ETR enabling results in the memory buffer for the ETR being allocated.
Assuming you are able to configure CoreSight outside an atomic context, one approach may be to allow preparatory work to happen outside the atomic-context, and leave the final enable of devices inside the atomic context. However this approach would seem to require some significant restructuring of existing code.
Matthieu Poirier - who maintains the CS drivers in the kernel and is on this list, should have further insights when he returns from vacation.
Regards
Mike
Thank you!
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight