From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 09/12] coresight tmc: Add capability information
Date: Wed, 14 Jun 2017 12:22:51 -0600 [thread overview]
Message-ID: <20170614182251.GE22030@xps15> (raw)
In-Reply-To: <1497278211-5001-10-git-send-email-suzuki.poulose@arm.com>
On Mon, Jun 12, 2017 at 03:36:48PM +0100, Suzuki K Poulose wrote:
> This patch adds description of the capabilities of a given TMC.
> This will help us to handle different versions of the TMC in the
> same driver by checking the capabilities.
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> drivers/hwtracing/coresight/coresight-tmc.c | 10 +++++++++-
> drivers/hwtracing/coresight/coresight-tmc.h | 18 ++++++++++++++++++
> 2 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c
> index 7152656..e88f2f3 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc.c
> @@ -399,16 +399,24 @@ static int tmc_probe(struct amba_device *adev, const struct amba_id *id)
> ret = misc_register(&drvdata->miscdev);
> if (ret)
> coresight_unregister(drvdata->csdev);
> + else if (id->data)
> + drvdata->caps = *(struct tmc_caps *)id->data;
> out:
> return ret;
> }
>
> +static struct tmc_caps coresight_soc_400_tmc_caps = {
> + .caps = CORESIGHT_SOC_400_TMC_CAPS,
> +};
> +
> static struct amba_id tmc_ids[] = {
> {
> + /* Coresight SoC 400 TMC */
> .id = 0x000bb961,
> .mask = 0x000fffff,
> + .data = &coresight_soc_400_tmc_caps,
Do we need this? I don't see anywhere a check for TMC_CAP_ETR_SG_UNIT. And
I also suppose that the SoC600 suite also supports scatter-gather - is there a
need to differenciate both that may not be implemented in this set?
I'm also wondering if capabilities for SoC600 could not be retrieved from HW
registers rather than hard coded?
> },
> - { 0, 0},
> + {},
> };
>
> static struct amba_driver tmc_driver = {
> diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h
> index c78de00..87e4561 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc.h
> +++ b/drivers/hwtracing/coresight/coresight-tmc.h
> @@ -89,6 +89,18 @@ enum tmc_mem_intf_width {
> TMC_MEM_INTF_WIDTH_256BITS = 8,
> };
>
> +#define TMC_CAP_ETR_SG_UNIT (1U << 0)
> +
> +/**
> + * struct tmc_cap - Describes the capabilities of the TMC.
> + * @caps: - Bitmask of the capacities
> + */
> +struct tmc_caps {
> + u32 caps;
> +};
> +
> +#define CORESIGHT_SOC_400_TMC_CAPS (TMC_CAP_ETR_SG_UNIT)
> +
> /**
> * struct tmc_drvdata - specifics associated to an TMC component
> * @base: memory mapped base address for this component.
> @@ -110,6 +122,7 @@ struct tmc_drvdata {
> void __iomem *base;
> struct device *dev;
> struct coresight_device *csdev;
> + struct tmc_caps caps;
A simple u32 is probably best here rather than introducing a new structure. If
capabilites can't be retrieved from HW and have to be declared statically, a
*u32 referencing ->data is sufficient rather than copying memory.
> struct miscdevice miscdev;
> spinlock_t spinlock;
> bool reading;
> @@ -158,4 +171,9 @@ TMC_REG_PAIR(rrp, TMC_RRP, TMC_RRPHI)
> TMC_REG_PAIR(rwp, TMC_RWP, TMC_RWPHI)
> TMC_REG_PAIR(dba, TMC_DBALO, TMC_DBAHI)
>
> +static inline bool tmc_has_cap(struct tmc_drvdata *drvdata, u32 cap)
> +{
> + return !!(drvdata->caps.caps & cap);
> +}
> +
> #endif
> --
> 2.7.4
>
next prev parent reply other threads:[~2017-06-14 18:22 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-12 14:36 [PATCH 00/12] coresight: Support for ARM Coresight SoC-600 Suzuki K Poulose
2017-06-12 14:36 ` [PATCH 01/12] coresight replicator: Cleanup programmable replicator naming Suzuki K Poulose
2017-06-13 16:55 ` Mathieu Poirier
2017-06-13 17:56 ` Suzuki K Poulose
2017-06-18 14:04 ` Rob Herring
2017-06-20 16:44 ` Mathieu Poirier
2017-06-22 3:21 ` Rob Herring
2017-06-12 14:36 ` [PATCH 02/12] arm64: dts: juno: Use the new coresight replicator string Suzuki K Poulose
2017-06-12 14:36 ` [PATCH 03/12] coresight: Extend the PIDR mask to cover relevant bits in PIDR2 Suzuki K Poulose
2017-06-13 17:53 ` Mathieu Poirier
2017-06-13 17:55 ` Suzuki K Poulose
2017-06-13 19:06 ` Mathieu Poirier
2017-06-12 14:36 ` [PATCH 04/12] coresight: Add support for reading 64bit registers Suzuki K Poulose
2017-06-13 17:45 ` Mathieu Poirier
2017-06-13 17:57 ` Suzuki K Poulose
2017-06-12 14:36 ` [PATCH 05/12] coresight tmc: Add helpers for accessing " Suzuki K Poulose
2017-06-14 17:49 ` Mathieu Poirier
2017-06-15 10:13 ` Suzuki K Poulose
2017-06-15 13:29 ` Mike Leach
2017-06-15 14:24 ` Mathieu Poirier
2017-06-12 14:36 ` [PATCH 06/12] coresight tmc: Expose DBA and AXICTL Suzuki K Poulose
2017-06-14 17:50 ` Mathieu Poirier
2017-06-15 10:19 ` Suzuki K Poulose
2017-06-12 14:36 ` [PATCH 07/12] coresight replicator: Expose replicator management registers Suzuki K Poulose
2017-06-14 17:54 ` Mathieu Poirier
2017-06-15 10:23 ` Suzuki K Poulose
2017-06-12 14:36 ` [PATCH 08/12] coresight tmc: Handle configuration types properly Suzuki K Poulose
2017-06-14 17:59 ` Mathieu Poirier
2017-06-15 10:25 ` Suzuki K Poulose
2017-06-15 14:33 ` Mathieu Poirier
2017-06-12 14:36 ` [PATCH 09/12] coresight tmc: Add capability information Suzuki K Poulose
2017-06-14 18:22 ` Mathieu Poirier [this message]
2017-06-15 10:30 ` Suzuki K Poulose
2017-06-15 14:37 ` Mathieu Poirier
2017-06-12 14:36 ` [PATCH 10/12] coresight tmc: Support for save-restore in ETR Suzuki K Poulose
2017-06-12 14:36 ` [PATCH 11/12] coresight tmc: Add support for Coresight SoC 600 TMC Suzuki K Poulose
2017-06-14 18:25 ` Mathieu Poirier
2017-06-15 10:31 ` Suzuki K Poulose
2017-06-12 14:36 ` [PATCH 12/12] coresight: Add support for Coresight SoC 600 components Suzuki K Poulose
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170614182251.GE22030@xps15 \
--to=mathieu.poirier@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=suzuki.poulose@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox