* Re: [PATCH] arm64: dts: hikey960: pinctrl: Fix spi2/spi3 pinconf
From: Wei Xu @ 2020-05-15 7:05 UTC (permalink / raw)
To: Loic Poulain, robh+dt; +Cc: linux-arm-kernel
In-Reply-To: <1585044472-16706-1-git-send-email-loic.poulain@linaro.org>
Hi Loic,
On 2020/3/24 18:07, Loic Poulain wrote:
> Only the pinmux was selected, not the pinconf, leading to spi issues.
> Increase drive strength so that max speed (25Mhz) can be achieved.
>
> Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Thanks!
Applied to the hisilicon arm64 dt tree.
Best Regards,
Wei
> ---
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 4 ++--
> arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi | 6 +++---
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> index 253cc34..c39b7898 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> @@ -974,7 +974,7 @@
> clocks = <&crg_ctrl HI3660_CLK_GATE_SPI2>;
> clock-names = "apb_pclk";
> pinctrl-names = "default";
> - pinctrl-0 = <&spi2_pmx_func>;
> + pinctrl-0 = <&spi2_pmx_func &spi2_cfg_func>;
> num-cs = <1>;
> cs-gpios = <&gpio27 2 0>;
> status = "disabled";
> @@ -989,7 +989,7 @@
> clocks = <&crg_ctrl HI3660_CLK_GATE_SPI3>;
> clock-names = "apb_pclk";
> pinctrl-names = "default";
> - pinctrl-0 = <&spi3_pmx_func>;
> + pinctrl-0 = <&spi3_pmx_func &spi3_cfg_func>;
> num-cs = <1>;
> cs-gpios = <&gpio18 5 0>;
> status = "disabled";
> diff --git a/arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi b/arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi
> index d11efc8..920a311 100644
> --- a/arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi
> @@ -717,7 +717,7 @@
> spi3_cfg_func: spi3_cfg_func {
> pinctrl-single,pins = <
> 0x008 0x0 /* SPI3_CLK */
> - 0x0 /* SPI3_DI */
> + 0x00c 0x0 /* SPI3_DI */
> 0x010 0x0 /* SPI3_DO */
> 0x014 0x0 /* SPI3_CS0_N */
> >;
> @@ -734,7 +734,7 @@
> PULL_UP
> >;
> pinctrl-single,drive-strength = <
> - DRIVE7_02MA DRIVE6_MASK
> + DRIVE7_06MA DRIVE6_MASK
> >;
> };
> };
> @@ -1031,7 +1031,7 @@
> PULL_UP
> >;
> pinctrl-single,drive-strength = <
> - DRIVE7_02MA DRIVE6_MASK
> + DRIVE7_06MA DRIVE6_MASK
> >;
> };
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 1/9] dmaengine: Actions: get rid of bit fields from dma descriptor
From: Vinod Koul @ 2020-05-15 6:58 UTC (permalink / raw)
To: Amit Tomer
Cc: Andre Przywara, linux-actions, cristian.ciocaltea,
Manivannan Sadhasivam, dmaengine, dan.j.williams,
Andreas Färber, linux-arm-kernel
In-Reply-To: <CABHD4K8F_sk3Xsevu4pMtR1jEanh5-dSATLYySPKW-nDY9fAvA@mail.gmail.com>
On 15-05-20, 00:04, Amit Tomer wrote:
> Hi,
>
> On Thu, May 14, 2020 at 11:58 PM Vinod Koul <vkoul@kernel.org> wrote:
> >
> > On 14-05-20, 21:40, Amit Singh Tomar wrote:
> > > At the moment, Driver uses bit fields to describe registers of the DMA
> > > descriptor structure that makes it less portable and maintainable, and
> > > Andre suugested(and even sketched important bits for it) to make use of
> > > array to describe this DMA descriptors instead. It gives the flexibility
> > > while extending support for other platform such as Actions S700.
> > >
> > > This commit removes the "owl_dma_lli_hw" (that includes bit-fields) and
> > > uses array to describe DMA descriptor.
> >
> > So i see patch 1/9 and 2/9 in my inbox... where are the rest ? No cover
> > to detail out what the rest contains, who should merge them etc etc!
and what is the answer for this..?
> >
> > If you are sending a series to different subsystem please make a habit
> > to CC everyone on cover letter so that we understand details about the
> > series. If not dependent, just send as individual units to subsystems!
>
> Ok, I would make note of it and Cc everyone on cover letter going forward.
>
> Thanks
> -Amit
--
~Vinod
_______________________________________________
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] dmaengine: imx-sdma: initialize all script addresses
From: Vinod Koul @ 2020-05-15 6:57 UTC (permalink / raw)
To: Sascha Hauer; +Cc: dmaengine, Robin Gong, linux-imx, kernel, linux-arm-kernel
In-Reply-To: <20200513060405.18685-1-s.hauer@pengutronix.de>
On 13-05-20, 08:04, Sascha Hauer wrote:
> The script addresses array increases with each new version. The driver
> initializes the array to -EINVAL initially, but only up to the size
> of the v1 array. Initialize the additional addresses for the newer
> versions as well. Without this unitialized values of the newer arrays
> are treated as valid.
Applied, thanks
--
~Vinod
_______________________________________________
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/5] PCI: uniphier: Add error message when failed to get phy
From: kbuild test robot @ 2020-05-15 6:51 UTC (permalink / raw)
To: Kunihiko Hayashi, Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han,
Gustavo Pimentel, Rob Herring, Masahiro Yamada
Cc: devicetree, kbuild-all, Kunihiko Hayashi, Masami Hiramatsu,
linux-pci, linux-kernel, Jassi Brar, linux-arm-kernel
In-Reply-To: <1589518105-18368-6-git-send-email-hayashi.kunihiko@socionext.com>
[-- Attachment #1: Type: text/plain, Size: 3606 bytes --]
Hi Kunihiko,
I love your patch! Perhaps something to improve:
[auto build test WARNING on pci/next]
[also build test WARNING on robh/for-next v5.7-rc5 next-20200514]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Kunihiko-Hayashi/PCI-uniphier-Add-features-for-UniPhier-PCIe-host-controller/20200515-125031
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
In file included from include/linux/device.h:15:0,
from include/linux/pci.h:37,
from drivers/pci/controller/dwc/pcie-uniphier.c:18:
drivers/pci/controller/dwc/pcie-uniphier.c: In function 'uniphier_pcie_probe':
>> drivers/pci/controller/dwc/pcie-uniphier.c:470:16: warning: format '%d' expects argument of type 'int', but argument 3 has type 'long int' [-Wformat=]
dev_err(dev, "Failed to get phy (%d)n", PTR_ERR(priv->phy));
^
include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt'
#define dev_fmt(fmt) fmt
^~~
>> drivers/pci/controller/dwc/pcie-uniphier.c:470:3: note: in expansion of macro 'dev_err'
dev_err(dev, "Failed to get phy (%d)n", PTR_ERR(priv->phy));
^~~~~~~
vim +470 drivers/pci/controller/dwc/pcie-uniphier.c
430
431 static int uniphier_pcie_probe(struct platform_device *pdev)
432 {
433 struct device *dev = &pdev->dev;
434 struct uniphier_pcie_priv *priv;
435 struct resource *res;
436 int ret;
437
438 priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
439 if (!priv)
440 return -ENOMEM;
441
442 priv->pci.dev = dev;
443 priv->pci.ops = &dw_pcie_ops;
444
445 res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbi");
446 priv->pci.dbi_base = devm_pci_remap_cfg_resource(dev, res);
447 if (IS_ERR(priv->pci.dbi_base))
448 return PTR_ERR(priv->pci.dbi_base);
449
450 res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
451 priv->pci.atu_base = devm_pci_remap_cfg_resource(dev, res);
452 if (IS_ERR(priv->pci.atu_base))
453 priv->pci.atu_base = NULL;
454
455 res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "link");
456 priv->base = devm_ioremap_resource(dev, res);
457 if (IS_ERR(priv->base))
458 return PTR_ERR(priv->base);
459
460 priv->clk = devm_clk_get(dev, NULL);
461 if (IS_ERR(priv->clk))
462 return PTR_ERR(priv->clk);
463
464 priv->rst = devm_reset_control_get_shared(dev, NULL);
465 if (IS_ERR(priv->rst))
466 return PTR_ERR(priv->rst);
467
468 priv->phy = devm_phy_optional_get(dev, "pcie-phy");
469 if (IS_ERR(priv->phy)) {
> 470 dev_err(dev, "Failed to get phy (%d)\n", PTR_ERR(priv->phy));
471 return PTR_ERR(priv->phy);
472 }
473
474 platform_set_drvdata(pdev, priv);
475
476 ret = uniphier_pcie_host_enable(priv);
477 if (ret)
478 return ret;
479
480 return uniphier_add_pcie_port(priv, pdev);
481 }
482
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 72245 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 1/6] dt-bindings: mfd: add Khadas Microcontroller bindings
From: Amit Kucheria @ 2020-05-15 6:42 UTC (permalink / raw)
To: Neil Armstrong
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux PM list, Daniel Lezcano, LKML, Srini Kandagatla,
linux-amlogic, Zhang Rui, Lee Jones, Rob Herring, lakml
In-Reply-To: <20200512132613.31507-2-narmstrong@baylibre.com>
On Tue, May 12, 2020 at 6:56 PM Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> This Microcontroller is present on the Khadas VIM1, VIM2, VIM3 and Edge
> boards.
>
> It has multiple boot control features like password check, power-on
> options, power-off control and system FAN control on recent boards.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
> ---
> .../devicetree/bindings/mfd/khadas,mcu.yaml | 44 +++++++++++++++++++
> 1 file changed, 44 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
>
> diff --git a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
> new file mode 100644
> index 000000000000..a3b976f101e8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
> @@ -0,0 +1,44 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/khadas,mcu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Khadas on-board Microcontroller Device Tree Bindings
> +
> +maintainers:
> + - Neil Armstrong <narmstrong@baylibre.com>
> +
> +description: |
> + Khadas embeds a microcontroller on their VIM and Edge boards adding some
> + system feature as PWM Fan control (for VIM2 rev14 or VIM3), User memory
> + storage, IR/Key resume control, system power LED control and more.
> +
> +properties:
> + compatible:
> + enum:
> + - khadas,mcu # MCU revision is discoverable
> +
> + "#cooling-cells": # Only needed for boards having FAN control feature
> + const: 2
> +
> + reg:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + khadas_mcu: system-controller@18 {
> + compatible = "khadas,mcu";
> + reg = <0x18>;
> + #cooling-cells = <2>;
> + };
> + };
> --
> 2.22.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 v2 3/6] thermal: add support for the MCU controlled FAN on Khadas boards
From: Amit Kucheria @ 2020-05-15 6:41 UTC (permalink / raw)
To: Neil Armstrong
Cc: Linux PM list, Daniel Lezcano, LKML, Srini Kandagatla,
linux-amlogic, Zhang Rui, lakml
In-Reply-To: <20200512132613.31507-4-narmstrong@baylibre.com>
On Tue, May 12, 2020 at 6:56 PM Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> The new Khadas VIM2 and VIM3 boards controls the cooling fan via the
> on-board microcontroller.
>
> This implements the FAN control as thermal devices and as cell of the Khadas
> MCU MFD driver.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> drivers/thermal/Kconfig | 10 ++
> drivers/thermal/Makefile | 1 +
> drivers/thermal/khadas_mcu_fan.c | 174 +++++++++++++++++++++++++++++++
> 3 files changed, 185 insertions(+)
> create mode 100644 drivers/thermal/khadas_mcu_fan.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 91af271e9bb0..72b3960cc5ac 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -490,4 +490,14 @@ config SPRD_THERMAL
> help
> Support for the Spreadtrum thermal sensor driver in the Linux thermal
> framework.
> +
> +config KHADAS_MCU_FAN_THERMAL
> + tristate "Khadas MCU controller FAN cooling support"
> + depends on OF || COMPILE_TEST
Could you add a depends on the some board/SoC Kconfig option here so
this doesn't show up for non-Amlogic/non-Khadas boards?
Looks OK otherwise.
> + select MFD_CORE
> + select REGMAP
> + help
> + If you say yes here you get support for the FAN controlled
> + by the Microcontroller found on the Khadas VIM boards.
> +
> endif
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 8c8ed7b79915..460428c2122c 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -60,3 +60,4 @@ obj-$(CONFIG_ZX2967_THERMAL) += zx2967_thermal.o
> obj-$(CONFIG_UNIPHIER_THERMAL) += uniphier_thermal.o
> obj-$(CONFIG_AMLOGIC_THERMAL) += amlogic_thermal.o
> obj-$(CONFIG_SPRD_THERMAL) += sprd_thermal.o
> +obj-$(CONFIG_KHADAS_MCU_FAN_THERMAL) += khadas_mcu_fan.o
> diff --git a/drivers/thermal/khadas_mcu_fan.c b/drivers/thermal/khadas_mcu_fan.c
> new file mode 100644
> index 000000000000..044d4aba8be2
> --- /dev/null
> +++ b/drivers/thermal/khadas_mcu_fan.c
> @@ -0,0 +1,174 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Khadas MCU Controlled FAN driver
> + *
> + * Copyright (C) 2020 BayLibre SAS
> + * Author(s): Neil Armstrong <narmstrong@baylibre.com>
> + */
> +
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/mfd/khadas-mcu.h>
> +#include <linux/regmap.h>
> +#include <linux/sysfs.h>
> +#include <linux/thermal.h>
> +
> +#define MAX_LEVEL 3
> +
> +struct khadas_mcu_fan_ctx {
> + struct khadas_mcu *mcu;
> + unsigned int level;
> + struct thermal_cooling_device *cdev;
> +};
> +
> +static int khadas_mcu_fan_set_level(struct khadas_mcu_fan_ctx *ctx,
> + unsigned int level)
> +{
> + int ret;
> +
> + ret = regmap_write(ctx->mcu->map, KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG,
> + level);
> + if (ret)
> + return ret;
> +
> + ctx->level = level;
> +
> + return 0;
> +}
> +
> +static int khadas_mcu_fan_get_max_state(struct thermal_cooling_device *cdev,
> + unsigned long *state)
> +{
> + struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
> +
> + if (!ctx)
> + return -EINVAL;
> +
> + *state = MAX_LEVEL;
> +
> + return 0;
> +}
> +
> +static int khadas_mcu_fan_get_cur_state(struct thermal_cooling_device *cdev,
> + unsigned long *state)
> +{
> + struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
> +
> + if (!ctx)
> + return -EINVAL;
> +
> + *state = ctx->level;
> +
> + return 0;
> +}
> +
> +static int
> +khadas_mcu_fan_set_cur_state(struct thermal_cooling_device *cdev,
> + unsigned long state)
> +{
> + struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
> +
> + if (!ctx || (state > MAX_LEVEL))
> + return -EINVAL;
> +
> + if (state == ctx->level)
> + return 0;
> +
> + return khadas_mcu_fan_set_level(ctx, state);
> +}
> +
> +static const struct thermal_cooling_device_ops khadas_mcu_fan_cooling_ops = {
> + .get_max_state = khadas_mcu_fan_get_max_state,
> + .get_cur_state = khadas_mcu_fan_get_cur_state,
> + .set_cur_state = khadas_mcu_fan_set_cur_state,
> +};
> +
> +static int khadas_mcu_fan_probe(struct platform_device *pdev)
> +{
> + struct khadas_mcu *mcu = dev_get_drvdata(pdev->dev.parent);
> + struct thermal_cooling_device *cdev;
> + struct device *dev = &pdev->dev;
> + struct khadas_mcu_fan_ctx *ctx;
> + int ret;
> +
> + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> + if (!ctx)
> + return -ENOMEM;
> + ctx->mcu = mcu;
> + platform_set_drvdata(pdev, ctx);
> +
> + cdev = devm_thermal_of_cooling_device_register(dev->parent,
> + dev->parent->of_node, "khadas-mcu-fan", ctx,
> + &khadas_mcu_fan_cooling_ops);
> + if (IS_ERR(cdev)) {
> + ret = PTR_ERR(cdev);
> + dev_err(dev,
> + "Failed to register khadas-mcu-fan as cooling device: %d\n",
> + ret);
> + return ret;
> + }
> + ctx->cdev = cdev;
> + thermal_cdev_update(cdev);
> +
> + return 0;
> +}
> +
> +static int khadas_mcu_fan_disable(struct device *dev)
> +{
> + struct khadas_mcu_fan_ctx *ctx = dev_get_drvdata(dev);
> + unsigned int level_save = ctx->level;
> + int ret;
> +
> + ret = khadas_mcu_fan_set_level(ctx, 0);
> + if (ret)
> + return ret;
> +
> + ctx->level = level_save;
> +
> + return 0;
> +}
> +
> +static void khadas_mcu_fan_shutdown(struct platform_device *pdev)
> +{
> + khadas_mcu_fan_disable(&pdev->dev);
> +}
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int khadas_mcu_fan_suspend(struct device *dev)
> +{
> + return khadas_mcu_fan_disable(dev);
> +}
> +
> +static int khadas_mcu_fan_resume(struct device *dev)
> +{
> + struct khadas_mcu_fan_ctx *ctx = dev_get_drvdata(dev);
> +
> + return khadas_mcu_fan_set_level(ctx, ctx->level);
> +}
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(khadas_mcu_fan_pm, khadas_mcu_fan_suspend,
> + khadas_mcu_fan_resume);
> +
> +static const struct platform_device_id khadas_mcu_fan_id_table[] = {
> + { .name = "khadas-mcu-fan-ctrl", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(platform, khadas_mcu_fan_id_table);
> +
> +static struct platform_driver khadas_mcu_fan_driver = {
> + .probe = khadas_mcu_fan_probe,
> + .shutdown = khadas_mcu_fan_shutdown,
> + .driver = {
> + .name = "khadas-mcu-fan-ctrl",
> + .pm = &khadas_mcu_fan_pm,
> + },
> + .id_table = khadas_mcu_fan_id_table,
> +};
> +
> +module_platform_driver(khadas_mcu_fan_driver);
> +
> +MODULE_AUTHOR("Neil Armstrong <narmstrong@baylibre.com>");
> +MODULE_DESCRIPTION("Khadas MCU FAN driver");
> +MODULE_LICENSE("GPL");
> --
> 2.22.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 v8 2/3] drivers: input: keyboard: Add mtk keypad driver
From: Fengping Yu @ 2020-05-15 6:20 UTC (permalink / raw)
To: Yingjoe Chen, Dmitry Torokhov, Andy Shevchenko, Marco Felsch
Cc: fengping.yu, linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <20200515062007.28346-1-fengping.yu@mediatek.com>
From: "fengping.yu" <fengping.yu@mediatek.com>
This adds matrix keypad support for Mediatek SoCs.
Signed-off-by: fengping.yu <fengping.yu@mediatek.com>
---
drivers/input/keyboard/Kconfig | 9 ++
drivers/input/keyboard/Makefile | 1 +
drivers/input/keyboard/mtk-kpd.c | 231 +++++++++++++++++++++++++++++++
3 files changed, 241 insertions(+)
create mode 100644 drivers/input/keyboard/mtk-kpd.c
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 28de965a08d5..2b42015e6923 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -782,6 +782,15 @@ config KEYBOARD_BCM
To compile this driver as a module, choose M here: the
module will be called bcm-keypad.
+config KEYBOARD_MTK_KPD
+ tristate "MediaTek Keypad Support"
+ depends on OF && HAVE_CLK
+ help
+ Say Y here if you want to use the keypad on MediaTek SoCs.
+ If unsure, say N.
+ To compile this driver as a module, choose M here: the
+ module will be called mtk-kpd.
+
config KEYBOARD_MTK_PMIC
tristate "MediaTek PMIC keys support"
depends on MFD_MT6397
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 1d689fdd5c00..6c9d852c377e 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_KEYBOARD_MATRIX) += matrix_keypad.o
obj-$(CONFIG_KEYBOARD_MAX7359) += max7359_keypad.o
obj-$(CONFIG_KEYBOARD_MCS) += mcs_touchkey.o
obj-$(CONFIG_KEYBOARD_MPR121) += mpr121_touchkey.o
+obj-$(CONFIG_KEYBOARD_MTK_KPD) += mtk-kpd.o
obj-$(CONFIG_KEYBOARD_MTK_PMIC) += mtk-pmic-keys.o
obj-$(CONFIG_KEYBOARD_NEWTON) += newtonkbd.o
obj-$(CONFIG_KEYBOARD_NOMADIK) += nomadik-ske-keypad.o
diff --git a/drivers/input/keyboard/mtk-kpd.c b/drivers/input/keyboard/mtk-kpd.c
new file mode 100644
index 000000000000..66c70c475ee2
--- /dev/null
+++ b/drivers/input/keyboard/mtk-kpd.c
@@ -0,0 +1,231 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 MediaTek Inc.
+ * Author Terry Chang <terry.chang@mediatek.com>
+ */
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <linux/input/matrix_keypad.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/property.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#define MTK_KPD_NAME "mtk-kpd"
+#define MTK_KPD_MEM 0x0004
+#define MTK_KPD_DEBOUNCE 0x0018
+#define MTK_KPD_DEBOUNCE_MASK GENMASK(13, 0)
+#define MTK_KPD_DEBOUNCE_MAX_US 256000 /*256ms */
+#define MTK_KPD_NUM_MEMS 5
+#define MTK_KPD_NUM_BITS 136 /* 4*32+8 MEM5 only use 8 BITS */
+
+struct mtk_keypad {
+ struct regmap *regmap;
+ struct input_dev *input_dev;
+ struct clk *clk;
+ void __iomem *base;
+ bool wakeup;
+ u32 n_rows;
+ u32 n_cols;
+ DECLARE_BITMAP(keymap_state, MTK_KPD_NUM_BITS);
+};
+
+static const struct regmap_config keypad_regmap_cfg = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = sizeof(u32),
+ .max_register = 36,
+};
+
+static irqreturn_t kpd_irq_handler(int irq, void *dev_id)
+{
+ struct mtk_keypad *keypad = dev_id;
+ unsigned short *keycode = keypad->input_dev->keycode;
+ DECLARE_BITMAP(new_state, MTK_KPD_NUM_BITS);
+ DECLARE_BITMAP(change, MTK_KPD_NUM_BITS);
+ int bit_nr;
+ int pressed;
+ unsigned short code;
+
+ regmap_raw_read(keypad->regmap, MTK_KPD_MEM, new_state, MTK_KPD_NUM_MEMS);
+
+ bitmap_xor(change, new_state, keypad->keymap_state, MTK_KPD_NUM_BITS);
+
+ for_each_set_bit(bit_nr, change, MTK_KPD_NUM_BITS) {
+ /* 1: not pressed, 0: pressed */
+ pressed = !test_bit(bit_nr, new_state);
+ dev_dbg(&keypad->input_dev->dev, "%s",
+ pressed ? "pressed" : "released");
+
+ /* 32bit register only use low 16bit as keypad mem register */
+ code = keycode[bit_nr - 16 * (BITS_TO_U32(bit_nr) - 1)];
+
+ input_report_key(keypad->input_dev, code, pressed);
+ input_sync(keypad->input_dev);
+
+ dev_dbg(&keypad->input_dev->dev,
+ "report Linux keycode = %d\n", code);
+ }
+
+ bitmap_copy(keypad->keymap_state, new_state, MTK_KPD_NUM_BITS);
+
+ return IRQ_HANDLED;
+}
+
+static int kpd_probe_clock(struct platform_device *pdev, struct clk *clk)
+{
+ int ret;
+
+ clk = devm_clk_get(&pdev->dev, "kpd");
+ if (IS_ERR(clk))
+ return clk;
+
+ ret = clk_prepare_enable(clk);
+ if (ret) {
+ dev_err(&pdev->dev, "cannot prepare/enable keypad clock\n");
+ return ret;
+ }
+
+ ret = devm_add_action_or_reset(&pdev->dev,
+ (void (*)(void *))clk_disable_unprepare,
+ clk);
+
+ return ret;
+}
+
+static int kpd_pdrv_probe(struct platform_device *pdev)
+{
+ struct mtk_keypad *keypad;
+ struct pinctrl *keypad_pinctrl;
+ struct pinctrl_state *kpd_default;
+ unsigned int irqnr;
+ u32 debounce;
+ int ret;
+
+ keypad = devm_kzalloc(&pdev->dev, sizeof(*keypad), GFP_KERNEL);
+ if (!keypad)
+ return -ENOMEM;
+
+ keypad->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(keypad->base))
+ return PTR_ERR(keypad->base);
+
+ keypad->regmap = devm_regmap_init_mmio(&pdev->dev,
+ keypad->base,
+ &keypad_regmap_cfg);
+ if (IS_ERR(keypad->regmap)) {
+ dev_err(&pdev->dev,
+ "regmap init failed:%ld\n", PTR_ERR(keypad->regmap));
+ return PTR_ERR(keypad->regmap);
+ }
+
+ bitmap_fill(keypad->keymap_state, MTK_KPD_NUM_BITS);
+
+ keypad->input_dev = devm_input_allocate_device(&pdev->dev);
+ if (!keypad->input_dev) {
+ dev_err(&pdev->dev, "Failed to allocate input dev\n");
+ return -ENOMEM;
+ }
+
+ keypad->input_dev->name = MTK_KPD_NAME;
+ keypad->input_dev->id.bustype = BUS_HOST;
+
+ ret = matrix_keypad_parse_properties(&pdev->dev, &keypad->n_rows,
+ &keypad->n_cols);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to parse keypad params\n");
+ return ret;
+ }
+
+ if (device_property_read_u32(&pdev->dev, "mediatek,debounce-us",
+ &debounce))
+ debounce = 16000;
+
+ if (debounce > MTK_KPD_DEBOUNCE_MAX_US) {
+ dev_err(&pdev->dev, "Debounce time exceeds the maximum allowed time 256ms\n");
+ return -EINVAL;
+ }
+
+ keypad->wakeup = device_property_read_bool(&pdev->dev, "wakeup-source");
+
+ dev_dbg(&pdev->dev, "n_row=%d n_col=%d debounce=%d\n",
+ keypad->n_rows, keypad->n_cols, debounce);
+
+ ret = matrix_keypad_build_keymap(NULL, NULL,
+ keypad->n_rows,
+ keypad->n_cols,
+ NULL,
+ keypad->input_dev);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to build keymap\n");
+ return ret;
+ }
+
+ input_set_drvdata(keypad->input_dev, keypad);
+
+ regmap_write(keypad->regmap, KP_DEBOUNCE,
+ debounce * 32 / 1000 & MTK_KPD_DEBOUNCE_MASK);
+
+ if (kpd_probe_clock(pdev, keypad->clk)) {
+ dev_err(&pdev->dev, "Failed to enable clock\n");
+ return ret;
+ }
+
+ keypad_pinctrl = devm_pinctrl_get(&pdev->dev);
+ if (IS_ERR(keypad_pinctrl))
+ return PTR_ERR(keypad_pinctrl);
+
+ kpd_default = pinctrl_lookup_state(keypad_pinctrl, "default");
+ if (IS_ERR(kpd_default)) {
+ dev_err(&pdev->dev, "No default pinctrl state\n");
+ return PTR_ERR(kpd_default);
+ }
+
+ pinctrl_select_state(keypad_pinctrl, kpd_default);
+
+ irqnr = platform_get_irq(pdev, 0);
+ if (irqnr < 0) {
+ dev_err(&pdev->dev, "Failed to get irq\n");
+ return -irqnr;
+ }
+
+ ret = devm_request_threaded_irq(&pdev->dev, irqnr,
+ NULL, kpd_irq_handler, 0,
+ MTK_KPD_NAME, keypad);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to request IRQ#%d:%d\n",
+ irqnr, ret);
+ return ret;
+ }
+
+ ret = input_register_device(keypad->input_dev);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to register device\n");
+ return ret;
+ }
+
+ device_init_wakeup(&pdev->dev, keypad->wakeup);
+
+ return 0;
+}
+
+static const struct of_device_id kpd_of_match[] = {
+ {.compatible = "mediatek, mt6779-keypad"},
+ {.compatible = "mediatek,kp"},
+ {/*sentinel*/}
+};
+
+static struct platform_driver kpd_pdrv = {
+ .probe = kpd_pdrv_probe,
+ .driver = {
+ .name = MTK_KPD_NAME,
+ .of_match_table = kpd_of_match,
+ },
+};
+module_platform_driver(kpd_pdrv);
+
+MODULE_AUTHOR("Mediatek Corporation");
+MODULE_DESCRIPTION("MTK Keypad (KPD) Driver");
+MODULE_LICENSE("GPL");
--
2.18.0
_______________________________________________
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] configs: defconfig: Add CONFIG_KEYBOARD_MTK_KPD=m
From: Fengping Yu @ 2020-05-15 6:20 UTC (permalink / raw)
To: Yingjoe Chen, Dmitry Torokhov, Andy Shevchenko, Marco Felsch
Cc: fengping.yu, linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <20200515062007.28346-1-fengping.yu@mediatek.com>
From: "fengping.yu" <fengping.yu@mediatek.com>
Add Mediatek matrix keypad support in defconfig.
Signed-off-by: fengping.yu <fengping.yu@mediatek.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 24e534d85045..112ced090b21 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -349,6 +349,7 @@ CONFIG_KEYBOARD_GPIO=y
CONFIG_KEYBOARD_SNVS_PWRKEY=m
CONFIG_KEYBOARD_IMX_SC_KEY=m
CONFIG_KEYBOARD_CROS_EC=y
+CONFIG_KEYBOARD_MTK_KPD=m
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ATMEL_MXT=m
CONFIG_INPUT_MISC=y
--
2.18.0
_______________________________________________
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] dt-bindings: Add keypad devicetree documentation
From: Fengping Yu @ 2020-05-15 6:20 UTC (permalink / raw)
To: Yingjoe Chen, Dmitry Torokhov, Andy Shevchenko, Marco Felsch
Cc: fengping.yu, linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <20200515062007.28346-1-fengping.yu@mediatek.com>
From: "fengping.yu" <fengping.yu@mediatek.com>
Add Mediatek matrix keypad dt-bindings doc as yaml schema.
Signed-off-by: fengping.yu <fengping.yu@mediatek.com>
---
.../devicetree/bindings/input/mtk-kpd.yaml | 94 +++++++++++++++++++
1 file changed, 94 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/mtk-kpd.yaml
diff --git a/Documentation/devicetree/bindings/input/mtk-kpd.yaml b/Documentation/devicetree/bindings/input/mtk-kpd.yaml
new file mode 100644
index 000000000000..d5068720e5b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/mtk-kpd.yaml
@@ -0,0 +1,94 @@
+%YAML 1.2
+---
+version: 1
+
+$id: http://devicetree.org/schemas/input/mtk-keypad.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek's Keypad Controller device tree bindings
+
+maintainer:
+ - Fengping Yu <fengping.yu@mediatek.com>
+
+description: |
+ Mediatek's Keypad controller is used to interface a SoC with a matrix-type
+ keypad device. The keypad controller supports multiple row and column lines.
+ A key can be placed at each intersection of a unique row and a unique column.
+ The keypad controller can sense a key-press and key-release and report the
+ event using a interrupt to the cpu.
+
+properties:
+ compatible:
+ oneOf:
+ - const: "mediatek,mt6779-keypad"
+ - const: "mediatek, kp"
+
+ clock-names:
+ description: Names of the clocks listed in clocks property in the same order
+ maxItems: 1
+
+ clocks:
+ description: Must contain one entry, for the module clock
+ refs: devicetree/bindings/clocks/clock-bindings.txt for details.
+
+ interrupts:
+ description: A single interrupt specifier
+ maxItems: 1
+
+ linux,keymap:
+ description: The keymap for keys as described in the binding document
+ refs: devicetree/bindings/input/matrix-keymap.txt
+ minItems: 1
+ maxItems: 16
+
+ pinctrl-0:
+ description: Specify pin control groups used for this controller
+ refs: devicetree/bindings/pinctrl/pinctrl-bindings.txt
+
+ pinctrl-names:
+ description: Names for optional pin modes
+ maxItems: 1
+
+ reg:
+ description: The base address of the Keypad register bank
+ maxItems: 1
+
+ wakeup-source:
+ description: use any event on keypad as wakeup event
+ type: boolean
+
+ keypad,num-columns:
+ description: Number of column lines connected to the keypad controller,
+ it is not equal to PCB columns number, instead you should add required value
+ for each IC
+
+ keypad,num-rows:
+ description: Number of row lines connected to the keypad controller, it is
+ not equal to PCB rows number, instead you should add required value for each IC
+
+ mediatek,debounce-us:
+ description: Debounce interval in microseconds
+ maximum: 256000
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - linux,keymap
+ - pinctrl
+ - clocks
+ - clock-names
+
+examples:
+ - |
+
+ keypad: kp@10010000 {
+ compatible = "mediatek,kp";
+ reg = <0 0x10010000 0 0x1000>;
+ linux,keymap = < MATRIX_KEY(0x00, 0x00, KEY_VOLUMEDOWN) >;
+ interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_FALLING>;
+ clocks = <&clk26m>;
+ clock-names = "kpd";
+ pinctrl-names = "default";
+ pinctrl-0 = <&kpd_gpios_def_cfg>;
+ };
--
2.18.0
_______________________________________________
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] Add matrix keypad driver support for Mediatek SoCs
From: Fengping Yu @ 2020-05-15 6:20 UTC (permalink / raw)
To: Yingjoe Chen, Dmitry Torokhov, Andy Shevchenko, Marco Felsch
Cc: linux-mediatek, linux-kernel, linux-arm-kernel
Change since v7:
- specify compatible property as const string
- add maxItem in required property
- squash keypad example nodes
- sort header file with alphabetic order
- align all define values and add MTK_ prefix to make more uniform
- change debounce value to default 16ms if not specified in dts
- remove extra braces
- separate clk prepare as an internal driver function
- add special compatible string
- modify CONFIG_KEYBOARD_MTK_KPD=m to build keypad as ko module
fengping.yu (3):
dt-bindings: Add keypad devicetree documentation
drivers: input: keyboard: Add mtk keypad driver
configs: defconfig: Add CONFIG_ng.yu (3):
dt-bindings: Add keypad devicetree documentation
drivers: input: keyboard: Add mtk keypad driver
configs: defconfig: Add CONFIG_KEYBOARD_MTK_KPD=m
.../devicetree/bindings/input/mtk-kpd.yaml | 94 +++++++
arch/arm64/configs/defconfig | 1 +
drivers/input/keyboard/Kconfig | 9 +
drivers/input/keyboard/Makefile | 1 +
drivers/input/keyboard/mtk-kpd.c | 231 ++++++++++++++++++
5 files changed, 336 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/mtk-kpd.yaml
create mode 100644 drivers/input/keyboard/mtk-kpd.c
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next] crypto: xilinx - Remove set but not used variable 'drv_ctx'
From: Herbert Xu @ 2020-05-15 6:15 UTC (permalink / raw)
To: YueHaibing
Cc: kernel-janitors, rajan.vaja, gregkh, yuehaibing, michal.simek,
hulkci, linux-crypto, kalyani.akula, jolly.shah, linux-arm-kernel
In-Reply-To: <20200505101200.195184-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/crypto/xilinx/zynqmp-aes-gcm.c: In function 'zynqmp_aes_aead_cipher':
> drivers/crypto/xilinx/zynqmp-aes-gcm.c:83:30: warning:
> variable 'drv_ctx' set but not used [-Wunused-but-set-variable]
>
> commit bc86f9c54616 ("firmware: xilinx: Remove eemi ops for aes engine") left
> behind this, remove it.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/crypto/xilinx/zynqmp-aes-gcm.c | 4 ----
> 1 file changed, 4 deletions(-)
This patch doesn't apply to the current cryptodev tree.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
_______________________________________________
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] dma: zynqmp_dma: Move list_del inside zynqmp_dma_free_descriptor.
From: Vinod Koul @ 2020-05-15 5:50 UTC (permalink / raw)
To: Rafał Hibner
Cc: Radhey Shyam Pandey, Michal Simek, linux-kernel,
Appana Durga Kedareswara rao, dmaengine, Harini Katakam,
Dan Williams, linux-arm-kernel
In-Reply-To: <20200506102844.2259-1-rafal.hibner@secom.com.pl>
On 06-05-20, 12:28, Rafał Hibner wrote:
> List elements are not formally removed from list during zynqmp_dma_reset.
Applied after fixing subsystem name to dmaengine, thanks
--
~Vinod
_______________________________________________
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 1/2] [media] mtk-mdp: add driver to probe mdp components
From: Eizan Miyamoto @ 2020-05-15 5:21 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Andrew-CT Chen, Minghsiu Tsai, Enric Balletbo Serra, LKML,
Houlong Wei, Eizan Miyamoto,
moderated list:ARM/Mediatek SoC support, Matthias Brugger,
Mauro Carvalho Chehab, Linux ARM, linux-media
In-Reply-To: <7eb1d912-9115-ecd6-f1ca-28ac5063bcf0@collabora.com>
On Thu, May 7, 2020 at 11:44 PM Enric Balletbo i Serra
<enric.balletbo@collabora.com> wrote:
>
> Hi Eizan,
>
> On 7/5/20 13:11, Eizan Miyamoto wrote:
> > On Thu, May 7, 2020 at 2:54 AM Enric Balletbo Serra <eballetbo@gmail.com> wrote:
> >>
> >> Hi Eizan,
> >>
> >> Thank you for the patch.
> >>
> >> Missatge de Eizan Miyamoto <eizan@chromium.org> del dia dc., 6 de maig
> >> 2020 a les 10:41:
> >>>
> >>> Broadly, this patch (1) adds a driver for various MTK MDP components to
> >>> go alongside the main MTK MDP driver, and (2) hooks them all together
> >>> using the component framework.
> >>>
> >>> (1) Up until now, the MTK MDP driver controls 8 devices in the device
> >>> tree on its own. When running tests for the hardware video decoder, we
> >>> found that the iommus and LARBs were not being properly configured. To
> >>> configure them, a driver for each be added to mtk_mdp_comp so that
> >>> mtk_iommu_add_device() can (eventually) be called from dma_configure()
> >>> inside really_probe().
> >>>
> >>> (2) The integration into the component framework allows us to defer the
> >>> registration with the v4l2 subsystem until all the MDP-related devices
> >>> have been probed, so that the relevant device node does not become
> >>> available until initialization of all the components is complete.
> >>>
> >>> Some notes about how the component framework has been integrated:
> >>>
> >>> - The driver for the rdma0 component serves double duty as the "master"
> >>> (aggregate) driver as well as a component driver. This is a non-ideal
> >>> compromise until a better solution is developed. This device is
> >>> differentiated from the rest by checking for a "mediatek,vpu" property
> >>> in the device node.
> >>>
> >>> - The list of mdp components remains hard-coded as mtk_mdp_comp_dt_ids[]
> >>> in mtk_mdp_core.c, and as mtk_mdp_comp_driver_dt_match[] in
> >>> mtk_mdp_comp.c. This unfortunate duplication of information is
> >>> addressed in a following patch in this series.
> >>>
> >>> - The component driver calls component_add() for each device that is
> >>> probed.
> >>>
> >>> - In mtk_mdp_probe (the "master" device), we scan the device tree for
> >>> any matching nodes against mtk_mdp_comp_dt_ids, and add component
> >>> matches for them. The match criteria is a matching device node
> >>> pointer.
> >>>
> >>> - When the set of components devices that have been probed corresponds
> >>> with the list that is generated by the "master", the callback to
> >>> mtk_mdp_master_bind() is made, which then calls the component bind
> >>> functions.
> >>>
> >>> - Inside mtk_mdp_master_bind(), once all the component bind functions
> >>> have been called, we can then register our device to the v4l2
> >>> subsystem.
> >>>
> >>> - The call to pm_runtime_enable() in the master device is called after
> >>> all the components have been registered by their bind() functions
> >>> called by mtk_mtp_master_bind(). As a result, the list of components
> >>> will not change while power management callbacks mtk_mdp_suspend()/
> >>> resume() are accessing the list of components.
> >>>
> >>> Signed-off-by: Eizan Miyamoto <eizan@chromium.org>
> >>> ---
> >>>
> >>> Changes in v2: None
> >>>
> >>
> >> Not really true :-)
> >>
> >>> drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 150 +++++++++++++--
> >>> drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 26 +--
> >>> drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 176 +++++++++++++-----
> >>> drivers/media/platform/mtk-mdp/mtk_mdp_core.h | 1 +
> >>> 4 files changed, 263 insertions(+), 90 deletions(-)
> >>>
> >>> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> >>> index 362fff924aef..5b4d482df778 100644
> >>> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> >>> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> >>> @@ -5,14 +5,53 @@
> >>> */
> >>>
> >>> #include <linux/clk.h>
> >>> +#include <linux/component.h>
> >>> #include <linux/device.h>
> >>> -#include <linux/of.h>
> >>> +#include <linux/module.h>
> >>> #include <linux/of_address.h>
> >>> +#include <linux/of_device.h>
> >>> +#include <linux/of.h>
> >>> +#include <linux/of_irq.h>
> >>> #include <linux/of_platform.h>
> >>> #include <soc/mediatek/smi.h>
> >>> +#include <linux/platform_device.h>
> >>>
> >>> #include "mtk_mdp_comp.h"
> >>> -
> >>> +#include "mtk_mdp_core.h"
> >>> +
> >>> +/**
> >>> + * enum mtk_mdp_comp_type - the MDP component
> >>> + * @MTK_MDP_RDMA: Read DMA
> >>> + * @MTK_MDP_RSZ: Reszer
> >>> + * @MTK_MDP_WDMA: Write DMA
> >>> + * @MTK_MDP_WROT: Write DMA with rotation
> >>> + * @MTK_MDP_COMP_TYPE_MAX: Placeholder for num elems in this enum
> >>> + */
> >>> +enum mtk_mdp_comp_type {
> >>> + MTK_MDP_RDMA,
> >>> + MTK_MDP_RSZ,
> >>> + MTK_MDP_WDMA,
> >>> + MTK_MDP_WROT,
> >>> + MTK_MDP_COMP_TYPE_MAX,
> >>> +};
> >>> +
> >>> +static const struct of_device_id mtk_mdp_comp_driver_dt_match[] = {
> >>> + {
> >>> + .compatible = "mediatek,mt8173-mdp-rdma",
> >>> + .data = (void *)MTK_MDP_RDMA
> >>> + }, {
> >>> + .compatible = "mediatek,mt8173-mdp-rsz",
> >>> + .data = (void *)MTK_MDP_RSZ
> >>> + }, {
> >>> + .compatible = "mediatek,mt8173-mdp-wdma",
> >>> + .data = (void *)MTK_MDP_WDMA
> >>> + }, {
> >>> + .compatible = "mediatek,mt8173-mdp-wrot",
> >>> + .data = (void *)MTK_MDP_WROT
> >>> + },
> >>> + { }
> >>> +};
> >>> +MODULE_DEVICE_TABLE(of, mtk_mdp_comp_driver_dt_match);
> >>>
> >>> void mtk_mdp_comp_clock_on(struct device *dev, struct mtk_mdp_comp *comp)
> >>> {
> >>> @@ -20,10 +59,14 @@ void mtk_mdp_comp_clock_on(struct device *dev, struct mtk_mdp_comp *comp)
> >>>
> >>> if (comp->larb_dev) {
> >>> err = mtk_smi_larb_get(comp->larb_dev);
> >>> - if (err)
> >>> + if (err) {
> >>> + enum mtk_mdp_comp_type comp_type =
> >>> + (enum mtk_mdp_comp_type)
> >>> + of_device_get_match_data(dev);
> >>> dev_err(dev,
> >>> "failed to get larb, err %d. type:%d\n",
> >>> - err, comp->type);
> >>> + err, comp_type);
> >>> + }
> >>> }
> >>>
> >>> for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
> >>> @@ -32,8 +75,8 @@ void mtk_mdp_comp_clock_on(struct device *dev, struct mtk_mdp_comp *comp)
> >>> err = clk_prepare_enable(comp->clk[i]);
> >>> if (err)
> >>> dev_err(dev,
> >>> - "failed to enable clock, err %d. type:%d i:%d\n",
> >>> - err, comp->type, i);
> >>> + "failed to enable clock, err %d. i:%d\n",
> >>> + err, i);
> >>> }
> >>> }
> >>>
> >>> @@ -51,16 +94,41 @@ void mtk_mdp_comp_clock_off(struct device *dev, struct mtk_mdp_comp *comp)
> >>> mtk_smi_larb_put(comp->larb_dev);
> >>> }
> >>>
> >>> -int mtk_mdp_comp_init(struct device *dev, struct device_node *node,
> >>> - struct mtk_mdp_comp *comp,
> >>> - enum mtk_mdp_comp_type comp_type)
> >>> +static int mtk_mdp_comp_bind(struct device *dev, struct device *master,
> >>> + void *data)
> >>> +{
> >>> + struct mtk_mdp_comp *comp = dev_get_drvdata(dev);
> >>> + struct mtk_mdp_dev *mdp = data;
> >>> +
> >>> + mtk_mdp_register_component(mdp, comp);
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static void mtk_mdp_comp_unbind(struct device *dev, struct device *master,
> >>> + void *data)
> >>> +{
> >>> + struct mtk_mdp_dev *mdp = data;
> >>> + struct mtk_mdp_comp *comp = dev_get_drvdata(dev);
> >>> +
> >>> + mtk_mdp_unregister_component(mdp, comp);
> >>> +}
> >>> +
> >>> +static const struct component_ops mtk_mdp_component_ops = {
> >>> + .bind = mtk_mdp_comp_bind,
> >>> + .unbind = mtk_mdp_comp_unbind,
> >>> +};
> >>> +
> >>> +int mtk_mdp_comp_init(struct mtk_mdp_comp *comp, struct device *dev)
> >>> {
> >>> struct device_node *larb_node;
> >>> struct platform_device *larb_pdev;
> >>> int i;
> >>> + struct device_node *node = dev->of_node;
> >>> + enum mtk_mdp_comp_type comp_type =
> >>> + (enum mtk_mdp_comp_type)of_device_get_match_data(dev);
> >>>
> >>> - comp->dev_node = of_node_get(node);
> >>> - comp->type = comp_type;
> >>> + INIT_LIST_HEAD(&comp->node);
> >>>
> >>> for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
> >>> comp->clk[i] = of_clk_get(node, i);
> >>> @@ -72,15 +140,15 @@ int mtk_mdp_comp_init(struct device *dev, struct device_node *node,
> >>> }
> >>>
> >>> /* Only RDMA needs two clocks */
> >>> - if (comp->type != MTK_MDP_RDMA)
> >>> + if (comp_type != MTK_MDP_RDMA)
> >>> break;
> >>> }
> >>>
> >>> /* Only DMA capable components need the LARB property */
> >>> comp->larb_dev = NULL;
> >>> - if (comp->type != MTK_MDP_RDMA &&
> >>> - comp->type != MTK_MDP_WDMA &&
> >>> - comp->type != MTK_MDP_WROT)
> >>> + if (comp_type != MTK_MDP_RDMA &&
> >>> + comp_type != MTK_MDP_WDMA &&
> >>> + comp_type != MTK_MDP_WROT)
> >>> return 0;
> >>>
> >>> larb_node = of_parse_phandle(node, "mediatek,larb", 0);
> >>> @@ -103,7 +171,55 @@ int mtk_mdp_comp_init(struct device *dev, struct device_node *node,
> >>> return 0;
> >>> }
> >>>
> >>> -void mtk_mdp_comp_deinit(struct device *dev, struct mtk_mdp_comp *comp)
> >>> +static int mtk_mdp_comp_probe(struct platform_device *pdev)
> >>> +{
> >>> + struct device *dev = &pdev->dev;
> >>> + struct device_node *vpu_node;
> >>> + int status;
> >>> + struct mtk_mdp_comp *comp;
> >>> +
> >>> + vpu_node = of_parse_phandle(dev->of_node, "mediatek,vpu", 0);
> >>> + if (vpu_node) {
> >>> + of_node_put(vpu_node);
> >>> + /*
> >>> + * The device tree node with a mediatek,vpu property is deemed
> >>> + * the MDP "master" device, we don't want to add a component
> >>> + * for it in this function because the initialization for the
> >>> + * master is done elsewhere.
> >>> + */
> >>> + dev_info(dev, "vpu node found, not probing\n");
> >>
> >> Could you explain a bit more this? When this can happen? I am
> >> wondering if you are trying to solve a non-existing problem upstream.
> >
> > That line of code will be executed when probing for the rdma@14001000
> > device, for which the probe function in mtk_mdp_core.c will also be run
> > because there is a second '.compatible' string ("mediatek,mt8173-mdp") in
> > that device node.
> >
>
> Shouldn't we remove that second compatible then? (I don't think we break
> compatibility, so should be safe)
Hmm, it is possible to remove it, but then I think we will need to add
similar logic to the probe() function in mtk_mdp_core to return early as well
but when the vpu node is *not* found. My rationale is that there are two
device nodes with a .compatible = "mediatek,mt8173-mdp-rdma" property:
rdma@14001000 and rdma@14002000 and so the probe functions for the different
drivers need to be careful about what device they run for.
On the other hand, I wonder if our effort is better spent splitting the
rdma@14001000 into two: one for a component device that retains just
a .compatible = "mediatek,mt8173-mdp-rdma", and another for an aggregate
that contains a .compatible = "mediatek,mt8173-mdp". If we go this way, I
propose we do it in a subsequent change.
>
> FWIW I didn't see this message on my tests on Elm, do you know why?
I think the reason is that the probe function in mtk_mdp_core.c is (by
happenstance) called first, and because it succeeds, the probe function in
mtk_mdp_comp.c won't get called for that device node.
Specifically, __driver_attach only calls driver_probe_device (through
__driver_attach_async_helper) if dev->driver is NULL. dev->driver is set
before the probe function is called from really_probe, and if the probe
function fails, dev->driver is set to NULL.
>
> > In the probe function in mtk_mdp_core.c, a component is initialized, which
> > is component_add()ed separately by the master_bind function and so we don't
> > need to go through the component creation/initialization/addition done
> > here.
> >
> > I think, ideally, the master component wouldn't also be responsible for
> > rdma@14001000 and we would split apart the device node. I'd like to propose
> > that we work on that in a follow-up change while we make incremental
> > progress. (There are also other changes we'd like to propose in the
> > meantime, like not hard-coding the components that the master binds
> > together into the driver but instead make it possible to specify that in
> > the device tree itself).
> >
> >>
> >>> + return -ENODEV;
> >>> + }
> >>> +
> >>> + comp = devm_kzalloc(dev, sizeof(*comp), GFP_KERNEL);
> >>> + if (!comp)
> >>> + return -ENOMEM;
> >>> +
> >>> + status = mtk_mdp_comp_init(comp, dev);
> >>> + if (status) {
> >>> + dev_err(dev, "Failed to initialize component: %d\n", status);
> >>> + return status;
> >>> + }
> >>> +
> >>> + dev_set_drvdata(dev, comp);
> >>> +
> >>> + return component_add(dev, &mtk_mdp_component_ops);
> >>> +}
> >>> +
> >>> +static int mtk_mdp_comp_remove(struct platform_device *pdev)
> >>> {
> >>> - of_node_put(comp->dev_node);
> >>> + struct device *dev = &pdev->dev;
> >>> +
> >>> + component_del(dev, &mtk_mdp_component_ops);
> >>> + return 0;
> >>> }
> >>> +
> >>> +struct platform_driver mtk_mdp_component_driver = {
> >>> + .probe = mtk_mdp_comp_probe,
> >>> + .remove = mtk_mdp_comp_remove,
> >>> + .driver = {
> >>> + .name = "mediatek-mdp-comp",
> >>> + .owner = THIS_MODULE,
> >>> + .of_match_table = mtk_mdp_comp_driver_dt_match,
> >>> + },
> >>> +};
> >>> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> >>> index 1bf0242cce46..b5a18fe567aa 100644
> >>> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> >>> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> >>> @@ -7,43 +7,23 @@
> >>> #ifndef __MTK_MDP_COMP_H__
> >>> #define __MTK_MDP_COMP_H__
> >>>
> >>> -/**
> >>> - * enum mtk_mdp_comp_type - the MDP component
> >>> - * @MTK_MDP_RDMA: Read DMA
> >>> - * @MTK_MDP_RSZ: Riszer
> >>> - * @MTK_MDP_WDMA: Write DMA
> >>> - * @MTK_MDP_WROT: Write DMA with rotation
> >>> - */
> >>> -enum mtk_mdp_comp_type {
> >>> - MTK_MDP_RDMA,
> >>> - MTK_MDP_RSZ,
> >>> - MTK_MDP_WDMA,
> >>> - MTK_MDP_WROT,
> >>> - MTK_MDP_COMP_TYPE_MAX,
> >>> -};
> >>> -
> >>> /**
> >>> * struct mtk_mdp_comp - the MDP's function component data
> >>> * @node: list node to track sibing MDP components
> >>> - * @dev_node: component device node
> >>> * @clk: clocks required for component
> >>> * @larb_dev: SMI device required for component
> >>> - * @type: component type
> >>> */
> >>> struct mtk_mdp_comp {
> >>> struct list_head node;
> >>> - struct device_node *dev_node;
> >>> struct clk *clk[2];
> >>> struct device *larb_dev;
> >>> - enum mtk_mdp_comp_type type;
> >>> };
> >>>
> >>> -int mtk_mdp_comp_init(struct device *dev, struct device_node *node,
> >>> - struct mtk_mdp_comp *comp,
> >>> - enum mtk_mdp_comp_type comp_type);
> >>> -void mtk_mdp_comp_deinit(struct device *dev, struct mtk_mdp_comp *comp);
> >>> +int mtk_mdp_comp_init(struct mtk_mdp_comp *comp, struct device *dev);
> >>> +
> >>> void mtk_mdp_comp_clock_on(struct device *dev, struct mtk_mdp_comp *comp);
> >>> void mtk_mdp_comp_clock_off(struct device *dev, struct mtk_mdp_comp *comp);
> >>>
> >>> +extern struct platform_driver mtk_mdp_component_driver;
> >>>
> >>> #endif /* __MTK_MDP_COMP_H__ */
> >>> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> >>> index acbc5a01ae4c..539a7942e3cb 100644
> >>> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> >>> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> >>> @@ -6,6 +6,7 @@
> >>> */
> >>>
> >>> #include <linux/clk.h>
> >>> +#include <linux/component.h>
> >>> #include <linux/device.h>
> >>> #include <linux/errno.h>
> >>> #include <linux/interrupt.h>
> >>> @@ -19,6 +20,7 @@
> >>> #include <linux/workqueue.h>
> >>> #include <soc/mediatek/smi.h>
> >>>
> >>> +#include "mtk_mdp_comp.h"
> >>> #include "mtk_mdp_core.h"
> >>> #include "mtk_mdp_m2m.h"
> >>> #include "mtk_vpu.h"
> >>> @@ -32,16 +34,12 @@ module_param(mtk_mdp_dbg_level, int, 0644);
> >>> static const struct of_device_id mtk_mdp_comp_dt_ids[] = {
> >>> {
> >>> .compatible = "mediatek,mt8173-mdp-rdma",
> >>> - .data = (void *)MTK_MDP_RDMA
> >>> }, {
> >>> .compatible = "mediatek,mt8173-mdp-rsz",
> >>> - .data = (void *)MTK_MDP_RSZ
> >>> }, {
> >>> .compatible = "mediatek,mt8173-mdp-wdma",
> >>> - .data = (void *)MTK_MDP_WDMA
> >>> }, {
> >>> .compatible = "mediatek,mt8173-mdp-wrot",
> >>> - .data = (void *)MTK_MDP_WROT
> >>> },
> >>> { },
> >>> };
> >>> @@ -91,6 +89,64 @@ static void mtk_mdp_reset_handler(void *priv)
> >>> queue_work(mdp->wdt_wq, &mdp->wdt_work);
> >>> }
> >>>
> >>> +static int compare_of(struct device *dev, void *data)
> >>> +{
> >>> + return dev->of_node == data;
> >>> +}
> >>> +
> >>> +static void release_of(struct device *dev, void *data)
> >>> +{
> >>> + of_node_put(data);
> >>> +}
> >>> +
> >>> +static int mtk_mdp_master_bind(struct device *dev)
> >>> +{
> >>> + int status;
> >>> + struct mtk_mdp_dev *mdp = dev_get_drvdata(dev);
> >>> +
> >>> + mtk_mdp_register_component(mdp, &mdp->comp_self);
> >>> +
> >>> + status = component_bind_all(dev, mdp);
> >>> + if (status) {
> >>> + dev_err(dev, "Failed to bind all components: %d\n", status);
> >>> + goto err_component_bind_all;
> >>> + }
> >>> +
> >>> + status = mtk_mdp_register_m2m_device(mdp);
> >>> + if (status) {
> >>> + dev_err(dev, "Failed to register m2m device: %d\n", status);
> >>> + v4l2_err(&mdp->v4l2_dev, "Failed to init mem2mem device\n");
> >>> + goto err_mtk_mdp_register_m2m_device;
> >>> + }
> >>> +
> >>> + pm_runtime_enable(dev);
> >>> +
> >>> + return 0;
> >>> +
> >>> +err_mtk_mdp_register_m2m_device:
> >>> + component_unbind_all(dev, mdp);
> >>> +
> >>> +err_component_bind_all:
> >>> + mtk_mdp_unregister_component(mdp, &mdp->comp_self);
> >>> +
> >>> + return status;
> >>> +}
> >>> +
> >>> +static void mtk_mdp_master_unbind(struct device *dev)
> >>> +{
> >>> + struct mtk_mdp_dev *mdp = dev_get_drvdata(dev);
> >>> +
> >>> + pm_runtime_disable(dev);
> >>> + mtk_mdp_unregister_m2m_device(mdp);
> >>> + component_unbind_all(dev, mdp);
> >>> + mtk_mdp_unregister_component(mdp, &mdp->comp_self);
> >>> +}
> >>> +
> >>> +static const struct component_master_ops mtk_mdp_com_ops = {
> >>> + .bind = mtk_mdp_master_bind,
> >>> + .unbind = mtk_mdp_master_unbind,
> >>> +};
> >>> +
> >>> void mtk_mdp_register_component(struct mtk_mdp_dev *mdp,
> >>> struct mtk_mdp_comp *comp)
> >>> {
> >>> @@ -108,8 +164,8 @@ static int mtk_mdp_probe(struct platform_device *pdev)
> >>> struct mtk_mdp_dev *mdp;
> >>> struct device *dev = &pdev->dev;
> >>> struct device_node *node, *parent;
> >>> - struct mtk_mdp_comp *comp, *comp_temp;
> >>> - int ret = 0;
> >>> + int i, ret = 0;
> >>> + struct component_match *match = NULL;
> >>>
> >>> mdp = devm_kzalloc(dev, sizeof(*mdp), GFP_KERNEL);
> >>> if (!mdp)
> >>> @@ -134,37 +190,43 @@ static int mtk_mdp_probe(struct platform_device *pdev)
> >>> }
> >>>
> >>> /* Iterate over sibling MDP function blocks */
> >>> + i = 0;
> >>> for_each_child_of_node(parent, node) {
> >>> - const struct of_device_id *of_id;
> >>> - enum mtk_mdp_comp_type comp_type;
> >>> + struct platform_device *pdev;
> >>>
> >>> - of_id = of_match_node(mtk_mdp_comp_dt_ids, node);
> >>> - if (!of_id)
> >>> + if (!of_match_node(mtk_mdp_comp_dt_ids, node))
> >>> continue;
> >>>
> >>> - if (!of_device_is_available(node)) {
> >>> - dev_err(dev, "Skipping disabled component %pOF\n",
> >>> - node);
> >>> + if (!of_device_is_available(node))
> >>> continue;
> >>> - }
> >>> -
> >>> - comp_type = (enum mtk_mdp_comp_type)of_id->data;
> >>>
> >>> -
> >>> - comp = devm_kzalloc(dev, sizeof(*comp), GFP_KERNEL);
> >>> - if (!comp) {
> >>> - ret = -ENOMEM;
> >>> - of_node_put(node);
> >>> - goto err_comp;
> >>> + pdev = of_find_device_by_node(node);
> >>> + if (!pdev) {
> >>> + dev_warn(dev, "Unable to find comp device %s\n",
> >>> + node->full_name);
> >>> + continue;
> >>> }
> >>>
> >>> - ret = mtk_mdp_comp_init(dev, node, comp, comp_type);
> >>> - if (ret) {
> >>> - of_node_put(node);
> >>> - goto err_comp;
> >>> + /*
> >>> + * Do not add add a match for my own (rdma0) device node.
> >>> + * I will be managing it directly instead using comp_self.
> >>> + */
> >>> + if (&pdev->dev != dev) {
> >>> + dev_dbg(dev, "adding match %d for: %pOF\n", i++, node);
> >>> + component_match_add_release(dev, &match, release_of,
> >>> + compare_of,
> >>> + of_node_get(node));
> >>> }
> >>> + }
> >>>
> >>> - mtk_mdp_register_component(mdp, comp);
> >>> + /*
> >>> + * Create a component for myself so that clocks can be toggled in
> >>> + * clock_on().
> >>> + */
> >>> + ret = mtk_mdp_comp_init(&mdp->comp_self, dev);
> >>> + if (ret) {
> >>> + dev_err(dev, "Failed to initialize component\n");
> >>> + goto err_comp;
> >>> }
> >>>
> >>> mdp->job_wq = create_singlethread_workqueue(MTK_MDP_MODULE_NAME);
> >>> @@ -189,18 +251,12 @@ static int mtk_mdp_probe(struct platform_device *pdev)
> >>> goto err_dev_register;
> >>> }
> >>>
> >>> - ret = mtk_mdp_register_m2m_device(mdp);
> >>> - if (ret) {
> >>> - v4l2_err(&mdp->v4l2_dev, "Failed to init mem2mem device\n");
> >>> - goto err_m2m_register;
> >>> - }
> >>> -
> >>> mdp->vpu_dev = vpu_get_plat_device(pdev);
> >>> ret = vpu_wdt_reg_handler(mdp->vpu_dev, mtk_mdp_reset_handler, mdp,
> >>> VPU_RST_MDP);
> >>> if (ret) {
> >>> dev_err(&pdev->dev, "Failed to register reset handler\n");
> >>> - goto err_m2m_register;
> >>> + goto err_wdt_reg;
> >>> }
> >>>
> >>> platform_set_drvdata(pdev, mdp);
> >>> @@ -208,15 +264,25 @@ static int mtk_mdp_probe(struct platform_device *pdev)
> >>> ret = vb2_dma_contig_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
> >>> if (ret) {
> >>> dev_err(&pdev->dev, "Failed to set vb2 dma mag seg size\n");
> >>> - goto err_m2m_register;
> >>> + goto err_set_max_seg_size;
> >>> + }
> >>> +
> >>> + ret = component_master_add_with_match(dev, &mtk_mdp_com_ops, match);
> >>> + if (ret) {
> >>> + dev_err(dev, "Component master add failed\n");
> >>> + goto err_component_master_add;
> >>> }
> >>>
> >>> - pm_runtime_enable(dev);
> >>> dev_dbg(dev, "mdp-%d registered successfully\n", mdp->id);
> >>>
> >>> return 0;
> >>>
> >>> -err_m2m_register:
> >>> +err_component_master_add:
> >>> + vb2_dma_contig_clear_max_seg_size(&pdev->dev);
> >>> +
> >>> +err_set_max_seg_size:
> >>> +
> >>> +err_wdt_reg:
> >>
> >> No need for two labels here, rework the above goto logic.
> >>
> >>> v4l2_device_unregister(&mdp->v4l2_dev);
> >>>
> >>> err_dev_register:
> >>> @@ -228,11 +294,6 @@ static int mtk_mdp_probe(struct platform_device *pdev)
> >>> err_alloc_job_wq:
> >>>
> >>> err_comp:
> >>> - list_for_each_entry_safe(comp, comp_temp, &mdp->comp_list, node) {
> >>> - mtk_mdp_unregister_component(mdp, comp);
> >>> - mtk_mdp_comp_deinit(dev, comp);
> >>> - }
> >>> -
> >>> dev_dbg(dev, "err %d\n", ret);
> >>> return ret;
> >>> }
> >>> @@ -240,11 +301,10 @@ static int mtk_mdp_probe(struct platform_device *pdev)
> >>> static int mtk_mdp_remove(struct platform_device *pdev)
> >>> {
> >>> struct mtk_mdp_dev *mdp = platform_get_drvdata(pdev);
> >>> - struct mtk_mdp_comp *comp, *comp_temp;
> >>>
> >>> - pm_runtime_disable(&pdev->dev);
> >>> + component_master_del(&pdev->dev, &mtk_mdp_com_ops);
> >>> +
> >>> vb2_dma_contig_clear_max_seg_size(&pdev->dev);
> >>> - mtk_mdp_unregister_m2m_device(mdp);
> >>> v4l2_device_unregister(&mdp->v4l2_dev);
> >>>
> >>> flush_workqueue(mdp->wdt_wq);
> >>> @@ -253,10 +313,8 @@ static int mtk_mdp_remove(struct platform_device *pdev)
> >>> flush_workqueue(mdp->job_wq);
> >>> destroy_workqueue(mdp->job_wq);
> >>>
> >>> - list_for_each_entry_safe(comp, comp_temp, &mdp->comp_list, node) {
> >>> - mtk_mdp_unregister_component(mdp, comp);
> >>> - mtk_mdp_comp_deinit(&pdev->dev, comp);
> >>> - }
> >>> + if (!list_empty(&mdp->comp_list))
> >>> + dev_err(&pdev->dev, "not all components removed\n");
> >>>
> >>> dev_dbg(&pdev->dev, "%s driver unloaded\n", pdev->name);
> >>> return 0;
> >>> @@ -311,7 +369,25 @@ static struct platform_driver mtk_mdp_driver = {
> >>> }
> >>> };
> >>>
> >>> -module_platform_driver(mtk_mdp_driver);
> >>> +static struct platform_driver * const mtk_mdp_drivers[] = {
> >>> + &mtk_mdp_driver,
> >>> + &mtk_mdp_component_driver,
> >>> +};
> >>> +
> >>> +static int __init mtk_mdp_init(void)
> >>> +{
> >>> + return platform_register_drivers(mtk_mdp_drivers,
> >>> + ARRAY_SIZE(mtk_mdp_drivers));
> >>> +}
> >>> +
> >>> +static void __exit mtk_mdp_exit(void)
> >>> +{
> >>> + platform_unregister_drivers(mtk_mdp_drivers,
> >>> + ARRAY_SIZE(mtk_mdp_drivers));
> >>> +}
> >>> +
> >>> +module_init(mtk_mdp_init);
> >>> +module_exit(mtk_mdp_exit);
> >>>
> >>> MODULE_AUTHOR("Houlong Wei <houlong.wei@mediatek.com>");
> >>> MODULE_DESCRIPTION("Mediatek image processor driver");
> >>> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> >>> index a7da14b97077..230f531400ca 100644
> >>> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> >>> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> >>> @@ -155,6 +155,7 @@ struct mtk_mdp_dev {
> >>> struct mtk_mdp_variant *variant;
> >>> u16 id;
> >>> struct list_head comp_list;
> >>> + struct mtk_mdp_comp comp_self;
> >>> struct v4l2_m2m_dev *m2m_dev;
> >>> struct list_head ctx_list;
> >>> struct video_device *vdev;
> >>> --
> >>> 2.26.2.526.g744177e7f7-goog
> >>>
> >>>
> >>> _______________________________________________
> >>> Linux-mediatek mailing list
> >>> Linux-mediatek@lists.infradead.org
> >>> http://lists.infradead.org/mailman/listinfo/linux-mediatek
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Viresh Kumar @ 2020-05-15 5:17 UTC (permalink / raw)
To: Jassi Brar, Arnd Bergmann, Rob Herring, Frank Rowand
Cc: devicetree, Viresh Kumar, linux-kernel, Bjorn Andersson,
Sudeep Holla, linux-arm-kernel
From: Sudeep Holla <sudeep.holla@arm.com>
Hi Rob, Arnd and Jassi,
This stuff has been doing rounds on the mailing list since several years
now with no agreed conclusion by all the parties. And here is another
attempt to get some feedback from everyone involved to close this once
and for ever. Your comments will very much be appreciated.
The ARM MHU is defined here in the TRM [1] for your reference, which
states following:
"The MHU drives the signal using a 32-bit register, with all 32
bits logically ORed together. The MHU provides a set of
registers to enable software to set, clear, and check the status
of each of the bits of this register independently. The use of
32 bits for each interrupt line enables software to provide more
information about the source of the interrupt. For example, each
bit of the register can be associated with a type of event that
can contribute to raising the interrupt."
On few other platforms, like qcom, similar doorbell mechanism is present
with separate interrupt for each of the bits (that's how I understood
it), while in case of ARM MHU, there is a single interrupt line for all
the 32 bits. Also in case of ARM MHU, these registers and interrupts
have 3 copies for different priority levels, i.e. low priority
non-secure, high priority non-secure and secure channels.
For ARM MHU, both the dt bindings and the Linux driver support 3
channels for the different priorities right now and support sending a 32
bit data on every transfer in a locked fashion, i.e. only one transfer
can be done at once and the other have to wait for it to finish first.
Here are the point of view of the parties involved on this subject:
Jassi's viewpoint:
- Virtualization of channels should be discouraged in software based on
specific usecases of the application. This may invite other mailbox
driver authors to ask for doing virtualization in their drivers.
- In mailbox's terminology, every channel is equivalent to a signal,
since there is only one signal generated here by the MHU, there should
be only one channel per priority level.
- The clients should send data (of just setting 1 bit or many in the 32
bit word) using the existing mechanism as the delays due to
serialization shouldn't be significant anyway.
- The driver supports 90% of the users with the current implementation
and it shouldn't be extended to support doorbell and implement two
different modes by changing value of #mbox-cells field in bindings.
Sudeep (ARM) and myself as well to some extent:
- The hardware gives us the capability to write the register in
parallel, i.e. we can write 0x800 and 0x400 together without any
software locks, and so these 32 bits should be considered as separate
channel even if only one interrupt is issued by the hardware finally.
This shouldn't be called as virtualization of the channels, as the
hardware supports this (as clearly mentioned in the TRM) and it takes
care of handling the signal properly.
- With serialization, if we use only one channel as today at every
priority, if there are 5 requests to send signal to the receiver and
the dvfs request is the last one in queue (which may be called from
scheduler's hot path with fast switching), it unnecessarily needs to
wait for the first four transfers to finish due to the software
locking imposed by the mailbox framework. This adds additional delay,
maybe of few ms only, which isn't required by the hardware but just by
the software and few ms can be important in scheduler's hotpath.
- With the current approach it isn't possible to assign different bits
(or doorbell numbers) to clients from DT and the only way of doing
that without adding new bindings is by extending #mbox-cells to accept
a value of 2 as done in this patch.
Jassi and Sudeep, I hope I was able to represent both the view points
properly here. Please correct me if I have made a mistake here.
This is it. It would be nice to get the views of everyone now on this
and how should this be handled.
Thanks.
[1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0515f/DDI0515F_juno_arm_development_platform_soc_trm.pdf , section 3.4.4, page 3-38.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
.../devicetree/bindings/mailbox/arm-mhu.txt | 39 ++++++++++++++++++-
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mailbox/arm-mhu.txt b/Documentation/devicetree/bindings/mailbox/arm-mhu.txt
index 4971f03f0b33..ba659bcc7109 100644
--- a/Documentation/devicetree/bindings/mailbox/arm-mhu.txt
+++ b/Documentation/devicetree/bindings/mailbox/arm-mhu.txt
@@ -10,6 +10,15 @@ STAT register and the remote clears it after having read the data.
The last channel is specified to be a 'Secure' resource, hence can't be
used by Linux running NS.
+The MHU drives the interrupt signal using a 32-bit register, with all
+32-bits logically ORed together. It provides a set of registers to
+enable software to set, clear and check the status of each of the bits
+of this register independently. The use of 32 bits per interrupt line
+enables software to provide more information about the source of the
+interrupt. For example, each bit of the register can be associated with
+a type of event that can contribute to raising the interrupt. Each of
+the 32-bits can be used as "doorbell" to alert the remote processor.
+
Mailbox Device Node:
====================
@@ -18,13 +27,21 @@ used by Linux running NS.
- compatible: Shall be "arm,mhu" & "arm,primecell"
- reg: Contains the mailbox register address range (base
address and length)
-- #mbox-cells Shall be 1 - the index of the channel needed.
+- #mbox-cells Shall be 1 - the index of the channel needed when
+ not used as set of doorbell bits.
+ Shall be 2 - the index of the channel needed, and
+ the index of the doorbell bit within the channel
+ when used in doorbell mode.
- interrupts: Contains the interrupt information corresponding to
- each of the 3 links of MHU.
+ each of the 3 physical channels of MHU namely low
+ priority non-secure, high priority non-secure and
+ secure channels.
Example:
--------
+1. Controller which doesn't support doorbells
+
mhu: mailbox@2b1f0000 {
#mbox-cells = <1>;
compatible = "arm,mhu", "arm,primecell";
@@ -41,3 +58,21 @@ used by Linux running NS.
reg = <0 0x2e000000 0x4000>;
mboxes = <&mhu 1>; /* HP-NonSecure */
};
+
+2. Controller which supports doorbells
+
+ mhu: mailbox@2b1f0000 {
+ #mbox-cells = <2>;
+ compatible = "arm,mhu", "arm,primecell";
+ reg = <0 0x2b1f0000 0x1000>;
+ interrupts = <0 36 4>, /* LP-NonSecure */
+ <0 35 4>; /* HP-NonSecure */
+ clocks = <&clock 0 2 1>;
+ clock-names = "apb_pclk";
+ };
+
+ mhu_client: scb@2e000000 {
+ compatible = "arm,scpi";
+ reg = <0 0x2e000000 0x200>;
+ mboxes = <&mhu 1 4>; /* HP-NonSecure 5th doorbell bit */
+ };
--
2.25.0.rc1.19.g042ed3e048af
_______________________________________________
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 5/5] PCI: uniphier: Add error message when failed to get phy
From: Kunihiko Hayashi @ 2020-05-15 4:48 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
In-Reply-To: <1589518105-18368-1-git-send-email-hayashi.kunihiko@socionext.com>
Even if phy driver doesn't probe, the error message can't be
distinguished from other errors. This displays error message
caused by the phy driver explicitly.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/pci/controller/dwc/pcie-uniphier.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
index 6180d50..2bcf394 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier.c
@@ -480,8 +480,10 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
return PTR_ERR(priv->rst);
priv->phy = devm_phy_optional_get(dev, "pcie-phy");
- if (IS_ERR(priv->phy))
+ if (IS_ERR(priv->phy)) {
+ dev_err(dev, "Failed to get phy (%d)\n", PTR_ERR(priv->phy));
return PTR_ERR(priv->phy);
+ }
platform_set_drvdata(pdev, priv);
--
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 4/5] PCI: uniphier: Add iATU register support
From: Kunihiko Hayashi @ 2020-05-15 4:48 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
In-Reply-To: <1589518105-18368-1-git-send-email-hayashi.kunihiko@socionext.com>
This gets iATU register area from reg property. In Synopsis DWC version
4.80 or later, since iATU register area is separated from core register
area, this area is necessary to get from DT independently.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/pci/controller/dwc/pcie-uniphier.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
index 508fc7b..6180d50 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier.c
@@ -461,6 +461,11 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
if (IS_ERR(priv->pci.dbi_base))
return PTR_ERR(priv->pci.dbi_base);
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
+ priv->pci.atu_base = devm_pci_remap_cfg_resource(dev, res);
+ if (IS_ERR(priv->pci.atu_base))
+ priv->pci.atu_base = NULL;
+
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "link");
priv->base = devm_ioremap_resource(dev, res);
if (IS_ERR(priv->base))
--
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 3/5] dt-bindings: PCI: uniphier: Add iATU register description
From: Kunihiko Hayashi @ 2020-05-15 4:48 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
In-Reply-To: <1589518105-18368-1-git-send-email-hayashi.kunihiko@socionext.com>
In the dt-bindings, "atu" reg-names is required to get the register space
for iATU in Synopsis DWC version 4.80 or later.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
Documentation/devicetree/bindings/pci/uniphier-pcie.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pci/uniphier-pcie.txt b/Documentation/devicetree/bindings/pci/uniphier-pcie.txt
index 1fa2c59..c4b7381 100644
--- a/Documentation/devicetree/bindings/pci/uniphier-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/uniphier-pcie.txt
@@ -16,6 +16,7 @@ Required properties:
"dbi" - controller configuration registers
"link" - SoC-specific glue layer registers
"config" - PCIe configuration space
+ "atu" - iATU registers for DWC version 4.80 or later
- clocks: A phandle to the clock gate for PCIe glue layer including
the host controller.
- resets: A phandle to the reset line for PCIe glue layer including
--
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 2/5] PCI: uniphier: Add misc interrupt handler to invoke PME and AER
From: Kunihiko Hayashi @ 2020-05-15 4:48 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
In-Reply-To: <1589518105-18368-1-git-send-email-hayashi.kunihiko@socionext.com>
The misc interrupts consisting of PME, AER, and Link event, is handled
by INTx handler, however, these interrupts should be also handled by
MSI handler.
This adds the function uniphier_pcie_misc_isr() that handles misc
intterupts, which is called from both INTx and MSI handlers.
This function detects PME and AER interrupts with the status register,
and invoke PME and AER drivers related to INTx or MSI.
And this sets the mask for misc interrupts from INTx if MSI is enabled
and sets the mask for misc interrupts from MSI if MSI is disabled.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/pci/controller/dwc/pcie-uniphier.c | 53 +++++++++++++++++++++++-------
1 file changed, 42 insertions(+), 11 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
index 8fd7bad..508fc7b 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier.c
@@ -44,7 +44,9 @@
#define PCL_SYS_AUX_PWR_DET BIT(8)
#define PCL_RCV_INT 0x8108
+#define PCL_RCV_INT_ALL_INT_MASK GENMASK(28, 25)
#define PCL_RCV_INT_ALL_ENABLE GENMASK(20, 17)
+#define PCL_RCV_INT_ALL_MSI_MASK GENMASK(12, 9)
#define PCL_CFG_BW_MGT_STATUS BIT(4)
#define PCL_CFG_LINK_AUTO_BW_STATUS BIT(3)
#define PCL_CFG_AER_RC_ERR_MSI_STATUS BIT(2)
@@ -167,7 +169,15 @@ static void uniphier_pcie_stop_link(struct dw_pcie *pci)
static void uniphier_pcie_irq_enable(struct uniphier_pcie_priv *priv)
{
- writel(PCL_RCV_INT_ALL_ENABLE, priv->base + PCL_RCV_INT);
+ u32 val;
+
+ val = PCL_RCV_INT_ALL_ENABLE;
+ if (pci_msi_enabled())
+ val |= PCL_RCV_INT_ALL_INT_MASK;
+ else
+ val |= PCL_RCV_INT_ALL_MSI_MASK;
+
+ writel(val, priv->base + PCL_RCV_INT);
writel(PCL_RCV_INTX_ALL_ENABLE, priv->base + PCL_RCV_INTX);
}
@@ -237,28 +247,48 @@ static const struct irq_domain_ops uniphier_intx_domain_ops = {
.map = uniphier_pcie_intx_map,
};
-static void uniphier_pcie_irq_handler(struct irq_desc *desc)
+static void uniphier_pcie_misc_isr(struct pcie_port *pp)
{
- struct pcie_port *pp = irq_desc_get_handler_data(desc);
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
struct uniphier_pcie_priv *priv = to_uniphier_pcie(pci);
- struct irq_chip *chip = irq_desc_get_chip(desc);
- unsigned long reg;
- u32 val, bit, virq;
+ u32 val, virq;
- /* INT for debug */
val = readl(priv->base + PCL_RCV_INT);
if (val & PCL_CFG_BW_MGT_STATUS)
dev_dbg(pci->dev, "Link Bandwidth Management Event\n");
+
if (val & PCL_CFG_LINK_AUTO_BW_STATUS)
dev_dbg(pci->dev, "Link Autonomous Bandwidth Event\n");
- if (val & PCL_CFG_AER_RC_ERR_MSI_STATUS)
- dev_dbg(pci->dev, "Root Error\n");
- if (val & PCL_CFG_PME_MSI_STATUS)
- dev_dbg(pci->dev, "PME Interrupt\n");
+
+ if (pci_msi_enabled()) {
+ if (val & PCL_CFG_AER_RC_ERR_MSI_STATUS) {
+ dev_dbg(pci->dev, "Root Error Status\n");
+ virq = irq_linear_revmap(pp->irq_domain, 0);
+ generic_handle_irq(virq);
+ }
+
+ if (val & PCL_CFG_PME_MSI_STATUS) {
+ dev_dbg(pci->dev, "PME Interrupt\n");
+ virq = irq_linear_revmap(pp->irq_domain, 0);
+ generic_handle_irq(virq);
+ }
+ }
writel(val, priv->base + PCL_RCV_INT);
+}
+
+static void uniphier_pcie_irq_handler(struct irq_desc *desc)
+{
+ struct pcie_port *pp = irq_desc_get_handler_data(desc);
+ struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+ struct uniphier_pcie_priv *priv = to_uniphier_pcie(pci);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ unsigned long reg;
+ u32 val, bit, virq;
+
+ /* misc interrupt */
+ uniphier_pcie_misc_isr(pp);
/* INTx */
chained_irq_enter(chip, desc);
@@ -336,6 +366,7 @@ static int uniphier_pcie_host_init(struct pcie_port *pp)
static const struct dw_pcie_host_ops uniphier_pcie_host_ops = {
.host_init = uniphier_pcie_host_init,
+ .msi_host_isr = uniphier_pcie_misc_isr,
};
static int uniphier_add_pcie_port(struct uniphier_pcie_priv *priv,
--
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 1/5] PCI: dwc: Add msi_host_isr() callback
From: Kunihiko Hayashi @ 2020-05-15 4:48 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
In-Reply-To: <1589518105-18368-1-git-send-email-hayashi.kunihiko@socionext.com>
This adds msi_host_isr() callback function support to describe
SoC-dependent service triggered by MSI.
For example, when AER interrupt is triggered by MSI, the callback function
reads SoC-dependent registers and detects that the interrupt is from AER,
and invoke AER interrupts related to MSI.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/pci/controller/dwc/pcie-designware-host.c | 8 ++++----
drivers/pci/controller/dwc/pcie-designware.h | 1 +
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index 0f36a92..491b7a8 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -110,13 +110,13 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
static void dw_chained_msi_isr(struct irq_desc *desc)
{
struct irq_chip *chip = irq_desc_get_chip(desc);
- struct pcie_port *pp;
+ struct pcie_port *pp = irq_desc_get_handler_data(desc);
- chained_irq_enter(chip, desc);
+ if (pp->ops->msi_host_isr)
+ pp->ops->msi_host_isr(pp);
- pp = irq_desc_get_handler_data(desc);
+ chained_irq_enter(chip, desc);
dw_handle_msi_irq(pp);
-
chained_irq_exit(chip, desc);
}
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 5a18e94..27fee10 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -160,6 +160,7 @@ struct dw_pcie_host_ops {
void (*scan_bus)(struct pcie_port *pp);
void (*set_num_vectors)(struct pcie_port *pp);
int (*msi_host_init)(struct pcie_port *pp);
+ void (*msi_host_isr)(struct pcie_port *pp);
};
struct pcie_port {
--
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 0/5] PCI: uniphier: Add features for UniPhier PCIe host controller
From: Kunihiko Hayashi @ 2020-05-15 4:48 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
This series adds some features for UniPhier PCIe host controller.
- Add support for PME and AER invoked by MSI interrupt
- Add iATU register view support for PCIe version >= 4.80
- Add an error message when failing to get phy driver
This adds a new function called by MSI handler in DesignWare PCIe framework,
that invokes PME and AER funcions to detect the factor from SoC-dependent
registers.
---
Kunihiko Hayashi (5):
PCI: dwc: Add msi_host_isr() callback
PCI: uniphier: Add misc interrupt handler to invoke PME and AER
dt-bindings: PCI: uniphier: Add iATU register description
PCI: uniphier: Add iATU register support
PCI: uniphier: Add error message when failed to get phy
.../devicetree/bindings/pci/uniphier-pcie.txt | 1 +
drivers/pci/controller/dwc/pcie-designware-host.c | 8 +--
drivers/pci/controller/dwc/pcie-designware.h | 1 +
drivers/pci/controller/dwc/pcie-uniphier.c | 62 +++++++++++++++++-----
4 files changed, 56 insertions(+), 16 deletions(-)
--
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
* Re: [Question] Hardware management of stage2 page dirty state
From: zhukeqian @ 2020-05-15 4:20 UTC (permalink / raw)
To: Catalin Marinas
Cc: Marc Zyngier, Zengtao (B), yuzenghui, wanghaibin.wang, kvmarm,
linux-arm-kernel
In-Reply-To: <20200514161427.GD1907@gaia>
Hi Catalin,
On 2020/5/15 0:14, Catalin Marinas wrote:
> Hi Keqian,
>
> On Thu, May 14, 2020 at 05:16:52PM +0800, zhukeqian wrote:
>> I have some questions after deep reading your patch
>> https://patchwork.kernel.org/patch/8824261/ which enables hardware updates
>> of the Access Flag for Stage 2 page tables.
>>
>> I notice that at the bottom of commit message, you said the following words:
>> "After some digging through the KVM code, I concluded that hardware DBM
>> (dirty bit management) support is not feasible for Stage 2. A potential
>> user would be dirty logging but this requires a different bitmap exposed
>> to Qemu and, to avoid races, the stage 2 mappings need to be mapped
>> read-only on clean, writable on fault. This assumption simplifies the
>> hardware Stage 2 AF support."
>>
>> I have three questions here.
>>
>> 1. I do not understand the reason well about "not feasible". Does the main reason
>> for this is the "races" you referred?
>
> IIRC, dirty logging works by having a bitmap populated by the host
> kernel when the guest writes a page. Such write triggers a stage 2 fault
> and the kernel populates the bitmap. With S2 DBM, you wouldn't get a
> fault when the guest writes the page, so the host kernel would have to
> periodically check which S2 entries became writable to update the qemu
> bitmap.
Sure, the performance problem introduced by traversing page table entries is
a defect of DBM mechanism.
>
> I think the race I had in mind was that the bitmap still reports the
> page as clean while the guest already updated it.
>
> Looking at this again, it may not matter much as qemu can copy those
> pages again when migrating and before control is handed over to the new
> host.
Yes, race is not a problem. Qemu will not miss dirty pages when control is
handed over to the new Qemu.
>
>> 2. What does the "races" refer to? Do you mean the races between [hardware S2 DBM]
>> and [dirty information collection that executed by KVM]?
>
> Yes.
>
>> During VM live migration, Qemu will send dirty page iteratively and finally stop
>> VM when dirty pages is not too much. We may miss dirty pages during each iteration
>> before VM stop, but there are no races after VM stop, so we won't miss dirty pages
>> finally. It seems that "races" is not a convinced reason for "not feasible".
>
> You are probably right. But you'd have to change the dirty tracking from
> a fault mechanism to a polling one checking the S2 page tables
> periodically. Or, can you check then only once after VM stop?
Our purpose is to remove performance side effect on guest caused by fault mechanism, so we want to
use DBM from begin to end.
For now, the only problem of DBM that we can figure out is the page table traversing performance.
We have done some demo tests on this and situation is not that bad. Besides, we have come up with
some optimizations which can ease this situation effectively.
I plan to send out all test data and PATCH RFC to community next week. It should work functional
correctly but without any optimizations. After that I will add all optimizations based on PATCH
RFC and send PATCH v1.
>
>> 3. You said that disable hardware S2 DBM support can simplify the hardware S2 AF support.
>> Could you please explain the reason in detail?
>
> I probably meant that it simplifies the patch rather than something
> specific to the AF support. If you add DBM, you'd need to make sure that
> making a pte read-only doesn't lose the dirty information (see
> ptep_set_wrprotect(), not sure whether KVM uses the same macro).
>
OK, I will notice this problem, thanks!
Thanks,
Keqian
_______________________________________________
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 v14 03/11] soc: mediatek: Add basic_clk_name to scp_power_data
From: Weiyi Lu @ 2020-05-15 3:35 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: James Liao, Nicolas Boichat, srv_heupstream, Rob Herring,
Enric Balletbo Serra, linux-kernel, Fan Chen, linux-mediatek,
Sascha Hauer, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1589176947.21832.9.camel@mtksdaap41>
On Mon, 2020-05-11 at 14:02 +0800, Weiyi Lu wrote:
> On Wed, 2020-05-06 at 23:01 +0200, Enric Balletbo i Serra wrote:
> > Hi Weiyi,
> >
> > Thank you for your patch.
> >
> > On 6/5/20 10:15, Weiyi Lu wrote:
> > > Try to stop extending the clk_id or clk_names if there are
> > > more and more new BASIC clocks. To get its own clocks by the
> > > basic_clk_name of each power domain.
> > > And then use basic_clk_name strings for all compatibles, instead of
> > > mixing clk_id and clk_name.
> > >
> > > Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
> > > Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
> > > ---
> > > drivers/soc/mediatek/mtk-scpsys.c | 134 ++++++++++++--------------------------
> > > 1 file changed, 41 insertions(+), 93 deletions(-)
> > >
> > > diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> > > index f669d37..c9c3cf7 100644
> > > --- a/drivers/soc/mediatek/mtk-scpsys.c
> > > +++ b/drivers/soc/mediatek/mtk-scpsys.c
> > > @@ -78,34 +78,6 @@
> > > #define PWR_STATUS_HIF1 BIT(26) /* MT7622 */
> > > #define PWR_STATUS_WB BIT(27) /* MT7622 */
> > >
> > > -enum clk_id {
> > > - CLK_NONE,
> > > - CLK_MM,
> > > - CLK_MFG,
> > > - CLK_VENC,
> > > - CLK_VENC_LT,
> > > - CLK_ETHIF,
> > > - CLK_VDEC,
> > > - CLK_HIFSEL,
> > > - CLK_JPGDEC,
> > > - CLK_AUDIO,
> > > - CLK_MAX,
> > > -};
> > > -
> > > -static const char * const clk_names[] = {
> > > - NULL,
> > > - "mm",
> > > - "mfg",
> > > - "venc",
> > > - "venc_lt",
> > > - "ethif",
> > > - "vdec",
> > > - "hif_sel",
> > > - "jpgdec",
> > > - "audio",
> > > - NULL,
> > > -};
> > > -
> > > #define MAX_CLKS 3
> > >
> > > /**
> > > @@ -116,7 +88,7 @@ enum clk_id {
> > > * @sram_pdn_bits: The mask for sram power control bits.
> > > * @sram_pdn_ack_bits: The mask for sram power control acked bits.
> > > * @bus_prot_mask: The mask for single step bus protection.
> > > - * @clk_id: The basic clocks required by this power domain.
> > > + * @basic_clk_name: The basic clocks required by this power domain.
> > > * @caps: The flag for active wake-up action.
> > > */
> > > struct scp_domain_data {
> > > @@ -126,7 +98,7 @@ struct scp_domain_data {
> > > u32 sram_pdn_bits;
> > > u32 sram_pdn_ack_bits;
> > > u32 bus_prot_mask;
> > > - enum clk_id clk_id[MAX_CLKS];
> > > + const char *basic_clk_name[MAX_CLKS];
> >
> > I only reviewed v13, so sorry if this was already discussed. I am wondering if
> > would be better take advantage of the devm_clk_bulk_get() function instead of
> > kind of reimplementing the same, something like this
> >
> > const struct clk_bulk_data *basic_clocks;
> >
>
> I thought it should be const struct clk_bulk_data
> basic_clocks[MAX_CLKS]; instead of const struct clk_bulk_data
> *basic_clocks; in struct scp_domain_data data type
>
> > > u8 caps;
> > > };
> > >
> > > @@ -411,12 +383,19 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
> > > return ret;
> > > }
> > >
> > > -static void init_clks(struct platform_device *pdev, struct clk **clk)
> > > +static int init_basic_clks(struct platform_device *pdev, struct clk **clk,
> > > + const char * const *name)
> > > {
> > > int i;
> > >
> > > - for (i = CLK_NONE + 1; i < CLK_MAX; i++)
> > > - clk[i] = devm_clk_get(&pdev->dev, clk_names[i]);
> > > + for (i = 0; i < MAX_CLKS && name[i]; i++) {
> > > + clk[i] = devm_clk_get(&pdev->dev, name[i]);
> > > +
> > > + if (IS_ERR(clk[i]))
> > > + return PTR_ERR(clk[i]);
> > > + }
> >
> > You will be able to remove this function, see below ...
> >
> > > +
> > > + return 0;
> > > }
> > >
> > > static struct scp *init_scp(struct platform_device *pdev,
> > > @@ -426,9 +405,8 @@ static struct scp *init_scp(struct platform_device *pdev,
> > > {
> > > struct genpd_onecell_data *pd_data;
> > > struct resource *res;
> > > - int i, j;
> > > + int i, ret;
> > > struct scp *scp;
> > > - struct clk *clk[CLK_MAX];
> > >
> > > scp = devm_kzalloc(&pdev->dev, sizeof(*scp), GFP_KERNEL);
> > > if (!scp)
> > > @@ -481,8 +459,6 @@ static struct scp *init_scp(struct platform_device *pdev,
> > >
> > > pd_data->num_domains = num;
> > >
> > > - init_clks(pdev, clk);
> > > -
> > > for (i = 0; i < num; i++) {
> > > struct scp_domain *scpd = &scp->domains[i];
> > > struct generic_pm_domain *genpd = &scpd->genpd;
> > > @@ -493,17 +469,9 @@ static struct scp *init_scp(struct platform_device *pdev,
> > >
> > > scpd->data = data;
> > >
> > > - for (j = 0; j < MAX_CLKS && data->clk_id[j]; j++) {
> > > - struct clk *c = clk[data->clk_id[j]];
> > > -
> > > - if (IS_ERR(c)) {
> > > - dev_err(&pdev->dev, "%s: clk unavailable\n",
> > > - data->name);
> > > - return ERR_CAST(c);
> > > - }
> > > -
> > > - scpd->clk[j] = c;
> > > - }
> > > + ret = init_basic_clks(pdev, scpd->clk, data->basic_clk_name);
> > > + if (ret)
> > > + return ERR_PTR(ret);
> >
> > Just call:
> >
> > ret = devm_clk_bulk_get(&pdev->dev, ARRAY_SIZE(basic_clocks),
> > data->basic_clocks);
> > if (ret)
> > return ERR_PTR(ret);
> >
> > >
> > > genpd->name = data->name;
> > > genpd->power_off = scpsys_power_off;
> > > @@ -560,7 +528,6 @@ static void mtk_register_power_domains(struct platform_device *pdev,
> > > .ctl_offs = SPM_CONN_PWR_CON,
> > > .bus_prot_mask = MT2701_TOP_AXI_PROT_EN_CONN_M |
> > > MT2701_TOP_AXI_PROT_EN_CONN_S,
> > > - .clk_id = {CLK_NONE},
> > > .caps = MTK_SCPD_ACTIVE_WAKEUP,
> > > },
> > > [MT2701_POWER_DOMAIN_DISP] = {
> > > @@ -568,7 +535,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
> > > .sta_mask = PWR_STATUS_DISP,
> > > .ctl_offs = SPM_DIS_PWR_CON,
> > > .sram_pdn_bits = GENMASK(11, 8),
> > > - .clk_id = {CLK_MM},
> > > + .basic_clk_name = {"mm"},
> >
> > .basic_clocks[] = {
> > { .id = "mm" },
> > };
> >
>
> Those basic clocks without given a name (name: null) would get incorrect
> clock via clk_bulk_get(...) due to
>
> /**
> * of_parse_clkspec() - Parse a DT clock specifier for a given device
> node
> * @np: device node to parse clock specifier from
> * @index: index of phandle to parse clock out of. If index < 0, @name
> is used
> * @name: clock name to find and parse. If name is NULL, the index is
> used
>
> And the index is 0 here in this callstack
>
> I guess something need to be improved before we use the clk_bulk_ APIs.
>
Hi Enric,
According to the result above, is it necessary to change the APIs or
maybe I should send the next version v15 first to fix other problems you
mentioned? Many thanks.
>
> > > .bus_prot_mask = MT2701_TOP_AXI_PROT_EN_MM_M0,
> > > .caps = MTK_SCPD_ACTIVE_WAKEUP,
> > > },
> > > @@ -578,7 +545,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
> > > .ctl_offs = SPM_MFG_PWR_CON,
> > > .sram_pdn_bits = GENMASK(11, 8),
> > > .sram_pdn_ack_bits = GENMASK(12, 12),
> > > - .clk_id = {CLK_MFG},
> > > + .basic_clk_name = {"mfg"},
> >
> > .basic_clocks[] = {
> > { .id = "mfg" },
> > };
> >
> > > .caps = MTK_SCPD_ACTIVE_WAKEUP,
> > > },
> > > [MT2701_POWER_DOMAIN_VDEC] = {
> > > @@ -587,7 +554,7 @@ static void mtk_register_power_domains(struct platform_device *pdev,
> > > .ctl_offs = SPM_VDE_PWR_CON,
> > > .sram_pdn_bits = GENMASK(11, 8),
> > > .sram_pdn_ack_bits = GENMASK(12, 12),
> > > - .clk_id = {CLK_MM},
> > > + .basic_clk_name = {"mm"},
> >
> > ...
> >
> > [snip]
>
>
_______________________________________________
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] arm64/cpuinfo: Move HWCAP name arrays alongside their bit definitions
From: Anshuman Khandual @ 2020-05-15 3:28 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Suzuki K Poulose, Catalin Marinas, linux-kernel,
Ard Biesheuvel, Mark Brown, Dave Martin, linux-arm-kernel
In-Reply-To: <20200514073613.GB4280@willie-the-truck>
On 05/14/2020 01:06 PM, Will Deacon wrote:
> On Thu, May 14, 2020 at 07:14:58AM +0530, Anshuman Khandual wrote:
>> On 05/13/2020 08:34 PM, Dave Martin wrote:
>>> On Thu, May 07, 2020 at 06:59:10PM +0530, Anshuman Khandual wrote:
>>>> diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h
>>>> index 0f00265248b5..589ac02e1ddd 100644
>>>> --- a/arch/arm64/include/asm/hwcap.h
>>>> +++ b/arch/arm64/include/asm/hwcap.h
>>>> @@ -8,18 +8,27 @@
>>>> #include <uapi/asm/hwcap.h>
>>>> #include <asm/cpufeature.h>
>>>>
>>>> +#define COMPAT_HWCAP_SWP (1 << 0)
>>>> #define COMPAT_HWCAP_HALF (1 << 1)
>>>> #define COMPAT_HWCAP_THUMB (1 << 2)
>>>> +#define COMPAT_HWCAP_26BIT (1 << 3)
>>>> #define COMPAT_HWCAP_FAST_MULT (1 << 4)
>>>> +#define COMPAT_HWCAP_FPA (1 << 5)
>>>> #define COMPAT_HWCAP_VFP (1 << 6)
>>>> #define COMPAT_HWCAP_EDSP (1 << 7)
>>>> +#define COMPAT_HWCAP_JAVA (1 << 8)
>>>> +#define COMPAT_HWCAP_IWMMXT (1 << 9)
>>>> +#define COMPAT_HWCAP_CRUNCH (1 << 10)
>>>> +#define COMPAT_HWCAP_THUMBEE (1 << 11)
>>>> #define COMPAT_HWCAP_NEON (1 << 12)
>>>> #define COMPAT_HWCAP_VFPv3 (1 << 13)
>>>> +#define COMPAT_HWCAP_VFPV3D16 (1 << 14)
>>>> #define COMPAT_HWCAP_TLS (1 << 15)
>>>> #define COMPAT_HWCAP_VFPv4 (1 << 16)
>>>> #define COMPAT_HWCAP_IDIVA (1 << 17)
>>>> #define COMPAT_HWCAP_IDIVT (1 << 18)
>>>> #define COMPAT_HWCAP_IDIV (COMPAT_HWCAP_IDIVA|COMPAT_HWCAP_IDIVT)
>>>> +#define COMPAT_HWCAP_VFPD32 (1 << 19)
>>>> #define COMPAT_HWCAP_LPAE (1 << 20)
>>>> #define COMPAT_HWCAP_EVTSTRM (1 << 21)
>>>
>>> With the possible exception of SWP (does the swp emulation allow us to
>>> report this as supported?), I think all these weren't mentioned because
>>> they aren't included in ARMv8 and so can never be reported.
>>>
>>> If we find ourselves reporting them, there's a bug somewhere.
>>>
>>> So, can we just default all obsolete string entries to NULL?
>>>
>>> When generating the cpuinfo strings we could WARN and just emit an empty
>>> string for that hwcap.
>>
>> All these above will be a change in the existing user visible behavior on
>> the system and this patch never intended to create one.
>
> Why is it a change? We've never reported e.g. "java" on an arm64 kernel, so
We already have "java" defined in existing compat_hwcap_str[] array even
though it might never get set in compat_elf_hwcap. AFAICS, compat_elf_hwcap
will have the following capabilities set (at the most).
Via COMPAT_ELF_HWCAP_DEFAULT
01. COMPAT_HWCAP_HALF
02. COMPAT_HWCAP_THUMB
03. COMPAT_HWCAP_FAST_MULT
04. COMPAT_HWCAP_EDSP
05. COMPAT_HWCAP_TLS
06. COMPAT_HWCAP_IDIV
07. COMPAT_HWCAP_LPAE
Via setup_elf_hwcaps(compat_elf_hwcaps) <-- setup_cpu_features()
8. COMPAT_HWCAP_NEON
9. COMPAT_HWCAP_VFPv4
10. COMPAT_HWCAP_VFP
11. COMPAT_HWCAP_VFPv3
Via arch_timer_set_evtstrm_feature()
12. COMPAT_HWCAP_EVTSTRM
The code exists for "java" string to be displayed with /proc/cpuinfo but it
may never get triggered as compat_elf_hwcap will never have JAVA capability
unless there is a bug as you had rightly mentioned.
The current patch preserves status quo without fixing the underlying problem
("java" should have been dropped from possible /proc/cpuinfo display strings
as it can never happen). It tries to formalize what is already being done.
arch/arm64/kernel/cpuinfo.c
static int c_show(struct seq_file *m, void *v)
{
....
#ifdef CONFIG_COMPAT
for (j = 0; compat_hwcap_str[j]; j++)
if (compat_elf_hwcap & (1 << j))
seq_printf(m, " %s", compat_hwcap_str[j]);
....
#endif
....
}
When compat_hwcap_str[j] == "java" just define COMPAT_HWCAP_JAVA as (1 << j).
> I agree with Dave that we shouldn't be adding this string. If it /ever/ ends
> up in userspace it's because something has gone horribly wrong. NULL would
> be much better. Couldn't you achieve that by simply omitting these entries?
> e.g. deleting things like:
>
> [COMPAT_KERNEL_HWCAP(JAVA)] = "java",
>
> completely (including the COMPAT_HWCAP_JAVA definition)?
Right, dropping these above will fix the existing underlying problem. But the
only point here is should that be done in this patch (which keeps everything
as is) or with a separate patch fixing an already existing problem.
>
>> Hence, I will just defer this to maintainers on whether we should change
>> existing /proc/cpuinfo output (including non-practically-possible ones on
>> ARMv8) or even treat swap emulation as SWP.
>
> SWP is fine because we emulate it and so userspace can use it. Removing that
> *would* be a change in behaviour. I don't think the compat ABI is broken
> here, so please don't change it without good reason.
Understood, this patch was not trying to change the compat ABI. SWP just gets
carried over as is like before.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 20/20] dt-bindings: ehci/ohci: Allow iommus property
From: Rob Herring @ 2020-05-15 3:17 UTC (permalink / raw)
To: Andre Przywara
Cc: Mark Rutland, devicetree, Lorenzo Pieralisi, Greg Kroah-Hartman,
linux-usb, Liviu Dudau, Sudeep Holla, linux-arm-kernel
In-Reply-To: <20200513103016.130417-21-andre.przywara@arm.com>
On Wed, 13 May 2020 11:30:16 +0100, Andre Przywara wrote:
> A OHCI/EHCI controller could be behind an IOMMU, in which case an iommus
> property assigns the stream ID for this device.
>
> Allow that property in the DT bindings to fix a complaint about the Arm Juno
> board's DTS file.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> Documentation/devicetree/bindings/usb/generic-ehci.yaml | 3 +++
> Documentation/devicetree/bindings/usb/generic-ohci.yaml | 3 +++
> 2 files changed, 6 insertions(+)
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 19/20] dt-bindings: mali-midgard: Allow dma-coherent
From: Rob Herring @ 2020-05-15 3:16 UTC (permalink / raw)
To: Andre Przywara
Cc: Mark Rutland, devicetree, Lorenzo Pieralisi, David Airlie,
Liviu Dudau, dri-devel, Sudeep Holla, linux-arm-kernel
In-Reply-To: <20200513103016.130417-20-andre.przywara@arm.com>
On Wed, 13 May 2020 11:30:15 +0100, Andre Przywara wrote:
> Add the boolean dma-coherent property to the list of allowed properties,
> since some boards (Arm Juno) integrate the GPU this way.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
Applied, thanks!
_______________________________________________
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