* 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
* [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
* [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 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 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
* 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
* 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 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: [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 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: [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 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 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 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 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
* [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
* [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 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 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 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 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
* 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
* Re: [PATCH net-next v4 0/3] net: ethernet: mediatek: convert to PHYLINK
From: David Miller @ 2019-08-28 3:19 UTC (permalink / raw)
To: opensource
Cc: nelson.chang, frank-w, netdev, sean.wang, linux-mips, linux,
linux-mediatek, john, matthias.bgg, sr, linux-arm-kernel
In-Reply-To: <20190825174341.20750-1-opensource@vdorst.com>
From: René van Dorst <opensource@vdorst.com>
Date: Sun, 25 Aug 2019 19:43:38 +0200
> These patches converts mediatek driver to PHYLINK API.
>
> v3->v4:
> * Phylink improvements and clean-ups after review
> v2->v3:
> * Phylink improvements and clean-ups after review
> v1->v2:
> * Rebase for mt76x8 changes
> * Phylink improvements and clean-ups after review
> * SGMII port doesn't support 2.5Gbit in SGMII mode only in BASE-X mode.
> Refactor the code.
Series applied.
_______________________________________________
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 08/10] PCI: layerscape: Add EP mode support for ls1088a and ls2088a
From: Xiaowei Bao @ 2019-08-28 3:25 UTC (permalink / raw)
To: Andrew Murray
Cc: christophe leroy, mark.rutland@arm.com, bhelgaas@google.com,
lorenzo.pieralisi@arm.co, arnd@arndb.de,
devicetree@vger.kernel.org, gregkh@linuxfoundation.org, Leo Li,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kishon@ti.com, M.h. Lian, robh+dt@kernel.org,
linux-arm-kernel@lists.infradead.org, Roy Zang,
jingoohan1@gmail.com, shawnguo@kernel.org,
gustavo.pimentel@synopsys.com, linuxppc-dev@lists.ozlabs.org,
Mingkai Hu
In-Reply-To: <20190827144830.GN14582@e119886-lin.cambridge.arm.com>
> -----Original Message-----
> From: Andrew Murray <andrew.murray@arm.com>
> Sent: 2019年8月27日 22:49
> To: Xiaowei Bao <xiaowei.bao@nxp.com>
> Cc: christophe leroy <christophe.leroy@c-s.fr>; mark.rutland@arm.com; Roy
> Zang <roy.zang@nxp.com>; 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
> <minghuan.lian@nxp.com>; robh+dt@kernel.org;
> gustavo.pimentel@synopsys.com; jingoohan1@gmail.com;
> bhelgaas@google.com; Leo Li <leoyang.li@nxp.com>; shawnguo@kernel.org;
> Mingkai Hu <mingkai.hu@nxp.com>; linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH v2 08/10] PCI: layerscape: Add EP mode support for
> ls1088a and ls2088a
>
> On Sun, Aug 25, 2019 at 03:07:32AM +0000, Xiaowei Bao wrote:
> >
> >
> > > -----Original Message-----
> > > From: christophe leroy <christophe.leroy@c-s.fr>
> > > Sent: 2019年8月24日 14:45
> > > To: Xiaowei Bao <xiaowei.bao@nxp.com>; Andrew Murray
> > > <andrew.murray@arm.com>
> > > Cc: mark.rutland@arm.com; Roy Zang <roy.zang@nxp.com>;
> > > 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 <minghuan.lian@nxp.com>; robh+dt@kernel.org;
> > > gustavo.pimentel@synopsys.com; jingoohan1@gmail.com;
> > > bhelgaas@google.com; Leo Li <leoyang.li@nxp.com>;
> > > shawnguo@kernel.org; Mingkai Hu <mingkai.hu@nxp.com>;
> > > linux-arm-kernel@lists.infradead.org
> > > Subject: Re: [PATCH v2 08/10] PCI: layerscape: Add EP mode support
> > > for ls1088a and ls2088a
> > >
> > >
> > >
> > > Le 24/08/2019 à 02:18, Xiaowei Bao a écrit :
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Andrew Murray <andrew.murray@arm.com>
> > > >> Sent: 2019年8月23日 22:28
> > > >> 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 08/10] PCI: layerscape: Add EP mode
> > > >> support for ls1088a and ls2088a
> > > >>
> > > >> On Thu, Aug 22, 2019 at 07:22:40PM +0800, Xiaowei Bao wrote:
> > > >>> Add PCIe EP mode support for ls1088a and ls2088a, there are some
> > > >>> difference between LS1 and LS2 platform, so refactor the code of
> > > >>> the EP driver.
> > > >>>
> > > >>> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > >>> ---
> > > >>> v2:
> > > >>> - New mechanism for layerscape EP driver.
> > > >>
> > > >> Was there a v1 of this patch?
> > > >
> > > > Yes, but I don't know how to comments, ^_^
> > >
> > > As far as I can see, in the previous version of the series
> > > (https://patch
> > >
> work.ozlabs.org%2Fproject%2Flinuxppc-dev%2Flist%2F%3Fseries%3D125315
> > > %26state%3D*&data=02%7C01%7Cxiaowei.bao%40nxp.com%7C1b
> efe9
> > >
> a67c8046f9535e08d7285eaab6%7C686ea1d3bc2b4c6fa92cd99c5c301635%
> > >
> 7C0%7C0%7C637022259387139020&sdata=p4wbycd04Z7qRUfAoZtwc
> > > UP7pR%2FuA3%2FjVcWMz6YyQVQ%3D&reserved=0),
> > > the 8/10 was something completely different, and I can't find any
> > > other patch in the series that could have been the v1 of this patch.
> >
> > Thanks, I will correct it to v1 in next version patch.
>
> I think you numbered it correctly (so please leave it as v2, referring to the
> patch series revision) - I got confused trying to find a previous version of this
> patch.
>
> Perhaps in the future when new patches are introduced in a series you can
> indicate that in the description patch revision history (e.g. introduced in v2).
OK, thanks for your help, I will update it in the next version patch.
Thanks
Xiaowei
>
> Thanks,
>
> Andrew Murray
>
> >
> > >
> > > Christophe
> > >
> > > >
> > > >>
> > > >>>
> > > >>> drivers/pci/controller/dwc/pci-layerscape-ep.c | 76
> > > >>> ++++++++++++++++++++------
> > > >>> 1 file changed, 58 insertions(+), 18 deletions(-)
> > > >>>
> > > >>> diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > >>> b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > >>> index 7ca5fe8..2a66f07 100644
> > > >>> --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > >>> +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > >>> @@ -20,27 +20,29 @@
> > > >>>
> > > >>> #define PCIE_DBI2_OFFSET 0x1000 /* DBI2 base address*/
> > > >>>
> > > >>> -struct ls_pcie_ep {
> > > >>> - struct dw_pcie *pci;
> > > >>> - struct pci_epc_features *ls_epc;
> > > >>> +#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > > >>> +
> > > >>> +struct ls_pcie_ep_drvdata {
> > > >>> + u32 func_offset;
> > > >>> + const struct dw_pcie_ep_ops *ops;
> > > >>> + const struct dw_pcie_ops *dw_pcie_ops;
> > > >>> };
> > > >>>
> > > >>> -#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > > >>> +struct ls_pcie_ep {
> > > >>> + struct dw_pcie *pci;
> > > >>> + struct pci_epc_features *ls_epc;
> > > >>> + const struct ls_pcie_ep_drvdata *drvdata; };
> > > >>>
> > > >>> static int ls_pcie_establish_link(struct dw_pcie *pci) {
> > > >>> return 0;
> > > >>> }
> > > >>>
> > > >>> -static const struct dw_pcie_ops ls_pcie_ep_ops = {
> > > >>> +static const struct dw_pcie_ops dw_ls_pcie_ep_ops = {
> > > >>> .start_link = ls_pcie_establish_link, };
> > > >>>
> > > >>> -static const struct of_device_id ls_pcie_ep_of_match[] = {
> > > >>> - { .compatible = "fsl,ls-pcie-ep",},
> > > >>> - { },
> > > >>> -};
> > > >>> -
> > > >>> static const struct pci_epc_features*
> > > >>> ls_pcie_ep_get_features(struct dw_pcie_ep *ep) { @@ -82,10
> > > >>> +84,44 @@ static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8
> func_no,
> > > >>> }
> > > >>> }
> > > >>>
> > > >>> -static const struct dw_pcie_ep_ops pcie_ep_ops = {
> > > >>> +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep
> *ep,
> > > >>> + u8 func_no)
> > > >>> +{
> > > >>> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > >>> + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> > > >>> + u8 header_type;
> > > >>> +
> > > >>> + header_type = ioread8(pci->dbi_base + PCI_HEADER_TYPE);
> > > >>> +
> > > >>> + if (header_type & (1 << 7))
> > > >>> + return pcie->drvdata->func_offset * func_no;
> > > >>> + else
> > > >>> + return 0;
> > > >>
> > > >> It looks like there isn't a PCI define for multi function, the
> > > >> nearest I could find was PCI_HEADER_TYPE_MULTIDEVICE in
> > > >> hotplug/ibmphp.h. A comment above the test might be helpful to
> > > >> explain
> > > the test.
> > > >
> > > > Yes, I have not find the PCI_HEADER_TYPE_MULTIDEVICE define. OK, I
> > > > will add The comments in next version patch.
> > > >
> > > >>
> > > >> As the ls_pcie_ep_drvdata structures are static, the unset
> > > >> .func_offset will be initialised to 0, so you could just drop the test
> above.
> > > >
> > > > OK, thanks
> > > >
> > > >>
> > > >> However something to the effect of the following may help spot
> > > >> misconfiguration:
> > > >>
> > > >> WARN_ON(func_no && !pcie->drvdata->func_offset); return
> > > >> pcie->drvdata->func_offset * func_no;
> > > >
> > > > Thanks a lot, this looks better.
> > > >
> > > >>
> > > >> The WARN is probably quite useful as if you are attempting to use
> > > >> non-zero functions and func_offset isn't set - then things may
> > > >> appear to work normally but actually will break horribly.
> > > >
> > > > got it, thanks.
> > > >
> > > >>
> > > >> Thanks,
> > > >>
> > > >> Andrew Murray
> > > >>
> > > >>> +}
> > > >>> +
> > > >>> +static const struct dw_pcie_ep_ops ls_pcie_ep_ops = {
> > > >>> .ep_init = ls_pcie_ep_init,
> > > >>> .raise_irq = ls_pcie_ep_raise_irq,
> > > >>> .get_features = ls_pcie_ep_get_features,
> > > >>> + .func_conf_select = ls_pcie_ep_func_conf_select, };
> > > >>> +
> > > >>> +static const struct ls_pcie_ep_drvdata ls1_ep_drvdata = {
> > > >>> + .ops = &ls_pcie_ep_ops,
> > > >>> + .dw_pcie_ops = &dw_ls_pcie_ep_ops, };
> > > >>> +
> > > >>> +static const struct ls_pcie_ep_drvdata ls2_ep_drvdata = {
> > > >>> + .func_offset = 0x20000,
> > > >>> + .ops = &ls_pcie_ep_ops,
> > > >>> + .dw_pcie_ops = &dw_ls_pcie_ep_ops, };
> > > >>> +
> > > >>> +static const struct of_device_id ls_pcie_ep_of_match[] = {
> > > >>> + { .compatible = "fsl,ls1046a-pcie-ep", .data = &ls1_ep_drvdata },
> > > >>> + { .compatible = "fsl,ls1088a-pcie-ep", .data = &ls2_ep_drvdata },
> > > >>> + { .compatible = "fsl,ls2088a-pcie-ep", .data = &ls2_ep_drvdata },
> > > >>> + { },
> > > >>> };
> > > >>>
> > > >>> static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie, @@
> > > >>> -98,7
> > > >>> +134,7 @@ static int __init ls_add_pcie_ep(struct ls_pcie_ep
> > > >>> +*pcie,
> > > >>> int ret;
> > > >>>
> > > >>> ep = &pci->ep;
> > > >>> - ep->ops = &pcie_ep_ops;
> > > >>> + ep->ops = pcie->drvdata->ops;
> > > >>>
> > > >>> res = platform_get_resource_byname(pdev,
> IORESOURCE_MEM,
> > > >> "addr_space");
> > > >>> if (!res)
> > > >>> @@ -137,14 +173,11 @@ static int __init ls_pcie_ep_probe(struct
> > > >> platform_device *pdev)
> > > >>> if (!ls_epc)
> > > >>> return -ENOMEM;
> > > >>>
> > > >>> - dbi_base = platform_get_resource_byname(pdev,
> > > IORESOURCE_MEM,
> > > >> "regs");
> > > >>> - pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> > > >>> - if (IS_ERR(pci->dbi_base))
> > > >>> - return PTR_ERR(pci->dbi_base);
> > > >>> + pcie->drvdata = of_device_get_match_data(dev);
> > > >>>
> > > >>> - pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
> > > >>> pci->dev = dev;
> > > >>> - pci->ops = &ls_pcie_ep_ops;
> > > >>> + pci->ops = pcie->drvdata->dw_pcie_ops;
> > > >>> +
> > > >>> pcie->pci = pci;
> > > >>>
> > > >>> ls_epc->linkup_notifier = false, @@ -152,6 +185,13 @@ static
> > > >>> int __init ls_pcie_ep_probe(struct platform_device *pdev)
> > > >>>
> > > >>> pcie->ls_epc = ls_epc;
> > > >>>
> > > >>> + dbi_base = platform_get_resource_byname(pdev,
> > > IORESOURCE_MEM,
> > > >> "regs");
> > > >>> + pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> > > >>> + if (IS_ERR(pci->dbi_base))
> > > >>> + return PTR_ERR(pci->dbi_base);
> > > >>> +
> > > >>> + pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
> > > >>> +
> > > >>> platform_set_drvdata(pdev, pcie);
> > > >>>
> > > >>> ret = ls_add_pcie_ep(pcie, pdev);
> > > >>> --
> > > >>> 2.9.5
> > > >>>
> > >
> > > ---
> > > L'absence de virus dans ce courrier électronique a été vérifiée par
> > > le logiciel antivirus Avast.
> > > https://www.
> > >
> avast.com%2Fantivirus&data=02%7C01%7Cxiaowei.bao%40nxp.com%7
> > >
> C1befe9a67c8046f9535e08d7285eaab6%7C686ea1d3bc2b4c6fa92cd99c5c3
> > >
> 01635%7C0%7C0%7C637022259387139020&sdata=JAYds7X%2FHVxgtrg
> > > e%2F%2FvnP84zdb2yReXcctQUiSLC11I%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 v4 0/8] Enable Linux guests on Hyper-V on ARM64
From: Michael Kelley @ 2019-08-28 3:33 UTC (permalink / raw)
To: will.deacon@arm.com, catalin.marinas@arm.com,
mark.rutland@arm.com, marc.zyngier@arm.com,
linux-arm-kernel@lists.infradead.org, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
devel@linuxdriverproject.org, olaf@aepfle.de, apw@canonical.com,
vkuznets, jasowang@redhat.com, marcelo.cerri@canonical.com,
KY Srinivasan
Cc: Sunil Muthuswamy, boqun.feng
In-Reply-To: <1565122133-9086-1-git-send-email-mikelley@microsoft.com>
From: Michael Kelley <mikelley@microsoft.com> Sent: Tuesday, August 6, 2019 1:31 PM
>
> This series enables Linux guests running on Hyper-V on ARM64
> hardware. New ARM64-specific code in arch/arm64/hyperv initializes
> Hyper-V, including its interrupts and hypercall mechanism.
> Existing architecture independent drivers for Hyper-V's VMbus and
> synthetic devices just work when built for ARM64. Hyper-V code is
> built and included in the image and modules only if CONFIG_HYPERV
> is enabled.
>
> The eight patches are organized as follows:
> 1) Add include files that define the Hyper-V interface as
> described in the Hyper-V Top Level Functional Spec (TLFS), plus
> additional definitions specific to Linux running on Hyper-V.
>
> 2 thru 6) Add core Hyper-V support on ARM64, including hypercalls,
> interrupt handlers, kexec & panic handlers, and core hypervisor
> initialization.
>
> 7) Update the existing VMbus driver to generalize interrupt
> management across x86/x64 and ARM64.
>
> 8) Make CONFIG_HYPERV selectable on ARM64 in addition to x86/x64.
>
I'm hoping to get some feedback from the ARM64 maintainers on this
series. Previous feedback has been incorporated, so it should be
close to being able to go in.
Michael
_______________________________________________
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