CoreSight framework and drivers

drivers/coresight/coresight-tmc.c new file +17 -0

+static void __tmc_etb_dump(struct tmc_drvdata *drvdata)
+{
+	enum tmc_mem_intf_width memwidth;
+	uint8_t memwords;
+	char *bufp;
+	uint32_t read_data;
+	int i;
+
+	memwidth = BMVAL(tmc_readl(drvdata, CORESIGHT_DEVID), 8, 10);
+	if (memwidth == TMC_MEM_INTF_WIDTH_32BITS)
+		memwords = 1;
+	else if (memwidth == TMC_MEM_INTF_WIDTH_64BITS)
+		memwords = 2;
+	else if (memwidth == TMC_MEM_INTF_WIDTH_128BITS)
+		memwords = 4;
+	else
+		memwords = 8;

drivers/coresight/coresight-tmc.c new file +3 -1

+	}
+}
+
--

Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

From: Pratik Patel <[email protected]>

This driver manages CoreSight ETB (Embedded Trace Buffer) which acts as a circular buffer sink collecting generated trace data.

Signed-off-by Pratik Patel <[email protected]>

---
 drivers/coresight/Makefile        |    2 +-
 drivers/coresight/coresight-etb.c |  467 +++++++++++++++++++++++++++++++++++++
 2 files changed, 468 insertions(+), 1 deletions(-)

drivers/coresight/coresight-etb.c new file +40 -0

+static int __devinit etb_probe(struct platform_device *pdev)
+{
+	int ret;
+	struct device *dev = &pdev->dev;
+	struct coresight_platform_data *pdata;
+	struct etb_drvdata *drvdata;
+	struct resource *res;
+	struct coresight_desc *desc;
+
+	if (pdev->dev.of_node) {
+		pdata = of_get_coresight_platform_data(dev, pdev->dev.of_node);
+		if (IS_ERR(pdata))
+			return PTR_ERR(pdata);
+		pdev->dev.platform_data = pdata;
+	}
+
+	drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
+	if (!drvdata)
+		return -ENOMEM;
+	drvdata->dev = &pdev->dev;
+	platform_set_drvdata(pdev, drvdata);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res)
+		return -ENODEV;
+
+	drvdata->base = devm_ioremap(dev, res->start, resource_size(res));
+	if (!drvdata->base)
+		return -ENOMEM;
+
+	spin_lock_init(&drvdata->spinlock);
+
+	drvdata->clk = devm_clk_get(dev, "core_clk");
+	if (IS_ERR(drvdata->clk))
+		return PTR_ERR(drvdata->clk);
+
+	ret = clk_set_rate(drvdata->clk, CORESIGHT_CLK_RATE_TRACE);
+	if (ret)
+		return ret;
+

Quoted 10 lines · pratikp at codeaurora.org

From: Pratik Patel <[email protected]>

This driver manages CoreSight ETB (Embedded Trace Buffer) which acts as a circular buffer sink collecting generated trace data.

Signed-off-by Pratik Patel <[email protected]>

---
 drivers/coresight/Makefile        |    2 +-
 drivers/coresight/coresight-etb.c |  467 +++++++++++++++++++++++++++++++++++++
 2 files changed, 468 insertions(+), 1 deletions(-)

[snip]

Quoted 40 lines

drivers/coresight/coresight-etb.c new file +40 -0

+static int __devinit etb_probe(struct platform_device *pdev)
+{
+	int ret;
+	struct device *dev = &pdev->dev;
+	struct coresight_platform_data *pdata;
+	struct etb_drvdata *drvdata;
+	struct resource *res;
+	struct coresight_desc *desc;
+
+	if (pdev->dev.of_node) {
+		pdata = of_get_coresight_platform_data(dev, pdev->dev.of_node);
+		if (IS_ERR(pdata))
+			return PTR_ERR(pdata);
+		pdev->dev.platform_data = pdata;
+	}
+
+	drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
+	if (!drvdata)
+		return -ENOMEM;
+	drvdata->dev = &pdev->dev;
+	platform_set_drvdata(pdev, drvdata);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res)
+		return -ENODEV;
+
+	drvdata->base = devm_ioremap(dev, res->start, resource_size(res));
+	if (!drvdata->base)
+		return -ENOMEM;
+
+	spin_lock_init(&drvdata->spinlock);
+
+	drvdata->clk = devm_clk_get(dev, "core_clk");
+	if (IS_ERR(drvdata->clk))
+		return PTR_ERR(drvdata->clk);
+
+	ret = clk_set_rate(drvdata->clk, CORESIGHT_CLK_RATE_TRACE);
+	if (ret)
+		return ret;
+

drivers/coresight/coresight-etb.c line 405

Quoted 10 lines

drivers/coresight/coresight-etb.c new file +10 -0

