Coresight bus and drivers from CodeAurora

Coresight bus and drivers from CodeAurora

[Linus Walleij]

Hi Pratik,

recently my colleague Magnus (@ST-Ericsson) found this bus and
implementations for the ARM Coresight and drivers for the ARM Coresight
blocks ETB, ETM, Funnel, Replicator, STM, TMC and TPIU. The
code is here:
https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=tree;f=drivers/coresight;h=f0221ea9a55c1e8bcd63f36ec28abb6d5406e63d;hb=refs/heads/msm-3.4

What is your intention with this? Do you have any intention to mainline?

We can see it has references to Qualcomm in the device tree strings even
though they are ARM Coresight HW blocks, for example, so some changes
are likely necessary, and such bindings should pass the devicetree-discuss
list.

Will: what is ARM Ltd. position on these blocks and their drivers? Any plans
from your side?

Douglas: look another STM driver... :-)

John Stultz has recently been working on some PTM extensions
submitted by Arve Hj?nnev?g as well, relating quite closely to this.

The design is nice, but maybe this is one of the few cases where the
drivers should actually live under arch/arm/common/* or similar.

Yours,
Linus Walleij

Coresight bus and drivers from CodeAurora

[Will Deacon]

Hi Linus,

On Mon, Dec 10, 2012 at 12:40:20PM +0000, Linus Walleij wrote:
> recently my colleague Magnus (@ST-Ericsson) found this bus and
> implementations for the ARM Coresight and drivers for the ARM Coresight
> blocks ETB, ETM, Funnel, Replicator, STM, TMC and TPIU. The
> code is here:
> https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=tree;f=drivers/coresight;h=f0221ea9a55c1e8bcd63f36ec28abb6d5406e63d;hb=refs/heads/msm-3.4
> 
> What is your intention with this? Do you have any intention to mainline?
> 
> We can see it has references to Qualcomm in the device tree strings even
> though they are ARM Coresight HW blocks, for example, so some changes
> are likely necessary, and such bindings should pass the devicetree-discuss
> list.
> 
> Will: what is ARM Ltd. position on these blocks and their drivers? Any plans
> from your side?
>

>From what I understand, ARM has looked at the idea of self-hosted tracing
using Coresight but we couldn't find a compelling use-case and, as such,
don't currently have any plans in this area.

That's not to say it's been written off if somebody has good use for it.
What exactly is your use-case and why is there yet another driver on the
cards? I have some personal opinions about what we should/shouldn't do in
this space, but that can come later.

> The design is nice, but maybe this is one of the few cases where the
> drivers should actually live under arch/arm/common/* or similar.

Well, if the code is useful on arm64 then a directory outside of arch/ could
be beneficial.

Cheers,

Will

Coresight bus and drivers from CodeAurora

[Paul Walmsley]

cc Alex Shishkin

Hi

On Mon, 10 Dec 2012, Will Deacon wrote:

> On Mon, Dec 10, 2012 at 12:40:20PM +0000, Linus Walleij wrote:
> > recently my colleague Magnus (@ST-Ericsson) found this bus and
> > implementations for the ARM Coresight and drivers for the ARM Coresight
> > blocks ETB, ETM, Funnel, Replicator, STM, TMC and TPIU. The
> > code is here:
> > https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=tree;f=drivers/coresight;h=f0221ea9a55c1e8bcd63f36ec28abb6d5406e63d;hb=refs/heads/msm-3.4
> > 
> > What is your intention with this? Do you have any intention to mainline?

Just as an aside, there's also already some support for ETM and ETB in 
mainline in arch/arm/kernel/etm.c.

...

We've used self-hosted tracing in the past for post-mortem kernel 
debugging.  The ARM logs traces to the ETB; the kernel crashes; then upon 
the next reboot, the trace is read from the ETB.


- Paul 

Coresight bus and drivers from CodeAurora

[Pratik Patel]

Hi Linus

On Mon, Dec 10, 2012 at 01:40:20PM +0100, Linus Walleij wrote:
> Hi Pratik,
> 
> recently my colleague Magnus (@ST-Ericsson) found this bus and
> implementations for the ARM Coresight and drivers for the ARM Coresight
> blocks ETB, ETM, Funnel, Replicator, STM, TMC and TPIU. The
> code is here:
> https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=tree;f=drivers/coresight;h=f0221ea9a55c1e8bcd63f36ec28abb6d5406e63d;hb=refs/heads/msm-3.4
> 
> What is your intention with this? Do you have any intention to mainline?
> 

Thanks for the quick evaluation. I will be working on cleaning up
the drivers for upstream submission in the coming weeks.

> We can see it has references to Qualcomm in the device tree strings even
> though they are ARM Coresight HW blocks, for example, so some changes
> are likely necessary, and such bindings should pass the devicetree-discuss
> list.
> 

Yes, will clean it up.

> Will: what is ARM Ltd. position on these blocks and their drivers? Any plans
> from your side?
> 
> Douglas: look another STM driver... :-)
> 
> John Stultz has recently been working on some PTM extensions
> submitted by Arve Hj?nnev?g as well, relating quite closely to this.
> 
> The design is nice, but maybe this is one of the few cases where the
> drivers should actually live under arch/arm/common/* or similar.
> 
> Yours,
> Linus Walleij
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Coresight bus and drivers from CodeAurora

[Linus Walleij]

On Tue, Dec 11, 2012 at 10:39 PM, Pratik Patel <pratikp@codeaurora.org> wrote:

> Thanks for the quick evaluation. I will be working on cleaning up
> the drivers for upstream submission in the coming weeks.

This is exactly what I like to hear :-)

Can you preserver the CC line from this mail on your subsequent
posts so the involved experts can follow the discussions?

It seems like keeping this new framework in drivers/ and actually refactoring
the old stuff in arch/arm/kernel/etm.c etc is the way forward, but doing that
may require some patch to support the old style of things. As the older code
may be stale maybe just depend on !CONFIG_OC_ETM is a way forward.

Yours,
Linus Walleij

Coresight bus and drivers from CodeAurora

[Jon Hunter]

On 12/12/2012 02:00 AM, Linus Walleij wrote:
> On Tue, Dec 11, 2012 at 10:39 PM, Pratik Patel <pratikp@codeaurora.org> wrote:
> 
>> Thanks for the quick evaluation. I will be working on cleaning up
>> the drivers for upstream submission in the coming weeks.
> 
> This is exactly what I like to hear :-)
> 
> Can you preserver the CC line from this mail on your subsequent
> posts so the involved experts can follow the discussions?
> 
> It seems like keeping this new framework in drivers/ and actually refactoring
> the old stuff in arch/arm/kernel/etm.c etc is the way forward, but doing that
> may require some patch to support the old style of things. As the older code
> may be stale maybe just depend on !CONFIG_OC_ETM is a way forward.

I have also been working to migrate the coresight cross-trigger
interface (CTI) helpers from Ming Lei to a driver [1]. In the current
implementation I have opted to make the CTI driver an AMBA device (like
the existing ETM and ETB drivers). Therefore, I am curious if the plan
is to migrate these other coresight devices to AMBA versus adding this
new coresight bus?

It would be good to align on a plan here for coresight devices in general.

Cheers
Jon

[1] https://github.com/jonhunter/linux/commits/dev-cti

Coresight bus and drivers from CodeAurora

[Pratik Patel]

On Wed, Dec 12, 2012 at 03:50:44PM -0600, Jon Hunter wrote:
> 
> On 12/12/2012 02:00 AM, Linus Walleij wrote:
> > On Tue, Dec 11, 2012 at 10:39 PM, Pratik Patel <pratikp@codeaurora.org> wrote:
> > 
> >> Thanks for the quick evaluation. I will be working on cleaning up
> >> the drivers for upstream submission in the coming weeks.
> > 
> > This is exactly what I like to hear :-)
> > 
> > Can you preserver the CC line from this mail on your subsequent
> > posts so the involved experts can follow the discussions?
> > 
> > It seems like keeping this new framework in drivers/ and actually refactoring
> > the old stuff in arch/arm/kernel/etm.c etc is the way forward, but doing that
> > may require some patch to support the old style of things. As the older code
> > may be stale maybe just depend on !CONFIG_OC_ETM is a way forward.
> 
> I have also been working to migrate the coresight cross-trigger
> interface (CTI) helpers from Ming Lei to a driver [1]. In the current
> implementation I have opted to make the CTI driver an AMBA device (like
> the existing ETM and ETB drivers). Therefore, I am curious if the plan
> is to migrate these other coresight devices to AMBA versus adding this
> new coresight bus?
> 
> It would be good to align on a plan here for coresight devices in general.
> 

AMBA bus is for PrimeCell devices (class 0xF) as opposed to
CoreSight devices (class 0x9).

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Coresight bus and drivers from CodeAurora

[Will Deacon]

On Thu, Dec 13, 2012 at 07:46:26AM +0000, Pratik Patel wrote:
> On Wed, Dec 12, 2012 at 03:50:44PM -0600, Jon Hunter wrote:
> > I have also been working to migrate the coresight cross-trigger
> > interface (CTI) helpers from Ming Lei to a driver [1]. In the current
> > implementation I have opted to make the CTI driver an AMBA device (like
> > the existing ETM and ETB drivers). Therefore, I am curious if the plan
> > is to migrate these other coresight devices to AMBA versus adding this
> > new coresight bus?
> > 
> > It would be good to align on a plan here for coresight devices in general.

Having glanced at your patch series (I'll find some time to review it
properly) I think it looks like the right sort of thing to be doing. The
contentious part is likely to be exposing trace data from coresight devices
to userspace in a self-hosted environment. What we absolutely do *not* want
is a collection of disparate stream decoders in the kernel with a
corresponding set of magic ioctls/filehandles to expose proprietary binary data.
 
> AMBA bus is for PrimeCell devices (class 0xF) as opposed to
> CoreSight devices (class 0x9).

Yes, but if we can re-use all of that infrastructure on the software side of
things then there's really no reason not to.

Will