* Re: [PATCH v8 4/8] perf: imx_perf: refactor driver for imx93
From: Frank Li @ 2024-03-22 14:32 UTC (permalink / raw)
To: Xu Yang
Cc: will, mark.rutland, robh+dt, krzysztof.kozlowski+dt, conor+dt,
shawnguo, s.hauer, kernel, festevam, john.g.garry, jolsa,
namhyung, irogers, mike.leach, peterz, mingo, acme,
alexander.shishkin, adrian.hunter, linux-arm-kernel, devicetree,
linux-kernel, linux-perf-users, imx
In-Reply-To: <20240322063930.749126-4-xu.yang_2@nxp.com>
On Fri, Mar 22, 2024 at 02:39:26PM +0800, Xu Yang wrote:
> This driver is initinally used to support imx93 Soc and now it's time to
> add support for imx95 Soc. However, some macro definitions and events are
> different on these two Socs. For preparing imx95 supports, this will
> refactor driver for imx93.
>
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> ---
> Changes in v4:
> - new patch
> Changes in v5:
> - use is_visible to hide unwanted attributes as suggested by Will
> Changes in v6:
> - improve imx93_ddr_perf_monitor_config()
> Changes in v7:
> - improve imx93_ddr_perf_monitor_config() as suggested by Frank
> Changes in v8:
> - adjust is_visable() as suggested by Frank
> ---
> drivers/perf/fsl_imx9_ddr_perf.c | 106 ++++++++++++++++++++-----------
> 1 file changed, 68 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/perf/fsl_imx9_ddr_perf.c b/drivers/perf/fsl_imx9_ddr_perf.c
> index b728719b494c..011377c01dea 100644
> --- a/drivers/perf/fsl_imx9_ddr_perf.c
> +++ b/drivers/perf/fsl_imx9_ddr_perf.c
> @@ -11,14 +11,14 @@
> #include <linux/perf_event.h>
>
> /* Performance monitor configuration */
> -#define PMCFG1 0x00
> -#define PMCFG1_RD_TRANS_FILT_EN BIT(31)
> -#define PMCFG1_WR_TRANS_FILT_EN BIT(30)
> -#define PMCFG1_RD_BT_FILT_EN BIT(29)
> -#define PMCFG1_ID_MASK GENMASK(17, 0)
> +#define PMCFG1 0x00
> +#define MX93_PMCFG1_RD_TRANS_FILT_EN BIT(31)
> +#define MX93_PMCFG1_WR_TRANS_FILT_EN BIT(30)
> +#define MX93_PMCFG1_RD_BT_FILT_EN BIT(29)
> +#define MX93_PMCFG1_ID_MASK GENMASK(17, 0)
>
> -#define PMCFG2 0x04
> -#define PMCFG2_ID GENMASK(17, 0)
> +#define PMCFG2 0x04
> +#define MX93_PMCFG2_ID GENMASK(17, 0)
>
> /* Global control register affects all counters and takes priority over local control registers */
> #define PMGC0 0x40
> @@ -76,6 +76,11 @@ static const struct imx_ddr_devtype_data imx93_devtype_data = {
> .identifier = "imx93",
> };
>
> +static inline bool is_imx93(struct ddr_pmu *pmu)
> +{
> + return pmu->devtype_data == &imx93_devtype_data;
> +}
> +
> static const struct of_device_id imx_ddr_pmu_dt_ids[] = {
> {.compatible = "fsl,imx93-ddr-pmu", .data = &imx93_devtype_data},
> { /* sentinel */ }
> @@ -123,23 +128,36 @@ static const struct attribute_group ddr_perf_cpumask_attr_group = {
> .attrs = ddr_perf_cpumask_attrs,
> };
>
> +struct imx9_pmu_events_attr {
> + struct device_attribute attr;
> + u64 id;
> + const void *devtype_data;
> +};
> +
> static ssize_t ddr_pmu_event_show(struct device *dev,
> struct device_attribute *attr, char *page)
> {
> - struct perf_pmu_events_attr *pmu_attr;
> + struct imx9_pmu_events_attr *pmu_attr;
>
> - pmu_attr = container_of(attr, struct perf_pmu_events_attr, attr);
> + pmu_attr = container_of(attr, struct imx9_pmu_events_attr, attr);
> return sysfs_emit(page, "event=0x%02llx\n", pmu_attr->id);
> }
>
> #define ID(counter, id) ((counter << CONFIG_COUNTER_OFFSET) | id)
>
> -#define IMX9_DDR_PMU_EVENT_ATTR(_name, _id) \
> - (&((struct perf_pmu_events_attr[]) { \
> +#define DDR_PMU_EVENT_ATTR_COMM(_name, _id, _data) \
> + (&((struct imx9_pmu_events_attr[]) { \
> { .attr = __ATTR(_name, 0444, ddr_pmu_event_show, NULL),\
> - .id = _id, } \
> + .id = _id, \
> + .devtype_data = _data, } \
> })[0].attr.attr)
>
> +#define IMX9_DDR_PMU_EVENT_ATTR(_name, _id) \
> + DDR_PMU_EVENT_ATTR_COMM(_name, _id, NULL)
> +
> +#define IMX93_DDR_PMU_EVENT_ATTR(_name, _id) \
> + DDR_PMU_EVENT_ATTR_COMM(_name, _id, &imx93_devtype_data)
> +
> static struct attribute *ddr_perf_events_attrs[] = {
> /* counter0 cycles event */
> IMX9_DDR_PMU_EVENT_ATTR(cycles, 0),
> @@ -185,7 +203,7 @@ static struct attribute *ddr_perf_events_attrs[] = {
> IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_6, ID(2, 70)),
> IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_7, ID(2, 71)),
> IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_empty, ID(2, 72)),
> - IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_trans_filt, ID(2, 73)),
> + IMX93_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_trans_filt, ID(2, 73)), /* imx93 specific*/
>
> /* counter3 specific events */
> IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_0, ID(3, 64)),
> @@ -197,7 +215,7 @@ static struct attribute *ddr_perf_events_attrs[] = {
> IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_6, ID(3, 70)),
> IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_7, ID(3, 71)),
> IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_full, ID(3, 72)),
> - IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_wr_trans_filt, ID(3, 73)),
> + IMX93_DDR_PMU_EVENT_ATTR(eddrtq_pm_wr_trans_filt, ID(3, 73)), /* imx93 specific*/
>
> /* counter4 specific events */
> IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_0, ID(4, 64)),
> @@ -209,7 +227,7 @@ static struct attribute *ddr_perf_events_attrs[] = {
> IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_6, ID(4, 70)),
> IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_7, ID(4, 71)),
> IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_ld_rdq2_rmw, ID(4, 72)),
> - IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_beat_filt, ID(4, 73)),
> + IMX93_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_beat_filt, ID(4, 73)), /* imx93 specific*/
>
> /* counter5 specific events */
> IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_start_0, ID(5, 64)),
> @@ -244,9 +262,29 @@ static struct attribute *ddr_perf_events_attrs[] = {
> NULL,
> };
>
> +static umode_t
> +ddr_perf_events_attrs_is_visible(struct kobject *kobj,
> + struct attribute *attr, int unused)
> +{
> + struct pmu *pmu = dev_get_drvdata(kobj_to_dev(kobj));
> + struct ddr_pmu *ddr_pmu = to_ddr_pmu(pmu);
> + struct imx9_pmu_events_attr *eattr;
> +
> + eattr = container_of(attr, typeof(*eattr), attr.attr);
> +
> + if (!eattr->devtype_data)
> + return attr->mode;
> +
> + if (eattr->devtype_data != ddr_pmu->devtype_data)
> + return 0;
> +
> + return attr->mode;
> +}
> +
> static const struct attribute_group ddr_perf_events_attr_group = {
> .name = "events",
> .attrs = ddr_perf_events_attrs,
> + .is_visible = ddr_perf_events_attrs_is_visible,
> };
>
> PMU_FORMAT_ATTR(event, "config:0-15");
> @@ -368,36 +406,28 @@ static void ddr_perf_counter_local_config(struct ddr_pmu *pmu, int config,
> }
> }
>
> -static void ddr_perf_monitor_config(struct ddr_pmu *pmu, int event,
> - int counter, int axi_id, int axi_mask)
> +static void imx93_ddr_perf_monitor_config(struct ddr_pmu *pmu, int event,
> + int counter, int axi_id, int axi_mask)
> {
> u32 pmcfg1, pmcfg2;
> + u32 mask[] = { MX93_PMCFG1_RD_TRANS_FILT_EN,
> + MX93_PMCFG1_WR_TRANS_FILT_EN,
> + MX93_PMCFG1_RD_BT_FILT_EN };
>
> pmcfg1 = readl_relaxed(pmu->base + PMCFG1);
>
> - if (counter == 2 && event == 73)
> - pmcfg1 |= PMCFG1_RD_TRANS_FILT_EN;
> - else if (counter == 2 && event != 73)
> - pmcfg1 &= ~PMCFG1_RD_TRANS_FILT_EN;
> -
> - if (counter == 3 && event == 73)
> - pmcfg1 |= PMCFG1_WR_TRANS_FILT_EN;
> - else if (counter == 3 && event != 73)
> - pmcfg1 &= ~PMCFG1_WR_TRANS_FILT_EN;
> -
> - if (counter == 4 && event == 73)
> - pmcfg1 |= PMCFG1_RD_BT_FILT_EN;
> - else if (counter == 4 && event != 73)
> - pmcfg1 &= ~PMCFG1_RD_BT_FILT_EN;
> + if (counter >= 2 && counter <= 4)
> + pmcfg1 = event == 73 ? pmcfg1 | mask[counter - 2] :
> + pmcfg1 & ~mask[counter - 2];
>
> - pmcfg1 &= ~FIELD_PREP(PMCFG1_ID_MASK, 0x3FFFF);
> - pmcfg1 |= FIELD_PREP(PMCFG1_ID_MASK, axi_mask);
> - writel(pmcfg1, pmu->base + PMCFG1);
> + pmcfg1 &= ~FIELD_PREP(MX93_PMCFG1_ID_MASK, 0x3FFFF);
> + pmcfg1 |= FIELD_PREP(MX93_PMCFG1_ID_MASK, axi_mask);
> + writel_relaxed(pmcfg1, pmu->base + PMCFG1);
>
> pmcfg2 = readl_relaxed(pmu->base + PMCFG2);
> - pmcfg2 &= ~FIELD_PREP(PMCFG2_ID, 0x3FFFF);
> - pmcfg2 |= FIELD_PREP(PMCFG2_ID, axi_id);
> - writel(pmcfg2, pmu->base + PMCFG2);
> + pmcfg2 &= ~FIELD_PREP(MX93_PMCFG2_ID, 0x3FFFF);
> + pmcfg2 |= FIELD_PREP(MX93_PMCFG2_ID, axi_id);
> + writel_relaxed(pmcfg2, pmu->base + PMCFG2);
> }
>
> static void ddr_perf_event_update(struct perf_event *event)
> @@ -513,7 +543,7 @@ static int ddr_perf_event_add(struct perf_event *event, int flags)
> ddr_perf_event_start(event, flags);
>
> /* read trans, write trans, read beat */
> - ddr_perf_monitor_config(pmu, event_id, counter, cfg1, cfg2);
> + imx93_ddr_perf_monitor_config(pmu, event_id, counter, cfg1, cfg2);
>
> return 0;
> }
> --
> 2.34.1
>
_______________________________________________
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 v8 5/8] perf: imx_perf: fix counter start and config sequence
From: Frank Li @ 2024-03-22 14:32 UTC (permalink / raw)
To: Xu Yang
Cc: will, mark.rutland, robh+dt, krzysztof.kozlowski+dt, conor+dt,
shawnguo, s.hauer, kernel, festevam, john.g.garry, jolsa,
namhyung, irogers, mike.leach, peterz, mingo, acme,
alexander.shishkin, adrian.hunter, linux-arm-kernel, devicetree,
linux-kernel, linux-perf-users, imx
In-Reply-To: <20240322063930.749126-5-xu.yang_2@nxp.com>
On Fri, Mar 22, 2024 at 02:39:27PM +0800, Xu Yang wrote:
> In current driver, the counter will start firstly and then be configured.
> This sequence is not correct for AXI filter events since the correct
> AXI_MASK and AXI_ID are not set yet. Then the results may be inaccurate.
>
> Fixes: 55691f99d417 ("drivers/perf: imx_ddr: Add support for NXP i.MX9 SoC DDRC PMU driver")
> cc: <stable@vger.kernel.org>
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> ---
> Changes in v5:
> - new patch
> Changes in v6:
> - no changes
> Changes in v7:
> - no changes
> Changes in v8:
> - add fix tag
> ---
> drivers/perf/fsl_imx9_ddr_perf.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/perf/fsl_imx9_ddr_perf.c b/drivers/perf/fsl_imx9_ddr_perf.c
> index 011377c01dea..fab6596d3e28 100644
> --- a/drivers/perf/fsl_imx9_ddr_perf.c
> +++ b/drivers/perf/fsl_imx9_ddr_perf.c
> @@ -539,12 +539,12 @@ static int ddr_perf_event_add(struct perf_event *event, int flags)
> hwc->idx = counter;
> hwc->state |= PERF_HES_STOPPED;
>
> - if (flags & PERF_EF_START)
> - ddr_perf_event_start(event, flags);
> -
> /* read trans, write trans, read beat */
> imx93_ddr_perf_monitor_config(pmu, event_id, counter, cfg1, cfg2);
>
> + if (flags & PERF_EF_START)
> + ddr_perf_event_start(event, flags);
> +
> return 0;
> }
>
> --
> 2.34.1
>
_______________________________________________
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 v8 6/8] perf: imx_perf: add support for i.MX95 platform
From: Frank Li @ 2024-03-22 14:34 UTC (permalink / raw)
To: Xu Yang
Cc: will, mark.rutland, robh+dt, krzysztof.kozlowski+dt, conor+dt,
shawnguo, s.hauer, kernel, festevam, john.g.garry, jolsa,
namhyung, irogers, mike.leach, peterz, mingo, acme,
alexander.shishkin, adrian.hunter, linux-arm-kernel, devicetree,
linux-kernel, linux-perf-users, imx
In-Reply-To: <20240322063930.749126-6-xu.yang_2@nxp.com>
On Fri, Mar 22, 2024 at 02:39:28PM +0800, Xu Yang wrote:
> i.MX95 has a DDR PMU which is almostly same as i.MX93, it now supports
> read beat and write beat filter capabilities. This will add support for
> i.MX95 and enhance the driver to support specific filter handling for it.
>
> Usage:
>
> For read beat:
> ~# perf stat -a -I 1000 -e imx9_ddr0/eddrtq_pm_rd_beat_filt2,axi_mask=ID_MASK,axi_id=ID/
> ~# perf stat -a -I 1000 -e imx9_ddr0/eddrtq_pm_rd_beat_filt1,axi_mask=ID_MASK,axi_id=ID/
> ~# perf stat -a -I 1000 -e imx9_ddr0/eddrtq_pm_rd_beat_filt0,axi_mask=ID_MASK,axi_id=ID/
> eg: For edma2: perf stat -a -I 1000 -e imx9_ddr0/eddrtq_pm_rd_beat_filt0,axi_mask=0x00f,axi_id=0x00c/
>
> For write beat:
> ~# perf stat -a -I 1000 -e imx9_ddr0/eddrtq_pm_wr_beat_filt,axi_mask=ID_MASK,axi_id=ID/
> eg: For edma2: perf stat -a -I 1000 -e imx9_ddr0/eddrtq_pm_wr_beat_filt,axi_mask=0x00f,axi_id=0x00c/
>
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> ---
> Changes in v2:
> - put soc spefific axi filter events to drvdata according
> to franks suggestions.
> - adjust pmcfg axi_id and axi_mask config
> Changes in v3:
> - no changes
> Changes in v4:
> - only contain imx95 parts
> Changes in v5:
> - improve imx95_ddr_perf_monitor_config()
> - use write_relaxed to pair read_relaxed
> Changes in v6:
> - no changes
> Changes in v7:
> - no changes
> Changes in v8:
> - add definition IMX95_DDR_PMU_EVENT_ATTR
> ---
> drivers/perf/fsl_imx9_ddr_perf.c | 89 ++++++++++++++++++++++++++++++--
> 1 file changed, 86 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/perf/fsl_imx9_ddr_perf.c b/drivers/perf/fsl_imx9_ddr_perf.c
> index fab6596d3e28..9dcab4192d6e 100644
> --- a/drivers/perf/fsl_imx9_ddr_perf.c
> +++ b/drivers/perf/fsl_imx9_ddr_perf.c
> @@ -17,9 +17,19 @@
> #define MX93_PMCFG1_RD_BT_FILT_EN BIT(29)
> #define MX93_PMCFG1_ID_MASK GENMASK(17, 0)
>
> +#define MX95_PMCFG1_WR_BEAT_FILT_EN BIT(31)
> +#define MX95_PMCFG1_RD_BEAT_FILT_EN BIT(30)
> +
> #define PMCFG2 0x04
> #define MX93_PMCFG2_ID GENMASK(17, 0)
>
> +#define PMCFG3 0x08
> +#define PMCFG4 0x0C
> +#define PMCFG5 0x10
> +#define PMCFG6 0x14
> +#define MX95_PMCFG_ID_MASK GENMASK(9, 0)
> +#define MX95_PMCFG_ID GENMASK(25, 16)
> +
> /* Global control register affects all counters and takes priority over local control registers */
> #define PMGC0 0x40
> /* Global control register bits */
> @@ -76,13 +86,23 @@ static const struct imx_ddr_devtype_data imx93_devtype_data = {
> .identifier = "imx93",
> };
>
> +static const struct imx_ddr_devtype_data imx95_devtype_data = {
> + .identifier = "imx95",
> +};
> +
> static inline bool is_imx93(struct ddr_pmu *pmu)
> {
> return pmu->devtype_data == &imx93_devtype_data;
> }
>
> +static inline bool is_imx95(struct ddr_pmu *pmu)
> +{
> + return pmu->devtype_data == &imx95_devtype_data;
> +}
> +
> static const struct of_device_id imx_ddr_pmu_dt_ids[] = {
> - {.compatible = "fsl,imx93-ddr-pmu", .data = &imx93_devtype_data},
> + { .compatible = "fsl,imx93-ddr-pmu", .data = &imx93_devtype_data },
> + { .compatible = "fsl,imx95-ddr-pmu", .data = &imx95_devtype_data },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, imx_ddr_pmu_dt_ids);
> @@ -158,6 +178,9 @@ static ssize_t ddr_pmu_event_show(struct device *dev,
> #define IMX93_DDR_PMU_EVENT_ATTR(_name, _id) \
> DDR_PMU_EVENT_ATTR_COMM(_name, _id, &imx93_devtype_data)
>
> +#define IMX95_DDR_PMU_EVENT_ATTR(_name, _id) \
> + DDR_PMU_EVENT_ATTR_COMM(_name, _id, &imx95_devtype_data)
> +
> static struct attribute *ddr_perf_events_attrs[] = {
> /* counter0 cycles event */
> IMX9_DDR_PMU_EVENT_ATTR(cycles, 0),
> @@ -204,6 +227,7 @@ static struct attribute *ddr_perf_events_attrs[] = {
> IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_7, ID(2, 71)),
> IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_empty, ID(2, 72)),
> IMX93_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_trans_filt, ID(2, 73)), /* imx93 specific*/
> + IMX95_DDR_PMU_EVENT_ATTR(eddrtq_pm_wr_beat_filt, ID(2, 73)), /* imx95 specific*/
>
> /* counter3 specific events */
> IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_0, ID(3, 64)),
> @@ -216,6 +240,7 @@ static struct attribute *ddr_perf_events_attrs[] = {
> IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_7, ID(3, 71)),
> IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_full, ID(3, 72)),
> IMX93_DDR_PMU_EVENT_ATTR(eddrtq_pm_wr_trans_filt, ID(3, 73)), /* imx93 specific*/
> + IMX95_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_beat_filt2, ID(3, 73)), /* imx95 specific*/
>
> /* counter4 specific events */
> IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_0, ID(4, 64)),
> @@ -228,6 +253,7 @@ static struct attribute *ddr_perf_events_attrs[] = {
> IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_7, ID(4, 71)),
> IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_ld_rdq2_rmw, ID(4, 72)),
> IMX93_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_beat_filt, ID(4, 73)), /* imx93 specific*/
> + IMX95_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_beat_filt1, ID(4, 73)), /* imx95 specific*/
>
> /* counter5 specific events */
> IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_start_0, ID(5, 64)),
> @@ -239,6 +265,7 @@ static struct attribute *ddr_perf_events_attrs[] = {
> IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_start_6, ID(5, 70)),
> IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_start_7, ID(5, 71)),
> IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_ld_rdq1, ID(5, 72)),
> + IMX95_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_beat_filt0, ID(5, 73)), /* imx95 specific*/
>
> /* counter6 specific events */
> IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_end_0, ID(6, 64)),
> @@ -430,6 +457,57 @@ static void imx93_ddr_perf_monitor_config(struct ddr_pmu *pmu, int event,
> writel_relaxed(pmcfg2, pmu->base + PMCFG2);
> }
>
> +static void imx95_ddr_perf_monitor_config(struct ddr_pmu *pmu, int event,
> + int counter, int axi_id, int axi_mask)
> +{
> + u32 pmcfg1, pmcfg, offset = 0;
> +
> + pmcfg1 = readl_relaxed(pmu->base + PMCFG1);
> +
> + if (event == 73) {
> + switch (counter) {
> + case 2:
> + pmcfg1 |= MX95_PMCFG1_WR_BEAT_FILT_EN;
> + offset = PMCFG3;
> + break;
> + case 3:
> + pmcfg1 |= MX95_PMCFG1_RD_BEAT_FILT_EN;
> + offset = PMCFG4;
> + break;
> + case 4:
> + pmcfg1 |= MX95_PMCFG1_RD_BEAT_FILT_EN;
> + offset = PMCFG5;
> + break;
> + case 5:
> + pmcfg1 |= MX95_PMCFG1_RD_BEAT_FILT_EN;
> + offset = PMCFG6;
> + break;
> + }
> + } else {
> + switch (counter) {
> + case 2:
> + pmcfg1 &= ~MX95_PMCFG1_WR_BEAT_FILT_EN;
> + break;
> + case 3:
> + case 4:
> + case 5:
> + pmcfg1 &= ~MX95_PMCFG1_RD_BEAT_FILT_EN;
> + break;
> + }
> + }
> +
> + writel_relaxed(pmcfg1, pmu->base + PMCFG1);
> +
> + if (offset) {
> + pmcfg = readl_relaxed(pmu->base + offset);
> + pmcfg &= ~(FIELD_PREP(MX95_PMCFG_ID_MASK, 0x3FF) |
> + FIELD_PREP(MX95_PMCFG_ID, 0x3FF));
> + pmcfg |= (FIELD_PREP(MX95_PMCFG_ID_MASK, axi_mask) |
> + FIELD_PREP(MX95_PMCFG_ID, axi_id));
> + writel_relaxed(pmcfg, pmu->base + offset);
> + }
> +}
> +
> static void ddr_perf_event_update(struct perf_event *event)
> {
> struct ddr_pmu *pmu = to_ddr_pmu(event->pmu);
> @@ -539,8 +617,13 @@ static int ddr_perf_event_add(struct perf_event *event, int flags)
> hwc->idx = counter;
> hwc->state |= PERF_HES_STOPPED;
>
> - /* read trans, write trans, read beat */
> - imx93_ddr_perf_monitor_config(pmu, event_id, counter, cfg1, cfg2);
> + if (is_imx93(pmu))
> + /* read trans, write trans, read beat */
> + imx93_ddr_perf_monitor_config(pmu, event_id, counter, cfg1, cfg2);
> +
> + if (is_imx95(pmu))
> + /* write beat, read beat2, read beat1, read beat */
> + imx95_ddr_perf_monitor_config(pmu, event_id, counter, cfg1, cfg2);
>
> if (flags & PERF_EF_START)
> ddr_perf_event_start(event, flags);
> --
> 2.34.1
>
_______________________________________________
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] KVM: arm64: Add KVM_CAP to control WFx trapping
From: Quentin Perret @ 2024-03-22 14:34 UTC (permalink / raw)
To: Colton Lewis
Cc: kvm, Marc Zyngier, Oliver Upton, James Morse, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Paolo Bonzini,
Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Daniel Bristot de Oliveira, Valentin Schneider, linux-arm-kernel,
kvmarm, linux-kernel
In-Reply-To: <Zf2Uo1l0JgBEKRAL@google.com>
On Friday 22 Mar 2024 at 14:24:35 (+0000), Quentin Perret wrote:
> On Tuesday 19 Mar 2024 at 16:43:41 (+0000), Colton Lewis wrote:
> > Add a KVM_CAP to control WFx (WFI or WFE) trapping based on scheduler
> > runqueue depth. This is so they can be passed through if the runqueue
> > is shallow or the CPU has support for direct interrupt injection. They
> > may be always trapped by setting this value to 0. Technically this
> > means traps will be cleared when the runqueue depth is 0, but that
> > implies nothing is running anyway so there is no reason to care. The
> > default value is 1 to preserve previous behavior before adding this
> > option.
>
> I recently discovered that this was enabled by default, but it's not
> obvious to me everyone will want this enabled, so I'm in favour of
> figuring out a way to turn it off (in fact we might want to make this
> feature opt in as the status quo used to be to always trap).
>
> There are a few potential issues I see with having this enabled:
>
> - a lone vcpu thread on a CPU will completely screw up the host
> scheduler's load tracking metrics if the vCPU actually spends a
> significant amount of time in WFI (the PELT signal will no longer
> be a good proxy for "how much CPU time does this task need");
>
> - the scheduler's decision will impact massively the behaviour of the
> vcpu task itself. Co-scheduling a task with a vcpu task (or not) will
> impact massively the perceived behaviour of the vcpu task in a way
> that is entirely unpredictable to the scheduler;
>
> - while the above problems might be OK for some users, I don't think
> this will always be true, e.g. when running on big.LITTLE systems the
> above sounds nightmare-ish;
>
> - the guest spending long periods of time in WFI prevents the host from
> being able to enter deeper idle states, which will impact power very
> negatively;
>
> And probably a whole bunch of other things.
>
> > Think about his option as a threshold. The instruction will be trapped
> > if the runqueue depth is higher than the threshold.
>
> So talking about the exact interface, I'm not sure exposing this to
> userspace is really appropriate. The current rq depth is next to
> impossible for userspace to control well.
>
> My gut feeling tells me we might want to gate all of this on
> PREEMPT_FULL instead, since PREEMPT_FULL is pretty much a way to say
> "I'm willing to give up scheduler tracking accuracy to gain throughput
> when I've got a task running alone on a CPU". Thoughts?
And obviously I meant s/PREEMPT_FULL/NOHZ_FULL, but hopefully that was
clear :-)
_______________________________________________
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] pinctrl: armada-37xx: remove an unused variable
From: Andrew Lunn @ 2024-03-22 14:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Gregory Clement, Sebastian Hesselbarth, Linus Walleij,
Arnd Bergmann, linux-arm-kernel, linux-gpio, linux-kernel
In-Reply-To: <20240322132205.906729-1-arnd@kernel.org>
On Fri, Mar 22, 2024 at 02:21:43PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> This variable has never been used and can be removed to avoid a W=1 warning:
>
> drivers/pinctrl/mvebu/pinctrl-armada-37xx.c:837:6: error: variable 'i' set but not used [-Werror,-Wunused-but-set-variable]
> 837 | int i = 0;
>
> Fixes: 87466ccd9401 ("pinctrl: armada-37xx: Add pin controller support for Armada 37xx")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
_______________________________________________
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] media: mediatek: vcodec: Handle invalid decoder vsi
From: Nicolas Dufresne @ 2024-03-22 14:44 UTC (permalink / raw)
To: Irui Wang, Hans Verkuil, Mauro Carvalho Chehab, Matthias Brugger,
Yunfei Dong, angelogioacchino.delregno, sebastian.fricke
Cc: Longfei Wang, Maoguang Meng, Project_Global_Chrome_Upstream_Group,
linux-media, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20240320061336.2615-1-irui.wang@mediatek.com>
Hi,
Le mercredi 20 mars 2024 à 14:13 +0800, Irui Wang a écrit :
> Handle invalid decoder vsi in vpu_dec_init to ensure the decoder vsi is
> valid for future use.
>
> Signed-off-by: Irui Wang <irui.wang@mediatek.com>
> ---
> .../media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
> index 82e57ae983d5..17770993fe5a 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
> @@ -231,6 +231,12 @@ int vpu_dec_init(struct vdec_vpu_inst *vpu)
> mtk_vdec_debug(vpu->ctx, "vdec_inst=%p", vpu);
>
> err = vcodec_vpu_send_msg(vpu, (void *)&msg, sizeof(msg));
> +
> + if (IS_ERR_OR_NULL(vpu->vsi)) {
> + mtk_vdec_err(vpu->ctx, "invalid vdec vsi, status=%d", err);
> + return -EINVAL;
> + }
> +
Make sense, though on the cosmetic side, were is the err value from if the vsi
pointer is NULL ?
Nicolas
> mtk_vdec_debug(vpu->ctx, "- ret=%d", err);
> return err;
> }
_______________________________________________
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 v3 4/4] arm64: dts: S32G3: Introduce device tree for S32G-VNP-RDB3
From: Ghennadi Procopciuc @ 2024-03-22 14:52 UTC (permalink / raw)
To: Wadim Mueller
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Greg Kroah-Hartman, Jiri Slaby, Chester Lin,
Andreas Färber, Matthias Brugger, NXP S32 Linux Team,
Tim Harvey, Alexander Stein, Gregor Herburger, Marek Vasut,
Hugo Villeneuve, Marco Felsch, Markus Niebel, Matthias Schiffer,
Stefan Wahren, Bjorn Helgaas, Philippe Schenker, Li Yang,
devicetree, linux-kernel, linux-mmc, linux-arm-kernel,
linux-serial
In-Reply-To: <20240321154108.146223-5-wafgo01@gmail.com>
On 3/21/24 17:41, Wadim Mueller wrote:
> +++ b/arch/arm64/boot/dts/freescale/s32g3.dtsi
> @@ -0,0 +1,237 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
Please use the dual license model (GPL-2.0+ OR BSD-3-Clause) for device
tree files, as the TF-A version of these files [0] already uses this
license. Using a consistent license is needed to keep files in sync
between upstream versions of Linux and TF-A for S32G in the future.
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
This paragraph is already implied by the SPDX tag.
> + *
> + */> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +/ {
Missing empty line here between header include and '{'?
[0]
https://github.com/nxp-auto-linux/arm-trusted-firmware/blob/release/bsp39.0-2.5/fdts/s32g3.dtsi#L1
Regards,
Ghennadi
_______________________________________________
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/4] media: dt-binding: media: Document rk3588’s vepu121
From: Nicolas Dufresne @ 2024-03-22 14:57 UTC (permalink / raw)
To: Heiko Stübner, Emmanuel Gil Peyrot, linux-kernel,
Krzysztof Kozlowski
Cc: Ezequiel Garcia, Philipp Zabel, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joerg Roedel,
Will Deacon, Robin Murphy, Sebastian Reichel, Cristian Ciocaltea,
Dragan Simic, Shreeya Patel, Chris Morgan, Andy Yan,
Nicolas Frattaroli, linux-media, linux-rockchip, devicetree,
linux-arm-kernel, iommu
In-Reply-To: <2798331.BEx9A2HvPv@diego>
Le jeudi 21 mars 2024 à 10:32 +0100, Heiko Stübner a écrit :
> Am Donnerstag, 21. März 2024, 10:19:54 CET schrieb Krzysztof Kozlowski:
> > On 21/03/2024 09:47, Heiko Stübner wrote:
> > > > > enum:
> > > > > - rockchip,rk3568-vepu
> > > > > + - rockchip,rk3588-vepu121
> > > >
> > > > What is 121?
> > >
> > > That is the strange naming of the ip block inside the soc.
> > >
> > > I.e. the rk3588 TRM lists a number of different video encoders and decoders:
> > > - VDPU121 is decoding h.263 and mpeg1,2,4
> > > - VDPU381 is decoding h.265, h.264 and some more
> > > - VDPU720 is decoding jpeg
> > > - VDPU981 decodes AV1
> > > - VEPU121 is the jpeg encoder above
> > > - VEPU580 encodes h.264 and h.265
> > >
> > > Each of those are separate IP blocks with their own io-memory, their own
> > > interrupts and their own iommus, etc.
> >
> > Thanks for explanation. Short introduction in commit msg would be nice
> > (e.g. VEPU121, one of two VEPU encoders). OTOH, why not documenting all
> > of them? Bindings are supposed to be as complete as possible.
>
> We have a concurrent series for the vdpu121 running at
> https://lore.kernel.org/all/20240316071100.2419369-1-liujianfeng1994@gmail.com
>
> I think not all of those encoders/decoders are based on the Hantro IP
> or at least at the moment we don't know this yet.
> Hence people adding compatibles for the blocks they have actually
> managed to run on their hardware.
Correct, on top of this legacy core, only VDPU981 (AV1 decode) is a chip from
Hantro / Verisilicon. Everything else looks like their own design and derived
from their original rkvdec codec pack. We didn't name this AV1 decoder after VSI
brand as we didn't have the proper version information available, but we suspect
that is variant of their VSI9000D cores. In short, we tried to avoid documenting
our speculation, even if we believe we are right.
>
> Bindings are supposed to be as complete as possible, but revising a wrong
> binding later is very hard. And the whole media part is full of binary libraries
> in the vendor kernel and has not the best documentation.
I agree with this, but I must give to RK that despite the lack of documentation,
their CODEC software is fully open-source and blob free on this platform.
>
> So I guess people are just cautious ;-)
>
exactly!
Nicolas
_______________________________________________
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 v3 3/4] dt-bindings: mmc: fsl-imx-esdhc: add NXP S32G3 support
From: Krzysztof Kozlowski @ 2024-03-22 15:02 UTC (permalink / raw)
To: Wadim Mueller
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Greg Kroah-Hartman, Jiri Slaby, Chester Lin,
Andreas Färber, Matthias Brugger, NXP S32 Linux Team,
Tim Harvey, Marco Felsch, Gregor Herburger, Marek Vasut,
Joao Paulo Goncalves, Markus Niebel, Matthias Schiffer,
Stefan Wahren, Bjorn Helgaas, Philippe Schenker, Yannic Moog,
Li Yang, devicetree, linux-kernel, linux-mmc, linux-arm-kernel,
linux-serial
In-Reply-To: <20240322094526.GA7097@bhlegrsu.conti.de>
On 22/03/2024 10:45, Wadim Mueller wrote:
> On Thu, Mar 21, 2024 at 06:53:34PM +0100, Krzysztof Kozlowski wrote:
>> On 21/03/2024 16:41, Wadim Mueller wrote:
>>> Add a compatible string for the SDHC binding of NXP S32G3 platforms. Here
>>> we use "nxp,s32g2-usdhc" as fallback since the s32g2-usdhc
>>> driver works also on S32G3 platforms.
>>>
>>> Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
>>> ---
>>> Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
>>> index 82eb7a24c857..b42b4368fa4e 100644
>>> --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
>>> +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
>>> @@ -35,6 +35,7 @@ properties:
>>> - fsl,imx8mm-usdhc
>>> - fsl,imxrt1050-usdhc
>>> - nxp,s32g2-usdhc
>>> + - nxp,s32g3-usdhc
>>> - items:
>>> - const: fsl,imx50-esdhc
>>> - const: fsl,imx53-esdhc
>>> @@ -90,6 +91,9 @@ properties:
>>> - enum:
>>> - fsl,imxrt1170-usdhc
>>> - const: fsl,imxrt1050-usdhc
>>> + - items:
>>> + - const: nxp,s32g3-usdhc
>>> + - const: nxp,s32g2-usdhc
>>
>> No, that's just wrong. G3 is not and is compatible with G2? There is no
>> dualism here. Either it is or it is not. Not both.
>>
>
> I am trying to understand your statement but I am not sure whether I get
> it right.
>
> Let me try to explain what I understand is wrong with this patch.
>
> Having nxp,s32g2-usdhc and nxp,s32g2-usdhc in one enum
>
>>> - nxp,s32g2-usdhc
>>> + - nxp,s32g3-usdhc
>
> would mean that those are
> __not__ compatible with each other, whereas the anouther item
>
>>> + - items:
>>> + - const: nxp,s32g3-usdhc
>>> + - const: nxp,s32g2-usdhc
>>
>
> where both const entries are side by side means that those are compatible. Which is
> paradox. Is this undersanding correct?
Yes, you placed the same compatible in two separate places. It has two
separate meanings.
>
> So if I want to have the follwing im my DTS for the mmc node
>
> usdhc0: mmc@402f0000 {
> compatible = "nxp,s32g3-usdhc",
> "nxp,s32g2-usdhc";
> ...
> }
>
> The schema update should contain just this part?
>
> i@@ -90,6 +90,9 @@ properties:
> - enum:
> - fsl,imxrt1170-usdhc
> - const: fsl,imxrt1050-usdhc
> + - items:
> + - const: nxp,s32g3-usdhc
> + - const: nxp,s32g2-usdhc
>
> reg:
> maxItems: 1
>
>
> Is this correct?
Yes.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: timer: renesas: ostm: Document Renesas RZ/V2H(P) SoC
From: Prabhakar @ 2024-03-22 15:12 UTC (permalink / raw)
To: Geert Uytterhoeven, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chris Brandt, Magnus Damm
Cc: linux-kernel, devicetree, linux-arm-kernel, linux-renesas-soc,
Prabhakar, Fabrizio Castro, Lad Prabhakar, Conor Dooley
In-Reply-To: <20240322151219.885832-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Document the General Timer Module (a.k.a OSTM) block on Renesas RZ/V2H(P)
("R9A09G057") SoC, which is identical to the one found on the RZ/A1H and
RZ/G2L SoCs. Add the "renesas,r9a09g057-ostm" compatible string for the
RZ/V2H(P) SoC.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
v1->v2
- Included Ack and RB tags
---
Documentation/devicetree/bindings/timer/renesas,ostm.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/timer/renesas,ostm.yaml b/Documentation/devicetree/bindings/timer/renesas,ostm.yaml
index 8b06a681764e..e8c642166462 100644
--- a/Documentation/devicetree/bindings/timer/renesas,ostm.yaml
+++ b/Documentation/devicetree/bindings/timer/renesas,ostm.yaml
@@ -26,6 +26,7 @@ properties:
- renesas,r9a07g043-ostm # RZ/G2UL and RZ/Five
- renesas,r9a07g044-ostm # RZ/G2{L,LC}
- renesas,r9a07g054-ostm # RZ/V2L
+ - renesas,r9a09g057-ostm # RZ/V2H(P)
- const: renesas,ostm # Generic
reg:
@@ -58,6 +59,7 @@ if:
- renesas,r9a07g043-ostm
- renesas,r9a07g044-ostm
- renesas,r9a07g054-ostm
+ - renesas,r9a09g057-ostm
then:
required:
- resets
--
2.34.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 v2 0/2] Add OSTM support for Renesas RZ/V2H(P) SoC
From: Prabhakar @ 2024-03-22 15:12 UTC (permalink / raw)
To: Geert Uytterhoeven, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chris Brandt, Magnus Damm
Cc: linux-kernel, devicetree, linux-arm-kernel, linux-renesas-soc,
Prabhakar, Fabrizio Castro, Lad Prabhakar
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi,
This patch series aims to add OSTM support for Renesas RZ/V2H(P) SoC.
RZ/V2H(P) SoC has 8 GTM channels.
v1->v2
- Inlcuded Ack/RB tag
- Updated commit description for patch 2/2
v1: https://patchwork.kernel.org/project/linux-renesas-soc/cover/20240318160731.33960-1-prabhakar.mahadev-lad.rj@bp.renesas.com/
Cheers,
Prabhakar
Lad Prabhakar (2):
dt-bindings: timer: renesas: ostm: Document Renesas RZ/V2H(P) SoC
clocksource/drivers/renesas-ostm: Allow OSTM driver to reprobe for
RZ/V2H(P) SoC
Documentation/devicetree/bindings/timer/renesas,ostm.yaml | 2 ++
drivers/clocksource/renesas-ostm.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 2/2] clocksource/drivers/renesas-ostm: Allow OSTM driver to reprobe for RZ/V2H(P) SoC
From: Prabhakar @ 2024-03-22 15:12 UTC (permalink / raw)
To: Geert Uytterhoeven, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chris Brandt, Magnus Damm
Cc: linux-kernel, devicetree, linux-arm-kernel, linux-renesas-soc,
Prabhakar, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20240322151219.885832-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
The RZ/V2H(P) (R9A09G057) SoC is equipped with the Generic Timer Module,
also known as OSTM. Similar to the RZ/G2L SoC, the OSTM on the RZ/V2H(P)
SoC requires the reset line to be deasserted before accessing any
registers.
Early call to ostm_init() happens through TIMER_OF_DECLARE() which always
fails with -EPROBE_DEFER, as resets are not available that early in the
boot process. To address this issue on the RZ/V2H(P) SoC, enable the OSTM
driver to be reprobed through the platform driver probe mechanism.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
v1->v2
- Updated commit description
- Dropped usage of IS_ENABLED() and used defined() instead
---
drivers/clocksource/renesas-ostm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clocksource/renesas-ostm.c b/drivers/clocksource/renesas-ostm.c
index 8da972dc1713..39487d05a009 100644
--- a/drivers/clocksource/renesas-ostm.c
+++ b/drivers/clocksource/renesas-ostm.c
@@ -224,7 +224,7 @@ static int __init ostm_init(struct device_node *np)
TIMER_OF_DECLARE(ostm, "renesas,ostm", ostm_init);
-#ifdef CONFIG_ARCH_RZG2L
+#if defined(CONFIG_ARCH_RZG2L) || defined(CONFIG_ARCH_R9A09G057)
static int __init ostm_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
--
2.34.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
* Re: [PATCH v2 1/8] drm: xlnx: Fix kerneldoc
From: Sean Anderson @ 2024-03-22 15:22 UTC (permalink / raw)
To: Tomi Valkeinen, Randy Dunlap
Cc: Michal Simek, David Airlie, linux-kernel, Daniel Vetter,
linux-arm-kernel, Laurent Pinchart, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, dri-devel
In-Reply-To: <19d6da67-f9a6-4e01-a956-3b60f0ebf769@ideasonboard.com>
On 3/22/24 01:50, Tomi Valkeinen wrote:
> On 21/03/2024 17:33, Sean Anderson wrote:
>> On 3/20/24 02:05, Randy Dunlap wrote:
>>>
>>>
>>> On 3/19/24 22:42, Tomi Valkeinen wrote:
>>>> On 20/03/2024 00:51, Sean Anderson wrote:
>>>>> Fix a few errors in the kerneldoc. Mostly this addresses missing/renamed
>>>>> members.
>>>>>
>>>>> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
>>>>> ---
>>>>>
>>>>> Changes in v2:
>>>>> - New
>>>>>
>>>>> drivers/gpu/drm/xlnx/zynqmp_disp.c | 6 +++---
>>>>> drivers/gpu/drm/xlnx/zynqmp_dpsub.h | 1 +
>>>>> drivers/gpu/drm/xlnx/zynqmp_kms.h | 4 ++--
>>>>> 3 files changed, 6 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c
>>>>> index 407bc07cec69..f79bf3fb8110 100644
>>>>> --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
>>>>> +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
>>>>> @@ -128,9 +128,9 @@ struct zynqmp_disp_layer {
>>>>> * struct zynqmp_disp - Display controller
>>>>> * @dev: Device structure
>>>>> * @dpsub: Display subsystem
>>>>> - * @blend.base: Register I/O base address for the blender
>>>>> - * @avbuf.base: Register I/O base address for the audio/video buffer manager
>>>>> - * @audio.base: Registers I/O base address for the audio mixer
>>>>> + * @blend: Register I/O base address for the blender
>>>>> + * @avbuf: Register I/O base address for the audio/video buffer manager
>>>>> + * @audio: Registers I/O base address for the audio mixer
>>>>
>>>> Afaics, the kernel doc guide:
>>>>
>>>> https://docs.kernel.org/doc-guide/kernel-doc.html#nested-structs-unions
>>>>
>>>> says that the current version is correct. Or is the issue that while, say, 'base' is documented, 'blend' was not?
>>>
>>> Hi,
>>>
>>> I would do it more like so:
>>>
>>> ---
>>> drivers/gpu/drm/xlnx/zynqmp_disp.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff -- a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c
>>> --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
>>> +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
>>> @@ -128,8 +128,11 @@ struct zynqmp_disp_layer {
>>> * struct zynqmp_disp - Display controller
>>> * @dev: Device structure
>>> * @dpsub: Display subsystem
>>> + * @blend: blender iomem info
>>> * @blend.base: Register I/O base address for the blender
>>> + * @avbuf: audio/video buffer iomem info
>>> * @avbuf.base: Register I/O base address for the audio/video buffer manager
>>> + * @audio: audio mixer iomem info
>>> * @audio.base: Registers I/O base address for the audio mixer
>>> * @layers: Layers (planes)
>>> */
>>>
>>>
>>> but in my testing, Sean's way or my way result in no warning/errors.
>>>
>>
>> The specific errors are:
>>
>> ../drivers/gpu/drm/xlnx/zynqmp_disp.c:151: warning: Function parameter or struct member 'blend' not described in 'zynqmp_disp'
>> ../drivers/gpu/drm/xlnx/zynqmp_disp.c:151: warning: Function parameter or struct member 'avbuf' not described in 'zynqmp_disp'
>> ../drivers/gpu/drm/xlnx/zynqmp_disp.c:151: warning: Function parameter or struct member 'audio' not described in 'zynqmp_disp'
>>
>> I don't see the need to document a single-member struct twice. Actually,
>
> But if only the struct is documented, then we're documenting the wrong thing. A tool showing to the user what blend.base is would miss that documentation.
Are there any such tools? kerneldoc e.g. just prints the definition and
then a list of members with documentation. So from the user's
perspective the only thing which changes is the name.
--Sean
>> maybe it would be better to just lift the .base member to live in
>> zynqmp_disp. But I think that would be better in another series.
>
> Yes, there's not much point with the structs.
>
> Tomi
>
_______________________________________________
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 10/11] pinctrl: pinctrl-tps6594: Add TPS65224 PMIC pinctrl and GPIO
From: Esteban Blanc @ 2024-03-22 15:24 UTC (permalink / raw)
To: Bhargav Raviprakash, jpanis
Cc: arnd, broonie, conor+dt, devicetree, gregkh, kristo,
krzysztof.kozlowski+dt, lee, lgirdwood, linus.walleij,
linux-arm-kernel, linux-gpio, linux-kernel, m.nirmaladevi, nm,
robh+dt, vigneshr
In-Reply-To: <20240322141043.498005-1-bhargav.r@ltts.com>
Hi Bhargav,
LP8764 is not supported but the driver was wrongly instanciated on the
MFD. For V5 could you:
- Disable this driver for LD8764.
- Make sure this driver correctly supports TPS6593
Best Regards,
--
Esteban "Skallwar" Blanc
BayLibre
_______________________________________________
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 2/3] drm/tidss: Add support for display sharing
From: Devarsh Thakkar @ 2024-03-22 15:29 UTC (permalink / raw)
To: Maxime Ripard
Cc: jyri.sarha, tomi.valkeinen, airlied, daniel, maarten.lankhorst,
tzimmermann, robh+dt, krzysztof.kozlowski+dt, conor+dt, dri-devel,
devicetree, linux-kernel, linux-arm-kernel, nm, vigneshr, kristo,
praneeth, a-bhatia1, j-luthra
In-Reply-To: <20240314-hospitable-attractive-cuttlefish-a2f504@houat>
Hi Maxime,
On 14/03/24 20:04, Maxime Ripard wrote:
> Hi,
>
> On Wed, Feb 14, 2024 at 09:17:12PM +0530, Devarsh Thakkar wrote:
>> On 13/02/24 19:34, Maxime Ripard wrote:
>>> On Thu, Feb 08, 2024 at 06:26:17PM +0530, Devarsh Thakkar wrote:
>>>> On 26/01/24 17:45, Maxime Ripard wrote:
>>>>> Hi,
>>>>>
>>>>> Thanks a lot for working on that.
>>>>>
>>>>> On Tue, Jan 16, 2024 at 07:11:41PM +0530, Devarsh Thakkar wrote:
>>>>>> Display subsystem present in TI Keystone family of devices supports sharing
>>>>>> of display between multiple hosts as it provides separate register space
>>>>>> (common* region) for each host to programming display controller and also a
>>>>>> unique interrupt line for each host.
>>>>>>
>>>>>> This adds support for display sharing, by allowing partitioning of
>>>>>> resources either at video port level or at video plane level as
>>>>>> described below :
>>>>>>
>>>>>> 1) Linux can own (i.e have write access) completely one or more of video
>>>>>> ports along with corresponding resources (viz. overlay managers,
>>>>>> video planes) used by Linux in context of those video ports.
>>>>>> Even if Linux is owning
>>>>>> these video ports it can still share this video port with a remote core
>>>>>> which can own one or more video planes associated with this video port.
>>>>>>
>>>>>> 2) Linux owns one or more of the video planes with video port
>>>>>> (along with corresponding overlay manager) associated with these planes
>>>>>> being owned and controlled by a remote core. Linux still has read-only
>>>>>> access to the associated video port and overlay managers so that it can
>>>>>> parse the settings made by remote core.
>>>>>
>>>>> So, just to make sure we're on the same page. 1) means Linux drives the
>>>>> whole display engine, but can lend planes to the R5? How does that work,
>>>>> is Linux aware of the workload being there (plane size, format, etc) ?
>>>>>
>>>>
>>>> Well, there is no dynamic procedure being followed for lending. The
>>>> partitioning scheme is decided and known before hand, and the remote
>>>> core firmware updated and compiled accordingly, and similarly the
>>>> device-tree overlay for Linux is also updated with partitioning
>>>> information before bootup.
>>>>
>>>> What would happen here is that Linux will know before-hand this
>>>> partitioning information via device-tree properties and won't enumerate
>>>> the plane owned by RTOS, but it will enumerate the rest of the display
>>>> components and initialize the DSS, after which user can load the DSS
>>>> firmware on remote core and this firmware will only have control of
>>>> plane as it was compiled with that configuration.
>>>
>>> Right. If the RTOS is in control of a single plane, how it is expected
>>> to deal with Linux shutting the CRTC down, or enforcing a configuration
>>> that isn't compatible with what the RTOS expects (like a plane with a
>>> higher zpos masking its plane), what is the mechanism to reconcile it?
>>>
>>
>> Just for the note, for this "RTOS control single plane" mode, we don't have a
>> firmware available to test (right now we are only supporting example for "RTOS
>> controlling the display mode" as shared here [1]) and hence this is not
>> validated but the idea was to keep dt-bindings generic enough to support them
>> in future and that's why I referred to it here.
>>
>> Coming back to your questions, with the current scheme the Linux (tidss) would
>> be expected to make sure the CRTC being shared with RTOS is never shutdown and
>> the RTOS plane should never gets masked.
>
> I'm probably missing something then here, but if the Linux side of
> things is expected to keep the current configuration and keep it active
> for it to work, what use-case would it be useful for?
>
It's just one of the partitioning possibilities that I mentioned here, that
Linux is in control of DSS as a whole and the user want the other host (be it
RTOS or any other core) to control a single plane. For e.g it could be Linux
(with GPU rendering) displaying the graphics and RTOS overlaying a real time
clock or any other signs which need to be displayed in real-time.
But more than the use-case this is inspired by the fact that we want to be
flexible and support in the linux driver whatever partitioning scheme
possibilities are there which are supported in hardware and we let user decide
on the partitioning scheme.
>> I think the IPC based scheme would have been mainly needed for the case where
>> you have a single entity controlling the display for e.g you have a single
>> display controller register space and a single IRQ but you have multiple
>> planes and say you want to divide these planes to different host processors.
>
> And with, I assume, different OS on those host processors? Otherwise why
> would we need to handle some planes at the firmware level?
>
>> In that case you want a single entity to act as a main entity and be in
>> control of DSS and rest of the processors communicate with the "main entity"
>> to request display resources and plane updates and main entity also programs
>> dss on their behalf.
>>
>> But unlike above, TI DSS7 is designed to support static partitioning of
>> display resources among multiple hosts, where each host can program the
>> display hardware independently using separate register space and having a
>> separate irq and without requirement of any communication between the hosts.
>> Now as this feature is unique to TI DSS7 we want to support this feature in
>> tidss driver. The DSS resource partitioning feature is described in detail
>> here [2]
>
> So, if I understand this properly, and in KMS terms, DSS7 can assign the
> planes, CRTCs or encoders to a given VM or CPU, and you can segment the
> hardware that way. It looks like a good way to split encoders between
> VMs, but going back to the discussion about one plane being handled by
> the firmware, I don't really see how it can work with something else
> than splitting away the whole pipeline and having a VM claiming a CRTC
> and encoder, and another VM claiming another pipeline.
>
> Like, if they share either a CRTC or encoder, we will still go back to
> the discussion about arbitration about who has the final word if the two
> have conflicting requirements, or if it changes something the other
> probably has to know about it.
There should not be any conflicting requirements as this sharing scheme is a
static one i.e. it is pre-negotiated or decided by the user before Linux
kernel compilation or RTOS firmware compilation and resources are split
statically and the sharing scheme is communicated to Linux via device-tree and
RTOS side firmware configured and compiled accordingly, and this scheme stays
intact without any change after device boots up. So for e.g. if Linux is
assigned only one plane and RTOS is the DSS master controlling all other
entities then this scheme will stay intact as long as device is up.
Also there could be only a single DSS master (the one in control of global
common0 reg space, i.e. having access to global DSS registers and also in
control of dss clock and power domains) and whichever core is acting as DSS
master will be knowing which of the CRTC and encoders are shared with other
hosts so that it doesn't power them off given other cores may still be using it.
>
>>>>> And 2) would mean that the display engine is under the R5 control and
>>>>> Linux only gets to fill the plane and let the firmware know of what it
>>>>> wants?
>>>>>
>>>>
>>>> Here too the partitioning information is pre-decided and remote core
>>>> firmware and device-tree overlay for Linux updated accordingly. But in
>>>> this case as remote core firmware owns the display (minus the plane
>>>> owned by Linux) it is started and initialized during the bootloader
>>>> phase itself where it initializes the DSS and starts rendering using the
>>>> plane owned by it and Linux just latches to the DSS without
>>>> re-initializing it, with write access only to the plane that is owned by
>>>> Linux. You can refer [1] for more details on this.
>>>>
>>>>> If so, do we even need the tidss driver in the second case? We could
>>>>> just write a fwkms driver of some sorts that could be used by multiple
>>>>> implementations of the same "defer to firmware" logic.
>>>>>
>>>>
>>>> This feature of static partitioning of DSS resources is specific to DSS7
>>>> hardware (which is controlled by tidss driver) which supports dedicated
>>>> register space and interrupt line for each of the hosts [0], so that
>>>> multiple hosts can drive the display controller simultaneously as per
>>>> the desired static partitioning of resources, and so I don't think a
>>>> separate driver is required here and tidss seems the right place to
>>>> support this, where using this device-tree approach different resource
>>>> partitioning schemas can be achieved as described here [1]. This was
>>>> also aligned with Tomi too where we discussed that tidss is the right
>>>> place to support this as we are simply leveraging the DSS hardware
>>>> capabilities of static partitioning here.
>>>
>>> If the only thing tidss does in the "owned by RTOS" is forwarding KMS
>>> atomic states to the RTOS, then I'm still not sure why we need to
>>> involve tidss at all.
>>
>> I think maybe here is the point of misunderstanding. We are not forwarding
>> atomic states to RTOS here. Linux (tidss) is infact, accessing the display
>> register space assigned to it (common1 assigned to Linux, commmon0 assigned to
>> RTOS) and also writing to DSS plane registers for the plane assigned to it
>> (say VID assigned to Linux and VIDL assigned to RTOS).
>>
>>> It's not just about interrupts, it's also about how your arbitrate
>>> between what Linux wants and what the RTOS wants. Like if the RTOS still
>>> wants to output something but Linux wants to disable it, how do you
>>> reconcile the two?
>>>
>>
>> The scheme involves static partitioning of display resource which are assigned
>> compile-time to RTOS and Linux. Here the RTOS firmware is compiled with
>> specific ownership/display resources as desired by user and this assignment
>> stays intact.
>>
>> If there is a more complex use-case which requires dynamic
>> assignment/arbitration of resources then I agree those require some sort of
>> IPC scheme but this is not what we target with these series. This series is
>> simply to support static partitioning feature (separate register space,
>> separate irq, firewalling support etc) of TI DSS hardware across the multiple
>> hosts and there are use-cases too for which this scheme suffices.
>
> I think you're right and we have a misunderstanding. My initial
> assumption was that it was to prevent the Linux side of sides from
> screwing up the output if it was to crash.
>
> But it looks like it's not the main point of this series, so could you
> share some use-cases you're trying to address?
>
The end use-case we have demonstrated right now with this series is a
proof-of-concept display cluster use-case where RTOS boots early on MCU core
(launched at bootloader stage) and initializes the display (using the global
common0 register space and irq) and starts displaying safety tell-tales on one
plane, and once Linux boots up on application processor,
Linux (using common1 register space and irq) controls the other plane with GPU
rendering using a QT based application. And yes, we also support the scenario
where Linux crashes but RTOS being the DSS master and in control of DSS power,
clock domain and global register space is not impacted by the crash.
This is demonstrated in this video [1] and steps to simulate the same are also
documented here [2].
[1]: https://www.youtube.com/watch?v=WIcds6HGeMI&t=884s
[2]:
https://software-dl.ti.com/processor-sdk-linux/esd/AM62PX/09_01_00_08/exports/docs/system/Demo_User_Guides/Display_Cluster_User_Guide.html
Regards
Devarsh
> Thanks!
> Maxime
_______________________________________________
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/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards
From: Josua Mayer @ 2024-03-22 15:38 UTC (permalink / raw)
To: Andrew Lunn
Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Yazan Shhady,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <4fff2165-c3cc-41d8-b541-6e69ce4d98ac@lunn.ch>
Am 22.03.24 um 14:11 schrieb Andrew Lunn:
>>> Sorry, but no. List the LEDs in the PHY node, and they can then be
>>> controlled via /sys/class/leds.
>> May I ask more precisely the motivation?
>> Does this replace the phy's builtin automatic led control?
>>> arch/arm/boot/dts/marvell/armada-370-rd.dts is an example.
>> I will investigate it.
>>
>> My main motivation for tweaking the led controls was to make them all consistent across the two boards:
>> - LEDs under control of PHYs on cpu mdio bus
>> - LEDs under control of ethernet switch on mdio bus
>> - LEDs under control of ethernet phy on external mdio bus behind ethernet switch
>>
>> It looks as if the marvell phy driver supports led subnodes,
>> The switch driver does not.
> https://lwn.net/Articles/965775/
Great!
>
> There has been quite a bit of interest in mv88e6xxx driver support, so
> i expect support for other families outside of 6352 will be added
> after it has been merged, and it is not difficult code to write.
>
>> Finally one phy can only be written to but not read,
>> the cpu can never know its link state.
> O.K. That one cannot use the LED infrastructure in a meaningful way.
>
>> So I prefer (for the Clearfog Pro) board to explicitly use the phys
>> autonomous management of LEDs.
>> Is that still possible if I added led subnodes?
> You can combine both. The horrible marvell,reg-init will be applied
> first. The generic LED code will then take over controlling the LEDs.
I (currently) can't put in the led node e.g.
linux,default-trigger = "link100|link1000|tx|rx";
Right?
>
> For the discrete PHYs, the generic LED code can make use of the
> hardware offload support to read back the hardware configuration and
> configure itself to match. The switch code is missing hardware offload
> at the moment. So it cannot read back the current
> configuration. However, it is simple code to add, and the discrete
> code is a good example to follow.
>
> marvell,reg-init is not going to go away, because of backwards
> compatibility with old DT blobs. But in general, i expect all vendor
> proprietary methods of configuring LEDs to be deprecated and replaced
> with the vendor neutral /sys/class/leds.
Sounds good.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Re: [PATCH 0/0] (proposed?) Add ACPI binding to Rockchip RK3xxx I2C bus
From: Shimrra Shai @ 2024-03-22 15:51 UTC (permalink / raw)
To: jonathan.cameron
Cc: heiko, linux-arm-kernel, linux-kernel, linux-rockchip,
max.schwarz, niyas.sait, shimmyshai00
In-Reply-To: <20240322103521.00001a12@Huawei.com>
Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:
For
> It would be good to highlight in this description what is missing for
> doing a standard ACPI binding and not using any specific hacks in the
> driver (get clocks as normal etc).
>
> There are ACPI clock bindings, but Linux doesn't support the yet (I think?)
> See ACPICA commit
> https://github.com/acpica/acpica/commit/661feab5ee01a34af95a389a18c82e79f1aba05a
>
> I've seen prototype code but was a while back. I'd like to see that
> work compled rather than having every driver need to paper over the hole.
>
> The alias is a different question that needs to be addressed.
> If this is a common pattern, push it up in to the i2c core, not
> a specific driver. I see there is already code related to that
> in i2c_add_adapter - that just wants an ACPI option.
>
> Jonathan
and
> That implies that the kernel can cope with the device tree wrapped up in
> ACPI path. If that's the case, why do you need RKCP3001 as you can
> match on the compatible?
This was all based on how the people working on the firmware project wrote
the ACPI binding. That said, since I've got a foot in it too I can
definitely submit them an updated binding. The binding for the I2C in the
project looks like this:
Device (I2C1) {
Name (_HID, "RKCP3001")
Name (_CID, "PRP0001")
Name (_UID, 1)
Name (_CCA, 0)
Method (_CRS, 0x0, Serialized) {
Name (RBUF, ResourceTemplate() {
Memory32Fixed (ReadWrite, 0xfea90000, 0x1000)
Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) { 350 }
})
Return (RBUF)
}
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package (2) { "i2c,clk-rate", 198000000 },
Package (2) { "rockchip,bclk", 198000000 },
Package (2) { "#address-cells", 1 },
Package (2) { "#size-cells", 0 },
}
})
}
(there are others, e.g. I2C2, I2C3, etc. one for each I2C bus, with
correspondingly different _UID and some different numbers for interrupts
etc.)
From what I'm gathering from reading the documentation at
https://uefi.org/specs/ACPI/6.5/19_ASL_Reference.html
which is admittedly quite terse and doesn't provide nearly enough examples
for my liking, and given I have not been able to find a "in the wild" ACPI
using ClockInput, I presume a better binding would be like this, correct?:
Device (I2C1) {
Name (_HID, "RKCP3001")
/* _CID is gone now because we are no longer assuming mirror of DT */
Name (_UID, 1)
Name (_CCA, 0)
Method (_CRS, 0x0, Serialized) {
Name (RBUF, ResourceTemplate() {
Memory32Fixed (ReadWrite, 0xfea90000, 0x1000)
Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) { 350 }
ClockInput (198000000, 1, Hz, Fixed, "PCLK", 0)
ClockInput (198000000, 1, Hz, Fixed, "BCLK", 0)
})
Return (RBUF)
}
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package (2) { "#address-cells", 1 },
Package (2) { "#size-cells", 0 },
}
})
Device (PCLK) {
Name (_ADR, 0x0)
}
Device (BCLK) {
Name (_ADR, 0x1)
}
}
Note now I added two device nodes for the clocks and use ClockInput to
describe the frequencies. I'm unsure though about the device node part,
however; I know that the .DTB has a central node for the CRU (the actual
clock generator on the RK3588), so should we instead have a top-level
Device node "CRU_" and reference the ClockInputs to that, e.g. something
like
ClockInput (198000000, 1, Hz, Fixed, "CRU_", I2C1_PCLK)
ClockInput (198000000, 1, Hz, Fixed, "CRU_", I2C1_BCLK)
? (Note the obvious analogy to rk3588s.dtsi for the labels, which would be
#defined constants.) Though in this case I'd ask if someone here would be
kind enough to supply the structure for the top-level CRU binding so that I
don't have to guess the "best" form for the kernel like the makers of the
firmware were doing which is what led to this disagreement in the first
place.
FWIW, I'd also be willing to help lend a hand to finish out the support for
the ClockInput binding in the ACPI reader subsystem. There already seems to
be some support, e.g. in drivers/acpi/acpica/rsinfo.c and a few other
places, but I'm not sure what else is needed to get it going and would need
to study that subsystem in much more depth.
- Shimmy
_______________________________________________
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/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards
From: Andrew Lunn @ 2024-03-22 15:49 UTC (permalink / raw)
To: Josua Mayer
Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Yazan Shhady,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <748753a6-9fde-4d4f-8fee-5b93dbb532f0@solid-run.com>
> I (currently) can't put in the led node e.g.
> linux,default-trigger = "link100|link1000|tx|rx";
> Right?
No. The trigger will be 'netdev'. Or 'heartbeat', or
'kbd-numlock'. They are just LEDs, they can be used for
anything. While testing some of this code i had the keyboard numlock
indicating network packets, since it easier to see than the RJ45
socket... The same applies the other way. The RJ45 LEDs are just Linux
LEDs, they can be used for anything...
I do have some code adding additional properties for the blink
reason. However, it is very debatable if it belongs in DT. DT
describes hardware, not configuration of hardware.
Do you actually have labels on the case indicating what the LEDs mean?
It could be we describe the label, which is hardware, not the
configuration of the LED, which is policy from user space.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Why is the ARM SMMU v1/v2 put into bypass mode on kexec?
From: Will Deacon @ 2024-03-22 15:51 UTC (permalink / raw)
To: Robin Murphy
Cc: Tyler Hicks, Jason Gunthorpe, Jerry Snitselaar, linux-arm-kernel,
iommu, linux-kernel, Dexuan Cui, Easwar Hariharan
In-Reply-To: <5b19ab13-a7a0-48e2-99a4-357a9f4aeafa@arm.com>
On Tue, Mar 19, 2024 at 06:17:39PM +0000, Robin Murphy wrote:
> In terms of the shutdown behaviour, I think it actually works out as-is. For
> the normal case we haven't touched GBPA, so we are truly returning to the
> boot-time condition; in the unexpected case where SMMUEN was already enabled
> then we'll go into an explicit GPBA abort state, but that seems a
> not-unreasonable compromise for not preserving the entire boot-time Stream
> Table etc., whose presence kind of implies it wouldn't have been bypassing
> everything anyway.
>
> The more I look at the remaining aspect of disable_bypass for controlling
> broken-DT behaviour the more I suspect it can't actually be useful either
> way, especially not since default domains. I have no memory of what my
> original reasoning might have been, so I'm inclined to just rip that all out
> and let probe fail. I see no reason these days not to expect a broken DT to
> leads to a broken system, especially not now with DTSchema validation.
That sounds reasonable to me, although we may end up having to back it
out if we regress systems with borked firmware :(
> Then there's just the kdump warning it suppresses, of which I also have no
> idea why it's there either, but apparently that one's on you :P
I think _that_ one is because the previous (crashed) kernel won't have
torn anything down, so there could be active DMA using translations in
the SMMU. In that case, the crashkernel (which is running from some
carveout) may find the SMMU enabled, but it really can't stick it into
bypass mode because that's likely to corrupt random memory. So in that
case, we do stick it into abort before we reinitialise it and then we
disabling fault reporting altogether to avoid the log spam:
if (is_kdump_kernel())
enables &= ~(CR0_EVTQEN | CR0_PRIQEN)
Will
_______________________________________________
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 v3 12/12] mm/gup: Handle hugetlb in the generic follow_page_mask code
From: Peter Xu @ 2024-03-22 15:55 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: linux-mm, linux-kernel, linuxppc-dev, Michael Ellerman,
Christophe Leroy, Matthew Wilcox, Rik van Riel, Lorenzo Stoakes,
Axel Rasmussen, Yang Shi, John Hubbard, linux-arm-kernel,
Kirill A . Shutemov, Andrew Jones, Vlastimil Babka, Mike Rapoport,
Andrew Morton, Muchun Song, Christoph Hellwig, linux-riscv,
James Houghton, David Hildenbrand, Andrea Arcangeli,
Aneesh Kumar K . V, Mike Kravetz
In-Reply-To: <20240322133012.GI159172@nvidia.com>
Jason,
On Fri, Mar 22, 2024 at 10:30:12AM -0300, Jason Gunthorpe wrote:
> On Thu, Mar 21, 2024 at 06:08:02PM -0400, peterx@redhat.com wrote:
>
> > A quick performance test on an aarch64 VM on M1 chip shows 15% degrade over
> > a tight loop of slow gup after the path switched. That shouldn't be a
> > problem because slow-gup should not be a hot path for GUP in general: when
> > page is commonly present, fast-gup will already succeed, while when the
> > page is indeed missing and require a follow up page fault, the slow gup
> > degrade will probably buried in the fault paths anyway. It also explains
> > why slow gup for THP used to be very slow before 57edfcfd3419 ("mm/gup:
> > accelerate thp gup even for "pages != NULL"") lands, the latter not part of
> > a performance analysis but a side benefit. If the performance will be a
> > concern, we can consider handle CONT_PTE in follow_page().
>
> I think this is probably fine for the moment, at least for this
> series, as CONT_PTE is still very new.
>
> But it will need to be optimized. "slow" GUP is the only GUP that is
> used by FOLL_LONGTERM and it still needs to be optimized because you
> can't assume a FOLL_LONGTERM user will be hitting the really slow
> fault path. There are enough important cases where it is just reading
> already populted page tables, and these days, often with large folios.
Ah, I thought FOLL_LONGTERM should work in most cases for fast-gup,
especially for hugetlb, but maybe I missed something? I do see that devmap
skips fast-gup for LONGTERM, we also have that writeback issue but none of
those that I can find applies to hugetlb. This might be a problem indeed
if we have hugetlb cont_pte pages that will constantly fallback to slow
gup.
OTOH, I also agree with you that such batching would be nice to have for
slow-gup, likely devmap or many fs (exclude shmem/hugetlb) file mappings
can at least benefit from it due to above. But then that'll be a more
generic issue to solve, IOW, we still don't do that for !hugetlb cont_pte
large folios, before or after this series.
>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Thanks!
--
Peter Xu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Why is the ARM SMMU v1/v2 put into bypass mode on kexec?
From: Will Deacon @ 2024-03-22 15:55 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Robin Murphy, Tyler Hicks, Jerry Snitselaar, linux-arm-kernel,
iommu, linux-kernel, Dexuan Cui, Easwar Hariharan
In-Reply-To: <20240319175007.GC66976@ziepe.ca>
Hey Jason,
On Tue, Mar 19, 2024 at 02:50:07PM -0300, Jason Gunthorpe wrote:
> On Tue, Mar 19, 2024 at 03:47:56PM +0000, Will Deacon wrote:
>
> > Right, it's hard to win if DMA-active devices weren't quiesced properly
> > by the outgoing kernel. Either the SMMU was left in abort (leading to the
> > problems you list above) or the SMMU is left in bypass (leading to possible
> > data corruption). Which is better?
>
> For whatever reason (and I really don't like this design) alot of work
> was done on x86 so that device continues to work as-was right up until
> the crash kernel does the first DMA operation. Including having the
> crash kernel non disruptively inherit and retain the IOMMU
> configuration. (eg see translation_pre_enabled() stuff in intel
> driver)
Right, I'm also not thrilled about trying to implement that :)
What we have at the moment seems to be good enough to avoid folks
complaining about it.
For the case Tyler is reporting, though, I _think_ it's just a standard
kexec() rather than a crashkernel.
Will
_______________________________________________
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/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards
From: Josua Mayer @ 2024-03-22 15:58 UTC (permalink / raw)
To: Andrew Lunn
Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Yazan Shhady,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <a22e7861-c140-4f34-97be-a1f4e435b44b@lunn.ch>
Am 22.03.24 um 16:49 schrieb Andrew Lunn:
>> I (currently) can't put in the led node e.g.
>> linux,default-trigger = "link100|link1000|tx|rx";
>> Right?
> No. The trigger will be 'netdev'. Or 'heartbeat', or
> 'kbd-numlock'.
OK.
> They are just LEDs, they can be used for
> anything. While testing some of this code i had the keyboard numlock
> indicating network packets, since it easier to see than the RJ45
> socket... The same applies the other way. The RJ45 LEDs are just Linux
> LEDs, they can be used for anything...
>
> I do have some code adding additional properties for the blink
> reason. However, it is very debatable if it belongs in DT. DT
> describes hardware, not configuration of hardware.
>
> Do you actually have labels on the case indicating what the LEDs mean?
> It could be we describe the label, which is hardware, not the
> configuration of the LED, which is policy from user space.
I have seen it on customer products, and I have seen it in manuals,
and it can help in customer support.
Personally I would want it for consistency reasons, so that even if
hardware engineers confused 0 and 1 I can ensure consistent
behaviour out of the box.
It could be the vendor recommended or intended configuration ...
_______________________________________________
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 v3 5/5] arm64: Use SYSTEM_OFF2 PSCI call to power off for hibernate
From: Marc Zyngier @ 2024-03-22 16:02 UTC (permalink / raw)
To: David Woodhouse
Cc: linux-arm-kernel, kvm, Paolo Bonzini, Jonathan Corbet,
Oliver Upton, James Morse, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Mark Rutland, Lorenzo Pieralisi,
Rafael J. Wysocki, Len Brown, Pavel Machek, David Woodhouse,
Mostafa Saleh, Jean-Philippe Brucker, linux-doc, linux-kernel,
kvmarm, linux-pm
In-Reply-To: <20240319130957.1050637-6-dwmw2@infradead.org>
On Tue, 19 Mar 2024 12:59:06 +0000,
David Woodhouse <dwmw2@infradead.org> wrote:
[...]
> +static void __init psci_init_system_off2(void)
> +{
> + int ret;
> +
> + ret = psci_features(PSCI_FN_NATIVE(1_3, SYSTEM_OFF2));
> +
> + if (ret != PSCI_RET_NOT_SUPPORTED)
> + psci_system_off2_supported = true;
It'd be worth considering the (slightly broken) case where SYSTEM_OFF2
is supported, but HIBERNATE_OFF is not set in the response, as the
spec doesn't say that this bit is mandatory (it seems legal to
implement SYSTEM_OFF2 without any hibernate type, making it similar to
SYSTEM_OFF).
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
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 10/11] pinctrl: pinctrl-tps6594: Add TPS65224 PMIC pinctrl and GPIO
From: Esteban Blanc @ 2024-03-22 16:03 UTC (permalink / raw)
To: Bhargav Raviprakash, linux-kernel
Cc: m.nirmaladevi, lee, robh+dt, krzysztof.kozlowski+dt, conor+dt,
jpanis, devicetree, arnd, gregkh, lgirdwood, broonie,
linus.walleij, linux-gpio, linux-arm-kernel, nm, vigneshr, kristo
In-Reply-To: <20240320102559.464981-11-bhargav.r@ltts.com>
On Wed Mar 20, 2024 at 11:25 AM CET, Bhargav Raviprakash wrote:
> From: Nirmala Devi Mal Nadar <m.nirmaladevi@ltts.com>
>
> Add support for TPS65224 pinctrl and GPIOs to TPS6594 driver as they have
> significant functional overlap.
> TPS65224 PMIC has 6 GPIOS which can be configured as GPIO or other
> dedicated device functions.
>
> Signed-off-by: Nirmala Devi Mal Nadar <m.nirmaladevi@ltts.com>
> Signed-off-by: Bhargav Raviprakash <bhargav.r@ltts.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> drivers/pinctrl/pinctrl-tps6594.c | 258 +++++++++++++++++++++++++-----
> 1 file changed, 215 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-tps6594.c b/drivers/pinctrl/pinctrl-tps6594.c
> index 66985e54b..db0f5d2a8 100644
> --- a/drivers/pinctrl/pinctrl-tps6594.c
> +++ b/drivers/pinctrl/pinctrl-tps6594.c
> @@ -320,8 +451,18 @@ static int tps6594_pinctrl_probe(struct platform_device *pdev)
> return -ENOMEM;
> pctrl_desc->name = dev_name(dev);
> pctrl_desc->owner = THIS_MODULE;
> - pctrl_desc->pins = tps6594_pins;
> - pctrl_desc->npins = ARRAY_SIZE(tps6594_pins);
> + switch (tps->chip_id) {
> + case TPS65224:
> + pctrl_desc->pins = tps65224_pins;
> + pctrl_desc->npins = ARRAY_SIZE(tps65224_pins);
> + break;
> + case TPS6594:
> + pctrl_desc->pins = tps6594_pins;
> + pctrl_desc->npins = ARRAY_SIZE(tps6594_pins);
> + break;
> + default:
> + break;
> + }
> pctrl_desc->pctlops = &tps6594_pctrl_ops;
> pctrl_desc->pmxops = &tps6594_pmx_ops;
See below.
> @@ -329,8 +470,28 @@ static int tps6594_pinctrl_probe(struct platform_device *pdev)
> if (!pinctrl)
> return -ENOMEM;
> pinctrl->tps = dev_get_drvdata(dev->parent);
> - pinctrl->funcs = pinctrl_functions;
> - pinctrl->pins = tps6594_pins;
> + switch (pinctrl->tps->chip_id) {
You could use tps->chip_id like in the previous switch.
> + case TPS65224:
> + pinctrl->funcs = tps65224_pinctrl_functions;
> + pinctrl->func_cnt = ARRAY_SIZE(tps65224_pinctrl_functions);
> + pinctrl->pins = tps65224_pins;
> + pinctrl->num_pins = ARRAY_SIZE(tps65224_pins);
> + pinctrl->mux_sel_mask = TPS65224_MASK_GPIO_SEL;
> + pinctrl->remap = tps65224_muxval_remap;
> + pinctrl->remap_cnt = ARRAY_SIZE(tps65224_muxval_remap);
> + break;
> + case TPS6594:
> + pinctrl->funcs = pinctrl_functions;
This should be tps6594_pinctrl_functions
> + pinctrl->func_cnt = ARRAY_SIZE(pinctrl_functions);
> + pinctrl->pins = tps6594_pins;
> + pinctrl->num_pins = ARRAY_SIZE(tps6594_pins);
> + pinctrl->mux_sel_mask = TPS6594_MASK_GPIO_SEL;
> + pinctrl->remap = tps6594_muxval_remap;
> + pinctrl->remap_cnt = ARRAY_SIZE(tps6594_muxval_remap);
> + break;
> + default:
> + break;
> + }
See blow.
> pinctrl->pctl_dev = devm_pinctrl_register(dev, pctrl_desc, pinctrl);
> if (IS_ERR(pinctrl->pctl_dev))
> return dev_err_probe(dev, PTR_ERR(pinctrl->pctl_dev),
> @@ -338,8 +499,18 @@ static int tps6594_pinctrl_probe(struct platform_device *pdev)
>
> config.parent = tps->dev;
> config.regmap = tps->regmap;
> - config.ngpio = TPS6594_PINCTRL_PINS_NB;
> - config.ngpio_per_reg = 8;
> + switch (pinctrl->tps->chip_id) {
Same here, use tps->chip_id
> + case TPS65224:
> + config.ngpio = ARRAY_SIZE(tps65224_gpio_func_group_names);
> + config.ngpio_per_reg = TPS65224_NGPIO_PER_REG;
> + break;
> + case TPS6594:
> + config.ngpio = ARRAY_SIZE(tps6594_gpio_func_group_names);
> + config.ngpio_per_reg = TPS6594_NGPIO_PER_REG;
> + break;
> + default:
> + break;
> + }
> config.reg_dat_base = TPS6594_REG_GPIO_IN_1;
> config.reg_set_base = TPS6594_REG_GPIO_OUT_1;
> config.reg_dir_out_base = TPS6594_REG_GPIOX_CONF(0);
Regarding all the switch case, they should be use to set all the struct
fields that are known at runtime only. For example, pinctrl->funcs, and
pinctrl->func_cnt are known at compile time. You should create template
structs, one for TPS6594 the other TPS65224, initialise the allocated
struct with the template and then fill the remaining fields with the
runtime values. Something like this:
```c
struct test {
int a;
int *b;
};
static struct test template = {
.a = 42,
};
int main(void) {
struct test *test = malloc(sizeof(*test));
*test = sample;
test->b = NULL;
return 0;
}
```
You could also try to reduce the number of switch case, there is no good
reason to have 2 switch instead of one for pctrl_desc and pinctrl
structs.
Best regards,
--
Esteban "Skallwar" Blanc
BayLibre
_______________________________________________
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 v3 2/5] KVM: arm64: Add support for PSCI v1.2 and v1.3
From: Marc Zyngier @ 2024-03-22 16:05 UTC (permalink / raw)
To: David Woodhouse
Cc: linux-arm-kernel, kvm, Paolo Bonzini, Jonathan Corbet,
Oliver Upton, James Morse, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Mark Rutland, Lorenzo Pieralisi,
Rafael J. Wysocki, Len Brown, Pavel Machek, David Woodhouse,
Mostafa Saleh, Jean-Philippe Brucker, linux-doc, linux-kernel,
kvmarm, linux-pm
In-Reply-To: <20240319130957.1050637-3-dwmw2@infradead.org>
On Tue, 19 Mar 2024 12:59:03 +0000,
David Woodhouse <dwmw2@infradead.org> wrote:
>
> From: David Woodhouse <dwmw@amazon.co.uk>
>
> Since the v1.3 specification is still in Alpha, only default to v1.2
> unless userspace explicitly requests v1.3 for now.
>
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> ---
> arch/arm64/kvm/hypercalls.c | 2 ++
> arch/arm64/kvm/psci.c | 6 +++++-
> include/kvm/arm_psci.h | 4 +++-
> 3 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index 5763d979d8ca..9c6267ca2b82 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -575,6 +575,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> case KVM_ARM_PSCI_0_2:
> case KVM_ARM_PSCI_1_0:
> case KVM_ARM_PSCI_1_1:
> + case KVM_ARM_PSCI_1_2:
> + case KVM_ARM_PSCI_1_3:
> if (!wants_02)
> return -EINVAL;
> vcpu->kvm->arch.psci_version = val;
> diff --git a/arch/arm64/kvm/psci.c b/arch/arm64/kvm/psci.c
> index 1f69b667332b..f689ef3f2f10 100644
> --- a/arch/arm64/kvm/psci.c
> +++ b/arch/arm64/kvm/psci.c
> @@ -322,7 +322,7 @@ static int kvm_psci_1_x_call(struct kvm_vcpu *vcpu, u32 minor)
>
> switch(psci_fn) {
> case PSCI_0_2_FN_PSCI_VERSION:
> - val = minor == 0 ? KVM_ARM_PSCI_1_0 : KVM_ARM_PSCI_1_1;
> + val = PSCI_VERSION(1, minor);
> break;
> case PSCI_1_0_FN_PSCI_FEATURES:
> arg = smccc_get_arg1(vcpu);
> @@ -449,6 +449,10 @@ int kvm_psci_call(struct kvm_vcpu *vcpu)
> }
>
> switch (version) {
> + case KVM_ARM_PSCI_1_3:
> + return kvm_psci_1_x_call(vcpu, 3);
> + case KVM_ARM_PSCI_1_2:
> + return kvm_psci_1_x_call(vcpu, 2);
> case KVM_ARM_PSCI_1_1:
> return kvm_psci_1_x_call(vcpu, 1);
> case KVM_ARM_PSCI_1_0:
> diff --git a/include/kvm/arm_psci.h b/include/kvm/arm_psci.h
> index e8fb624013d1..ebd7d9a12790 100644
> --- a/include/kvm/arm_psci.h
> +++ b/include/kvm/arm_psci.h
> @@ -14,8 +14,10 @@
> #define KVM_ARM_PSCI_0_2 PSCI_VERSION(0, 2)
> #define KVM_ARM_PSCI_1_0 PSCI_VERSION(1, 0)
> #define KVM_ARM_PSCI_1_1 PSCI_VERSION(1, 1)
> +#define KVM_ARM_PSCI_1_2 PSCI_VERSION(1, 2)
> +#define KVM_ARM_PSCI_1_3 PSCI_VERSION(1, 3)
>
> -#define KVM_ARM_PSCI_LATEST KVM_ARM_PSCI_1_1
> +#define KVM_ARM_PSCI_LATEST KVM_ARM_PSCI_1_2 /* v1.3 is still Alpha */
>
> static inline int kvm_psci_version(struct kvm_vcpu *vcpu)
> {
Consider making the visibility of v1.2/1.3 to userspace and guest the
last patch in the series, so that there is no transient support for
some oddball PSCI version with no feature (keeps bisection clean).
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
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