+	drvdata->buf = devm_kzalloc(dev, ETB_SIZE_WORDS * BYTES_PER_WORD,
+				    GFP_KERNEL);
+	if (!drvdata->buf)
+		return -ENOMEM;
+
+	desc = devm_kzalloc(dev, sizeof(*desc), GFP_KERNEL);
+	if (!desc)
+		return -ENOMEM;
+	desc->type = CORESIGHT_DEV_TYPE_SINK;
+	desc->subtype.sink_subtype = CORESIGHT_DEV_SUBTYPE_SINK_BUFFER;

Can a source be directly connected to a sink or do you need to have a link in between?

The reason, I ask is because on some Cortex-A8 devices we have ETM directly connected to ETB and there is no link per-se to configure.

This RFC is aimed at introducing CoreSight framework as well as individual CoreSight trace component drivers adhering to ARM CoreSight specification. Some prior discussion on this can be referred at [1].

There are 3 kinds of CoreSight trace components:

* Sources: Responsible for producing trace data to provide visibility for the associated entity.

* Links: Transport components that carry trace data.

* Sinks: Collectors for storing trace data or acting as conduits for off-chip trace data collection.

These components can be connected in various topologies to suite a particular SoCs tracing needs.

Framework is responsible for gathering and using the information about the registered CoreSight components and their connections to allow it to dynamically deduce the sequence of components representing a connection from a CoreSight source to the currently selected CoreSight sink. This helps the framework to program the correct set of components to satisfy user request.

From a million miles up, this looks like a sensible sort of design but I

Hi Pratik,

Quoted 18 lines · pratikp at codeaurora.org

This RFC is aimed at introducing CoreSight framework as well as individual CoreSight trace component drivers adhering to ARM CoreSight specification. Some prior discussion on this can be referred at [1].

There are 3 kinds of CoreSight trace components:

* Sources: Responsible for producing trace data to provide visibility for the associated entity.

* Links: Transport components that carry trace data.

* Sinks: Collectors for storing trace data or acting as conduits for off-chip trace data collection.

These components can be connected in various topologies to suite a particular SoCs tracing needs.

Quoted 6 lines

Framework is responsible for gathering and using the information about the registered CoreSight components and their connections to allow it to dynamically deduce the sequence of components representing a connection from a CoreSight source to the currently selected CoreSight sink. This helps the framework to program the correct set of components to satisfy user request.

