* Re: [PATCH 4/8] coresight: etm4x: Fix issues with start-stop logic.
From: Leo Yan @ 2019-08-28 3:17 UTC (permalink / raw)
To: Mike Leach; +Cc: coresight, linux-arm-kernel, mathieu.poirier
In-Reply-To: <20190819205720.24457-5-mike.leach@linaro.org>
Hi Mike,
On Mon, Aug 19, 2019 at 09:57:16PM +0100, Mike Leach wrote:
> Fixes the following issues when using the ETMv4 start-stop logic.
>
> 1) Setting a start or a stop address should not automatically set the
> start-stop status to 'on'. The value set by the user in 'mode' must
> be respected or start instances could be missed.
> 2) Missing API for controlling TRCVIPCSSCTLR - start stop control by
> PE comparators.
> 3) Default ETM configuration sets a trace all range, and correctly sets
> the start-stop status bit. This was not being correctly reflected in
> the 'mode' parameter.
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> ---
> .../coresight/coresight-etm4x-sysfs.c | 39 +++++++++++++++++--
> drivers/hwtracing/coresight/coresight-etm4x.c | 1 +
> 2 files changed, 36 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> index 7eab5d7d0b62..3bcc260c9e55 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> @@ -217,6 +217,7 @@ static ssize_t reset_store(struct device *dev,
>
> /* No start-stop filtering for ViewInst */
> config->vissctlr = 0x0;
> + config->vipcssctlr = 0x0;
>
> /* Disable seq events */
> for (i = 0; i < drvdata->nrseqstate-1; i++)
> @@ -1059,8 +1060,6 @@ static ssize_t addr_start_store(struct device *dev,
> config->addr_val[idx] = (u64)val;
> config->addr_type[idx] = ETM_ADDR_TYPE_START;
> config->vissctlr |= BIT(idx);
> - /* SSSTATUS, bit[9] - turn on start/stop logic */
> - config->vinst_ctrl |= BIT(9);
> spin_unlock(&drvdata->spinlock);
> return size;
> }
> @@ -1116,8 +1115,6 @@ static ssize_t addr_stop_store(struct device *dev,
> config->addr_val[idx] = (u64)val;
> config->addr_type[idx] = ETM_ADDR_TYPE_STOP;
> config->vissctlr |= BIT(idx + 16);
> - /* SSSTATUS, bit[9] - turn on start/stop logic */
> - config->vinst_ctrl |= BIT(9);
> spin_unlock(&drvdata->spinlock);
> return size;
> }
> @@ -1271,6 +1268,39 @@ static ssize_t addr_exlevel_s_ns_store(struct device *dev,
> }
> static DEVICE_ATTR_RW(addr_exlevel_s_ns);
>
> +static ssize_t vinst_pe_cmp_start_stop_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + unsigned long val;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> +
> + if (!drvdata->nr_pe_cmp)
> + return -EINVAL;
> + val = config->vipcssctlr;
> + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> +}
> +static ssize_t vinst_pe_cmp_start_stop_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t size)
> +{
> + unsigned long val;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> +
> + if (kstrtoul(buf, 16, &val))
> + return -EINVAL;
> + if (!drvdata->nr_pe_cmp)
> + return -EINVAL;
> +
> + spin_lock(&drvdata->spinlock);
> + config->vipcssctlr = val;
> + spin_unlock(&drvdata->spinlock);
I don't find the code to set 'config->vipcssctlr' into hardware register
TRCVIPCSSCTLR.
And based on the register definition, here we also should clamp the
value for START/STOP?
Thanks,
Leo Yan
> + return size;
> +}
> +static DEVICE_ATTR_RW(vinst_pe_cmp_start_stop);
> +
> static ssize_t seq_idx_show(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> @@ -2077,6 +2107,7 @@ static struct attribute *coresight_etmv4_attrs[] = {
> &dev_attr_addr_ctxtype.attr,
> &dev_attr_addr_context.attr,
> &dev_attr_addr_exlevel_s_ns.attr,
> + &dev_attr_vinst_pe_cmp_start_stop.attr,
> &dev_attr_seq_idx.attr,
> &dev_attr_seq_state.attr,
> &dev_attr_seq_event.attr,
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
> index 52b8876de157..d8b078d0cc7f 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> @@ -868,6 +868,7 @@ static void etm4_set_default_filter(struct etmv4_config *config)
> * in the started state
> */
> config->vinst_ctrl |= BIT(9);
> + config->mode |= ETM_MODE_VIEWINST_STARTSTOP;
>
> /* No start-stop filtering for ViewInst */
> config->vissctlr = 0x0;
> --
> 2.17.1
>
> _______________________________________________
> CoreSight mailing list
> CoreSight@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/coresight
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V8 3/3] MAINTAINERS: add imx8 ddr perf admin-guide maintainer information
From: Joakim Zhang @ 2019-08-28 3:05 UTC (permalink / raw)
To: mark.rutland@arm.com, will@kernel.org, robin.murphy@arm.com
Cc: Frank Li, dl-linux-imx, linux-arm-kernel@lists.infradead.org,
Joakim Zhang
In-Reply-To: <20190828030305.7190-1-qiangqing.zhang@nxp.com>
Add imx8 ddr perf admin-guide maintainer information.
ChangeLog:
V1 -> V5:
* new add in V5.
V5 -> V6:
* no change.
V6 -> V7:
* no change.
V7 -> V8:
* no change.
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e60f5c361969..2ba378e806c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6462,6 +6462,7 @@ M: Frank Li <Frank.li@nxp.com>
L: linux-arm-kernel@lists.infradead.org
S: Maintained
F: drivers/perf/fsl_imx8_ddr_perf.c
+F: Documentation/admin-guide/perf/imx-ddr.rst
F: Documentation/devicetree/bindings/perf/fsl-imx-ddr.txt
FREESCALE IMX LPI2C DRIVER
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V8 2/3] Documentation: admin-guide: perf: add i.MX8 ddr pmu user doc
From: Joakim Zhang @ 2019-08-28 3:05 UTC (permalink / raw)
To: mark.rutland@arm.com, will@kernel.org, robin.murphy@arm.com
Cc: Frank Li, dl-linux-imx, linux-arm-kernel@lists.infradead.org,
Joakim Zhang
In-Reply-To: <20190828030305.7190-1-qiangqing.zhang@nxp.com>
Add i.MX8 ddr pmu user doc.
ChangeLog:
V1 -> V4:
* new add in V4.
V4 -> V5:
* no change.
V5 -> V6:
* change the event name
V6 -> V7:
* no change.
V7 -> V8:
* improve the doc, add more details.
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
---
Documentation/admin-guide/perf/imx-ddr.rst | 51 ++++++++++++++++++++++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/admin-guide/perf/imx-ddr.rst
diff --git a/Documentation/admin-guide/perf/imx-ddr.rst b/Documentation/admin-guide/perf/imx-ddr.rst
new file mode 100644
index 000000000000..438de3be667b
--- /dev/null
+++ b/Documentation/admin-guide/perf/imx-ddr.rst
@@ -0,0 +1,51 @@
+=====================================================
+Freescale i.MX8 DDR Performance Monitoring Unit (PMU)
+=====================================================
+
+There are no performance counters inside the DRAM controller, so performance
+signals are brought out to the edge of the controller where a set of 4 x 32 bit
+counters is implemented. This is controlled by the Performance log on parameter
+which causes a large number of PERF signals to be generated.
+
+Selection of the value for each counter is done via the config registiers. There
+is one register for each counter. Counter 0 is special in that it always counts
+“time” and when expired causes a lock on itself and the other counters and an
+interrupt ie enable of counter 0 is a global function.
+
+The "format" directory describes format of the config (event ID) and config1
+(AXI filtering) fields of the perf_event_attr structure, see /sys/bus/event_source/
+devices/imx8_ddr0/format/. The "events" directory describes the events types
+hardware supported that can be used with perf tool, see /sys/bus/event_source/
+devices/imx8_ddr0/events/.
+ e.g.::
+ perf stat -a -e imx8_ddr0/cycles/ cmd
+ perf stat -a -e imx8_ddr0/read/,imx8_ddr0/write/ cmd
+
+AXI filtering is only used by CSV modes 0x41 (axid-read) and 0x42 (axid-write)
+to count reading or writing matches filter setting. Filter setting is various
+from different DRAM controller implementations, which is distinguished by quirks
+in the driver.
+
+* With DDR_CAP_AXI_ID_FILTER quirk.
+ Filter is defined with two configuration parts:
+ --AXI_ID defines AxID matching value.
+ --AXI_MASKING defines which bits of AxID are meaningful for the matching.
+ 0:corresponding bit is masked.
+ 1: corresponding bit is not masked, i.e. used to do the matching.
+
+ AXI_ID and AXI_MASKING are mapped on DPCR1 register in performance counter.
+ When non-masked bits are matching corresponding AXI_ID bits then counter is
+ incremented. Perf counter is incremented if
+ AxID && AXI_MASKING == AXI_ID && AXI_MASKING
+
+ This filter doesn't support filter different AXI ID for axid-read and axid-write
+ event at the same time as this filter is shared between counters.
+ e.g.::
+ perf stat -a -e imx8_ddr0/axid-read,axi_mask=0xMMMM,axi_id=0xDDDD/ cmd
+ perf stat -a -e imx8_ddr0/axid-write,axi_mask=0xMMMM,axi_id=0xDDDD/ cmd
+
+ NOTE: axi_mask is inverted in userspace(i.e. set bits are bits to mask), and
+ it will be reverted in driver automatically. so that the user can just specify
+ axi_id to monitor a specific id, rather than having to specify axi_mask.
+ e.g.::
+ perf stat -a -e imx8_ddr0/axid-read,axi_id=0x12/ cmd, which will monitor ARID=0x12
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V8 1/3] perf: imx8_ddr_perf: add AXI ID filter support
From: Joakim Zhang @ 2019-08-28 3:05 UTC (permalink / raw)
To: mark.rutland@arm.com, will@kernel.org, robin.murphy@arm.com
Cc: Frank Li, dl-linux-imx, linux-arm-kernel@lists.infradead.org,
Joakim Zhang
AXI filtering is used by CSV modes 0x41 and 0x42 to count reads or
writes with an ARID or AWID matching filter setting. Granularity is at
subsystem level. Implementation does not allow filtring between masters
within a subsystem. Filter is defined with 2 configuration parameters.
--AXI_ID defines AxID matching value
--AXI_MASKING defines which bits of AxID are meaningful for the matching
0:corresponding bit is masked
1: corresponding bit is not masked, i.e. used to do the matching
When non-masked bits are matching corresponding AXI_ID bits then counter
is incremented. This filter allows counting read or write access from a
subsystem or multiple subsystems.
Perf counter is incremented if AxID && AXI_MASKING == AXI_ID && AXI_MASKING
AXI_ID and AXI_MASKING are mapped on DPCR1 register in performance counter.
Read and write AXI ID filter should write same value to DPCR1 if want to
specify at the same time as this filter is shared between counters.
e.g.
perf stat -a -e imx8_ddr0/axid-read,axi_mask=0xMMMM,axi_id=0xDDDD/ cmd
perf stat -a -e imx8_ddr0/axid-write,axi_mask=0xMMMM,axi_id=0xDDDD/ cmd
NOTE: axi_mask is inverted in userspace(i.e. set bits are bits to mask), and
it will be reverted in driver automatically. so that the user can just specify
axi_id to monitor a specific id, rather than having to specify axi_mask.
e.g.
perf stat -a -e imx8_ddr0/axid-read,axi_id=0x12/ cmd, which will monitor ARID=0x12
ChangeLog:
V1 -> V2:
* add error log if user specifies read/write AXI ID filter at
the same time.
* of_device_get_match_data() instead of of_match_device(), and
remove the check of return value.
V2 -> V3:
* move the AXI ID check to event_add().
* add support for same value of axi_id.
V3 -> V4:
* move the AXI ID check to event_init().
V4 -> V5:
* reject event group if AXI ID not consistent in event_init().
V5 -> V6:
* change the event name: axi-id-read->axid-read;
axi-id-write->axid-write
* add another helper: ddr_perf_filters_compatible()
* drop the dev_dbg()
V6 -> V7:
* revert AXI_MASKING at driver.
V7 -> V8:
* separate axi_id to axi_mask and axi_id these two fileds.
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
---
drivers/perf/fsl_imx8_ddr_perf.c | 72 +++++++++++++++++++++++++++++++-
1 file changed, 70 insertions(+), 2 deletions(-)
diff --git a/drivers/perf/fsl_imx8_ddr_perf.c b/drivers/perf/fsl_imx8_ddr_perf.c
index 0e3310dbb145..e9bf956f434d 100644
--- a/drivers/perf/fsl_imx8_ddr_perf.c
+++ b/drivers/perf/fsl_imx8_ddr_perf.c
@@ -35,6 +35,8 @@
#define EVENT_CYCLES_COUNTER 0
#define NUM_COUNTERS 4
+#define AXI_MASKING_REVERT 0xffff0000 /* AXI_MASKING(MSB 16bits) + AXI_ID(LSB 16bits) */
+
#define to_ddr_pmu(p) container_of(p, struct ddr_pmu, pmu)
#define DDR_PERF_DEV_NAME "imx8_ddr"
@@ -42,9 +44,22 @@
static DEFINE_IDA(ddr_ida);
+/* DDR Perf hardware feature */
+#define DDR_CAP_AXI_ID_FILTER 0x1 /* support AXI ID filter */
+
+struct fsl_ddr_devtype_data {
+ unsigned int quirks; /* quirks needed for different DDR Perf core */
+};
+
+static const struct fsl_ddr_devtype_data imx8_devtype_data;
+
+static const struct fsl_ddr_devtype_data imx8m_devtype_data = {
+ .quirks = DDR_CAP_AXI_ID_FILTER,
+};
+
static const struct of_device_id imx_ddr_pmu_dt_ids[] = {
- { .compatible = "fsl,imx8-ddr-pmu",},
- { .compatible = "fsl,imx8m-ddr-pmu",},
+ { .compatible = "fsl,imx8-ddr-pmu", .data = &imx8_devtype_data},
+ { .compatible = "fsl,imx8m-ddr-pmu", .data = &imx8m_devtype_data},
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, imx_ddr_pmu_dt_ids);
@@ -58,6 +73,7 @@ struct ddr_pmu {
struct perf_event *events[NUM_COUNTERS];
int active_events;
enum cpuhp_state cpuhp_state;
+ const struct fsl_ddr_devtype_data *devtype_data;
int irq;
int id;
};
@@ -129,6 +145,8 @@ static struct attribute *ddr_perf_events_attrs[] = {
IMX8_DDR_PMU_EVENT_ATTR(refresh, 0x37),
IMX8_DDR_PMU_EVENT_ATTR(write, 0x38),
IMX8_DDR_PMU_EVENT_ATTR(raw-hazard, 0x39),
+ IMX8_DDR_PMU_EVENT_ATTR(axid-read, 0x41),
+ IMX8_DDR_PMU_EVENT_ATTR(axid-write, 0x42),
NULL,
};
@@ -138,9 +156,13 @@ static struct attribute_group ddr_perf_events_attr_group = {
};
PMU_FORMAT_ATTR(event, "config:0-7");
+PMU_FORMAT_ATTR(axi_id, "config1:0-15");
+PMU_FORMAT_ATTR(axi_mask, "config1:16-31");
static struct attribute *ddr_perf_format_attrs[] = {
&format_attr_event.attr,
+ &format_attr_axi_id.attr,
+ &format_attr_axi_mask.attr,
NULL,
};
@@ -190,6 +212,26 @@ static u32 ddr_perf_read_counter(struct ddr_pmu *pmu, int counter)
return readl_relaxed(pmu->base + COUNTER_READ + counter * 4);
}
+static bool ddr_perf_is_filtered(struct perf_event *event)
+{
+ return event->attr.config == 0x41 || event->attr.config == 0x42;
+}
+
+static u32 ddr_perf_filter_val(struct perf_event *event)
+{
+ return event->attr.config1;
+}
+
+static bool ddr_perf_filters_compatible(struct perf_event *a,
+ struct perf_event *b)
+{
+ if (!ddr_perf_is_filtered(a))
+ return true;
+ if (!ddr_perf_is_filtered(b))
+ return true;
+ return ddr_perf_filter_val(a) == ddr_perf_filter_val(b);
+}
+
static int ddr_perf_event_init(struct perf_event *event)
{
struct ddr_pmu *pmu = to_ddr_pmu(event->pmu);
@@ -216,6 +258,15 @@ static int ddr_perf_event_init(struct perf_event *event)
!is_software_event(event->group_leader))
return -EINVAL;
+ if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
+ if (!ddr_perf_filters_compatible(event, event->group_leader))
+ return -EINVAL;
+ for_each_sibling_event(sibling, event->group_leader) {
+ if (!ddr_perf_filters_compatible(event, sibling))
+ return -EINVAL;
+ }
+ }
+
for_each_sibling_event(sibling, event->group_leader) {
if (sibling->pmu != event->pmu &&
!is_software_event(sibling))
@@ -288,6 +339,21 @@ static int ddr_perf_event_add(struct perf_event *event, int flags)
struct hw_perf_event *hwc = &event->hw;
int counter;
int cfg = event->attr.config;
+ int cfg1 = event->attr.config1;
+
+ if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
+ int i;
+
+ for (i = 1; i < NUM_COUNTERS; i++) {
+ if (pmu->events[i] &&
+ !ddr_perf_filters_compatible(event, pmu->events[i]))
+ return -EINVAL;
+ }
+
+ /* revert axi id masking(axi_mask) value */
+ cfg1 ^= AXI_MASKING_REVERT;
+ writel(cfg1, pmu->base + COUNTER_DPCR1);
+ }
counter = ddr_perf_alloc_counter(pmu, cfg);
if (counter < 0) {
@@ -473,6 +539,8 @@ static int ddr_perf_probe(struct platform_device *pdev)
if (!name)
return -ENOMEM;
+ pmu->devtype_data = of_device_get_match_data(&pdev->dev);
+
pmu->cpu = raw_smp_processor_id();
ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN,
DDR_CPUHP_CB_NAME,
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 2/2] mailbox: introduce ARM SMC based mailbox
From: Peng Fan @ 2019-08-28 3:03 UTC (permalink / raw)
To: robh+dt@kernel.org, mark.rutland@arm.com,
jassisinghbrar@gmail.com, sudeep.holla@arm.com,
andre.przywara@arm.com, f.fainelli@gmail.com
Cc: devicetree@vger.kernel.org, Peng Fan,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, dl-linux-imx
In-Reply-To: <1567004515-3567-1-git-send-email-peng.fan@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.
Modified from Andre Przywara's v2 patch
https://lore.kernel.org/patchwork/patch/812999/
Cc: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/mailbox/Kconfig | 7 ++
drivers/mailbox/Makefile | 2 +
drivers/mailbox/arm-smc-mailbox.c | 215 ++++++++++++++++++++++++++++++++++++++
3 files changed, 224 insertions(+)
create mode 100644 drivers/mailbox/arm-smc-mailbox.c
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ab4eb750bbdd..7707ee26251a 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -16,6 +16,13 @@ config ARM_MHU
The controller has 3 mailbox channels, the last of which can be
used in Secure mode only.
+config ARM_SMC_MBOX
+ tristate "Generic ARM smc mailbox"
+ depends on OF && HAVE_ARM_SMCCC
+ help
+ Generic mailbox driver which uses ARM smc calls to call into
+ firmware for triggering mailboxes.
+
config IMX_MBOX
tristate "i.MX Mailbox"
depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c22fad6f696b..93918a84c91b 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
obj-$(CONFIG_ARM_MHU) += arm_mhu.o
+obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
+
obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX) += armada-37xx-rwtm-mailbox.o
diff --git a/drivers/mailbox/arm-smc-mailbox.c b/drivers/mailbox/arm-smc-mailbox.c
new file mode 100644
index 000000000000..76a2ae11ee4d
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016,2017 ARM Ltd.
+ * Copyright 2019 NXP
+ */
+
+#include <linux/arm-smccc.h>
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/interrupt.h>
+#include <linux/mailbox_controller.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+
+#define ARM_SMC_MBOX_MEM_TRANS BIT(0)
+
+struct arm_smc_chan_data {
+ u32 function_id;
+ u32 chan_id;
+ u32 flags;
+};
+
+struct arm_smccc_mbox_cmd {
+ unsigned long a0, a1, a2, a3, a4, a5, a6, a7;
+};
+
+typedef unsigned long (smc_mbox_fn)(unsigned long, unsigned long,
+ unsigned long, unsigned long,
+ unsigned long, unsigned long,
+ unsigned long, unsigned long);
+static smc_mbox_fn *invoke_smc_mbox_fn;
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+ struct arm_smc_chan_data *chan_data = link->con_priv;
+ struct arm_smccc_mbox_cmd *cmd = data;
+ unsigned long ret;
+ u32 function_id;
+ u32 chan_id;
+
+ if (chan_data->flags & ARM_SMC_MBOX_MEM_TRANS) {
+ if (chan_data->function_id != UINT_MAX)
+ function_id = chan_data->function_id;
+ else
+ function_id = cmd->a0;
+ chan_id = chan_data->chan_id;
+ ret = invoke_smc_mbox_fn(function_id, chan_id, 0, 0, 0, 0,
+ 0, 0);
+ } else {
+ ret = invoke_smc_mbox_fn(cmd->a0, cmd->a1, cmd->a2, cmd->a3,
+ cmd->a4, cmd->a5, cmd->a6, cmd->a7);
+ }
+
+ mbox_chan_received_data(link, (void *)ret);
+
+ return 0;
+}
+
+static unsigned long __invoke_fn_hvc(unsigned long function_id,
+ unsigned long arg0, unsigned long arg1,
+ unsigned long arg2, unsigned long arg3,
+ unsigned long arg4, unsigned long arg5,
+ unsigned long arg6)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4,
+ arg5, arg6, &res);
+ return res.a0;
+}
+
+static unsigned long __invoke_fn_smc(unsigned long function_id,
+ unsigned long arg0, unsigned long arg1,
+ unsigned long arg2, unsigned long arg3,
+ unsigned long arg4, unsigned long arg5,
+ unsigned long arg6)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(function_id, arg0, arg1, arg2, arg3, arg4,
+ arg5, arg6, &res);
+ return res.a0;
+}
+
+static const struct mbox_chan_ops arm_smc_mbox_chan_ops = {
+ .send_data = arm_smc_send_data,
+};
+
+static int arm_smc_mbox_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct mbox_controller *mbox;
+ struct arm_smc_chan_data *chan_data;
+ const char *method;
+ bool mem_trans = false;
+ int ret, i;
+ u32 val;
+
+ if (!of_property_read_u32(dev->of_node, "arm,num-chans", &val)) {
+ if (!val) {
+ dev_err(dev, "invalid arm,num-chans value %u\n", val);
+ return -EINVAL;
+ }
+ } else {
+ return -EINVAL;
+ }
+
+ if (!of_property_read_string(dev->of_node, "transports", &method)) {
+ if (!strcmp("mem", method)) {
+ mem_trans = true;
+ } else if (!strcmp("reg", method)) {
+ mem_trans = false;
+ } else {
+ dev_warn(dev, "invalid \"transports\" property: %s\n",
+ method);
+
+ return -EINVAL;
+ }
+ } else {
+ return -EINVAL;
+ }
+
+ if (!of_property_read_string(dev->of_node, "method", &method)) {
+ if (!strcmp("hvc", method)) {
+ invoke_smc_mbox_fn = __invoke_fn_hvc;
+ } else if (!strcmp("smc", method)) {
+ invoke_smc_mbox_fn = __invoke_fn_smc;
+ } else {
+ dev_warn(dev, "invalid \"method\" property: %s\n",
+ method);
+
+ return -EINVAL;
+ }
+ } else {
+ return -EINVAL;
+ }
+
+ mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
+ if (!mbox)
+ return -ENOMEM;
+
+ mbox->num_chans = val;
+ mbox->chans = devm_kcalloc(dev, mbox->num_chans, sizeof(*mbox->chans),
+ GFP_KERNEL);
+ if (!mbox->chans)
+ return -ENOMEM;
+
+ chan_data = devm_kcalloc(dev, mbox->num_chans, sizeof(*chan_data),
+ GFP_KERNEL);
+ if (!chan_data)
+ return -ENOMEM;
+
+ for (i = 0; i < mbox->num_chans; i++) {
+ u32 function_id;
+
+ ret = of_property_read_u32_index(dev->of_node,
+ "arm,func-ids", i,
+ &function_id);
+ if (ret)
+ chan_data[i].function_id = UINT_MAX;
+
+ else
+ chan_data[i].function_id = function_id;
+
+ chan_data[i].chan_id = i;
+
+ if (mem_trans)
+ chan_data[i].flags |= ARM_SMC_MBOX_MEM_TRANS;
+ mbox->chans[i].con_priv = &chan_data[i];
+ }
+
+ mbox->txdone_poll = false;
+ mbox->txdone_irq = false;
+ mbox->ops = &arm_smc_mbox_chan_ops;
+ mbox->dev = dev;
+
+ platform_set_drvdata(pdev, mbox);
+
+ ret = devm_mbox_controller_register(dev, mbox);
+ if (ret)
+ return ret;
+
+ dev_info(dev, "ARM SMC mailbox enabled with %d chan%s.\n",
+ mbox->num_chans, mbox->num_chans == 1 ? "" : "s");
+
+ return ret;
+}
+
+static int arm_smc_mbox_remove(struct platform_device *pdev)
+{
+ struct mbox_controller *mbox = platform_get_drvdata(pdev);
+
+ mbox_controller_unregister(mbox);
+ return 0;
+}
+
+static const struct of_device_id arm_smc_mbox_of_match[] = {
+ { .compatible = "arm,smc-mbox", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, arm_smc_mbox_of_match);
+
+static struct platform_driver arm_smc_mbox_driver = {
+ .driver = {
+ .name = "arm-smc-mbox",
+ .of_match_table = arm_smc_mbox_of_match,
+ },
+ .probe = arm_smc_mbox_probe,
+ .remove = arm_smc_mbox_remove,
+};
+module_platform_driver(arm_smc_mbox_driver);
+
+MODULE_AUTHOR("Andre Przywara <andre.przywara@arm.com>");
+MODULE_DESCRIPTION("Generic ARM smc mailbox driver");
+MODULE_LICENSE("GPL v2");
--
2.16.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Peng Fan @ 2019-08-28 3:02 UTC (permalink / raw)
To: robh+dt@kernel.org, mark.rutland@arm.com,
jassisinghbrar@gmail.com, sudeep.holla@arm.com,
andre.przywara@arm.com, f.fainelli@gmail.com
Cc: devicetree@vger.kernel.org, Peng Fan,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, dl-linux-imx
In-Reply-To: <1567004515-3567-1-git-send-email-peng.fan@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
actions in software layers running in the EL2 or EL3 exception levels.
The term "ARM" here relates to the SMC instruction as part of the ARM
instruction set, not as a standard endorsed by ARM Ltd.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
.../devicetree/bindings/mailbox/arm-smc.yaml | 125 +++++++++++++++++++++
1 file changed, 125 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
new file mode 100644
index 000000000000..f8eb28d5e307
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
@@ -0,0 +1,125 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM SMC Mailbox Interface
+
+maintainers:
+ - Peng Fan <peng.fan@nxp.com>
+
+description: |
+ This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor
+ call) instruction to trigger a mailbox-connected activity in firmware,
+ executing on the very same core as the caller. By nature this operation
+ is synchronous and this mailbox provides no way for asynchronous messages
+ to be delivered the other way round, from firmware to the OS, but
+ asynchronous notification could also be supported. However the value of
+ r0/w0/x0 the firmware returns after the smc call is delivered as a received
+ message to the mailbox framework, so a synchronous communication can be
+ established, for a asynchronous notification, no value will be returned.
+ The exact meaning of both the action the mailbox triggers as well as the
+ return value is defined by their users and is not subject to this binding.
+
+ One use case of this mailbox is the SCMI interface, which uses shared memory
+ to transfer commands and parameters, and a mailbox to trigger a function
+ call. This allows SoCs without a separate management processor (or when
+ such a processor is not available or used) to use this standardized
+ interface anyway.
+
+ This binding describes no hardware, but establishes a firmware interface.
+ Upon receiving an SMC using one of the described SMC function identifiers,
+ the firmware is expected to trigger some mailbox connected functionality.
+ The communication follows the ARM SMC calling convention.
+ Firmware expects an SMC function identifier in r0 or w0. The supported
+ identifiers are passed from consumers, or listed in the the arm,func-ids
+ properties as described below. The firmware can return one value in
+ the first SMC result register, it is expected to be an error value,
+ which shall be propagated to the mailbox client.
+
+ Any core which supports the SMC or HVC instruction can be used, as long as
+ a firmware component running in EL3 or EL2 is handling these calls.
+
+properties:
+ compatible:
+ const: arm,smc-mbox
+
+ "#mbox-cells":
+ const: 1
+
+ arm,num-chans:
+ description: The number of channels supported.
+ items:
+ minimum: 1
+ maximum: 4096 # Should be enough?
+
+ method:
+ - enum:
+ - smc
+ - hvc
+
+ transports:
+ - enum:
+ - mem
+ - reg
+
+ arm,func-ids:
+ description: |
+ An array of 32-bit values specifying the function IDs used by each
+ mailbox channel. Those function IDs follow the ARM SMC calling
+ convention standard [1].
+
+ There is one identifier per channel and the number of supported
+ channels is determined by the length of this array.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 0
+ maxItems: 4096 # Should be enough?
+
+required:
+ - compatible
+ - "#mbox-cells"
+ - arm,num-chans
+ - transports
+ - method
+
+examples:
+ - |
+ sram@910000 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x93f000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x0 0x93f000 0x1000>;
+
+ cpu_scp_lpri: scp-shmem@0 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x0 0x200>;
+ };
+
+ cpu_scp_hpri: scp-shmem@200 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x200 0x200>;
+ };
+ };
+
+ firmware {
+ smc_mbox: mailbox {
+ #mbox-cells = <1>;
+ compatible = "arm,smc-mbox";
+ method = "smc";
+ arm,num-chans = <0x2>;
+ transports = "mem";
+ /* Optional */
+ arm,func-ids = <0xc20000fe>, <0xc20000ff>;
+ };
+
+ scmi {
+ compatible = "arm,scmi";
+ mboxes = <&smc_mbox 0>, <&smc_mbox 1>;
+ mbox-names = "tx", "rx";
+ shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>;
+ };
+ };
+
+...
--
2.16.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 0/2] mailbox: arm: introduce smc triggered mailbox
From: Peng Fan @ 2019-08-28 3:02 UTC (permalink / raw)
To: robh+dt@kernel.org, mark.rutland@arm.com,
jassisinghbrar@gmail.com, sudeep.holla@arm.com,
andre.przywara@arm.com, f.fainelli@gmail.com
Cc: devicetree@vger.kernel.org, Peng Fan,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, dl-linux-imx
From: Peng Fan <peng.fan@nxp.com>
V5:
yaml fix
V4:
yaml fix for num-chans in patch 1/2.
https://patchwork.kernel.org/cover/11116521/
V3:
Drop interrupt
Introduce transports for mem/reg usage
Add chan-id for mem usage
Convert to yaml format
https://patchwork.kernel.org/cover/11043541/
V2:
This is a modified version from Andre Przywara's patch series
https://lore.kernel.org/patchwork/cover/812997/.
The modification are mostly:
Introduce arm,num-chans
Introduce arm_smccc_mbox_cmd
txdone_poll and txdone_irq are both set to false
arm,func-ids are kept, but as an optional property.
Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI.
Introduce interrupts notification.
[1] is a draft implementation of i.MX8MM SCMI ATF implementation that
use smc as mailbox, power/clk is included, but only part of clk has been
implemented to work with hardware, power domain only supports get name
for now.
The traditional Linux mailbox mechanism uses some kind of dedicated hardware
IP to signal a condition to some other processing unit, typically a dedicated
management processor.
This mailbox feature is used for instance by the SCMI protocol to signal a
request for some action to be taken by the management processor.
However some SoCs does not have a dedicated management core to provide
those services. In order to service TEE and to avoid linux shutdown
power and clock that used by TEE, need let firmware to handle power
and clock, the firmware here is ARM Trusted Firmware that could also
run SCMI service.
The existing SCMI implementation uses a rather flexible shared memory
region to communicate commands and their parameters, it still requires a
mailbox to actually trigger the action.
This patch series provides a Linux mailbox compatible service which uses
smc calls to invoke firmware code, for instance taking care of SCMI requests.
The actual requests are still communicated using the standard SCMI way of
shared memory regions, but a dedicated mailbox hardware IP can be replaced via
this new driver.
This simple driver uses the architected SMC calling convention to trigger
firmware services, also allows for using "HVC" calls to call into hypervisors
or firmware layers running in the EL2 exception level.
Patch 1 contains the device tree binding documentation, patch 2 introduces
the actual mailbox driver.
Please note that this driver just provides a generic mailbox mechanism,
It could support synchronous TX/RX, or synchronous TX with asynchronous
RX. And while providing SCMI services was the reason for this exercise,
this driver is in no way bound to this use case, but can be used generically
where the OS wants to signal a mailbox condition to firmware or a
hypervisor.
Also the driver is in no way meant to replace any existing firmware
interface, but actually to complement existing interfaces.
[1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi
Peng Fan (2):
dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
mailbox: introduce ARM SMC based mailbox
.../devicetree/bindings/mailbox/arm-smc.yaml | 125 ++++++++++++
drivers/mailbox/Kconfig | 7 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/arm-smc-mailbox.c | 215 +++++++++++++++++++++
4 files changed, 349 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
create mode 100644 drivers/mailbox/arm-smc-mailbox.c
--
2.16.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH V7 1/3] perf: imx8_ddr_perf: add AXI ID filter support
From: Joakim Zhang @ 2019-08-28 3:02 UTC (permalink / raw)
To: Will Deacon
Cc: mark.rutland@arm.com, Frank Li, robin.murphy@arm.com,
dl-linux-imx, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190827183040.633fcj2m2xb6vfow@willie-the-truck>
> -----Original Message-----
> From: Will Deacon <will@kernel.org>
> Sent: 2019年8月28日 2:31
> To: Joakim Zhang <qiangqing.zhang@nxp.com>
> Cc: mark.rutland@arm.com; robin.murphy@arm.com; Frank Li
> <frank.li@nxp.com>; dl-linux-imx <linux-imx@nxp.com>;
> linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH V7 1/3] perf: imx8_ddr_perf: add AXI ID filter support
>
> Hi Joakim,
>
> On Tue, Aug 27, 2019 at 02:39:32AM +0000, Joakim Zhang wrote:
> > AXI filtering is used by CSV modes 0x41 and 0x42 to count reads or
> > writes with an ARID or AWID matching filter setting. Granularity is at
> > subsystem level. Implementation does not allow filtring between
> > masters within a subsystem. Filter is defined with 2 configuration
> parameters.
> >
> > --AXI_ID defines AxID matching value
> > --AXI_MASKING defines which bits of AxID are meaningful for the matching
> > 0:corresponding bit is masked
> > 1: corresponding bit is not masked, i.e. used to do the matching
> >
> > When non-masked bits are matching corresponding AXI_ID bits then
> > counter is incremented. This filter allows counting read or write
> > access from a subsystem or multiple subsystems.
> >
> > Perf counter is incremented if AxID && AXI_MASKING == AXI_ID &&
> > AXI_MASKING
> >
> > AXI_ID and AXI_MASKING are mapped on DPCR1 register in performance
> counter.
> >
> > Read and write AXI ID filter should write same value to DPCR1 if want
> > to specify at the same time as this filter is shared between counters.
> >
> > e.g.
> > perf stat -a -e
> >
> imx8_ddr0/axid-read,axi_id=0xMMMMDDDD/,imx8_ddr0/axid-write,axi_id=0x
> M
> > MMMDDDD/ cmd
> > MMMM: AXI_MASKING DDDD: AXI_ID
> > perf stat -a -e imx8_ddr0/axid-read,axi_id=0x12/ cmd, which will
> > monitor ARID=0x12
> >
> > NOTE: AXI_MASKING is inverted at driver(i.e. set bits are bits to
> > mask), so that the user can just specify axi_id to monitor a specific
> > id, rather than having to specify axi_id=0xffff<id>.
>
> [...]
>
> > @@ -138,9 +156,11 @@ static struct attribute_group
> > ddr_perf_events_attr_group = { };
> >
> > PMU_FORMAT_ATTR(event, "config:0-7");
> > +PMU_FORMAT_ATTR(axi_id, "config1:0-31");
>
> I still don't think this is quite what Mark was suggesting. My understanding of
> his email [1] was that you would do something like:
>
> PMU_FORMAT_ATTR(axi_id, "config1:0-15");
> PMU_FORMAT_ATTR(axi_mask, "config1:16-31");
>
> and then if the user omits to specify axi_mask, it has a value of 0 which means
> that all of the axi_id bits are matched (i.e. the driver inverts the mask
> internally). I think that's actually what your code is doing:
>
> > @@ -288,6 +337,21 @@ static int ddr_perf_event_add(struct perf_event
> *event, int flags)
> > struct hw_perf_event *hwc = &event->hw;
> > int counter;
> > int cfg = event->attr.config;
> > + int cfg1 = event->attr.config1;
> > +
> > + if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> > + int i;
> > +
> > + for (i = 1; i < NUM_COUNTERS; i++) {
> > + if (pmu->events[i] &&
> > + !ddr_perf_filters_compatible(event, pmu->events[i]))
> > + return -EINVAL;
> > + }
> > +
> > + /* revert axi_id masking value */
> > + cfg1 ^= AXI_MASKING_REVERT;
>
> it's just that the user ABI should probably separate these two fields out as
> above.
>
> I was going to make the change when merging this patch, but you need to
> update the Documentation in the second patch too.
[Joakim] Thanks Will, I have updated the driver and commit message in the first patch, also updated doc in the second patch. I am going to send out a V8, thank you for your kindly review.
Best Regards,
Joakim Zhang
> Will
>
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.ker
> nel.org%2Fr%2F20190823125719.GD55480%40lakrids.cambridge.arm.com&a
> mp;data=02%7C01%7Cqiangqing.zhang%40nxp.com%7Cfa6af1320ed345c2de3
> f08d72b1cae85%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6370
> 25274507822105&sdata=mwLua%2BInlqd83Z3h7DTkYz2Wb0VxbizrroWY
> h83l%2B0g%3D&reserved=0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/8] coresight: etm4x: Add missing API to set EL match on address filters
From: Leo Yan @ 2019-08-28 2:53 UTC (permalink / raw)
To: Mike Leach; +Cc: coresight, linux-arm-kernel, mathieu.poirier
In-Reply-To: <20190819205720.24457-4-mike.leach@linaro.org>
On Mon, Aug 19, 2019 at 09:57:15PM +0100, Mike Leach wrote:
> TRCACATRn registers have match bits for secure and non-secure exception
> levels which are not accessible by the sysfs API.
> This adds a new sysfs parameter to enable this - addr_exlevel_s_ns.
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> ---
> .../coresight/coresight-etm4x-sysfs.c | 39 +++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> index fa1d6a938f6c..7eab5d7d0b62 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> @@ -1233,6 +1233,44 @@ static ssize_t addr_context_store(struct device *dev,
> }
> static DEVICE_ATTR_RW(addr_context);
>
> +static ssize_t addr_exlevel_s_ns_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + u8 idx;
> + unsigned long val;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> +
> + spin_lock(&drvdata->spinlock);
> + idx = config->addr_idx;
> + val = BMVAL(config->addr_acc[idx], 14, 8);
> + spin_unlock(&drvdata->spinlock);
> + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> +}
> +
> +static ssize_t addr_exlevel_s_ns_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t size)
> +{
> + u8 idx;
> + unsigned long val;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> +
> + if (kstrtoul(buf, 16, &val))
> + return -EINVAL;
> +
> + spin_lock(&drvdata->spinlock);
> + idx = config->addr_idx;
> + /* clear Exlevel_ns & Exlevel_s bits[14:12, 11:8] */
> + config->addr_acc[idx] &= ~(GENMASK(14, 8));
> + config->addr_acc[idx] |= (val << 8);
I think it needs to check if 'val' is out of bound, which only can have
value which is less than 7 bits (finally set for bit 8 to bit 14).
Just curious, if the CPU runs in non-secure mode (e.g. NS-EL1 in
kernel mode), does it have permission to access EXLEVEL_S field? I
don't see the spec give info for this.
Thanks,
Leo Yan
> + spin_unlock(&drvdata->spinlock);
> + return size;
> +}
> +static DEVICE_ATTR_RW(addr_exlevel_s_ns);
> +
> static ssize_t seq_idx_show(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> @@ -2038,6 +2076,7 @@ static struct attribute *coresight_etmv4_attrs[] = {
> &dev_attr_addr_stop.attr,
> &dev_attr_addr_ctxtype.attr,
> &dev_attr_addr_context.attr,
> + &dev_attr_addr_exlevel_s_ns.attr,
> &dev_attr_seq_idx.attr,
> &dev_attr_seq_state.attr,
> &dev_attr_seq_event.attr,
> --
> 2.17.1
>
> _______________________________________________
> CoreSight mailing list
> CoreSight@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/coresight
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v2 07/10] PCI: layerscape: Modify the MSIX to the doorbell way
From: Xiaowei Bao @ 2019-08-28 2:49 UTC (permalink / raw)
To: Andrew Murray
Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.co,
arnd@arndb.de, devicetree@vger.kernel.org,
gregkh@linuxfoundation.org, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kishon@ti.com, M.h. Lian, robh+dt@kernel.org,
gustavo.pimentel@synopsys.com, jingoohan1@gmail.com,
bhelgaas@google.com, Leo Li, shawnguo@kernel.org, Mingkai Hu,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190827132504.GL14582@e119886-lin.cambridge.arm.com>
> -----Original Message-----
> From: Andrew Murray <andrew.murray@arm.com>
> Sent: 2019年8月27日 21:25
> To: Xiaowei Bao <xiaowei.bao@nxp.com>
> Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com;
> lorenzo.pieralisi@arm.co; arnd@arndb.de; gregkh@linuxfoundation.org; M.h.
> Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH v2 07/10] PCI: layerscape: Modify the MSIX to the
> doorbell way
>
> On Sat, Aug 24, 2019 at 12:08:40AM +0000, Xiaowei Bao wrote:
> >
> >
> > > -----Original Message-----
> > > From: Andrew Murray <andrew.murray@arm.com>
> > > Sent: 2019年8月23日 21:58
> > > To: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> > > shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com;
> > > lorenzo.pieralisi@arm.co; arnd@arndb.de; gregkh@linuxfoundation.org;
> M.h.
> > > Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> > > Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> > > gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> > > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> > > Subject: Re: [PATCH v2 07/10] PCI: layerscape: Modify the MSIX to
> > > the doorbell way
> > >
> > > On Thu, Aug 22, 2019 at 07:22:39PM +0800, Xiaowei Bao wrote:
> > > > The layerscape platform use the doorbell way to trigger MSIX
> > > > interrupt in EP mode.
> > > >
> > >
> > > I have no problems with this patch, however...
> > >
> > > Are you able to add to this message a reason for why you are making
> > > this change? Did dw_pcie_ep_raise_msix_irq not work when func_no !=
> > > 0? Or did it work yet dw_pcie_ep_raise_msix_irq_doorbell is more
> efficient?
> >
> > The fact is that, this driver is verified in ls1046a platform of NXP
> > before, and ls1046a don't support MSIX feature, so I set the
> > msix_capable of pci_epc_features struct is false, but in other
> > platform, e.g. ls1088a, it support the MSIX feature, I verified the MSIX
> feature in ls1088a, it is not OK, so I changed to another way. Thanks.
>
> Right, so the existing pci-layerscape-ep.c driver never supported MSIX yet it
> erroneously had a switch case statement to call dw_pcie_ep_raise_msix_irq
> which would never get used.
>
> Now that we're adding a platform with MSIX support the existing
> dw_pcie_ep_raise_msix_irq doesn't work (for this platform) so we are adding
> a different method.
>
> Given that dw_pcie_ep_raise_msix_irq is used by pcie-designware-plat.c we
> can assume this function at least works for it's use case.
>
> Please update the commit message - It would be helpful to suggest that
> dw_pcie_ep_raise_msix_irq was never called in the exisitng driver because
> msix_capable was always set to false.
Agree, this is much clearer, I will modify the commit message in the next version patch,
thanks a lot.
>
> Thanks,
>
> Andrew Murray
>
> >
> > >
> > > Thanks,
> > >
> > > Andrew Murray
> > >
> > > > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > > ---
> > > > v2:
> > > > - No change.
> > > >
> > > > drivers/pci/controller/dwc/pci-layerscape-ep.c | 3 ++-
> > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > index 8461f62..7ca5fe8 100644
> > > > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > @@ -74,7 +74,8 @@ static int ls_pcie_ep_raise_irq(struct
> > > > dw_pcie_ep *ep,
> > > u8 func_no,
> > > > case PCI_EPC_IRQ_MSI:
> > > > return dw_pcie_ep_raise_msi_irq(ep, func_no, interrupt_num);
> > > > case PCI_EPC_IRQ_MSIX:
> > > > - return dw_pcie_ep_raise_msix_irq(ep, func_no,
> interrupt_num);
> > > > + return dw_pcie_ep_raise_msix_irq_doorbell(ep, func_no,
> > > > + interrupt_num);
> > > > default:
> > > > dev_err(pci->dev, "UNKNOWN IRQ type\n");
> > > > return -EINVAL;
> > > > --
> > > > 2.9.5
> > > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/8] coresight: etm4x: Fix input validation for sysfs.
From: Leo Yan @ 2019-08-28 2:42 UTC (permalink / raw)
To: Mike Leach; +Cc: coresight, linux-arm-kernel, mathieu.poirier
In-Reply-To: <20190819205720.24457-3-mike.leach@linaro.org>
On Mon, Aug 19, 2019 at 09:57:14PM +0100, Mike Leach wrote:
> A number of issues are fixed relating to sysfs input validation:-
>
> 1) bb_ctrl_store() - incorrect compare of bit select field to absolute
> value. Reworked per ETMv4 specification.
> 2) seq_event_store() - incorrect mask value - register has two
> event values.
> 3) cyc_threshold_store() - must mask with max before checking min
> otherwise wrapped values can set illegal value below min.
> 4) res_ctrl_store() - update to mask off all res0 bits.
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> ---
> .../coresight/coresight-etm4x-sysfs.c | 21 ++++++++++++-------
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> index b6984be0c515..fa1d6a938f6c 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> @@ -652,10 +652,13 @@ static ssize_t cyc_threshold_store(struct device *dev,
>
> if (kstrtoul(buf, 16, &val))
> return -EINVAL;
> +
> + /* mask off max threshold before checking min value */
> + val &= ETM_CYC_THRESHOLD_MASK;
> if (val < drvdata->ccitmin)
> return -EINVAL;
>
> - config->ccctlr = val & ETM_CYC_THRESHOLD_MASK;
> + config->ccctlr = val;
> return size;
> }
> static DEVICE_ATTR_RW(cyc_threshold);
> @@ -686,14 +689,16 @@ static ssize_t bb_ctrl_store(struct device *dev,
> return -EINVAL;
> if (!drvdata->nr_addr_cmp)
> return -EINVAL;
> +
> /*
> - * Bit[7:0] selects which address range comparator is used for
> - * branch broadcast control.
> + * Bit[8] controls include(1) / exclude(0), bits[0-7] select
> + * individual range comparators. If include then at least 1
> + * range must be selected.
> */
> - if (BMVAL(val, 0, 7) > drvdata->nr_addr_cmp)
> + if ((val & BIT(8)) && (BMVAL(val, 0, 7) == 0))
> return -EINVAL;
>
> - config->bb_ctrl = val;
> + config->bb_ctrl = val & GENMASK(8, 0);
> return size;
> }
> static DEVICE_ATTR_RW(bb_ctrl);
> @@ -1324,8 +1329,8 @@ static ssize_t seq_event_store(struct device *dev,
>
> spin_lock(&drvdata->spinlock);
> idx = config->seq_idx;
> - /* RST, bits[7:0] */
> - config->seq_ctrl[idx] = val & 0xFF;
> + /* Seq control has two masks B[15:5] F[7:0] */
s/B[15:5]/B[15:8]
With this change and Mathieu mentioned redundant space:
Reviewed-by: Leo Yan <leo.yan@linaro.org>
> + config->seq_ctrl[idx] = val & 0xFFFF;
> spin_unlock(&drvdata->spinlock);
> return size;
> }
> @@ -1580,7 +1585,7 @@ static ssize_t res_ctrl_store(struct device *dev,
> if (idx % 2 != 0)
> /* PAIRINV, bit[21] */
> val &= ~BIT(21);
> - config->res_ctrl[idx] = val;
> + config->res_ctrl[idx] = val & GENMASK(21, 0);
> spin_unlock(&drvdata->spinlock);
> return size;
> }
> --
> 2.17.1
>
> _______________________________________________
> CoreSight mailing list
> CoreSight@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/coresight
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/6] Revert "arm64: Remove unnecessary ISBs from set_{pte, pmd, pud}"
From: Sasha Levin @ 2019-08-28 2:29 UTC (permalink / raw)
To: Sasha Levin, Will Deacon, linux-arm-kernel
Cc: linux-arch, , Will Deacon, stable
In-Reply-To: <20190827131818.14724-2-will@kernel.org>
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 24fe1b0efad4 arm64: Remove unnecessary ISBs from set_{pte,pmd,pud}.
The bot has tested the following trees: v5.2.10, v4.19.68.
v5.2.10: Build OK!
v4.19.68: Failed to apply! Possible dependencies:
0795edaf3f1f ("arm64: pgtable: Implement p[mu]d_valid() and check in set_p[mu]d()")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks,
Sasha
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/9] block: support diskcipher
From: boojin.kim @ 2019-08-28 2:20 UTC (permalink / raw)
To: 'Theodore Y. Ts'o'
Cc: 'Ulf Hansson', 'Mike Snitzer', dm-devel,
'Andreas Dilger', 'Alasdair Kergon',
'Eric Biggers', linux-samsung-soc, 'Herbert Xu',
'Krzysztof Kozlowski', 'Jaehoon Chung',
'Kukjin Kim', linux-ext4, 'Chao Yu', linux-block,
linux-fscrypt, 'Jaegeuk Kim', linux-arm-kernel,
'Jens Axboe', 'Theodore Ts'o', linux-mmc,
linux-kernel, linux-f2fs-devel, linux-crypto, linux-fsdevel,
'David S. Miller'
In-Reply-To: <CGME20190828022055epcas2p25525077d0a5a3fa5a2027bac06a10bc1@epcas2p2.samsung.com>
On Tue, Aug 27, 2019 at 05:33:33PM +0900, boojin.kim wrote:
>
> Hi Boojin,
>
> I think the important thing to realize here is that there are a large
> number of hardware devices for which the keyslot manager *is* needed.
> And from the upstream kernel's perspective, supporting two different
> schemes for supporting the inline encryption feature is more
> complexity than just supporting one which is general enough to support
> a wider variety of hardware devices.
>
> If you want somethig which is only good for the hardware platform you
> are charged to support, that's fine if it's only going to be in a
> Samsung-specific kernel. But if your goal is to get something that
> works upstream, especially if it requires changes in core layers of
> the kernel, it's important that it's general enough to support most,
> if not all, if the hardware devices in the industry.
>
> Regards,
I understood your reply.
But, Please consider the diskcipher isn't just for FMP.
The UFS in Samsung SoC also has UFS ICE. This UFS ICE can be registered
as an algorithm of diskcipher like FMP.
Following is my opinion to introduce diskcipher.
I think the common feature of ICE like FMP and UFS ICE,
is 'exposing cipher text to storage".
And, Crypto test is also important for ICE. Diskcipher supports
the common feature of ICE.
I think specific functions for each ICE such as the key control of UFS ICE
and the writing crypto table of FMP can be processed at algorithm level.
Thanks for your reply.
Boojin Kim.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH V2 4/4] platform: mtk-isp: Add Mediatek FD driver
From: Jerry-ch Chen @ 2019-08-28 2:00 UTC (permalink / raw)
To: Tomasz Figa
Cc: devicetree@vger.kernel.org, Sean Cheng (鄭昇弘),
laurent.pinchart+renesas@ideasonboard.com,
Rynn Wu (吳育恩), srv_heupstream,
Po-Yang Huang (黃柏陽), mchehab@kernel.org,
suleiman@chromium.org, shik@chromium.org,
Jungo Lin (林明俊),
Sj Huang (黃信璋), yuzhao@chromium.org,
linux-mediatek@lists.infradead.org, zwisler@chromium.org,
matthias.bgg@gmail.com, Christie Yu (游雅惠),
Frederic Chen (陳俊元), hans.verkuil@cisco.com,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <CAAFQd5Dw+jaT-+LAUEVeB8W1zdnOgPw7u+aCfDWhYW1SfbzO8g@mail.gmail.com>
Hi Tomasz,
On Mon, 2019-08-26 at 14:36 +0800, Tomasz Figa wrote:
> Hi Jerry,
>
> On Sun, Aug 25, 2019 at 6:18 PM Jerry-ch Chen
> <Jerry-ch.Chen@mediatek.com> wrote:
> >
> > Hi Tomasz,
> >
> > On Fri, 2019-08-02 at 16:28 +0800, Tomasz Figa wrote:
> > > Hi Jerry,
> > >
> > > On Tue, Jul 09, 2019 at 04:41:12PM +0800, Jerry-ch Chen wrote:
> > > > From: Jerry-ch Chen <jerry-ch.chen@mediatek.com>
> > > >
> > > > This patch adds the driver of Face Detection (FD) unit in
> > > > Mediatek camera system, providing face detection function.
> > > >
> > > > The mtk-isp directory will contain drivers for multiple IP
> > > > blocks found in Mediatek ISP system. It will include ISP Pass 1
> > > > driver (CAM), sensor interface driver, DIP driver and face
> > > > detection driver.
> > > >
> > > > Signed-off-by: Jerry-ch Chen <jerry-ch.chen@mediatek.com>
> > > > ---
> > > > drivers/media/platform/Makefile | 2 +
> > > > drivers/media/platform/mtk-isp/fd/Makefile | 5 +
> > > > drivers/media/platform/mtk-isp/fd/mtk_fd.h | 157 +++
> > > > drivers/media/platform/mtk-isp/fd/mtk_fd_40.c | 1259 +++++++++++++++++++++++++
> > > > include/uapi/linux/v4l2-controls.h | 4 +
> > > > 5 files changed, 1427 insertions(+)
> > > > create mode 100644 drivers/media/platform/mtk-isp/fd/Makefile
> > > > create mode 100644 drivers/media/platform/mtk-isp/fd/mtk_fd.h
> > > > create mode 100644 drivers/media/platform/mtk-isp/fd/mtk_fd_40.c
> > > >
> > >
> > > Thanks for the patch! I finally got a chance to fully review the code. Sorry
> > > for the delay. Please check my comments inline.
> > >
> > I appreciate your comments.
> > I've fixed most of the comments and verifying them,
> > Sorry for the delay, here is the reply.
> >
>
> Thanks for replying to all the comments, it's very helpful. I'll snip
> the parts that I don't have any further comments.
>
> [snip]
>
> > > > + if (usercount == 1) {
> > > > + pm_runtime_get_sync(&fd_dev->pdev->dev);
> > > > + if (mtk_fd_hw_enable(fd_hw)) {
> > > > + pm_runtime_put_sync(&fd_dev->pdev->dev);
> > > > + atomic_dec_return(&fd_hw->fd_user_cnt);
> > > > + mutex_unlock(&fd_hw->fd_hw_lock);
> > > > + return -EINVAL;
> > > > + }
> > > > + }
> > >
> > > This is a simple mem-to-mem device, so there is no reason to keep it active
> > > all the time it's streaming. Please just get the runtime PM counter when
> > > queuing a job to the hardware and release it when the job finishes.
> > >
> > > I guess we might still want to do the costly operations like rproc_boot()
> > > when we start streaming, though.
> > >
> > Do you mean by moving the pm_runtime_get/put stuff to the job execution
> > and job finish place?
>
> Yes.
>
> > the rproc_boot() operation will be done here.
> >
>
> How much time does the rproc_boot() operation take?
>
About 0.7~1.3ms, average 0.8ms (14 measurements)
> [snip]
>
> > > > +
> > > > + pm_runtime_put_sync(&fd_dev->pdev->dev);
> > >
> > > Any reason to use pm_runtime_put_sync() over pm_runtime_put()?
> > >
> > No special reason to do so, the pm_runtime_put_sync here will be moved
> > to the place each job finished.
> >
>
> If there is no reason, then the _sync() variant shouldn't be used, as
> it could affect the performance negatively.
>
Ok, I will use pm_runtime_put();
> [snip]
>
> > > > +static int mtk_fd_hw_job_exec(struct mtk_fd_hw *fd_hw,
> > > > + struct fd_hw_param *fd_param,
> > > > + void *output_vaddr)
> > > > +{
> > > > + struct fd_user_output *fd_output;
> > > > + struct ipi_message fd_ipi_msg;
> > > > + int ret;
> > > > + u32 num;
> > > > +
> > > > + if (fd_param->user_param.src_img_fmt == FMT_UNKNOWN)
> > > > + goto param_err;
> > >
> > > Is this possible?
> > >
> > Only if user set wrong format, I will remove this.
> >
>
> It shouldn't be possible to set a wrong format, because TRY_/S_FMT
> should adjust what the user set to something that is valid.
>
Ok, this will be removed.
> > > > +
> > > > + mutex_lock(&fd_hw->fd_hw_lock);
> > > > + fd_hw->state = FD_ENQ;
> > >
> > > What is this state for?
> > >
> > It was for checking status, if a job is processing, the state is
> > FD_ENQ,
> > then we should wait for the last job to be done when pm_suspend().
> >
>
> If so, would it be possible to make it a bool and call is_processing?
>
> [snip]
>
> > > > +static int mtk_fd_vb2_queue_setup(struct vb2_queue *vq,
> > > > + unsigned int *num_buffers,
> > > > + unsigned int *num_planes,
> > > > + unsigned int sizes[],
> > > > + struct device *alloc_devs[])
> > > > +{
> > > > + struct mtk_fd_ctx *ctx = vb2_get_drv_priv(vq);
> > > > + struct device *dev = ctx->dev;
> > > > + unsigned int size;
> > > > +
> > > > + switch (vq->type) {
> > > > + case V4L2_BUF_TYPE_META_CAPTURE:
> > > > + size = ctx->dst_fmt.buffersize;
> > > > + break;
> > > > + case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
> > > > + size = ctx->src_fmt.plane_fmt[0].sizeimage;
> > > > + break;
> > > > + default:
> > > > + dev_err(dev, "invalid queue type: %d\n", vq->type);
> > >
> > > We should need to handle this.
> > >
> > Do you mean by giving a size instead of return -EINVAL?
> >
>
> Sorry, typo. I meant we shouldn't need to handle it, because we can't
> get any other queue type here.
>
Ok, I see, I will remove it.
also, this function will be updated as following due to the 2 plane
case.
static int mtk_fd_vb2_queue_setup(struct vb2_queue *vq,
unsigned int *num_buffers,
unsigned int *num_planes,
unsigned int sizes[],
struct device *alloc_devs[])
{
struct mtk_fd_ctx *ctx = vb2_get_drv_priv(vq);
struct device *dev = ctx->dev;
unsigned int size[2];
switch (vq->type) {
case V4L2_BUF_TYPE_META_CAPTURE:
size[0] = ctx->dst_fmt.buffersize;
break;
case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
size[0] = ctx->src_fmt.plane_fmt[0].sizeimage;
if (*num_planes == 2)
size[1] = ctx->src_fmt.plane_fmt[1].sizeimage;
break;
}
if (*num_planes == 1) {
if (sizes[0] < size[0])
return -EINVAL;
} else if (*num_planes == 2) {
if ((sizes[0] < size[0]) && (sizes[1] < size[1]))
return -EINVAL;
} else {
*num_planes = 1;
sizes[0] = size[0];
}
return 0;
}
> [snip]
>
> > > > +static void mtk_fd_vb2_stop_streaming(struct vb2_queue *vq)
> > > > +{
> > > > + struct mtk_fd_ctx *ctx = vb2_get_drv_priv(vq);
> > > > + struct vb2_buffer *vb;
> > >
> > > How do we guarantee here that the hardware isn't still accessing the buffers
> > > removed below?
> > >
> > Maybe we can check the driver state flag and aborting the unfinished
> > jobs?
> > (fd_hw->state == FD_ENQ)
> >
>
> Yes, we need to either cancel or wait for the currently processing
> job. It depends on hardware capabilities, but cancelling is generally
> preferred for the lower latency.
>
Ok, it the state is ENQ, then we can disable the FD hw by controlling
the registers.
for example:
writel(0x0, fd->fd_base + FD_HW_ENABLE);
writel(0x0, fd->fd_base + FD_INT_EN);
> > > > +
> > > > + if (V4L2_TYPE_IS_OUTPUT(vq->type))
> > > > + vb = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> > > > + else
> > > > + vb = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> > > > +
> > > > + while (vb) {
> > > > + v4l2_m2m_buf_done(to_vb2_v4l2_buffer(vb), VB2_BUF_STATE_ERROR);
> > > > + if (V4L2_TYPE_IS_OUTPUT(vq->type))
> > > > + vb = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> > > > + else
> > > > + vb = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> > > > + }
> > >
> > > We can use v4l2_m2m_buf_remove(). Also we can move the call into the loop
> > > condition:
> > >
> > > while ((vb == v4l2_m2m_buf_remove(...)))
> > > v4l2_m2m_buf_done(...);
> > >
> > Ok, I will refine as following:
> >
> > while ((vb = v4l2_m2m_buf_remove(V4L2_TYPE_IS_OUTPUT(vq->type)?
> > &m2m_ctx->out_q_ctx :
> > &m2m_ctx->cap_q_ctx)))
> > v4l2_m2m_buf_done(vb, VB2_BUF_STATE_ERROR);
>
> Please move the queue type check before the loop and save the queue
> context in a local variable.
>
Ok, I will refine as following:
struct v4l2_m2m_queue_ctx *queue_ctx;
queue_ctx = V4L2_TYPE_IS_OUTPUT(vq->type) ?
&m2m_ctx->out_q_ctx :
&m2m_ctx->cap_q_ctx;
while ((vb = v4l2_m2m_buf_remove(queue_ctx)))
v4l2_m2m_buf_done(vb, VB2_BUF_STATE_ERROR);
> [snip]
>
> > > > +}
> > > > +
> > > > +static void mtk_fd_vb2_request_complete(struct vb2_buffer *vb)
> > > > +{
> > > > + struct mtk_fd_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
> > > > +
> > > > + v4l2_ctrl_request_complete(vb->req_obj.req, &ctx->hdl);
> > > > +}
> > > > +
> > > > +static void mtk_fd_fill_pixfmt_mp(struct v4l2_pix_format_mplane *dfmt,
> > > > + const struct v4l2_pix_format_mplane *sfmt)
> > > > +{
> > > > + dfmt->width = sfmt->width;
> > > > + dfmt->height = sfmt->height;
> > > > + dfmt->pixelformat = sfmt->pixelformat;
> > > > + dfmt->field = sfmt->field;
> > > > + dfmt->colorspace = sfmt->colorspace;
> > > > + dfmt->num_planes = sfmt->num_planes;
> > > > +
> > > > + /* Use default */
> > > > + dfmt->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;
> > > > + dfmt->quantization = V4L2_QUANTIZATION_DEFAULT;
> > > > + dfmt->xfer_func =
> > > > + V4L2_MAP_XFER_FUNC_DEFAULT(dfmt->colorspace);
> > > > + dfmt->plane_fmt[0].bytesperline = dfmt->width * 2;
> > > > + dfmt->plane_fmt[0].sizeimage =
> > > > + dfmt->height * dfmt->plane_fmt[0].bytesperline;
> > > > + memset(dfmt->reserved, 0, sizeof(dfmt->reserved));
> > > > +}
> > >
> > > Could we unify this function with mtk_fd_m2m_try_fmt_out_mp()? That function
> > > should be almost directly reusable for the default format initialization +/-
> > > the arguments passed to it.
> > >
> > Ok, I will try to reuse it as following:
> >
> > static void mtk_fd_fill_pixfmt_mp(struct v4l2_pix_format_mplane *dfmt,
> > const struct v4l2_pix_format_mplane *sfmt)
> > {
> > dfmt->field = V4L2_FIELD_NONE;
> > dfmt->colorspace = V4L2_COLORSPACE_BT2020;
> > dfmt->num_planes = sfmt->num_planes;
> > dfmt->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;
> > dfmt->quantization = V4L2_QUANTIZATION_DEFAULT;
> > dfmt->xfer_func =
> > V4L2_MAP_XFER_FUNC_DEFAULT(dfmt->colorspace);
> >
> > /* Keep user setting as possible */
> > dfmt->width = clamp(dfmt->width,
> > MTK_FD_OUTPUT_MIN_WIDTH,
> > MTK_FD_OUTPUT_MAX_WIDTH);
> > dfmt->height = clamp(dfmt->height,
> > MTK_FD_OUTPUT_MIN_HEIGHT,
> > MTK_FD_OUTPUT_MAX_HEIGHT);
> >
> > if (sfmt->num_planes == 2) {
> > /* NV16M and NV61M has 1 byte per pixel */
> > dfmt->plane_fmt[0].bytesperline = dfmt->width;
> > dfmt->plane_fmt[1].bytesperline = dfmt->width;
> > } else {
> > /* 2 bytes per pixel */
> > dfmt->plane_fmt[0].bytesperline = dfmt->width * 2;
> > }
> >
> > dfmt->plane_fmt[0].sizeimage =
> > dfmt->height * dfmt->plane_fmt[0].bytesperline;
> > }
>
> How would the implementation of TRY_FMT look in this case?
>
It will be looked like:
static int mtk_fd_try_fmt_out_mp(struct file *file,
void *fh,
struct v4l2_format *f)
{
struct v4l2_pix_format_mplane *pix_mp = &f->fmt.pix_mp;
const struct v4l2_pix_format_mplane *fmt;
fmt = mtk_fd_find_fmt(pix_mp->pixelformat);
if (!fmt)
fmt = &mtk_fd_img_fmts[0]; /* Get default img fmt */
mtk_fd_fill_pixfmt_mp(pix_mp, fmt);
return 0;
}
> [snip]
>
> > > > +static int mtk_fd_m2m_enum_fmt_out_mp(struct file *file, void *fh,
> > > > + struct v4l2_fmtdesc *f)
> > > > +{
> > > > + int i;
> > > > +
> > > > + for (i = 0; i < NUM_FORMATS; ++i) {
> > > > + if (i == f->index) {
> > > > + f->pixelformat = in_img_fmts[i].pixelformat;
> > > > + return 0;
> > > > + }
> > > > + }
> > >
> > > Why don't we just check if f->index is within the [0, ARRAY_SIZE()-1] bounds
> > > and then just use it to index the array directly?
> > >
> > I will refine as :
> >
> > static int mtk_fd_m2m_enum_fmt_out_mp(struct file *file, void *fh,
> > struct v4l2_fmtdesc *f)
> > {
> > if ((f->index >= 0) && (f->index < NUM_FORMATS)) {
>
> f->index is unsigned
>
> > f->pixelformat = in_img_fmts[f->index].pixelformat;
> > return 0;
> > }
> >
> > return -EINVAL;
> > }
>
> nit: The usual convention is to check for invalid values and return early, i.e.
>
> if (f->index >= NUM_FORMATS)
> return -EINVAL;
>
> f->pixelformat = in_img_fmts[f->index].pixelformat;
> return 0;
>
Ok, Done.
> > > > +
> > > > + return -EINVAL;
> > > > +}
> > > > +
> > > > +static int mtk_fd_m2m_try_fmt_out_mp(struct file *file,
> > > > + void *fh,
> > > > + struct v4l2_format *f)
> > >
> > > I think we could just shorten the function prefixes to "mtk_fd_".
> > >
> > Do you mean by replace mtk_fd_m2m_* with mtk_fd_ ?
> >
>
> Yes.
>
Done.
> [snip]
>
> > > > +static int mtk_fd_request_validate(struct media_request *req)
> > > > +{
> > > > + unsigned int count;
> > > > +
> > > > + count = vb2_request_buffer_cnt(req);
> > > > + if (!count)
> > > > + return -ENOENT;
> > >
> > > Why -ENOENT?
> > >
> > Reference the return code in vb2_request_validate()
>
> You're right, -ENOENT seems to be the right error code here.
>
> > I consider refining as following:
> > static int mtk_fd_request_validate(struct media_request *req)
> > {
> > if (vb2_request_buffer_cnt(req) > 1)
> > return -EINVAL;
> >
> > return vb2_request_validate(req);
> > }
> > or maybe I don't need to worry the request count greater than 1,
> > just remove this function and set vb2_request_validate as .req_validate
> > directly?
> >
>
> Given that we only have 1 queue handling requests, we should be able
> to just use vb2_request_validate() indeed.
>
Ok, it will be refined as following:
static const struct media_device_ops fd_m2m_media_ops = {
.req_validate = vb2_request_validate,
.req_queue = v4l2_m2m_request_queue,
};
Thanks and best regards,
Jerry
> Best regards,
> Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/8] coresight: etm4x: Fixes for ETM v4.4 architecture updates.
From: Leo Yan @ 2019-08-28 1:52 UTC (permalink / raw)
To: Mike Leach; +Cc: coresight, linux-arm-kernel, mathieu.poirier
In-Reply-To: <20190819205720.24457-2-mike.leach@linaro.org>
Hi Mike,
On Mon, Aug 19, 2019 at 09:57:13PM +0100, Mike Leach wrote:
> ETMv4.4 adds in support for tracing secure EL2 (per arch 8.x updates).
> Patch accounts for this new capability.
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
I reviewed this patch with connecting ETMv4.4 specification (which you
shared pointer in another email), I don't find any issue for registers
operations:
Reviewed-by: Leo Yan <leo.yan@linaro.org>
> ---
> .../hwtracing/coresight/coresight-etm4x-sysfs.c | 12 ++++++------
> drivers/hwtracing/coresight/coresight-etm4x.c | 5 ++++-
> drivers/hwtracing/coresight/coresight-etm4x.h | 15 +++++++++++----
> 3 files changed, 21 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> index 219c10eb752c..b6984be0c515 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> @@ -738,7 +738,7 @@ static ssize_t s_exlevel_vinst_show(struct device *dev,
> struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> struct etmv4_config *config = &drvdata->config;
>
> - val = BMVAL(config->vinst_ctrl, 16, 19);
> + val = (config->vinst_ctrl & ETM_EXLEVEL_S_VICTLR_MASK) >> 16;
> return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> }
>
> @@ -754,8 +754,8 @@ static ssize_t s_exlevel_vinst_store(struct device *dev,
> return -EINVAL;
>
> spin_lock(&drvdata->spinlock);
> - /* clear all EXLEVEL_S bits (bit[18] is never implemented) */
> - config->vinst_ctrl &= ~(BIT(16) | BIT(17) | BIT(19));
> + /* clear all EXLEVEL_S bits */
> + config->vinst_ctrl &= ~(ETM_EXLEVEL_S_VICTLR_MASK);
> /* enable instruction tracing for corresponding exception level */
> val &= drvdata->s_ex_level;
> config->vinst_ctrl |= (val << 16);
> @@ -773,7 +773,7 @@ static ssize_t ns_exlevel_vinst_show(struct device *dev,
> struct etmv4_config *config = &drvdata->config;
>
> /* EXLEVEL_NS, bits[23:20] */
> - val = BMVAL(config->vinst_ctrl, 20, 23);
> + val = (config->vinst_ctrl & ETM_EXLEVEL_NS_VICTLR_MASK) >> 20;
> return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> }
>
> @@ -789,8 +789,8 @@ static ssize_t ns_exlevel_vinst_store(struct device *dev,
> return -EINVAL;
>
> spin_lock(&drvdata->spinlock);
> - /* clear EXLEVEL_NS bits (bit[23] is never implemented */
> - config->vinst_ctrl &= ~(BIT(20) | BIT(21) | BIT(22));
> + /* clear EXLEVEL_NS bits */
> + config->vinst_ctrl &= ~(ETM_EXLEVEL_NS_VICTLR_MASK);
> /* enable instruction tracing for corresponding exception level */
> val &= drvdata->ns_ex_level;
> config->vinst_ctrl |= (val << 20);
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
> index a128b5063f46..52b8876de157 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> @@ -629,6 +629,7 @@ static void etm4_init_arch_data(void *info)
> * TRCARCHMAJ, bits[11:8] architecture major versin number
> */
> drvdata->arch = BMVAL(etmidr1, 4, 11);
> + drvdata->config.arch = drvdata->arch;
>
> /* maximum size of resources */
> etmidr2 = readl_relaxed(drvdata->base + TRCIDR2);
> @@ -780,6 +781,7 @@ static u64 etm4_get_ns_access_type(struct etmv4_config *config)
> static u64 etm4_get_access_type(struct etmv4_config *config)
> {
> u64 access_type = etm4_get_ns_access_type(config);
> + u64 s_hyp = (config->arch & 0x0f) >= 0x4 ? ETM_EXLEVEL_S_HYP : 0;
>
> /*
> * EXLEVEL_S, bits[11:8], don't trace anything happening
> @@ -787,7 +789,8 @@ static u64 etm4_get_access_type(struct etmv4_config *config)
> */
> access_type |= (ETM_EXLEVEL_S_APP |
> ETM_EXLEVEL_S_OS |
> - ETM_EXLEVEL_S_HYP);
> + s_hyp |
> + ETM_EXLEVEL_S_MON);
>
> return access_type;
> }
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
> index 4523f10ddd0f..60bc2fb5159b 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x.h
> +++ b/drivers/hwtracing/coresight/coresight-etm4x.h
> @@ -180,17 +180,22 @@
> /* PowerDown Control Register bits */
> #define TRCPDCR_PU BIT(3)
>
> -/* secure state access levels */
> +/* secure state access levels - TRCACATRn */
> #define ETM_EXLEVEL_S_APP BIT(8)
> #define ETM_EXLEVEL_S_OS BIT(9)
> -#define ETM_EXLEVEL_S_NA BIT(10)
> -#define ETM_EXLEVEL_S_HYP BIT(11)
> -/* non-secure state access levels */
> +#define ETM_EXLEVEL_S_HYP BIT(10)
> +#define ETM_EXLEVEL_S_MON BIT(11)
> +/* non-secure state access levels - TRCACATRn */
> #define ETM_EXLEVEL_NS_APP BIT(12)
> #define ETM_EXLEVEL_NS_OS BIT(13)
> #define ETM_EXLEVEL_NS_HYP BIT(14)
> #define ETM_EXLEVEL_NS_NA BIT(15)
>
> +/* secure / non secure masks - TRCVICTLR, IDR3 */
> +#define ETM_EXLEVEL_S_VICTLR_MASK GENMASK(19, 16)
> +/* NS MON (EL3) mode never implemented */
> +#define ETM_EXLEVEL_NS_VICTLR_MASK GENMASK(22, 20)
> +
> /**
> * struct etmv4_config - configuration information related to an ETMv4
> * @mode: Controls various modes supported by this ETM.
> @@ -237,6 +242,7 @@
> * @vmid_mask0: VM ID comparator mask for comparator 0-3.
> * @vmid_mask1: VM ID comparator mask for comparator 4-7.
> * @ext_inp: External input selection.
> + * @arch: ETM architecture version (for arch dependent config).
> */
> struct etmv4_config {
> u32 mode;
> @@ -279,6 +285,7 @@ struct etmv4_config {
> u32 vmid_mask0;
> u32 vmid_mask1;
> u32 ext_inp;
> + u8 arch;
> };
>
> /**
> --
> 2.17.1
>
> _______________________________________________
> CoreSight mailing list
> CoreSight@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/coresight
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v4 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Peng Fan @ 2019-08-28 1:51 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
f.fainelli@gmail.com, andre.przywara@arm.com,
jassisinghbrar@gmail.com, linux-kernel@vger.kernel.org,
dl-linux-imx, sudeep.holla@arm.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAL_JsqK7xPTYFzSXt52m+Z0LRcFy2TUfa45XzY1YGH0-JRA-WQ@mail.gmail.com>
Hi Rob,
> Subject: Re: [PATCH v4 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
>
> On Tue, Aug 27, 2019 at 4:51 AM Peng Fan <peng.fan@nxp.com> wrote:
> >
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > The ARM SMC/HVC mailbox binding describes a firmware interface to
> > trigger actions in software layers running in the EL2 or EL3 exception levels.
> > The term "ARM" here relates to the SMC instruction as part of the ARM
> > instruction set, not as a standard endorsed by ARM Ltd.
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > .../devicetree/bindings/mailbox/arm-smc.yaml | 126
> +++++++++++++++++++++
> > 1 file changed, 126 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > new file mode 100644
> > index 000000000000..ae677e0c0910
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > @@ -0,0 +1,126 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fschemas%2Fmailbox%2Farm-smc.yaml%23&data=02%7
> C01%7Cp
> >
> +eng.fan%40nxp.com%7C0e905f3fe89b4dc9ee0608d72af06e30%7C686ea1d
> 3bc2b4c
> >
> +6fa92cd99c5c301635%7C0%7C0%7C637025084458964761&sdata=p8
> EeFkU5pW3
> > +D8bzpZu9IHCoFD%2F2ZBcSr6WyCsIK9LqU%3D&reserved=0
> > +$schema:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=02%7C01%7Cpe
> ng.fan%
> >
> +40nxp.com%7C0e905f3fe89b4dc9ee0608d72af06e30%7C686ea1d3bc2b4c6
> fa92cd9
> >
> +9c5c301635%7C0%7C0%7C637025084458964761&sdata=JFhz7meFyG
> ozMLnt4Jb
> > +RGneYty6cBSCKyxHpl26TAsI%3D&reserved=0
> > +
> > +title: ARM SMC Mailbox Interface
> > +
> > +maintainers:
> > + - Peng Fan <peng.fan@nxp.com>
> > +
> > +description: |
> > + This mailbox uses the ARM smc (secure monitor call) and hvc
> > +(hypervisor
> > + call) instruction to trigger a mailbox-connected activity in
> > +firmware,
> > + executing on the very same core as the caller. By nature this
> > +operation
> > + is synchronous and this mailbox provides no way for asynchronous
> > +messages
> > + to be delivered the other way round, from firmware to the OS, but
> > + asynchronous notification could also be supported. However the
> > +value of
> > + r0/w0/x0 the firmware returns after the smc call is delivered as a
> > +received
> > + message to the mailbox framework, so a synchronous communication
> > +can be
> > + established, for a asynchronous notification, no value will be returned.
> > + The exact meaning of both the action the mailbox triggers as well
> > +as the
> > + return value is defined by their users and is not subject to this binding.
> > +
> > + One use case of this mailbox is the SCMI interface, which uses
> > + shared memory to transfer commands and parameters, and a mailbox
> to
> > + trigger a function call. This allows SoCs without a separate
> > + management processor (or when such a processor is not available or
> > + used) to use this standardized interface anyway.
> > +
> > + This binding describes no hardware, but establishes a firmware
> interface.
> > + Upon receiving an SMC using one of the described SMC function
> > + identifiers, the firmware is expected to trigger some mailbox connected
> functionality.
> > + The communication follows the ARM SMC calling convention.
> > + Firmware expects an SMC function identifier in r0 or w0. The
> > + supported identifiers are passed from consumers, or listed in the
> > + the arm,func-ids properties as described below. The firmware can
> > + return one value in the first SMC result register, it is expected
> > + to be an error value, which shall be propagated to the mailbox client.
> > +
> > + Any core which supports the SMC or HVC instruction can be used, as
> > + long as a firmware component running in EL3 or EL2 is handling these
> calls.
> > +
> > +properties:
> > + compatible:
> > + const: arm,smc-mbox
> > +
> > + "#mbox-cells":
> > + const: 1
> > +
> > + arm,num-chans:
> > + description: The number of channels supported.
> > + items:
> > + minimum: 1
> > + maximum: 4096 # Should be enough?
> > +
> > + method:
> > + items:
>
> You can drop 'items' as this is a single entry.
Will fix in v5.
>
> > + - enum:
> > + - smc
> > + - hvc
> > +
> > + transports:
> > + items:
>
> same here
Fix in v5.
>
> > + - enum:
> > + - mem
> > + - reg
> > +
> > + arm,func-ids:
>
> Needs a $ref to a type (uint32-array).
Fix in v5.
>
> > + description: |
> > + An array of 32-bit values specifying the function IDs used by each
> > + mailbox channel. Those function IDs follow the ARM SMC calling
> > + convention standard [1].
> > +
> > + There is one identifier per channel and the number of supported
> > + channels is determined by the length of this array.
> > + minItems: 0
> > + maxItems: 4096 # Should be enough?
> > +
> > +required:
> > + - compatible
> > + - "#mbox-cells"
> > + - arm,num-chans
> > + - transports
> > + - method
> > +
> > +examples:
> > + - |
> > + sram@910000 {
> > + compatible = "mmio-sram";
> > + reg = <0x0 0x93f000 0x0 0x1000>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0x0 0x93f000 0x1000>;
> > +
> > + cpu_scp_lpri: scp-shmem@0 {
>
> Looks like some indentation problem...
Fix in v5.
>
> > + compatible = "arm,scmi-shmem";
> > + reg = <0x0 0x200>;
> > + };
> > +
> > + cpu_scp_hpri: scp-shmem@200 {
> > + compatible = "arm,scmi-shmem";
> > + reg = <0x200 0x200>;
> > + };
> > + };
> > +
> > + firmware {
> > + smc_mbox: mailbox {
> > + #mbox-cells = <1>;
> > + compatible = "arm,smc-mbox";
> > + method = "smc";
> > + arm,num-chans = <0x2>;
> > + transports = "mem";
> > + /* Optional */
> > + arm,func-ids = <0xc20000fe>, <0xc20000ff>;
> > + };
> > +
> > + scmi {
> > + compatible = "arm,scmi";
> > + mboxes = <&mailbox 0 &mailbox 1>;
>
> &smc_mbox and <> each entry.
Fix in v5.
>
> > + mbox-names = "tx", "rx";
> > + shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
>
> <> each entry
Fix in v5.
Thanks,
Peng.
>
> > + };
> > + };
> > +
> > +...
> > --
> > 2.16.4
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
From: Peng Fan @ 2019-08-28 1:48 UTC (permalink / raw)
To: Robin Murphy, sstabellini@kernel.org, linux@armlinux.org.uk
Cc: van.freenix@gmail.com, xen-devel@lists.xenproject.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, dl-linux-imx
In-Reply-To: <d70b3a5c-647c-2147-99be-4572f76e898b@arm.com>
Hi Robin,
> Subject: Re: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
>
> On 09/07/2019 09:22, Peng Fan wrote:
> > arm64 shares some code under arch/arm/xen, including mm.c.
> > However ZONE_DMA is removed by commit
> > ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
> > So to ARM64, need use __GFP_DMA32.
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > arch/arm/xen/mm.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index
> > e1d44b903dfc..a95e76d18bf9 100644
> > --- a/arch/arm/xen/mm.c
> > +++ b/arch/arm/xen/mm.c
> > @@ -27,7 +27,7 @@ unsigned long xen_get_swiotlb_free_pages(unsigned
> > int order)
> >
> > for_each_memblock(memory, reg) {
> > if (reg->base < (phys_addr_t)0xffffffff) {
> > - flags |= __GFP_DMA;
> > + flags |= __GFP_DMA | __GFP_DMA32;
>
> Given the definition of GFP_ZONE_BAD, I'm not sure this combination of flags
> is strictly valid, but rather is implicitly reliant on only one of those zones ever
> actually existing. As such, it seems liable to blow up if the plans to add
> ZONE_DMA to arm64[1] go ahead.
How about this, or do you have any suggestions?
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index d33b77e9add3..f61c29a4430f 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -28,7 +28,11 @@ unsigned long xen_get_swiotlb_free_pages(unsigned int order)
for_each_memblock(memory, reg) {
if (reg->base < (phys_addr_t)0xffffffff) {
+#ifdef CONFIG_ARM64
+ flags |= __GFP_DMA32;
+#else
flags |= __GFP_DMA;
+#endif
break;
}
}
Thanks,
Peng.
>
> Robin.
>
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke
> rnel.org%2Flinux-arm-kernel%2F20190820145821.27214-1-nsaenzjulienne%
> 40suse.de%2F&data=02%7C01%7Cpeng.fan%40nxp.com%7C5d2a641b1
> e3f449562f908d72ae95d85%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0
> %7C0%7C637025054169859035&sdata=1ZPGH0gZnvgmlMpX7VrjUNME
> XbEjiv4%2FZ9pYwTQTWxY%3D&reserved=0
>
> > break;
> > }
> > }
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V5 4/4] ARM: dts: imx7ulp: Add wdog1 node
From: Anson Huang @ 2019-08-28 13:35 UTC (permalink / raw)
To: wim, linux, robh+dt, mark.rutland, shawnguo, s.hauer, kernel,
festevam, linux, otavio, leonard.crestez, u.kleine-koenig,
schnitzeltony, jan.tuerk, linux-watchdog, devicetree,
linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1566999303-18795-1-git-send-email-Anson.Huang@nxp.com>
Add wdog1 node to support watchdog driver.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
Changes since V4:
- improve watchdog node name.
---
arch/arm/boot/dts/imx7ulp.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/imx7ulp.dtsi b/arch/arm/boot/dts/imx7ulp.dtsi
index 6859a3a..2677e00 100644
--- a/arch/arm/boot/dts/imx7ulp.dtsi
+++ b/arch/arm/boot/dts/imx7ulp.dtsi
@@ -264,6 +264,16 @@
#clock-cells = <1>;
};
+ wdog1: watchdog@403d0000 {
+ compatible = "fsl,imx7ulp-wdt";
+ reg = <0x403d0000 0x10000>;
+ interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pcc2 IMX7ULP_CLK_WDG1>;
+ assigned-clocks = <&pcc2 IMX7ULP_CLK_WDG1>;
+ assigned-clocks-parents = <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>;
+ timeout-sec = <40>;
+ };
+
pcc2: clock-controller@403f0000 {
compatible = "fsl,imx7ulp-pcc2";
reg = <0x403f0000 0x10000>;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V5 2/4] watchdog: Add i.MX7ULP watchdog support
From: Anson Huang @ 2019-08-28 13:35 UTC (permalink / raw)
To: wim, linux, robh+dt, mark.rutland, shawnguo, s.hauer, kernel,
festevam, linux, otavio, leonard.crestez, u.kleine-koenig,
schnitzeltony, jan.tuerk, linux-watchdog, devicetree,
linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1566999303-18795-1-git-send-email-Anson.Huang@nxp.com>
The i.MX7ULP Watchdog Timer (WDOG) module is an independent timer
that is available for system use.
It provides a safety feature to ensure that software is executing
as planned and that the CPU is not stuck in an infinite loop or
executing unintended code. If the WDOG module is not serviced
(refreshed) within a certain period, it resets the MCU.
Add driver support for i.MX7ULP watchdog.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
No changes.
---
drivers/watchdog/Kconfig | 13 +++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/imx7ulp_wdt.c | 243 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 257 insertions(+)
create mode 100644 drivers/watchdog/imx7ulp_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index a8f5c81..d68e5b5 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -724,6 +724,19 @@ config IMX_SC_WDT
To compile this driver as a module, choose M here: the
module will be called imx_sc_wdt.
+config IMX7ULP_WDT
+ tristate "IMX7ULP Watchdog"
+ depends on ARCH_MXC || COMPILE_TEST
+ select WATCHDOG_CORE
+ help
+ This is the driver for the hardware watchdog on the Freescale
+ IMX7ULP and later processors. If you have one of these
+ processors and wish to have watchdog support enabled,
+ say Y, otherwise say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called imx7ulp_wdt.
+
config UX500_WATCHDOG
tristate "ST-Ericsson Ux500 watchdog"
depends on MFD_DB8500_PRCMU
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index b5a0aed..2ee352b 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o
obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
obj-$(CONFIG_IMX_SC_WDT) += imx_sc_wdt.o
+obj-$(CONFIG_IMX7ULP_WDT) += imx7ulp_wdt.o
obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
diff --git a/drivers/watchdog/imx7ulp_wdt.c b/drivers/watchdog/imx7ulp_wdt.c
new file mode 100644
index 0000000..5ce5102
--- /dev/null
+++ b/drivers/watchdog/imx7ulp_wdt.c
@@ -0,0 +1,243 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2019 NXP.
+ */
+
+#include <linux/clk.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/reboot.h>
+#include <linux/watchdog.h>
+
+#define WDOG_CS 0x0
+#define WDOG_CS_CMD32EN BIT(13)
+#define WDOG_CS_ULK BIT(11)
+#define WDOG_CS_RCS BIT(10)
+#define WDOG_CS_EN BIT(7)
+#define WDOG_CS_UPDATE BIT(5)
+
+#define WDOG_CNT 0x4
+#define WDOG_TOVAL 0x8
+
+#define REFRESH_SEQ0 0xA602
+#define REFRESH_SEQ1 0xB480
+#define REFRESH ((REFRESH_SEQ1 << 16) | REFRESH_SEQ0)
+
+#define UNLOCK_SEQ0 0xC520
+#define UNLOCK_SEQ1 0xD928
+#define UNLOCK ((UNLOCK_SEQ1 << 16) | UNLOCK_SEQ0)
+
+#define DEFAULT_TIMEOUT 60
+#define MAX_TIMEOUT 128
+#define WDOG_CLOCK_RATE 1000
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0000);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+ __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+struct imx7ulp_wdt_device {
+ struct notifier_block restart_handler;
+ struct watchdog_device wdd;
+ void __iomem *base;
+ struct clk *clk;
+};
+
+static inline void imx7ulp_wdt_enable(void __iomem *base, bool enable)
+{
+ u32 val = readl(base + WDOG_CS);
+
+ writel(UNLOCK, base + WDOG_CNT);
+ if (enable)
+ writel(val | WDOG_CS_EN, base + WDOG_CS);
+ else
+ writel(val & ~WDOG_CS_EN, base + WDOG_CS);
+}
+
+static inline bool imx7ulp_wdt_is_enabled(void __iomem *base)
+{
+ u32 val = readl(base + WDOG_CS);
+
+ return val & WDOG_CS_EN;
+}
+
+static int imx7ulp_wdt_ping(struct watchdog_device *wdog)
+{
+ struct imx7ulp_wdt_device *wdt = watchdog_get_drvdata(wdog);
+
+ writel(REFRESH, wdt->base + WDOG_CNT);
+
+ return 0;
+}
+
+static int imx7ulp_wdt_start(struct watchdog_device *wdog)
+{
+ struct imx7ulp_wdt_device *wdt = watchdog_get_drvdata(wdog);
+
+ imx7ulp_wdt_enable(wdt->base, true);
+
+ return 0;
+}
+
+static int imx7ulp_wdt_stop(struct watchdog_device *wdog)
+{
+ struct imx7ulp_wdt_device *wdt = watchdog_get_drvdata(wdog);
+
+ imx7ulp_wdt_enable(wdt->base, false);
+
+ return 0;
+}
+
+static int imx7ulp_wdt_set_timeout(struct watchdog_device *wdog,
+ unsigned int timeout)
+{
+ struct imx7ulp_wdt_device *wdt = watchdog_get_drvdata(wdog);
+ u32 val = WDOG_CLOCK_RATE * timeout;
+
+ writel(UNLOCK, wdt->base + WDOG_CNT);
+ writel(val, wdt->base + WDOG_TOVAL);
+
+ wdog->timeout = timeout;
+
+ return 0;
+}
+
+static const struct watchdog_ops imx7ulp_wdt_ops = {
+ .owner = THIS_MODULE,
+ .start = imx7ulp_wdt_start,
+ .stop = imx7ulp_wdt_stop,
+ .ping = imx7ulp_wdt_ping,
+ .set_timeout = imx7ulp_wdt_set_timeout,
+};
+
+static const struct watchdog_info imx7ulp_wdt_info = {
+ .identity = "i.MX7ULP watchdog timer",
+ .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
+ WDIOF_MAGICCLOSE,
+};
+
+static inline void imx7ulp_wdt_init(void __iomem *base, unsigned int timeout)
+{
+ u32 val;
+
+ /* unlock the wdog for reconfiguration */
+ writel_relaxed(UNLOCK_SEQ0, base + WDOG_CNT);
+ writel_relaxed(UNLOCK_SEQ1, base + WDOG_CNT);
+
+ /* set an initial timeout value in TOVAL */
+ writel(timeout, base + WDOG_TOVAL);
+ /* enable 32bit command sequence and reconfigure */
+ val = BIT(13) | BIT(8) | BIT(5);
+ writel(val, base + WDOG_CS);
+}
+
+static void imx7ulp_wdt_action(void *data)
+{
+ clk_disable_unprepare(data);
+}
+
+static int imx7ulp_wdt_probe(struct platform_device *pdev)
+{
+ struct imx7ulp_wdt_device *imx7ulp_wdt;
+ struct device *dev = &pdev->dev;
+ struct watchdog_device *wdog;
+ int ret;
+
+ imx7ulp_wdt = devm_kzalloc(dev, sizeof(*imx7ulp_wdt), GFP_KERNEL);
+ if (!imx7ulp_wdt)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, imx7ulp_wdt);
+
+ imx7ulp_wdt->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(imx7ulp_wdt->base))
+ return PTR_ERR(imx7ulp_wdt->base);
+
+ imx7ulp_wdt->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(imx7ulp_wdt->clk)) {
+ dev_err(dev, "Failed to get watchdog clock\n");
+ return PTR_ERR(imx7ulp_wdt->clk);
+ }
+
+ ret = clk_prepare_enable(imx7ulp_wdt->clk);
+ if (ret)
+ return ret;
+
+ ret = devm_add_action_or_reset(dev, imx7ulp_wdt_action, imx7ulp_wdt->clk);
+ if (ret)
+ return ret;
+
+ wdog = &imx7ulp_wdt->wdd;
+ wdog->info = &imx7ulp_wdt_info;
+ wdog->ops = &imx7ulp_wdt_ops;
+ wdog->min_timeout = 1;
+ wdog->max_timeout = MAX_TIMEOUT;
+ wdog->parent = dev;
+ wdog->timeout = DEFAULT_TIMEOUT;
+
+ watchdog_init_timeout(wdog, 0, dev);
+ watchdog_stop_on_reboot(wdog);
+ watchdog_stop_on_unregister(wdog);
+ watchdog_set_drvdata(wdog, imx7ulp_wdt);
+ imx7ulp_wdt_init(imx7ulp_wdt->base, wdog->timeout * WDOG_CLOCK_RATE);
+
+ return devm_watchdog_register_device(dev, wdog);
+}
+
+static int __maybe_unused imx7ulp_wdt_suspend(struct device *dev)
+{
+ struct imx7ulp_wdt_device *imx7ulp_wdt = dev_get_drvdata(dev);
+
+ if (watchdog_active(&imx7ulp_wdt->wdd))
+ imx7ulp_wdt_stop(&imx7ulp_wdt->wdd);
+
+ clk_disable_unprepare(imx7ulp_wdt->clk);
+
+ return 0;
+}
+
+static int __maybe_unused imx7ulp_wdt_resume(struct device *dev)
+{
+ struct imx7ulp_wdt_device *imx7ulp_wdt = dev_get_drvdata(dev);
+ u32 timeout = imx7ulp_wdt->wdd.timeout * WDOG_CLOCK_RATE;
+ int ret;
+
+ ret = clk_prepare_enable(imx7ulp_wdt->clk);
+ if (ret)
+ return ret;
+
+ if (imx7ulp_wdt_is_enabled(imx7ulp_wdt->base))
+ imx7ulp_wdt_init(imx7ulp_wdt->base, timeout);
+
+ if (watchdog_active(&imx7ulp_wdt->wdd))
+ imx7ulp_wdt_start(&imx7ulp_wdt->wdd);
+
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(imx7ulp_wdt_pm_ops, imx7ulp_wdt_suspend,
+ imx7ulp_wdt_resume);
+
+static const struct of_device_id imx7ulp_wdt_dt_ids[] = {
+ { .compatible = "fsl,imx7ulp-wdt", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, imx7ulp_wdt_dt_ids);
+
+static struct platform_driver imx7ulp_wdt_driver = {
+ .probe = imx7ulp_wdt_probe,
+ .driver = {
+ .name = "imx7ulp-wdt",
+ .pm = &imx7ulp_wdt_pm_ops,
+ .of_match_table = imx7ulp_wdt_dt_ids,
+ },
+};
+module_platform_driver(imx7ulp_wdt_driver);
+
+MODULE_AUTHOR("Anson Huang <Anson.Huang@nxp.com>");
+MODULE_DESCRIPTION("Freescale i.MX7ULP watchdog driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V5 3/4] ARM: imx_v6_v7_defconfig: Enable CONFIG_IMX7ULP_WDT by default
From: Anson Huang @ 2019-08-28 13:35 UTC (permalink / raw)
To: wim, linux, robh+dt, mark.rutland, shawnguo, s.hauer, kernel,
festevam, linux, otavio, leonard.crestez, u.kleine-koenig,
schnitzeltony, jan.tuerk, linux-watchdog, devicetree,
linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1566999303-18795-1-git-send-email-Anson.Huang@nxp.com>
Select CONFIG_IMX7ULP_WDT by default to support i.MX7ULP watchdog.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
no changes.
---
arch/arm/configs/imx_v6_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 9bfffbe..be2a694 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -236,6 +236,7 @@ CONFIG_DA9062_WATCHDOG=y
CONFIG_DA9063_WATCHDOG=m
CONFIG_RN5T618_WATCHDOG=y
CONFIG_IMX2_WDT=y
+CONFIG_IMX7ULP_WDT=y
CONFIG_MFD_DA9052_I2C=y
CONFIG_MFD_DA9062=y
CONFIG_MFD_DA9063=y
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V5 1/4] dt-bindings: watchdog: Add i.MX7ULP bindings
From: Anson Huang @ 2019-08-28 13:35 UTC (permalink / raw)
To: wim, linux, robh+dt, mark.rutland, shawnguo, s.hauer, kernel,
festevam, linux, otavio, leonard.crestez, u.kleine-koenig,
schnitzeltony, jan.tuerk, linux-watchdog, devicetree,
linux-arm-kernel, linux-kernel
Cc: Linux-imx
Add the watchdog bindings for Freescale i.MX7ULP.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Rob Herring <rohb@kernel.org>
---
Changes since V4:
- improve watchdog node name.
---
.../bindings/watchdog/fsl-imx7ulp-wdt.txt | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt
new file mode 100644
index 0000000..f902508
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt
@@ -0,0 +1,22 @@
+* Freescale i.MX7ULP Watchdog Timer (WDT) Controller
+
+Required properties:
+- compatible : Should be "fsl,imx7ulp-wdt"
+- reg : Should contain WDT registers location and length
+- interrupts : Should contain WDT interrupt
+- clocks: Should contain a phandle pointing to the gated peripheral clock.
+
+Optional properties:
+- timeout-sec : Contains the watchdog timeout in seconds
+
+Examples:
+
+wdog1: watchdog@403d0000 {
+ compatible = "fsl,imx7ulp-wdt";
+ reg = <0x403d0000 0x10000>;
+ interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pcc2 IMX7ULP_CLK_WDG1>;
+ assigned-clocks = <&pcc2 IMX7ULP_CLK_WDG1>;
+ assigned-clocks-parents = <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>;
+ timeout-sec = <40>;
+};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v1 2/2] mmc: sdhci-of-arasan: Add Support for Intel LGM eMMC
From: Ramuthevar, Vadivel MuruganX @ 2019-08-28 1:34 UTC (permalink / raw)
To: Ulf Hansson
Cc: Mark Rutland, DTML, qi-ming.wu, andriy.shevchenko, cheol.yong.kim,
linux-mmc@vger.kernel.org, Michal Simek,
Linux Kernel Mailing List, Rob Herring, Adrian Hunter, Linux ARM
In-Reply-To: <CAPDyKFrPoPqnh3_23P=wGO+QrUE9ogJzC6xgzy+0QeyuyeO=HQ@mail.gmail.com>
Hi Ulf,
On 27/8/2019 9:49 PM, Ulf Hansson wrote:
> On Mon, 26 Aug 2019 at 09:28, Ramuthevar,Vadivel MuruganX
> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>> From: Ramuthevar Vadivel Muruganx <vadivel.muruganx.ramuthevar@linux.intel.com>
>>
>> The current arasan sdhci PHY configuration isn't compatible
>> with the PHY on Intel's LGM(Lightning Mountain) SoC devices.
>>
>> Therefore, add a new compatible, to adapt the Intel's LGM
>> eMMC PHY with arasan-sdhc controller to configure the PHY.
>>
>> Signed-off-by: Ramuthevar Vadivel Muruganx <vadivel.muruganx.ramuthevar@linux.intel.com>
>
> Applied for next, thanks!
>
> Kind regards
> Uffe
>
Thank you so much for review and applied for next.
Best Regards
Vadivel
>> ---
>> drivers/mmc/host/sdhci-of-arasan.c | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
>> index b12abf9b15f2..7023cbec4017 100644
>> --- a/drivers/mmc/host/sdhci-of-arasan.c
>> +++ b/drivers/mmc/host/sdhci-of-arasan.c
>> @@ -114,6 +114,12 @@ static const struct sdhci_arasan_soc_ctl_map rk3399_soc_ctl_map = {
>> .hiword_update = true,
>> };
>>
>> +static const struct sdhci_arasan_soc_ctl_map intel_lgm_emmc_soc_ctl_map = {
>> + .baseclkfreq = { .reg = 0xa0, .width = 8, .shift = 2 },
>> + .clockmultiplier = { .reg = 0, .width = -1, .shift = -1 },
>> + .hiword_update = false,
>> +};
>> +
>> /**
>> * sdhci_arasan_syscon_write - Write to a field in soc_ctl registers
>> *
>> @@ -373,6 +379,11 @@ static struct sdhci_arasan_of_data sdhci_arasan_rk3399_data = {
>> .pdata = &sdhci_arasan_cqe_pdata,
>> };
>>
>> +static struct sdhci_arasan_of_data intel_lgm_emmc_data = {
>> + .soc_ctl_map = &intel_lgm_emmc_soc_ctl_map,
>> + .pdata = &sdhci_arasan_cqe_pdata,
>> +};
>> +
>> #ifdef CONFIG_PM_SLEEP
>> /**
>> * sdhci_arasan_suspend - Suspend method for the driver
>> @@ -474,6 +485,10 @@ static const struct of_device_id sdhci_arasan_of_match[] = {
>> .compatible = "rockchip,rk3399-sdhci-5.1",
>> .data = &sdhci_arasan_rk3399_data,
>> },
>> + {
>> + .compatible = "intel,lgm-sdhci-5.1-emmc",
>> + .data = &intel_lgm_emmc_data,
>> + },
>> /* Generic compatible below here */
>> {
>> .compatible = "arasan,sdhci-8.9a",
>> --
>> 2.11.0
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: mmc: sdhci-of-arasan: Add new compatible for Intel LGM eMMC
From: Ramuthevar, Vadivel MuruganX @ 2019-08-28 1:33 UTC (permalink / raw)
To: Ulf Hansson
Cc: Mark Rutland, DTML, qi-ming.wu, andriy.shevchenko, cheol.yong.kim,
linux-mmc@vger.kernel.org, Michal Simek,
Linux Kernel Mailing List, Rob Herring, Adrian Hunter, Linux ARM
In-Reply-To: <CAPDyKFpsvZ+LEwY91LiSExgm=4g=BhWNpkkJMniBNff+qch-QA@mail.gmail.com>
Hi Ulf,
On 27/8/2019 9:49 PM, Ulf Hansson wrote:
> On Mon, 26 Aug 2019 at 09:28, Ramuthevar,Vadivel MuruganX
> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
>>
>> Add a new compatible to use the sdhc-arasan host controller driver
>> with the eMMC PHY on Intel's Lightning Mountain SoC.
>>
>> Signed-off-by: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
> Applied for next, thanks!
>
> Kind regards
> Uffe
Thank you so much for review and applied for next.
Best Regards
Vadivel
>
>> ---
>> Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>> index 1edbb049cccb..7ca0aa7ccc0b 100644
>> --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>> +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>> @@ -17,6 +17,8 @@ Required Properties:
>> For this device it is strongly suggested to include arasan,soc-ctl-syscon.
>> - "ti,am654-sdhci-5.1", "arasan,sdhci-5.1": TI AM654 MMC PHY
>> Note: This binding has been deprecated and moved to [5].
>> + - "intel,lgm-sdhci-5.1-emmc", "arasan,sdhci-5.1": Intel LGM eMMC PHY
>> + For this device it is strongly suggested to include arasan,soc-ctl-syscon.
>>
>> [5] Documentation/devicetree/bindings/mmc/sdhci-am654.txt
>>
>> @@ -80,3 +82,18 @@ Example:
>> phy-names = "phy_arasan";
>> #clock-cells = <0>;
>> };
>> +
>> + emmc: sdhci@ec700000 {
>> + compatible = "intel,lgm-sdhci-5.1-emmc", "arasan,sdhci-5.1";
>> + reg = <0xec700000 0x300>;
>> + interrupt-parent = <&ioapic1>;
>> + interrupts = <44 1>;
>> + clocks = <&cgu0 LGM_CLK_EMMC5>, <&cgu0 LGM_CLK_NGI>,
>> + <&cgu0 LGM_GCLK_EMMC>;
>> + clock-names = "clk_xin", "clk_ahb", "gate";
>> + clock-output-names = "emmc_cardclock";
>> + #clock-cells = <0>;
>> + phys = <&emmc_phy>;
>> + phy-names = "phy_arasan";
>> + arasan,soc-ctl-syscon = <&sysconf>;
>> + };
>> --
>> 2.11.0
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH next v10 03/11] dt-bindings: usb: add binding for USB GPIO based connection detection driver
From: Chunfeng Yun @ 2019-08-28 1:28 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Heikki Krogerus, Hans de Goede,
Greg Kroah-Hartman, Linus Walleij, linux-usb, linux-kernel,
Biju Das, Badhri Jagan Sridharan, Andy Shevchenko, linux-mediatek,
Min Guo, Matthias Brugger, Nagarjuna Kristam, Adam Thomson,
linux-arm-kernel, Li Jun
In-Reply-To: <20190827183154.GA10374@bogus>
On Tue, 2019-08-27 at 13:31 -0500, Rob Herring wrote:
> On Fri, Aug 23, 2019 at 03:57:13PM +0800, Chunfeng Yun wrote:
> > It's used to support dual role switch via GPIO when use Type-B
> > receptacle, typically the USB ID pin is connected to an input
> > GPIO, and also used to enable/disable device when the USB Vbus
> > pin is connected to an input GPIO.
> >
> > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> > ---
> > v9~v10 no changes
> >
> > v8 changes:
> > 1. rename the title
> > 2. change the compatible as "linux,usb-conn-gpio" instead of
> > "linux,typeb-conn-gpio"
>
> I don't think that is an improvement. How about 'gpio-usb-b-connector'
> to be consistent.
Ok
>
> >
> > v7 changes:
> > 1. add description for device only mode
> >
> > v6 changes:
> > 1. remove status and port nodes in example
> > 2. make vbus-supply as optional property
> >
> > v5 changes:
> > 1. treat type-B connector as child device of USB controller's, but not
> > as a separate virtual device, suggested by Rob
> > 2. put connector's port node under connector node, suggested by Rob
> >
> > v4 no changes
> >
> > v3 changes:
> > 1. treat type-B connector as a virtual device, but not child device of
> > USB controller's
> >
> > v2 changes:
> > 1. new patch to make binding clear suggested by Hans
> > ---
> > .../devicetree/bindings/usb/usb-conn-gpio.txt | 31 +++++++++++++++++++
> > 1 file changed, 31 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/usb/usb-conn-gpio.txt
> >
> > diff --git a/Documentation/devicetree/bindings/usb/usb-conn-gpio.txt b/Documentation/devicetree/bindings/usb/usb-conn-gpio.txt
> > new file mode 100644
> > index 000000000000..d4d107fedc22
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/usb-conn-gpio.txt
> > @@ -0,0 +1,31 @@
> > +USB GPIO Based Connection Detection
> > +
> > +This is typically used to switch dual role mode from the USB ID pin connected
> > +to an input GPIO, and also used to enable/disable device mode from the USB
> > +Vbus pin connected to an input GPIO.
> > +
> > +Required properties:
> > +- compatible : should include "linux,usb-conn-gpio" and "usb-b-connector".
> > +- id-gpios, vbus-gpios : input gpios, either one of them must be present,
> > + and both can be present as well.
> > + see connector/usb-connector.txt
> > +
> > +Optional properties:
> > +- vbus-supply : can be present if needed when supports dual role mode.
> > + see connector/usb-connector.txt
> > +
> > +- Sub-nodes:
> > + - port : can be present.
> > + see graph.txt
> > +
> > +Example:
> > +
> > +&mtu3 {
> > + connector {
> > + compatible = "linux,usb-conn-gpio", "usb-b-connector";
> > + label = "micro-USB";
>
> 'label' is for a human identifying a particular connector when there are
> multiple (of the same type). So not a great example here.
Got it, will remove it
Thanks a lot
>
> > + type = "micro";
> > + id-gpios = <&pio 12 GPIO_ACTIVE_HIGH>;
> > + vbus-supply = <&usb_p0_vbus>;
> > + };
> > +};
> > --
> > 2.23.0
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/6] Fix TLB invalidation on arm64
From: Nicholas Piggin @ 2019-08-28 0:35 UTC (permalink / raw)
To: linux-arm-kernel, Will Deacon
Cc: linux-arch, Catalin Marinas, Mark Rutland, Peter Zijlstra,
Marc Zyngier
In-Reply-To: <20190827131818.14724-1-will@kernel.org>
Will Deacon's on August 27, 2019 11:18 pm:
> can actually raise a translation fault on the load instruction because the
> translation can be performed speculatively before the page table update and
> then marked as "faulting" by the CPU. For user PTEs, this is ok because we
> can handle the spurious fault, but for kernel PTEs and intermediate table
> entries this results in a panic().
powerpc sounds like it has the same coherency issue with stores vs loads
from the MMU's page table walker, and a barrier called ptesync to order
them.
> We can fix this by reverting 24fe1b0efad4fcdd, but the fun doesn't stop
> there. If we consider the unmap case, then a similar constraint applies to
> ordering subsequent memory accesses after the completion of the TLB
> invalidation, so we also need to add an ISB instruction to
> __flush_tlb_kernel_pgtable(). For user addresses, the exception return
> provides the necessary context synchronisation.
>
> This then raises an interesting question: if an ISB is required after a TLBI
> instruction to prevent speculative translation of subsequent instructions,
> how is this speculation prevented on concurrent CPUs that receive the
> broadcast TLB invalidation message? Sending and completing a broadcast TLB
> invalidation message does not imply execution of an ISB on the remote CPU,
> however it /does/ require that the remote CPU will no longer make use of any
> old translations because otherwise we wouldn't be able to guarantee that an
> unmapped page could no longer be modified. In this regard, receiving a TLB
> invalidation is in some ways stronger than sending one (where you need the
> ISB).
Similar with powerpc's tlbie, sender requires extra barriers!
> So far, so good, but the final piece of the puzzle isn't quite so rosy.
>
> *** Other architecture maintainers -- start here! ***
>
> In the case that one CPU maps a page and then sets a flag to tell another
> CPU:
>
> CPU 0
> -----
>
> MOV X0, <valid pte>
> STR X0, [Xptep] // Store new PTE to page table
> DSB ISHST
> ISB
> MOV X1, #1
> STR X1, [Xflag] // Set the flag
>
> CPU 1
> -----
>
> loop: LDAR X0, [Xflag] // Poll flag with Acquire semantics
> CBZ X0, loop
> LDR X1, [X2] // Translates using the new PTE
>
> then the final load on CPU 1 can raise a translation fault for the same
> reasons as mentioned at the start of this description.
powerpc's ptesync instruction is defined to order MMU memory accesses on
all other CPUs. ptesync does not go out to the fabric though. How does
it work then?
Because the MMU coherency problem (at least we have) is not that the
load will begin to "partially" execute ahead of the store, enough to
kick off a table walk that goes ahead of the store, but not so much
that it violates the regular CPU barriers. It's just that the loads
from the MMU don't participate in the LSU pipeline, they don't snoop
the store queues aren't inserted into load queues so the regular
memory barrier instructions won't see stores from other threads cuasing
ordering violations.
In your first example, if powerpc just has a normal memory barrier
there instead of a ptesync, it could all execute completely
non-speculatively and in-order but still cause a fault, because the
table walker's loads didn't see the store in the store queue.
From the other side of the fabric you have no such problem. The table
walker is cache coherent apart from the local stores, so we don't need a
special barrier on the other side. That's why ptesync doesn't broadcast.
I would be surprised if ARM's issue is different, but interested to
hear if it is.
> In reality, code
> such as:
>
> CPU 0 CPU 1
> ----- -----
> spin_lock(&lock); spin_lock(&lock);
> *ptr = vmalloc(size); if (*ptr)
> spin_unlock(&lock); foo = **ptr;
> spin_unlock(&lock);
>
> will not trigger the fault because there is an address dependency on
> CPU1 which prevents the speculative translation. However, more exotic
> code where the virtual address is known ahead of time, such as:
>
> CPU 0 CPU 1
> ----- -----
> spin_lock(&lock); spin_lock(&lock);
> set_fixmap(0, paddr, prot); if (mapped)
> mapped = true; foo = *fix_to_virt(0);
> spin_unlock(&lock); spin_unlock(&lock);
>
> could fault.
This is kind of a different issue, or part of a wider one at least.
Consider speculative execution more generally, any branch mispredict can
send us off to crazy town executing instructions using nonsense register
values. CPU0 does not have to be in the picture, or any kernel page
table modification at all, CPU1 alone will be doing speculative loads
wildly all over the kernel address space and trying to access pages with
no pte.
Yet we don't have to flush TLB when creating a new kernel mapping, and
we don't get spurious kernel faults. The page table walker won't
install negative entries, at least not "architectural" i.e., that cause
faults and require flushing. My guess is ARM is similar, or you would
have seen bigger problems by now?
If you have CPU0 doing a ro->rw upgrade on a kernel PTE, then it may
be possible another CPU1 would speculatively install a ro TLB and then
spurious fault on it when attempting to store to it. But no amount of
barriers would help because CPU1 could have picked up that TLB any time
in the past.
Thanks,
Nick
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox