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:
> >
> > 1) 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.
>
> > 2) 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.
>
> > 3) 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