From a million miles up, this looks like a sensible sort of design but I really think you need to talk to Jon Hunter (he's at least on CC) about this, especially where bindings are concerned. If we can get something that you both agree on, then we can include the CTI with the other coresight components and do a more in-depth review at that point.

Quoted 28 lines · Will Deacon

Hi Pratik,

Quoted 18 lines · pratikp at codeaurora.org

This RFC is aimed at introducing CoreSight framework as well as individual CoreSight trace component drivers adhering to ARM CoreSight specification. Some prior discussion on this can be referred at [1].

There are 3 kinds of CoreSight trace components:

* Sources: Responsible for producing trace data to provide visibility for the associated entity.

* Links: Transport components that carry trace data.

* Sinks: Collectors for storing trace data or acting as conduits for off-chip trace data collection.

These components can be connected in various topologies to suite a particular SoCs tracing needs.

Quoted 6 lines

Framework is responsible for gathering and using the information about the registered CoreSight components and their connections to allow it to dynamically deduce the sequence of components representing a connection from a CoreSight source to the currently selected CoreSight sink. This helps the framework to program the correct set of components to satisfy user request.

Quoted 5 lines

From a million miles up, this looks like a sensible sort of design but I really think you need to talk to Jon Hunter (he's at least on CC) about this, especially where bindings are concerned. If we can get something that you both agree on, then we can include the CTI with the other coresight components and do a more in-depth review at that point.

I need to look at these in closer detail, but there are a couple high-level items that need to be aligned on which are ...

1. Why not use the AMBA bus framework?

You mentioned before that "AMBA bus is for PrimeCell devices (class 0xF) as opposed to CoreSight devices (class 0x9)". I will not claim to be that familiar with primecell and coresight devices and there differences, but this statement does not help me understand why a new bus type is needed. Furthermore, the existing ETM and ETB driver in arch/arm/kernel/etm.c uses the AMBA bus today and so at least those coresight devices are able to use the AMBA bus type.

2. What about the existing ETM/ETB drivers?

We have existing drivers for ETM and ETB in arch/arm/kernel/etm.c. We should either move those drivers to the drivers directory or replace them with the new one. However, no point in having two drivers for the same coresight device.

Currently we use the CoreSight virtual bus to conveniently list sysfs configuration attributes for all the registered CoreSight devices.

For eg:
/sys/bus/coresight/devices/coresight-etm0/<attribute> /sys/bus/coresight/devices/coresight-etm1/<attribute> /sys/bus/coresight/devices/coresight-stm/<attribute> /sys/bus/coresight/devices/coresight-tmc-etf/<attribute>
...
...

Some of the attributes are based on device type (i.e. source, link or sink) so they will exist for all devices of that type while some are device specific.

Maybe I am misunderstanding the question but are you suggesting to register CoreSight devices to the AMBA bus instead of the CoreSight core layer code?

Will Deacon mentioned earlier that AMBA framework can be changed to accomodate devices with a different class but I am more concerned with losing some of the stuff that the core layer code does (eg. coresight_register, coresight_enable, coresight_disable in coresight.c) if we register CoreSight drivers to the AMBA bus without letting the core layer know about the device connections.

On 12/19/2012 03:24 PM, Pratik Patel wrote:

[snip]

Quoted 12 lines

Currently we use the CoreSight virtual bus to conveniently list sysfs configuration attributes for all the registered CoreSight devices.

For eg:
/sys/bus/coresight/devices/coresight-etm0/<attribute> /sys/bus/coresight/devices/coresight-etm1/<attribute> /sys/bus/coresight/devices/coresight-stm/<attribute> /sys/bus/coresight/devices/coresight-tmc-etf/<attribute>
...
...

Quoted 7 lines

Some of the attributes are based on device type (i.e. source, link or sink) so they will exist for all devices of that type while some are device specific.

Maybe I am misunderstanding the question but are you suggesting to register CoreSight devices to the AMBA bus instead of the CoreSight core layer code?

Yes exactly.

Quoted 6 lines

Will Deacon mentioned earlier that AMBA framework can be changed to accomodate devices with a different class but I am more concerned with losing some of the stuff that the core layer code does (eg. coresight_register, coresight_enable, coresight_disable in coresight.c) if we register CoreSight drivers to the AMBA bus without letting the core layer know about the device connections.

I may be missing something, but couldn't you keep all the register/enable/disable stuff but just register the device with the amba bus? Obviously some changes would need to be made.

Personally, I don't have strong feeling either way, but we have ETM/ETB drivers using AMBA today and so I am hoping we can come to agreement on this going forward.

Russell, Will, what are your thoughts?

Otherwise, looking at the code, I like what you have implemented. I still need to look closer, but I am struggling to figure out how a coresight device such as the cross-trigger-interface fits with this model. This model appears to be geared towards coresight devices used for traces purposes and are either source, links or sinks. The cross-trigger-interface is not a source or a sink. However, although you it could be considered as a link (routing events), it is not really, as it may not link to other coresight sinks/source.

In my case, I have PMU-IRQ --> CTI --> GIC. So a non-coresight source and sink. In away the CTI looks more like a 2nd-level interrupt controller than anything else. Hence, another type of coresight device may be needed in addition to source, links and sinks. Or link is extended in some way to connect to non-coresight sources/sinks.

Let me know if you have any thoughts.

Quoted 34 lines · Jon Hunter

On 12/19/2012 03:24 PM, Pratik Patel wrote:

[snip]

Quoted 12 lines

Currently we use the CoreSight virtual bus to conveniently list sysfs configuration attributes for all the registered CoreSight devices.

For eg:
/sys/bus/coresight/devices/coresight-etm0/<attribute> /sys/bus/coresight/devices/coresight-etm1/<attribute> /sys/bus/coresight/devices/coresight-stm/<attribute> /sys/bus/coresight/devices/coresight-tmc-etf/<attribute>
...
...

Quoted 7 lines

Some of the attributes are based on device type (i.e. source, link or sink) so they will exist for all devices of that type while some are device specific.

Maybe I am misunderstanding the question but are you suggesting to register CoreSight devices to the AMBA bus instead of the CoreSight core layer code?

Yes exactly.

Quoted 6 lines

Will Deacon mentioned earlier that AMBA framework can be changed to accomodate devices with a different class but I am more concerned with losing some of the stuff that the core layer code does (eg. coresight_register, coresight_enable, coresight_disable in coresight.c) if we register CoreSight drivers to the AMBA bus without letting the core layer know about the device connections.

Quoted 4 lines

I may be missing something, but couldn't you keep all the register/enable/disable stuff but just register the device with the amba bus? Obviously some changes would need to be made.

Ok, so are you referring to making CoreSight devices register with AMBA bus instead of platform bus keeping everything else intact?

Quoted 15 lines

Personally, I don't have strong feeling either way, but we have ETM/ETB drivers using AMBA today and so I am hoping we can come to agreement on this going forward.

Russell, Will, what are your thoughts?

Otherwise, looking at the code, I like what you have implemented. I still need to look closer, but I am struggling to figure out how a coresight device such as the cross-trigger-interface fits with this model. This model appears to be geared towards coresight devices used for traces purposes and are either source, links or sinks. The cross-trigger-interface is not a source or a sink. However, although you it could be considered as a link (routing events), it is not really, as it may not link to other coresight sinks/source.

Quoted 8 lines

In my case, I have PMU-IRQ --> CTI --> GIC. So a non-coresight source and sink. In away the CTI looks more like a 2nd-level interrupt controller than anything else. Hence, another type of coresight device may be needed in addition to source, links and sinks. Or link is extended in some way to connect to non-coresight sources/sinks.

Let me know if you have any thoughts.

I had left the "None" type for miscellaneous stuff but I agree it should be a separate type - maybe "debug".

Having said that I like the CTI driver you have uploaded. Need to look at it in more detail. Since CTI connections can vary between chip to chip, we need a generic way to deal with it.

--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi Pratik,

Quoted 68 lines · Pratik Patel

Quoted 34 lines · Jon Hunter

On 12/19/2012 03:24 PM, Pratik Patel wrote:

[snip]

Quoted 12 lines

Currently we use the CoreSight virtual bus to conveniently list sysfs configuration attributes for all the registered CoreSight devices.

For eg:
/sys/bus/coresight/devices/coresight-etm0/<attribute> /sys/bus/coresight/devices/coresight-etm1/<attribute> /sys/bus/coresight/devices/coresight-stm/<attribute> /sys/bus/coresight/devices/coresight-tmc-etf/<attribute>
...
...

Quoted 7 lines

Some of the attributes are based on device type (i.e. source, link or sink) so they will exist for all devices of that type while some are device specific.

Maybe I am misunderstanding the question but are you suggesting to register CoreSight devices to the AMBA bus instead of the CoreSight core layer code?

Yes exactly.

Quoted 6 lines

Will Deacon mentioned earlier that AMBA framework can be changed to accomodate devices with a different class but I am more concerned with losing some of the stuff that the core layer code does (eg. coresight_register, coresight_enable, coresight_disable in coresight.c) if we register CoreSight drivers to the AMBA bus without letting the core layer know about the device connections.

Quoted 4 lines

I may be missing something, but couldn't you keep all the register/enable/disable stuff but just register the device with the amba bus? Obviously some changes would need to be made.

Ok, so are you referring to making CoreSight devices register with AMBA bus instead of platform bus keeping everything else intact?

Quoted 15 lines

Personally, I don't have strong feeling either way, but we have ETM/ETB drivers using AMBA today and so I am hoping we can come to agreement on this going forward.

Russell, Will, what are your thoughts?

Otherwise, looking at the code, I like what you have implemented. I still need to look closer, but I am struggling to figure out how a coresight device such as the cross-trigger-interface fits with this model. This model appears to be geared towards coresight devices used for traces purposes and are either source, links or sinks. The cross-trigger-interface is not a source or a sink. However, although you it could be considered as a link (routing events), it is not really, as it may not link to other coresight sinks/source.

Quoted 8 lines

In my case, I have PMU-IRQ --> CTI --> GIC. So a non-coresight source and sink. In away the CTI looks more like a 2nd-level interrupt controller than anything else. Hence, another type of coresight device may be needed in addition to source, links and sinks. Or link is extended in some way to connect to non-coresight sources/sinks.

Let me know if you have any thoughts.

Quoted 6 lines

I had left the "None" type for miscellaneous stuff but I agree it should be a separate type - maybe "debug".

Having said that I like the CTI driver you have uploaded. Need to look at it in more detail. Since CTI connections can vary between chip to chip, we need a generic way to deal with it.

I am also interested to look at such a framework in order to have a clean implementation of the ETM, PMI/CMI (HW tracing IP on OMAP4+). I am currently busy on a driver for PMI/CMI which requires some configuration of the Coresight, ETM, ETB, ATB etc. IP blocks.

Could you send your patches to linux-arm and linux-omap mailing lists? I will be pleased to review them.

Quoted 34 lines · Jon Hunter

On 12/19/2012 03:24 PM, Pratik Patel wrote:

[snip]

Quoted 12 lines

Currently we use the CoreSight virtual bus to conveniently list sysfs configuration attributes for all the registered CoreSight devices.

For eg:
/sys/bus/coresight/devices/coresight-etm0/<attribute> /sys/bus/coresight/devices/coresight-etm1/<attribute> /sys/bus/coresight/devices/coresight-stm/<attribute> /sys/bus/coresight/devices/coresight-tmc-etf/<attribute>
...
...

Quoted 7 lines

Some of the attributes are based on device type (i.e. source, link or sink) so they will exist for all devices of that type while some are device specific.

Maybe I am misunderstanding the question but are you suggesting to register CoreSight devices to the AMBA bus instead of the CoreSight core layer code?

Yes exactly.

Quoted 6 lines

Will Deacon mentioned earlier that AMBA framework can be changed to accomodate devices with a different class but I am more concerned with losing some of the stuff that the core layer code does (eg. coresight_register, coresight_enable, coresight_disable in coresight.c) if we register CoreSight drivers to the AMBA bus without letting the core layer know about the device connections.

Quoted 4 lines

I may be missing something, but couldn't you keep all the register/enable/disable stuff but just register the device with the amba bus? Obviously some changes would need to be made.

Ok, so are you referring to making CoreSight devices register with AMBA bus instead of platform bus keeping everything else intact?

Quoted 15 lines

Personally, I don't have strong feeling either way, but we have ETM/ETB drivers using AMBA today and so I am hoping we can come to agreement on this going forward.

Russell, Will, what are your thoughts?

Otherwise, looking at the code, I like what you have implemented. I still need to look closer, but I am struggling to figure out how a coresight device such as the cross-trigger-interface fits with this model. This model appears to be geared towards coresight devices used for traces purposes and are either source, links or sinks. The cross-trigger-interface is not a source or a sink. However, although you it could be considered as a link (routing events), it is not really, as it may not link to other coresight sinks/source.

Quoted 8 lines

In my case, I have PMU-IRQ --> CTI --> GIC. So a non-coresight source and sink. In away the CTI looks more like a 2nd-level interrupt controller than anything else. Hence, another type of coresight device may be needed in addition to source, links and sinks. Or link is extended in some way to connect to non-coresight sources/sinks.

Let me know if you have any thoughts.

I had left the "None" type for miscellaneous stuff but I agree it should be a separate type - maybe "debug".

Having said that I like the CTI driver you have uploaded. Need to look at it in more detail. Since CTI connections can vary between chip to chip, we need a generic way to deal with it.

Quoted 3 lines · Pratik Patel

Ok, so are you referring to making CoreSight devices register with AMBA bus instead of platform bus keeping everything else intact?

Yes exactly. However, please note I am not saying that we should do this, and I asking what direction does the community want us to take here? Platform bus or AMBA bus?

Quoted 8 lines · Jon Hunter

Quoted 3 lines · Pratik Patel

Ok, so are you referring to making CoreSight devices register with AMBA bus instead of platform bus keeping everything else intact?

Yes exactly. However, please note I am not saying that we should do this, and I asking what direction does the community want us to take here? Platform bus or AMBA bus?

One of the issues which worries me about mixing peripheral drivers on random different buses is... what happens when we end up with a SoC which gates the APB clock at bus level (there are SoCs which gate the APB clock at peripheral level.) In other words, an APB bus only gets clocked upon request.

We can deal with that with the infrastructure we have in place in the AMBA bus layer, but not with the platform bus - we'd have to teach the platform bus driver about the special APB clock instead of having it handled primerily at the bus layer.

At least the coresight ETM peripherals make use of the APB bus. They have a whole pile of registers on the APB bus, and they have the primecell IDs stored in the last words of the peripheral, again just like the other primecell devices we have using the AMBA bus layer.

What I'd say is... why stick it on a different bus type from the other peripherals which might make things harder in the future?

Quoted 35 lines · Pratik Patel

Quoted 34 lines · Jon Hunter

On 12/19/2012 03:24 PM, Pratik Patel wrote:

[snip]

Quoted 12 lines

Currently we use the CoreSight virtual bus to conveniently list sysfs configuration attributes for all the registered CoreSight devices.

For eg:
/sys/bus/coresight/devices/coresight-etm0/<attribute> /sys/bus/coresight/devices/coresight-etm1/<attribute> /sys/bus/coresight/devices/coresight-stm/<attribute> /sys/bus/coresight/devices/coresight-tmc-etf/<attribute>
...
...

Quoted 7 lines

Some of the attributes are based on device type (i.e. source, link or sink) so they will exist for all devices of that type while some are device specific.

Maybe I am misunderstanding the question but are you suggesting to register CoreSight devices to the AMBA bus instead of the CoreSight core layer code?

Yes exactly.

Quoted 6 lines

Will Deacon mentioned earlier that AMBA framework can be changed to accomodate devices with a different class but I am more concerned with losing some of the stuff that the core layer code does (eg. coresight_register, coresight_enable, coresight_disable in coresight.c) if we register CoreSight drivers to the AMBA bus without letting the core layer know about the device connections.

Quoted 8 lines

Quoted 4 lines

I may be missing something, but couldn't you keep all the register/enable/disable stuff but just register the device with the amba bus? Obviously some changes would need to be made.

Ok, so are you referring to making CoreSight devices register with AMBA bus instead of platform bus keeping everything else intact?

Yes exactly. However, please note I am not saying that we should do this, and I asking what direction does the community want us to take here? Platform bus or AMBA bus?

Quoted 27 lines

Quoted 15 lines

Personally, I don't have strong feeling either way, but we have ETM/ETB drivers using AMBA today and so I am hoping we can come to agreement on this going forward.

Russell, Will, what are your thoughts?

Otherwise, looking at the code, I like what you have implemented. I still need to look closer, but I am struggling to figure out how a coresight device such as the cross-trigger-interface fits with this model. This model appears to be geared towards coresight devices used for traces purposes and are either source, links or sinks. The cross-trigger-interface is not a source or a sink. However, although you it could be considered as a link (routing events), it is not really, as it may not link to other coresight sinks/source.

Quoted 8 lines

In my case, I have PMU-IRQ --> CTI --> GIC. So a non-coresight source and sink. In away the CTI looks more like a 2nd-level interrupt controller than anything else. Hence, another type of coresight device may be needed in addition to source, links and sinks. Or link is extended in some way to connect to non-coresight sources/sinks.

Let me know if you have any thoughts.

I had left the "None" type for miscellaneous stuff but I agree it should be a separate type - maybe "debug".

Quoted 3 lines

Having said that I like the CTI driver you have uploaded. Need to look at it in more detail. Since CTI connections can vary between chip to chip, we need a generic way to deal with it.

Yes if you have any ideas let me know. As Will had mentioned it would be good to have a common function table all these devices could use too. I will take a closer look at what you have.

What user interface do you plan to provide for the CTI? Maybe something consistent with other CoreSight components in sysfs to allow users to enable, disable, map and unmap ???

Please let me know your thoughts.

Quoted 4 lines · Pratik Patel

What user interface do you plan to provide for the CTI? Maybe something consistent with other CoreSight components in sysfs to allow users to enable, disable, map and unmap ???

Quoted 1 line

Please let me know your thoughts.

Rather than have your current approach of dev nodes + sysfs config files for each coresight device, I think it might be better to follow something closer to ftrace and stick per-device directories under debugfs/coresight/. Then you can have a pipe file and some config files in the same directory for each component. You also don't need to do any mapping operations with this (just post-process the stream directly).

It might also be fun to play with file redirection for sources and sinks, but that's probably a bit too invasive.

Will

Quoted 5 lines · Will Deacon

Quoted 4 lines · Pratik Patel

What user interface do you plan to provide for the CTI? Maybe something consistent with other CoreSight components in sysfs to allow users to enable, disable, map and unmap ???

Quoted 9 lines

Quoted 1 line

Please let me know your thoughts.

Rather than have your current approach of dev nodes + sysfs config files for each coresight device, I think it might be better to follow something closer to ftrace and stick per-device directories under debugfs/coresight/. Then you can have a pipe file and some config files in the same directory for each component. You also don't need to do any mapping operations with this (just post-process the stream directly).

Thanks for the suggestion. I had initially debated between debugfs and sysfs but chose sysfs + dev nodes since using device attributes relieves the drivers from manually managing directories and files, its taken care of by the device and sysfs layers. Moreover, since these are physical devices, device attributes made sense at the time.

The map and unmap I was referring to was for the CTI trigger mappings. Dev nodes are currently intended to provide the raw data collected in the sinks.

Whats the advantage in using debugfs here?

Quoted 27 lines · Pratik Patel

Quoted 5 lines · Will Deacon

Quoted 4 lines · Pratik Patel

What user interface do you plan to provide for the CTI? Maybe something consistent with other CoreSight components in sysfs to allow users to enable, disable, map and unmap ???

Quoted 9 lines

Quoted 1 line

Please let me know your thoughts.

Rather than have your current approach of dev nodes + sysfs config files for each coresight device, I think it might be better to follow something closer to ftrace and stick per-device directories under debugfs/coresight/. Then you can have a pipe file and some config files in the same directory for each component. You also don't need to do any mapping operations with this (just post-process the stream directly).

Thanks for the suggestion. I had initially debated between debugfs and sysfs but chose sysfs + dev nodes since using device attributes relieves the drivers from manually managing directories and files, its taken care of by the device and sysfs layers. Moreover, since these are physical devices, device attributes made sense at the time.

The map and unmap I was referring to was for the CTI trigger mappings. Dev nodes are currently intended to provide the raw data collected in the sinks.

Quoted 1 line

Whats the advantage in using debugfs here?

The main things I like about debugfs are (a) it's a text-driven interface and easy to script with and (b) it matches what we do for ftrace.

Furthermore, it means that subtle differences between devices can be hidden in the driver and not require different vendor tools for parsing the trace data.

Quoted 10 lines · Will Deacon

Quoted 1 line · Pratik Patel

Whats the advantage in using debugfs here?

The main things I like about debugfs are (a) it's a text-driven interface and easy to script with and (b) it matches what we do for ftrace.

Furthermore, it means that subtle differences between devices can be hidden in the driver and not require different vendor tools for parsing the trace data.

Sorry for the delay and maybe I am missing something but it seems we can take care of such protocol or parsing/decoding differences even with device nodes since that seems independent of the interface used - per device debugfs attributes or per device device nodes.

CoreSight trace solution is typically a SoC wide solution and hence can get used by non-Linux processors or hardware. Using debugfs would imply compiling it and exposing all the debug knobs even if the use case was to use the CoreSight solution for something that didn't need all that.

Quoted 77 lines · Jon Hunter

Quoted 35 lines · Pratik Patel

Quoted 34 lines · Jon Hunter

On 12/19/2012 03:24 PM, Pratik Patel wrote:

[snip]

Quoted 12 lines

Currently we use the CoreSight virtual bus to conveniently list sysfs configuration attributes for all the registered CoreSight devices.

For eg:
/sys/bus/coresight/devices/coresight-etm0/<attribute> /sys/bus/coresight/devices/coresight-etm1/<attribute> /sys/bus/coresight/devices/coresight-stm/<attribute> /sys/bus/coresight/devices/coresight-tmc-etf/<attribute>
...
...

Quoted 7 lines

Some of the attributes are based on device type (i.e. source, link or sink) so they will exist for all devices of that type while some are device specific.

Maybe I am misunderstanding the question but are you suggesting to register CoreSight devices to the AMBA bus instead of the CoreSight core layer code?

Yes exactly.

Quoted 6 lines

Will Deacon mentioned earlier that AMBA framework can be changed to accomodate devices with a different class but I am more concerned with losing some of the stuff that the core layer code does (eg. coresight_register, coresight_enable, coresight_disable in coresight.c) if we register CoreSight drivers to the AMBA bus without letting the core layer know about the device connections.

Quoted 8 lines

Quoted 4 lines

I may be missing something, but couldn't you keep all the register/enable/disable stuff but just register the device with the amba bus? Obviously some changes would need to be made.

Ok, so are you referring to making CoreSight devices register with AMBA bus instead of platform bus keeping everything else intact?

Yes exactly. However, please note I am not saying that we should do this, and I asking what direction does the community want us to take here? Platform bus or AMBA bus?

Quoted 27 lines

Quoted 15 lines

Personally, I don't have strong feeling either way, but we have ETM/ETB drivers using AMBA today and so I am hoping we can come to agreement on this going forward.

Russell, Will, what are your thoughts?

Otherwise, looking at the code, I like what you have implemented. I still need to look closer, but I am struggling to figure out how a coresight device such as the cross-trigger-interface fits with this model. This model appears to be geared towards coresight devices used for traces purposes and are either source, links or sinks. The cross-trigger-interface is not a source or a sink. However, although you it could be considered as a link (routing events), it is not really, as it may not link to other coresight sinks/source.

Quoted 8 lines

In my case, I have PMU-IRQ --> CTI --> GIC. So a non-coresight source and sink. In away the CTI looks more like a 2nd-level interrupt controller than anything else. Hence, another type of coresight device may be needed in addition to source, links and sinks. Or link is extended in some way to connect to non-coresight sources/sinks.

Let me know if you have any thoughts.

I had left the "None" type for miscellaneous stuff but I agree it should be a separate type - maybe "debug".

Quoted 8 lines

Quoted 3 lines

Having said that I like the CTI driver you have uploaded. Need to look at it in more detail. Since CTI connections can vary between chip to chip, we need a generic way to deal with it.

Yes if you have any ideas let me know. As Will had mentioned it would be good to have a common function table all these devices could use too. I will take a closer look at what you have.

I had started on a CTI driver much in line with your current implementation but your approach looks good to me.

Looking at the code though, I couldn't find a way to perform a mapping between two different CTIs. Reason I ask is because we have use cases where we need to map one CTIs input to another CTIs output on the same channel.

Do you intend to support different entities within kernel to map different trig_in or trig_out on the same CTI? If so, it might probably require reference counting for the enable/disable.

What user interface do you plan to provide for the CTI? Maybe something consistent with other CoreSight components in sysfs to allow users to enable, disable, map and unmap ???

Please let me know your thoughts.

CTIs can easily be made part of the CoreSight core layer using a different type but apart from being part of the CoreSight list containing all the trace and CTI components, not sure if there is anything that is useful to do in the core layer. Need to think about this.

The code is largely based upon the existing cti helpers, which just had a cti_map_trigger() function. The use-case you described is not supported by the current helpers and so also not supported in my initial implementation (although we should add this). Hence, it would be probably best to split the cti_map_trigger() into two functions say, cti_map_triggerin() and cti_map_triggerout(), to map a trigger input/output to a channel.

Hi Pratik,

Quoted 18 lines · pratikp at codeaurora.org

This RFC is aimed at introducing CoreSight framework as well as individual CoreSight trace component drivers adhering to ARM CoreSight specification. Some prior discussion on this can be referred at [1].

There are 3 kinds of CoreSight trace components:

* Sources: Responsible for producing trace data to provide visibility for the associated entity.

* Links: Transport components that carry trace data.

* Sinks: Collectors for storing trace data or acting as conduits for off-chip trace data collection.

These components can be connected in various topologies to suite a particular SoCs tracing needs.

Quoted 6 lines

Framework is responsible for gathering and using the information about the registered CoreSight components and their connections to allow it to dynamically deduce the sequence of components representing a connection from a CoreSight source to the currently selected CoreSight sink. This helps the framework to program the correct set of components to satisfy user request.

From a million miles up, this looks like a sensible sort of design but I really think you need to talk to Jon Hunter (he's at least on CC) about this, especially where bindings are concerned. If we can get something that you both agree on, then we can include the CTI with the other coresight components and do a more in-depth review at that point.

Finally, how do you plan on exposing this data to the user? I think the only sane way is to have per-device file descriptors which act as pipes to the raw data but this means we need some readily available, open-source tooling (or at least public specifications of the trace formats).

-----Original Message-----
From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-arm-kernel-bounces at lists.infradead.org] On Behalf Of pratikp at codeaurora.org
Sent: den 18 december 2012 20:19
To: linux-arm-kernel at lists.infradead.org
Cc: linux at arm.linux.org.uk; linus.walleij at linaro.org; will.deacon at arm.com; Magnus PERSSON; david.rusling at linaro.org; arve at android.com; dsaxena at linaro.org; john.stultz at linaro.org; jon-hunter at ti.com; d-deao at ti.com; Christian BEJRAM; devicetree- discuss at lists.ozlabs.org
Subject: CoreSight framework and drivers

This RFC is aimed at introducing CoreSight framework as well as individual CoreSight trace component drivers adhering to ARM CoreSight specification. Some prior discussion on this can be referred at [1].

There are 3 kinds of CoreSight trace components:

* Sources: Responsible for producing trace data to provide visibility for the associated entity.

* Links: Transport components that carry trace data.

* Sinks: Collectors for storing trace data or acting as conduits for off-chip trace data collection.

These components can be connected in various topologies to suite a particular SoCs tracing needs.

Framework is responsible for gathering and using the information about the registered CoreSight components and their connections to allow it to dynamically deduce the sequence of components representing a connection from a CoreSight source to the currently selected CoreSight sink. This helps the framework to program the correct set of components to satisfy user request.

[1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/204591

Pratik Patel (8):
coresight: add CoreSight core layer framework
coresight: add CoreSight TMC driver
coresight: add CoreSight TPIU driver
coresight: add CoreSight ETB driver
coresight: add CoreSight Funnel driver
coresight: add CoreSight Replicator driver
coresight: add CoreSight STM driver
coresight: add CoreSight ETM driver

 Documentation/devicetree/bindings/arm/coresight.txt |  110 ++
 arch/arm/include/asm/hardware/cp14.h                |  540 ++++++
 drivers/Kconfig                                     |    2 +
 drivers/Makefile                                    |    1 +
 drivers/coresight/Kconfig                           |   60 +
 drivers/coresight/Makefile                          |    8 +
 drivers/coresight/coresight-etb.c                   |  467 +++++
 drivers/coresight/coresight-etm-cp14.c              |  510 ++++++
 drivers/coresight/coresight-etm.c                   | 1752 +++++++++++++++++++
 drivers/coresight/coresight-funnel.c                |  260 +++
 drivers/coresight/coresight-priv.h                  |   48 +
 drivers/coresight/coresight-replicator.c            |  211 +++
 drivers/coresight/coresight-stm.c                   |  819 +++++++++
 drivers/coresight/coresight-tmc.c                   |  794 +++++++++
 drivers/coresight/coresight-tpiu.c                  |  232 +++
 drivers/coresight/coresight.c                       |  681 +++++++
 drivers/coresight/of_coresight.c                    |   99 ++
 include/linux/coresight-stm.h                       |   51 +
 include/linux/coresight.h                           |  167 ++
 include/linux/of_coresight.h                        |   27 +
 20 files changed, 6839 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/coresight.txt
 create mode 100644 arch/arm/include/asm/hardware/cp14.h
 create mode 100644 drivers/coresight/Kconfig
 create mode 100644 drivers/coresight/Makefile
 create mode 100644 drivers/coresight/coresight-etb.c
 create mode 100644 drivers/coresight/coresight-etm-cp14.c
 create mode 100644 drivers/coresight/coresight-etm.c
 create mode 100644 drivers/coresight/coresight-funnel.c
 create mode 100644 drivers/coresight/coresight-priv.h
 create mode 100644 drivers/coresight/coresight-replicator.c
 create mode 100644 drivers/coresight/coresight-stm.c
 create mode 100644 drivers/coresight/coresight-tmc.c
 create mode 100644 drivers/coresight/coresight-tpiu.c
 create mode 100644 drivers/coresight/coresight.c
 create mode 100644 drivers/coresight/of_coresight.c
 create mode 100644 include/linux/coresight-stm.h
 create mode 100644 include/linux/coresight.h
 create mode 100644 include/linux/of_coresight.h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel