* RE: [PATCH 1/4] dt-bindings: watchdog: Add i.MX7ULP bindings
From: Anson Huang @ 2019-08-12 2:03 UTC (permalink / raw)
To: Guenter Roeck
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Leonard Crestez,
schnitzeltony@gmail.com, linux-watchdog@vger.kernel.org,
otavio@ossystems.com.br, festevam@gmail.com,
s.hauer@pengutronix.de, jan.tuerk@emtrion.com,
linux@armlinux.org.uk, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx, kernel@pengutronix.de,
u.kleine-koenig@pengutronix.de, wim@linux-watchdog.org,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190809164245.GA17136@roeck-us.net>
Hi, Guenter
> On Fri, Aug 09, 2019 at 03:13:59PM +0800, Anson Huang wrote:
> > Add the watchdog bindings for Freescale i.MX7ULP.
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > ---
> > .../bindings/watchdog/fsl-imx7ulp-wdt.txt | 22
> ++++++++++++++++++++++
> > 1 file changed, 22 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt
> > b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt
> > new file mode 100644
> > index 0000000..d83fc5c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt
> > @@ -0,0 +1,22 @@
> > +* Freescale i.MX7ULP Watchdog Timer (WDT) Controller
> > +
> > +Required properties:
> > +- compatible : Should be "fsl,imx7ulp-wdt"
> > +- reg : Should contain WDT registers location and length
> > +- interrupts : Should contain WDT interrupt
> > +- clocks: Should contain a phandle pointing to the gated peripheral clock.
>
> The driver as submitted does not include clock or interrupt handling.
> Why are those properties listed as mandatory if they are not really needed
> (nor used) ?
I missed the clk part in driver, it is working ONLY because the wdog clock is enabled
unexpected, I will add it in V2, thanks for pointing out such big mistake!
Anson
>
> > +
> > +Optional properties:
> > +- timeout-sec : Contains the watchdog timeout in seconds
> > +
> > +Examples:
> > +
> > +wdog1: wdog@403d0000 {
> > + compatible = "fsl,imx7ulp-wdt";
> > + reg = <0x403d0000 0x10000>;
> > + interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&pcc2 IMX7ULP_CLK_WDG1>;
> > + assigned-clocks = <&pcc2 IMX7ULP_CLK_WDG1>;
> > + assigned-clocks-parents = <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>;
> > + timeout-sec = <40>;
> > +};
> > --
> > 2.7.4
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH 2/4] watchdog: Add i.MX7ULP watchdog support
From: Anson Huang @ 2019-08-12 1:41 UTC (permalink / raw)
To: Guenter Roeck
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Leonard Crestez,
schnitzeltony@gmail.com, linux-watchdog@vger.kernel.org,
otavio@ossystems.com.br, festevam@gmail.com,
s.hauer@pengutronix.de, jan.tuerk@emtrion.com,
linux@armlinux.org.uk, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx, kernel@pengutronix.de,
u.kleine-koenig@pengutronix.de, wim@linux-watchdog.org,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190809161956.GA6248@roeck-us.net>
Hi, Guenter
> On Fri, Aug 09, 2019 at 03:14:00PM +0800, Anson Huang wrote:
> > The i.MX7ULP Watchdog Timer (WDOG) module is an independent timer
> that
> > is available for system use.
> > It provides a safety feature to ensure that software is executing as
> > planned and that the CPU is not stuck in an infinite loop or executing
> > unintended code. If the WDOG module is not serviced
> > (refreshed) within a certain period, it resets the MCU.
> >
> > Add driver support for i.MX7ULP watchdog.
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > ---
> > drivers/watchdog/Kconfig | 13 +++
> > drivers/watchdog/Makefile | 1 +
> > drivers/watchdog/imx7ulp_wdt.c | 221
> > +++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 235 insertions(+)
> > create mode 100644 drivers/watchdog/imx7ulp_wdt.c
> >
> > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index
> > 8188963..0884e53 100644
> > --- a/drivers/watchdog/Kconfig
> > +++ b/drivers/watchdog/Kconfig
> > @@ -740,6 +740,19 @@ config IMX_SC_WDT
> > To compile this driver as a module, choose M here: the
> > module will be called imx_sc_wdt.
> >
> > +config IMX7ULP_WDT
> > + tristate "IMX7ULP Watchdog"
> > + depends on ARCH_MXC || COMPILE_TEST
> > + select WATCHDOG_CORE
> > + help
> > + This is the driver for the hardware watchdog on the Freescale
> > + IMX7ULP and later processors. If you have one of these
> > + processors and wish to have watchdog support enabled,
> > + say Y, otherwise say N.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called imx7ulp_wdt.
> > +
> > config UX500_WATCHDOG
> > tristate "ST-Ericsson Ux500 watchdog"
> > depends on MFD_DB8500_PRCMU
> > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> > index 7caa920..7d32537 100644
> > --- a/drivers/watchdog/Makefile
> > +++ b/drivers/watchdog/Makefile
> > @@ -69,6 +69,7 @@ obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o
> > obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
> > obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
> > obj-$(CONFIG_IMX_SC_WDT) += imx_sc_wdt.o
> > +obj-$(CONFIG_IMX7ULP_WDT) += imx7ulp_wdt.o
> > obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
> > obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
> > obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o diff --git
> > a/drivers/watchdog/imx7ulp_wdt.c b/drivers/watchdog/imx7ulp_wdt.c
> new
> > file mode 100644 index 0000000..8d56023
> > --- /dev/null
> > +++ b/drivers/watchdog/imx7ulp_wdt.c
> > @@ -0,0 +1,221 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright 2019 NXP.
> > + */
> > +
> > +#include <linux/init.h>
> > +#include <linux/io.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/reboot.h>
> > +#include <linux/watchdog.h>
> > +
> > +#define WDOG_CS 0x0
> > +#define WDOG_CS_CMD32EN (1 << 13)
> > +#define WDOG_CS_ULK (1 << 11)
> > +#define WDOG_CS_RCS (1 << 10)
> > +#define WDOG_CS_EN (1 << 7)
> > +#define WDOG_CS_UPDATE (1 << 5)
> > +
>
> Please use BIT() where appropriate.
Got it.
>
> > +#define WDOG_CNT 0x4
> > +#define WDOG_TOVAL 0x8
> > +
> > +#define REFRESH_SEQ0 0xA602
> > +#define REFRESH_SEQ1 0xB480
> > +#define REFRESH ((REFRESH_SEQ1 << 16) | (REFRESH_SEQ0))
>
> The inner ( ) are unnecessary. While I would accept it for readability for the
> first part, (REFRESH_SEQ0) really doesn't add value.
Got it.
>
> > +
> > +#define UNLOCK_SEQ0 0xC520
> > +#define UNLOCK_SEQ1 0xD928
> > +#define UNLOCK ((UNLOCK_SEQ1 << 16) | (UNLOCK_SEQ0))
>
> Same as above.
Got it.
>
> > +
> > +#define DEFAULT_TIMEOUT 60
> > +#define MAX_TIMEOUT 128
>
> tabs after _TIMEOUT, please
Got it.
>
> > +
> > +static bool nowayout = WATCHDOG_NOWAYOUT;
> module_param(nowayout,
> > +bool, 0000); MODULE_PARM_DESC(nowayout, "Watchdog cannot be
> stopped
> > +once started (default="
> > + __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> > +
> > +struct imx7ulp_wdt_device {
> > + struct notifier_block restart_handler;
> > + struct watchdog_device wdd;
> > + void __iomem *base;
> > + int rate;
> > +};
> > +
> > +static inline void imx7ulp_wdt_enable(void __iomem *base, bool
> > +enable) {
> > + u32 val = readl(base + WDOG_CS);
> > +
> > + writel(UNLOCK, base + WDOG_CNT);
> > + if (enable)
> > + writel(val | WDOG_CS_EN, base + WDOG_CS);
> > + else
> > + writel(val & ~WDOG_CS_EN, base + WDOG_CS); }
> > +
> > +static inline bool imx7ulp_wdt_is_enabled(void __iomem *base) {
> > + u32 val = readl(base + WDOG_CS);
> > +
> > + return val & WDOG_CS_EN;
> > +}
> > +
> > +static int imx7ulp_wdt_ping(struct watchdog_device *wdog) {
> > + struct imx7ulp_wdt_device *wdt = watchdog_get_drvdata(wdog);
> > +
> > + writel(REFRESH, wdt->base + WDOG_CNT);
> > +
> > + return 0;
> > +}
> > +
> > +static int imx7ulp_wdt_start(struct watchdog_device *wdog) {
> > + struct imx7ulp_wdt_device *wdt = watchdog_get_drvdata(wdog);
> > +
> > + imx7ulp_wdt_enable(wdt->base, true);
> > +
> > + return 0;
> > +}
> > +
> > +static int imx7ulp_wdt_stop(struct watchdog_device *wdog) {
> > + struct imx7ulp_wdt_device *wdt = watchdog_get_drvdata(wdog);
> > +
> > + imx7ulp_wdt_enable(wdt->base, false);
> > +
> > + return 0;
> > +}
> > +
> > +static int imx7ulp_wdt_set_timeout(struct watchdog_device *wdog,
> > + unsigned int timeout)
> > +{
> > + struct imx7ulp_wdt_device *wdt = watchdog_get_drvdata(wdog);
> > + u32 val = wdt->rate * timeout;
> > +
> > + writel(UNLOCK, wdt->base + WDOG_CNT);
> > + writel(val, wdt->base + WDOG_TOVAL);
> > +
> > + wdog->timeout = timeout;
> > +
> > + return 0;
> > +}
> > +
> > +static const struct watchdog_ops imx7ulp_wdt_ops = {
> > + .owner = THIS_MODULE,
> > + .start = imx7ulp_wdt_start,
> > + .stop = imx7ulp_wdt_stop,
> > + .ping = imx7ulp_wdt_ping,
> > + .set_timeout = imx7ulp_wdt_set_timeout, };
> > +
> > +static const struct watchdog_info imx7ulp_wdt_info = {
> > + .identity = "i.MX7ULP watchdog timer",
> > + .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
> > + WDIOF_MAGICCLOSE,
> > +};
> > +
> > +static inline void imx7ulp_wdt_init(void __iomem *base, unsigned int
> > +timeout) {
> > + u32 val;
> > +
> > + /* unlock the wdog for reconfiguration */
> > + writel_relaxed(UNLOCK_SEQ0, base + WDOG_CNT);
> > + writel_relaxed(UNLOCK_SEQ1, base + WDOG_CNT);
> > +
> > + /* set an initial timeout value in TOVAL */
> > + writel(timeout, base + WDOG_TOVAL);
> > + /* enable 32bit command sequence and reconfigure */
> > + val = (1 << 13) | (1 << 8) | (1 << 5);
>
> Please use BIT()
Got it.
>
> > + writel(val, base + WDOG_CS);
> > +}
> > +
> > +static int imx7ulp_wdt_probe(struct platform_device *pdev) {
> > + struct imx7ulp_wdt_device *imx7ulp_wdt;
> > + struct device *dev = &pdev->dev;
> > + struct watchdog_device *wdog;
> > + int ret;
> > +
> > + imx7ulp_wdt = devm_kzalloc(&pdev->dev,
> > + sizeof(*imx7ulp_wdt), GFP_KERNEL);
> > + if (!imx7ulp_wdt)
> > + return -ENOMEM;
> > +
> > + platform_set_drvdata(pdev, imx7ulp_wdt);
> > +
> > + imx7ulp_wdt->base = devm_platform_ioremap_resource(pdev, 0);
> > + if (IS_ERR(imx7ulp_wdt->base))
> > + return PTR_ERR(imx7ulp_wdt->base);
> > +
> > + imx7ulp_wdt->rate = 1000;
> > + wdog = &imx7ulp_wdt->wdd;
> > + wdog->info = &imx7ulp_wdt_info;
> > + wdog->ops = &imx7ulp_wdt_ops;
> > + wdog->min_timeout = 1;
> > + wdog->max_timeout = MAX_TIMEOUT;
> > + wdog->parent = dev;
> > + wdog->timeout = DEFAULT_TIMEOUT;
> > +
> > + watchdog_init_timeout(wdog, 0, dev);
> > + watchdog_stop_on_reboot(wdog);
> > + watchdog_stop_on_unregister(wdog);
> > + watchdog_set_drvdata(wdog, imx7ulp_wdt);
> > + imx7ulp_wdt_init(imx7ulp_wdt->base, wdog->timeout *
> > +imx7ulp_wdt->rate);
> > +
> > + ret = devm_watchdog_register_device(dev, wdog);
> > + if (ret)
> > + dev_err(dev, "Failed to register watchdog device\n");
>
> An error message is already displayed by the watchdog core.
Got it.
>
> > +
> > + return ret;
> > +}
> > +
> > +static int __maybe_unused imx7ulp_wdt_suspend(struct device *dev) {
> > + struct imx7ulp_wdt_device *imx7ulp_wdt = dev_get_drvdata(dev);
> > +
> > + if (watchdog_active(&imx7ulp_wdt->wdd))
> > + imx7ulp_wdt_stop(&imx7ulp_wdt->wdd);
> > +
> > + return 0;
> > +}
> > +
> > +static int __maybe_unused imx7ulp_wdt_resume(struct device *dev) {
> > + struct imx7ulp_wdt_device *imx7ulp_wdt = dev_get_drvdata(dev);
> > + u32 timeout = imx7ulp_wdt->wdd.timeout * imx7ulp_wdt->rate;
> > +
> > + if (imx7ulp_wdt_is_enabled(imx7ulp_wdt->base))
> > + imx7ulp_wdt_init(imx7ulp_wdt->base, timeout);
> > +
> If I understand correctly, imx7ulp_wdt_is_enabled() returns true if the
> watchdog is running. Since it was stopped on suspend, that means that it was
> started in BIOS/rommon during resume.
>
> With that, the above translates to "If the watchdog was started by
> BIOS/rommon, re-initialize it. Otherwise do nothing". This doesn't really
> make much sense to me. What if the watchdog was reprogrammed by the
> BIOS/rommon, but not started ? In other words, why not call
> imx7ulp_wdt_init() unconditionally ?
The i.MX7ULP hardware design is, if A7 domain is powered off during suspend (mem suspend),
watchdog will be always reset and re-started by boot ROM. If A7 domain is NOT powered off during
suspend (standby suspend), the watchdog does NOT lose context and boot ROM NOT
run again after resume.
>
> Also, if it is possible that the watchdog is started by BIOS/rommon, why not
> keep it enabled and tell the watchdog core about it in the probe function ?
There are 2 cases of watchdog status during suspend/resume, i.MX7ULP supports
both standby suspend and mem suspend, for mem suspend, the whole A7 domain
will be powered off, and after resume, watchdog will be re-started by boot ROM (BIOS),
while for standby suspend, the watchdog does NOT re-started by boot ROM, as A7
domain is NOT powered off. That is why I added the check here, since there are 2 cases
sharing same suspend/resume callback. Does it make sense to you?
Thanks,
Anson
>
> > + if (watchdog_active(&imx7ulp_wdt->wdd))
> > + imx7ulp_wdt_start(&imx7ulp_wdt->wdd);
> > +
> > + return 0;
> > +}
> > +
> > +static SIMPLE_DEV_PM_OPS(imx7ulp_wdt_pm_ops,
> imx7ulp_wdt_suspend,
> > + imx7ulp_wdt_resume);
> > +
> > +static const struct of_device_id imx7ulp_wdt_dt_ids[] = {
> > + { .compatible = "fsl,imx7ulp-wdt", },
> > + { /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, imx7ulp_wdt_dt_ids);
> > +
> > +static struct platform_driver imx7ulp_wdt_driver = {
> > + .probe = imx7ulp_wdt_probe,
> > + .driver = {
> > + .name = "imx7ulp-wdt",
> > + .pm = &imx7ulp_wdt_pm_ops,
> > + .of_match_table = imx7ulp_wdt_dt_ids,
> > + },
> > +};
> > +module_platform_driver(imx7ulp_wdt_driver);
> > +
> > +MODULE_AUTHOR("Anson Huang <Anson.Huang@nxp.com>");
> > +MODULE_DESCRIPTION("Freescale i.MX7ULP watchdog driver");
> > +MODULE_LICENSE("GPL v2");
> > --
> > 2.7.4
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] pinctrl: aspeed: g6: Remove const specifier from aspeed_g6_sig_expr_set's ctx parameter
From: Andrew Jeffery @ 2019-08-12 0:51 UTC (permalink / raw)
To: Linus Walleij, Nathan Chancellor
Cc: linux-aspeed, clang-built-linux, OpenBMC Maillist,
linux-kernel@vger.kernel.org, open list:GPIO SUBSYSTEM,
Joel Stanley, Linux ARM
In-Reply-To: <CACRpkdbDgOQXfxgM4dEyzBRhtske3=V+858B7J8jGExnJE5fJQ@mail.gmail.com>
On Sat, 10 Aug 2019, at 17:43, Linus Walleij wrote:
> On Wed, Aug 7, 2019 at 2:32 AM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
>
> > clang errors:
> >
> > drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c:2325:9: error: incompatible
> > pointer types initializing 'int (*)(struct aspeed_pinmux_data *, const
> > struct aspeed_sig_expr *, bool)' with an expression of type 'int (const
> > struct aspeed_pinmux_data *, const struct aspeed_sig_expr *, bool)'
> > [-Werror,-Wincompatible-pointer-types]
> > .set = aspeed_g6_sig_expr_set,
> > ^~~~~~~~~~~~~~~~~~~~~~
> > 1 error generated.
> >
> > Commit 674fa8daa8c9 ("pinctrl: aspeed-g5: Delay acquisition of regmaps")
> > changed the set function pointer declaration and the g6 one wasn't
> > updated (I assume because it wasn't merged yet).
> >
> > Fixes: 2eda1cdec49f ("pinctrl: aspeed: Add AST2600 pinmux support")
> > Link: https://github.com/ClangBuiltLinux/linux/issues/632
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
>
> Patch applied with Andrew's ACK.
FYI this fixes pinctrl/for-next which is likely where Nathan ran into the issue,
however to fix pinctrl/devel we'll need a back-merge of pinctrl/fixes, or to
apply 674fa8daa8c9 ("pinctrl: aspeed-g5: Delay acquisition of regmaps") to
pinctrl/devel also.
Fixing that bug was unfortunate timing wrt the 2600 driver.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] ARM: dts: add device tree for Mecer Xtreme Mini S6
From: Justin Swartz @ 2019-08-11 23:00 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Heiko Stuebner
Cc: devicetree, Justin Swartz, linux-kernel, linux-arm-kernel,
linux-rockchip
The Mecer Xtreme Mini S6 features a Rockchip RK3229 SoC,
1GB DDR3 RAM, 8GB eMMC, MicroSD port, 10/100Mbps Ethernet,
Realtek 8723BS WLAN module, 2 x USB 2.0 ports, HDMI output,
and S/PDIF output.
Signed-off-by: Justin Swartz <justin.swartz@risingedge.co.za>
---
.../devicetree/bindings/arm/rockchip.yaml | 5 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/rk3229-xms6.dts | 283 +++++++++++++++++++++
4 files changed, 291 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3229-xms6.dts
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 34865042f4e4..4abd91c2b0bd 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -329,6 +329,11 @@ properties:
- khadas,edge-v
- const: rockchip,rk3399
+ - description: Mecer Xtreme Mini S6
+ items:
+ - const: mecer,xms6
+ - const: rockchip,rk3229
+
- description: mqmaker MiQi
items:
- const: mqmaker,miqi
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 6992bbbbffab..97992fccfc3d 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -549,6 +549,8 @@ patternProperties:
description: mCube
"^meas,.*":
description: Measurement Specialties
+ "^mecer,.*":
+ description: Mustek Limited
"^mediatek,.*":
description: MediaTek Inc.
"^megachips,.*":
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9159fa2cea90..4567c0b045c2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -905,6 +905,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3188-radxarock.dtb \
rk3228-evb.dtb \
rk3229-evb.dtb \
+ rk3229-xms6.dtb \
rk3288-evb-act8846.dtb \
rk3288-evb-rk808.dtb \
rk3288-fennec.dtb \
diff --git a/arch/arm/boot/dts/rk3229-xms6.dts b/arch/arm/boot/dts/rk3229-xms6.dts
new file mode 100644
index 000000000000..4b6ab4954dd4
--- /dev/null
+++ b/arch/arm/boot/dts/rk3229-xms6.dts
@@ -0,0 +1,283 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include <dt-bindings/input/input.h>
+#include "rk3229.dtsi"
+
+/ {
+ model = "Mecer Xtreme Mini S6";
+ compatible = "mecer,xms6", "rockchip,rk3229";
+
+ dc_12v: dc-12v-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "dc_12v";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ };
+
+ ext_gmac: ext_gmac {
+ compatible = "fixed-clock";
+ clock-frequency = <125000000>;
+ clock-output-names = "ext_gmac";
+ #clock-cells = <0>;
+ };
+
+ memory@60000000 {
+ device_type = "memory";
+ reg = <0x60000000 0x40000000>;
+ };
+
+ power-led {
+ compatible = "gpio-leds";
+
+ blue {
+ gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+ };
+
+ vcc_host: vcc-host-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio3 RK_PC4 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&host_vbus_drv>;
+ regulator-name = "vcc_host";
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <&vcc_sys>;
+ };
+
+ vcc_phy: vcc-phy-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ regulator-name = "vcc_phy";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <&vccio_1v8>;
+ };
+
+ vcc_sys: vcc-sys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&dc_12v>;
+ };
+
+ vccio_1v8: vccio-1v8-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vccio_1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ vin-supply = <&vcc_sys>;
+ };
+
+ vccio_3v3: vccio-3v3-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vccio_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ vin-supply = <&vcc_sys>;
+ };
+
+ vdd_arm: vdd-arm-regulator {
+ compatible = "pwm-regulator";
+ pwms = <&pwm1 0 25000 1>;
+ pwm-supply = <&vcc_sys>;
+ regulator-name = "vdd_arm";
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vdd_log: vdd-log-regulator {
+ compatible = "pwm-regulator";
+ pwms = <&pwm2 0 25000 1>;
+ pwm-supply = <&vcc_sys>;
+ regulator-name = "vdd_log";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+};
+
+&cpu0 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&cpu1 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&cpu2 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&cpu3 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&emmc {
+ cap-mmc-highspeed;
+ disable-wp;
+ non-removable;
+ status = "okay";
+};
+
+&gmac {
+ assigned-clocks = <&cru SCLK_MAC_SRC>;
+ assigned-clock-rates = <50000000>;
+ clock_in_out = "output";
+ phy-supply = <&vcc_phy>;
+ phy-mode = "rmii";
+ phy-handle = <&phy>;
+ status = "okay";
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy: phy@0 {
+ compatible = "ethernet-phy-id1234.d400",
+ "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ clocks = <&cru SCLK_MAC_PHY>;
+ resets = <&cru SRST_MACPHY>;
+ phy-is-integrated;
+ };
+ };
+};
+
+&gpu {
+ mali-supply = <&vdd_log>;
+ status = "okay";
+};
+
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_phy {
+ status = "okay";
+};
+
+&iep_mmu {
+ status = "okay";
+};
+
+&io_domains {
+ status = "okay";
+
+ vccio1-supply = <&vccio_3v3>;
+ vccio2-supply = <&vccio_1v8>;
+ vccio4-supply = <&vccio_3v3>;
+};
+
+&pinctrl {
+ usb {
+ host_vbus_drv: host-vbus-drv {
+ rockchip,pins = <3 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&pwm1 {
+ status = "okay";
+};
+
+&pwm2 {
+ status = "okay";
+};
+
+&sdmmc {
+ cap-mmc-highspeed;
+ disable-wp;
+ status = "okay";
+};
+
+&tsadc {
+ rockchip,hw-tshut-mode = <0>;
+ status = "okay";
+};
+
+&u2phy0 {
+ status = "okay";
+
+ u2phy0_host: host-port {
+ phy-supply = <&vcc_host>;
+ status = "okay";
+ };
+
+ u2phy0_otg: otg-port {
+ phy-supply = <&vcc_host>;
+ status = "okay";
+ };
+};
+
+&u2phy1 {
+ status = "okay";
+
+ u2phy1_host: host-port {
+ phy-supply = <&vcc_host>;
+ status = "okay";
+ };
+
+ u2phy1_otg: otg-port {
+ phy-supply = <&vcc_host>;
+ status = "okay";
+ };
+};
+
+&uart2 {
+ pinctrl-0 = <&uart21_xfer>;
+ status = "okay";
+};
+
+&usb_host0_ehci {
+ status = "okay";
+};
+
+&usb_host0_ohci {
+ status = "okay";
+};
+
+&usb_host1_ehci {
+ status = "okay";
+};
+
+&usb_host1_ohci {
+ status = "okay";
+};
+
+&usb_host2_ehci {
+ status = "okay";
+};
+
+&usb_host2_ohci {
+ status = "okay";
+};
+
+&usb_otg {
+ status = "okay";
+};
+
+&vop {
+ status = "okay";
+};
+
+&vop_mmu {
+ status = "okay";
+};
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v5 00/18] add thermal driver for h6
From: Clément Péron @ 2019-08-11 21:14 UTC (permalink / raw)
To: Yangtao Li, rui.zhang, edubezval, daniel.lezcano, robh+dt,
mark.rutland, maxime.ripard, wens, mchehab+samsung, davem, gregkh,
Jonathan.Cameron, nicolas.ferre
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-pm
In-Reply-To: <20190810052829.6032-1-tiny.windzz@gmail.com>
Hi Yangtao,
On 10/08/2019 07:28, Yangtao Li wrote:
> This patchset add support for A64, H3, H5, H6 and R40 thermal sensor.
Could you add the device-tree configuration in the same series?
This will allow user to test it.
Thanks,
Clément
>
> Thx to Icenowy and Vasily.
>
> BTY, do a cleanup in thermal makfile.
>
> Icenowy Zheng (3):
> thermal: sun8i: allow to use custom temperature calculation function
> thermal: sun8i: add support for Allwinner H5 thermal sensor
> thermal: sun8i: add support for Allwinner R40 thermal sensor
>
> Vasily Khoruzhick (1):
> thermal: sun8i: add thermal driver for A64
>
> Yangtao Li (14):
> thermal: sun8i: add thermal driver for h6
> dt-bindings: thermal: add binding document for h6 thermal controller
> thermal: fix indentation in makefile
> thermal: sun8i: get ths sensor number from device compatible
> thermal: sun8i: rework for sun8i_ths_get_temp()
> thermal: sun8i: get ths init func from device compatible
> thermal: sun8i: rework for ths irq handler func
> thermal: sun8i: support mod clocks
> thermal: sun8i: rework for ths calibrate func
> dt-bindings: thermal: add binding document for h3 thermal controller
> thermal: sun8i: add thermal driver for h3
> dt-bindings: thermal: add binding document for a64 thermal controller
> dt-bindings: thermal: add binding document for h5 thermal controller
> dt-bindings: thermal: add binding document for r40 thermal controller
>
> .../bindings/thermal/sun8i-thermal.yaml | 157 +++++
> MAINTAINERS | 7 +
> drivers/thermal/Kconfig | 14 +
> drivers/thermal/Makefile | 9 +-
> drivers/thermal/sun8i_thermal.c | 596 ++++++++++++++++++
> 5 files changed, 779 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml
> create mode 100644 drivers/thermal/sun8i_thermal.c
> ---
> v5:
> -add more support
> -some trival fix
> ---
> 2.17.1
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 0/4] Add drivers for auo, kd101n80-45na and boe, tv101wum-nl6 panels
From: Sam Ravnborg @ 2019-08-11 21:11 UTC (permalink / raw)
To: Jitao Shi
Cc: Mark Rutland, devicetree, David Airlie, stonea168, dri-devel,
Ajay Kumar, Vincent Palatin, cawa.cheng, yingjoe.chen,
Thierry Reding, Sean Paul, linux-pwm, Pawel Moll, Ian Campbell,
Rob Herring, linux-mediatek, Russell King, Matthias Brugger,
eddie.huang, linux-arm-kernel, Rahul Sharma, srv_heupstream,
linux-kernel, Sascha Hauer, Andy Yan
In-Reply-To: <20190811091001.49555-1-jitao.shi@mediatek.com>
Hi Jitao.
> .../display/panel/auo,kd101n80-45na.txt | 34 +
> .../display/panel/boe,tv101wum-nl6.txt | 34 +
panel bindings are in the process of being migrated to the new
meta-schema format.
Therefore new bindings should preferably also follow the new format.
Can you please look into this.
In upstream and drm-misc-next there is already some examples.
Note: It is not a hard rule that new bindings shall be in
the new meta-schema format (.yaml extension), but as this is
best practice now it is preferred.
Same goes for display bindings btw.
Sam
_______________________________________________
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 07/18] clk: bcm2835: Introduce SoC specific clock registration
From: Stefan Wahren @ 2019-08-11 20:43 UTC (permalink / raw)
To: Stefan Wahren, Eric Anholt, Florian Fainelli, Ray Jui,
Scott Branden, Nicolas Saenz Julienne, Matthias Brugger,
Rob Herring, Mark Rutland, Linus Walleij, Michael Turquette,
Stephen Boyd, Ulf Hansson, Adrian Hunter
Cc: linux-gpio, linux-mmc, linux-rpi-kernel, linux-arm-kernel,
bcm-kernel-feedback-list
In-Reply-To: <1563774880-8061-8-git-send-email-wahrenst@gmx.net>
Hi,
Am 22.07.19 um 07:54 schrieb Stefan Wahren:
> In order to support SoC specific clocks (e.g. emmc2 for BCM2711), we
> extend the description with a SoC support flag. This approach avoids long
> and mostly redundant lists of clock IDs.
>
> Suggested-by: Florian Fainelli <f.fainelli@gmail.com>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> ---
> drivers/clk/bcm/clk-bcm2835.c | 103 +++++++++++++++++++++++++++++++++++-------
> 1 file changed, 86 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
> index 867ae3c..3231b76 100644
> --- a/drivers/clk/bcm/clk-bcm2835.c
> +++ b/drivers/clk/bcm/clk-bcm2835.c
> @@ -31,7 +31,7 @@
> #include <linux/delay.h>
> #include <linux/io.h>
> #include <linux/module.h>
> -#include <linux/of.h>
> +#include <linux/of_device.h>
> #include <linux/platform_device.h>
> #include <linux/slab.h>
> #include <dt-bindings/clock/bcm2835.h>
> @@ -289,6 +289,9 @@
> #define LOCK_TIMEOUT_NS 100000000
> #define BCM2835_MAX_FB_RATE 1750000000u
>
> +#define SOC_BCM2835 BIT(0)
> +#define SOC_ALL (SOC_BCM2835)
> +
...
> .cm_reg = CM_PLLD,
> @@ -1775,6 +1805,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
> * It is in the HDMI power domain.
> */
> [BCM2835_PLLH] = REGISTER_PLL(
> + SOC_ALL,
> "pllh",
> .cm_ctrl_reg = CM_PLLH,
> .a2w_ctrl_reg = A2W_PLLH_CTRL,
> @@ -1789,6 +1820,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
> .max_rate = 3000000000u,
> .max_fb_rate = BCM2835_MAX_FB_RATE),
> [BCM2835_PLLH_RCAL] = REGISTER_PLL_DIV(
> + SOC_ALL,
> .name = "pllh_rcal",
> .source_pll = "pllh",
> .cm_reg = CM_PLLH,
> @@ -1798,6 +1830,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
> .fixed_divider = 10,
> .flags = CLK_SET_RATE_PARENT),
> [BCM2835_PLLH_AUX] = REGISTER_PLL_DIV(
> + SOC_ALL,
> .name = "pllh_aux",
> .source_pll = "pllh",
> .cm_reg = CM_PLLH,
> @@ -1807,6 +1840,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
> .fixed_divider = 1,
> .flags = CLK_SET_RATE_PARENT),
> [BCM2835_PLLH_PIX] = REGISTER_PLL_DIV(
> + SOC_ALL,
> .name = "pllh_pix",
> .source_pll = "pllh",
> .cm_reg = CM_PLLH,
i was informed that at least all PLLH related clocks are BCM2835
specific. So please don't apply this patch. I will send a fixed version
soon.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 3/3] arm64: defconfig: Enable Sun4i SPDIF module
From: Clément Péron @ 2019-08-11 20:31 UTC (permalink / raw)
To: Maxime Ripard, Rob Herring
Cc: devicetree, linux-sunxi, Clément Péron, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190811203144.5999-1-peron.clem@gmail.com>
Allwinner A64 and H6 use the Sun4i SPDIF driver.
Enable this to allow a proper support.
Signed-off-by: Clément Péron <peron.clem@gmail.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0e58ef02880c..b0638849c14c 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -558,6 +558,7 @@ CONFIG_SND_SOC_ROCKCHIP_RT5645=m
CONFIG_SND_SOC_RK3399_GRU_SOUND=m
CONFIG_SND_SOC_SAMSUNG=y
CONFIG_SND_SOC_RCAR=m
+CONFIG_SND_SUN4I_SPDIF=m
CONFIG_SND_SOC_AK4613=m
CONFIG_SND_SOC_ES7134=m
CONFIG_SND_SOC_ES7241=m
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 2/3] arm64: dts: allwinner: h6: Enable SPDIF for Beelink GS1
From: Clément Péron @ 2019-08-11 20:31 UTC (permalink / raw)
To: Maxime Ripard, Rob Herring
Cc: devicetree, linux-sunxi, Clément Péron, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190811203144.5999-1-peron.clem@gmail.com>
Beelink GS1 board has a SPDIF out connector, so enable it in
the device-tree.
Signed-off-by: Clément Péron <peron.clem@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
index 0dc33c90dd60..76a95ad33dc5 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
@@ -243,6 +243,10 @@
vcc-pm-supply = <®_aldo1>;
};
+&spdif {
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_ph_pins>;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 0/3] Allwinner H6 SPDIF support
From: Clément Péron @ 2019-08-11 20:31 UTC (permalink / raw)
To: Maxime Ripard, Rob Herring
Cc: devicetree, linux-sunxi, Clément Péron, linux-kernel,
linux-arm-kernel
Allwinner H6 SoC has a SPDIF controller called One Wire Audio (OWA) which
is different from the previous H3 generation and not compatible.
Difference are an increase of fifo sizes, some memory mapping are different
and there is now the possibility to output the master clock on a pin.
Actually all these features are unused and only a bit for flushing the TX
fifo is required.
Changes since v4:
- rename audio card name to sun50i-h6-spdif
- drop patches already merged
Changes since v3:
- rename reg_fctl_ftx to val_fctl_ftx
- rebase this series on sound-next
- fix dt-bindings due to change in sound-next
- change node name sound_spdif to sound-spdif
Changes since v2:
- Split quirks and H6 support patch
- Add specific section for quirks comment
Changes since v1:
- Remove H3 compatible
- Add TX fifo bit flush quirks
- Add H6 bindings in SPDIF driver
Clément Péron (3):
arm64: dts: allwinner: Add SPDIF node for Allwinner H6
arm64: dts: allwinner: h6: Enable SPDIF for Beelink GS1
arm64: defconfig: Enable Sun4i SPDIF module
.../dts/allwinner/sun50i-h6-beelink-gs1.dts | 4 ++
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 38 +++++++++++++++++++
arch/arm64/configs/defconfig | 1 +
3 files changed, 43 insertions(+)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 1/3] arm64: dts: allwinner: Add SPDIF node for Allwinner H6
From: Clément Péron @ 2019-08-11 20:31 UTC (permalink / raw)
To: Maxime Ripard, Rob Herring
Cc: devicetree, linux-sunxi, Clément Péron, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190811203144.5999-1-peron.clem@gmail.com>
The Allwinner H6 has a SPDIF controller called OWA (One Wire Audio).
Only one pinmuxing is available so set it as default.
Signed-off-by: Clément Péron <peron.clem@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 38 ++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 7628a7c83096..677eb374678d 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -83,6 +83,24 @@
method = "smc";
};
+ sound-spdif {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "sun50i-h6-spdif";
+
+ simple-audio-card,cpu {
+ sound-dai = <&spdif>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&spdif_out>;
+ };
+ };
+
+ spdif_out: spdif-out {
+ #sound-dai-cells = <0>;
+ compatible = "linux,spdif-dit";
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupts = <GIC_PPI 13
@@ -282,6 +300,11 @@
bias-pull-up;
};
+ spdif_tx_pin: spdif-tx-pin {
+ pins = "PH7";
+ function = "spdif";
+ };
+
uart0_ph_pins: uart0-ph-pins {
pins = "PH0", "PH1";
function = "uart0";
@@ -411,6 +434,21 @@
};
};
+ spdif: spdif@5093000 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun50i-h6-spdif";
+ reg = <0x05093000 0x400>;
+ interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_SPDIF>, <&ccu CLK_SPDIF>;
+ clock-names = "apb", "spdif";
+ resets = <&ccu RST_BUS_SPDIF>;
+ dmas = <&dma 2>;
+ dma-names = "tx";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spdif_tx_pin>;
+ status = "disabled";
+ };
+
usb2otg: usb@5100000 {
compatible = "allwinner,sun50i-h6-musb",
"allwinner,sun8i-a33-musb";
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 12/18] pinctrl: bcm2835: Add support for BCM2711 pull-up functionality
From: Stefan Wahren @ 2019-08-11 20:15 UTC (permalink / raw)
To: Linus Walleij
Cc: Mark Rutland, Ulf Hansson, Matthias Brugger, Scott Branden,
open list:GPIO SUBSYSTEM, Stephen Boyd, Ray Jui,
Michael Turquette, linux-mmc, Adrian Hunter, Rob Herring,
Eric Anholt, Florian Fainelli, bcm-kernel-feedback-list,
Linux ARM, Nicolas Saenz Julienne, linux-rpi-kernel
In-Reply-To: <CACRpkdabfiDbGmAQciAUSThY-KfTsVq3tHz0bBszs2j_ej18Nw@mail.gmail.com>
Am 05.08.19 um 11:38 schrieb Linus Walleij:
> On Mon, Jul 22, 2019 at 8:24 AM Stefan Wahren <wahrenst@gmx.net> wrote:
>
>> The BCM2711 has a new way of selecting the pull-up/pull-down setting
>> for a GPIO pin. The registers used for the BCM2835, GP_PUD and
>> GP_PUDCLKn0, are no longer connected. A new set of registers,
>> GP_GPIO_PUP_PDN_CNTRL_REGx must be used. This commit will add
>> a new compatible string "brcm,bcm2711-gpio" and the kernel
>> driver will use it to select which method is used to select
>> pull-up/pull-down.
>>
>> This patch based on a patch by Al Cooper which was intended for the
>> BCM7211. This is a bugfixed and improved version.
>>
>> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> Patch applied.
Thanks
>
> I think I complained about some other version of this patch, this one
> looks entirely acceptable.
>
> Can we get rid of custom pull settings etc from the upstream device
> trees so we don't set bad examples? I have a strong urge to
> throw in a pr_warn() about any use of it.
Ironically, my pre-RFC version tried to convert all BCM2835 pinmux
settings to generic ones. Unfortunately it seems that i made a mistake,
because it didn't work as expected. Since we stumpled above more and
more other issues (not relevant to pinctrl) during upstream review, i
decided to start with legacy pull-up support, so we can fix this later
in the devicetree for both platforms (currently BCM2711 uses most of the
old BCM2835 pinmuxes including the legacy stuff). So yes my plan is to
fix this soon.
Stefan
>
> Yours,
> Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [BUG] fec mdio times out under system stress
From: Andrew Lunn @ 2019-08-11 16:44 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: netdev, Florian Fainelli, Fabio Estevam, linux-arm-kernel,
Heiner Kallweit
In-Reply-To: <20190811133707.GC13294@shell.armlinux.org.uk>
> Maybe phylib should retry a number of times - but with read-sensitive
> registers, if the read has already completed successfully, and its
> just a problem with the FEC MDIO hardware, that could cause issues.
Hi Russell
At the bus level, MDIO cannot fail. The bits get clocked out, and the
bits get clocked in. There is no way for the PHY to stretch the clock
as I2C slaves can. There is nothing like the USB NACK, try again
later.
If something fails, it fails at a higher level, which means it is a
driver issue. In this case, the interrupt got delayed, after the timer
interrupt.
The FEC is also quite unusual in using an interrupt. Most MDIO drivers
poll. And if time gets 'stretched' because the system is too busy,
generally, the right thing happens anyway.
So i don't think it is phylib job to work around this issue.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [BUG] fec mdio times out under system stress
From: Andrew Lunn @ 2019-08-11 16:31 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: netdev, Florian Fainelli, Fabio Estevam, linux-arm-kernel,
Heiner Kallweit
In-Reply-To: <20190811133707.GC13294@shell.armlinux.org.uk>
On Sun, Aug 11, 2019 at 02:37:07PM +0100, Russell King - ARM Linux admin wrote:
> Hi Fabio,
>
> When I woke up this morning, I found that one of the Hummingboards
> had gone offline (as in, lost network link) during the night.
> Investigating, I find that the system had gone into OOM, and at
> that time, triggered an unrelated:
>
> [4111697.698776] fec 2188000.ethernet eth0: MDIO read timeout
> [4111697.712996] MII_DATA: 0x6006796d
> [4111697.729415] MII_SPEED: 0x0000001a
> [4111697.745232] IEVENT: 0x00000000
> [4111697.745242] IMASK: 0x0a8000aa
> [4111698.002233] Atheros 8035 ethernet 2188000.ethernet-1:00: PHY state change RUNNING -> HALTED
> [4111698.009882] fec 2188000.ethernet eth0: Link is Down
>
> This is on a dual-core iMX6.
>
> It looks like the read actually completed (since MII_DATA contains
> the register data) but we somehow lost the interrupt (or maybe
> received the interrupt after wait_for_completion_timeout() timed
> out.)
Hi Russell
The timeout is quite short,
#define FEC_MII_TIMEOUT 30000 /* us */
Looking at the Vybrid datasheet, there does not appear to be any way
to determine if the hardware is busy other than waiting for the
interrupt. There is no 'busy' bit which gets cleared on completion.
So about the only option is to make the timeout bigger.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [BUG] fec mdio times out under system stress
From: Andrew Lunn @ 2019-08-11 16:03 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Florian Fainelli, netdev, Russell King - ARM Linux admin,
Hubert Feurstein, Fabio Estevam, linux-arm-kernel,
Heiner Kallweit
In-Reply-To: <CA+h21hqkVoQWRweKKCFdvLLOLyP4gEtXQvJ9CO_J7i+YQW+TWw@mail.gmail.com>
> I think a better question is why is the FEC MDIO controller configured
> to emit interrupts anyway (especially since the API built on top does
> not benefit in any way from this)? Hubert (copied) sent an interesting
> email very recently where he pointed out that this is one of the main
> sources of jitter when reading the PTP clock on a Marvell switch
> attached over MDIO.
Hi Vladimir
One reason is runtime power management.
For a write operation, you could set it going and return
immediately. Many drivers do, and then when the next read/write
operation comes along, they poll in a loop waiting for the device to
go idle, if it was still busy from the last operation.
However, FEC supports runtime PM. When an MDIO read/write call is
made, it calls runtime PM functions to indicate the device is active.
Once it has completed the MDIO transaction, it calls runtime PM
functions to indicate the device is inactive. These transitions can
cause clocks to be enabled/disabled. If we don't wait around for the
operation to complete, the clock could be disabled too early, and bad
things would happen.
You could replace the interrupt with a sleeping poll, but my guess
would be, that has more jitter than using an interrupt.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/6] thermal: amlogic: Add thermal driver to support G12 SoCs
From: Martin Blumenstingl @ 2019-08-11 15:43 UTC (permalink / raw)
To: Guillaume La Roque
Cc: devicetree, linux-pm, khilman, daniel.lezcano, linux-kernel,
Neil Armstrong, linux-amlogic, linux-arm-kernel
In-Reply-To: <20190806130506.8753-3-glaroque@baylibre.com>
Hi Guillaume,
[...]
> +struct amlogic_thermal {
> + struct platform_device *pdev;
> + const struct amlogic_thermal_data *data;
> + struct regmap *regmap;
> + struct regmap *sec_ao_map;
> + struct clk *clk;
> + struct thermal_zone_device *tzd;
> + u32 trim_info;
> + void __iomem *base;
nit-pick: this is only used in _probe() so you could make it a local
variable there
[...]
> +static const struct of_device_id of_amlogic_thermal_match[] = {
> + {
> + .compatible = "amlogic,g12-ddr-thermal",
> + .data = &amlogic_thermal_g12_ddr_param,
> + },
> + {
> + .compatible = "amlogic,g12-cpu-thermal",
> + .data = &amlogic_thermal_g12_cpu_param,
> + },
I assume you are using "g12" to indicate that it's valid for both,
G12A and G12B?
meson-g12-common.dtsi currently does not use any other "amlogic,g12-*"
compatible string (there are some meson-axg-*, meson-gx-* and
meson-g12a-* ones, but no g12-*)
I would like to hear Kevin's and Neil's opinion on this one whether we
should introduce that "amlogic,g12-*" prefix or stick to
"amlogic,g12a-*"
[...]
> + ret = amlogic_thermal_enable(pdata);
> + if (ret)
> + clk_disable_unprepare(pdata->clk);
amlogic_thermal_enable only returns an error-code if clk_prepare_enable() fails
in that case the clock is neither prepared nor enabled so we must not
call clk_disable_unprepare
apart from that it looks good to me (as someone who doesn't know the
thermal framework)
Martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [BUG] fec mdio times out under system stress
From: Vladimir Oltean @ 2019-08-11 14:54 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, Florian Fainelli, netdev, Hubert Feurstein,
Fabio Estevam, linux-arm-kernel, Heiner Kallweit
In-Reply-To: <20190811133707.GC13294@shell.armlinux.org.uk>
Hi Russell, Fabio,
On Sun, 11 Aug 2019 at 16:42, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> Hi Fabio,
>
> When I woke up this morning, I found that one of the Hummingboards
> had gone offline (as in, lost network link) during the night.
> Investigating, I find that the system had gone into OOM, and at
> that time, triggered an unrelated:
>
> [4111697.698776] fec 2188000.ethernet eth0: MDIO read timeout
> [4111697.712996] MII_DATA: 0x6006796d
> [4111697.729415] MII_SPEED: 0x0000001a
> [4111697.745232] IEVENT: 0x00000000
> [4111697.745242] IMASK: 0x0a8000aa
> [4111698.002233] Atheros 8035 ethernet 2188000.ethernet-1:00: PHY state change RUNNING -> HALTED
> [4111698.009882] fec 2188000.ethernet eth0: Link is Down
>
> This is on a dual-core iMX6.
>
> It looks like the read actually completed (since MII_DATA contains
> the register data) but we somehow lost the interrupt (or maybe
> received the interrupt after wait_for_completion_timeout() timed
> out.)
>
> From what I can see, the OOM events happened on CPU1, CPU1 was
> allocated the FEC interrupt, and the PHY polling that suffered the
> MDIO timeout was on CPU0.
>
> Given that IEVENT is zero, it seems that CPU1 had read serviced the
> interrupt, but it is not clear how far through processing that it
> was - it may be that fec_enet_interrupt() had been delayed by the
> OOM condition.
>
> This seems rather fragile - as the system slowing down due to OOM
> triggers the network to completely collapse by phylib taking the
> PHY offline, making the system inaccessible except through the
> console.
>
> In my case, even serial console wasn't operational (except for
> magic sysrq). Not sure what agetty was playing at... so the only
> way I could recover any information from the system was to connect
> the HDMI and plug in a USB keyboard.
>
> Any thoughts on how FEC MDIO accesses could be made more robust?
>
I think a better question is why is the FEC MDIO controller configured
to emit interrupts anyway (especially since the API built on top does
not benefit in any way from this)? Hubert (copied) sent an interesting
email very recently where he pointed out that this is one of the main
sources of jitter when reading the PTP clock on a Marvell switch
attached over MDIO.
> Maybe phylib should retry a number of times - but with read-sensitive
> registers, if the read has already completed successfully, and its
> just a problem with the FEC MDIO hardware, that could cause issues.
>
> Thanks.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
Regards,
-Vladimir
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [BUG] fec mdio times out under system stress
From: Russell King - ARM Linux admin @ 2019-08-11 14:06 UTC (permalink / raw)
To: linux-arm-kernel, Fabio Estevam, netdev, Andrew Lunn,
Florian Fainelli, Heiner Kallweit
In-Reply-To: <20190811133707.GC13294@shell.armlinux.org.uk>
On Sun, Aug 11, 2019 at 02:37:07PM +0100, Russell King - ARM Linux admin wrote:
> Hi Fabio,
>
> When I woke up this morning, I found that one of the Hummingboards
> had gone offline (as in, lost network link) during the night.
> Investigating, I find that the system had gone into OOM, and at
> that time, triggered an unrelated:
>
> [4111697.698776] fec 2188000.ethernet eth0: MDIO read timeout
> [4111697.712996] MII_DATA: 0x6006796d
> [4111697.729415] MII_SPEED: 0x0000001a
> [4111697.745232] IEVENT: 0x00000000
> [4111697.745242] IMASK: 0x0a8000aa
> [4111698.002233] Atheros 8035 ethernet 2188000.ethernet-1:00: PHY state change RUNNING -> HALTED
> [4111698.009882] fec 2188000.ethernet eth0: Link is Down
>
> This is on a dual-core iMX6.
>
> It looks like the read actually completed (since MII_DATA contains
> the register data) but we somehow lost the interrupt (or maybe
> received the interrupt after wait_for_completion_timeout() timed
> out.)
>
> From what I can see, the OOM events happened on CPU1, CPU1 was
> allocated the FEC interrupt, and the PHY polling that suffered the
> MDIO timeout was on CPU0.
>
> Given that IEVENT is zero, it seems that CPU1 had read serviced the
> interrupt, but it is not clear how far through processing that it
> was - it may be that fec_enet_interrupt() had been delayed by the
> OOM condition.
>
> This seems rather fragile - as the system slowing down due to OOM
> triggers the network to completely collapse by phylib taking the
> PHY offline, making the system inaccessible except through the
> console.
>
> In my case, even serial console wasn't operational (except for
> magic sysrq). Not sure what agetty was playing at... so the only
> way I could recover any information from the system was to connect
> the HDMI and plug in a USB keyboard.
>
> Any thoughts on how FEC MDIO accesses could be made more robust?
>
> Maybe phylib should retry a number of times - but with read-sensitive
> registers, if the read has already completed successfully, and its
> just a problem with the FEC MDIO hardware, that could cause issues.
I should also note for the phylib people:
After phylib has received an error, and has entered the HALTED state,
downing the interface produces this warning, which seems rather unfair
as the FEC doesn't know that its PHY suffered an error - it is merely
reversing the phy_start() that happened when the interface was opened.
[4144039.099786] ------------[ cut here ]------------
[4144039.109001] WARNING: CPU: 1 PID: 25842 at drivers/net/phy/phy.c:835 fec_enet_close+0x14/0x148
[4144039.124366] called from state HALTED
[4144039.132626] Modules linked in: 8021q brcmfmac brcmutil imx_thermal
snd_soc_imx_spdif snd_soc_imx_audmux nvmem_imx_ocotp cfg80211
snd_soc_sgtl5000 imx_sdma
virt_dma rc_cec snd_soc_fsl_ssi snd_soc_fsl_spdif coda imx_pcm_dma
v4l2_mem2mem
imx_vdoa etnaviv videobuf2_dma_contig gpu_sched dw_hdmi_cec
dw_hdmi_ahb_audio imx6q_cpufreq caamrng caam_jr caam error ip_tables
x_tables [last unloaded: evbug][4144039.177249] CPU: 1 PID: 25842 Comm:
ip Tainted: G W 5.1.0+ #319
[4144039.189477] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[4144039.201025] [<c00194f0>] (unwind_backtrace) from [<c0014748>] (show_stack+0x10/0x14)
[4144039.213769] [<c0014748>] (show_stack) from [<c082e11c>] (dump_stack+0x9c/0xd4)
[4144039.225959] [<c082e11c>] (dump_stack) from [<c0030f3c>] (__warn+0xf8/0x124)
[4144039.237828] [<c0030f3c>] (__warn) from [<c0031030>] (warn_slowpath_fmt+0x38/0x48)
[4144039.250275] [<c0031030>] (warn_slowpath_fmt) from [<c052cb14>] (fec_enet_close+0x14/0x148)
[4144039.263558] [<c052cb14>] (fec_enet_close) from [<c066b5bc>] (__dev_close_many+0x88/0xf0)
[4144039.276639] [<c066b5bc>] (__dev_close_many) from [<c06740cc>] (__dev_change_flags+0xa4/0x1a0)
[4144039.290130] [<c06740cc>] (__dev_change_flags) from [<c06741e8>] (dev_change_flags+0x18/0x48)
[4144039.303558] [<c06741e8>] (dev_change_flags) from [<c068db80>] (do_setlink+0x29c/0x990)
[4144039.316517] [<c068db80>] (do_setlink) from [<c068eae8>] (__rtnl_newlink+0x4a4/0x72c)
[4144039.329282] [<c068eae8>] (__rtnl_newlink) from [<c068edb0>] (rtnl_newlink+0x40/0x60)
[4144039.342023] [<c068edb0>] (rtnl_newlink) from [<c0689a10>] (rtnetlink_rcv_msg+0x244/0x470)
[4144039.355224] [<c0689a10>] (rtnetlink_rcv_msg) from [<c06d20a0>] (netlink_rcv_skb+0xe0/0xf4)
[4144039.368492] [<c06d20a0>] (netlink_rcv_skb) from [<c06d194c>] (netlink_unicast+0x170/0x1b8)
[4144039.381758] [<c06d194c>] (netlink_unicast) from [<c06d1cdc>] (netlink_sendmsg+0x2b8/0x340)
[4144039.395023] [<c06d1cdc>] (netlink_sendmsg) from [<c064999c>] (sock_sendmsg+0x14/0x24)
[4144039.407825] [<c064999c>] (sock_sendmsg) from [<c064a5a0>] (___sys_sendmsg+0x200/0x214)
[4144039.420714] [<c064a5a0>] (___sys_sendmsg) from [<c064b0c4>] (__sys_sendmsg+0x40/0x6c)
[4144039.433506] [<c064b0c4>] (__sys_sendmsg) from [<c0009000>] (ret_fast_syscall+0x0/0x28)
[4144039.446366] Exception stack(0xe1933fa8 to 0xe1933ff0)
[4144039.456329] 3fa0: bea086f0 bea086bc 00000003 bea086d0 00000000 00000000
[4144039.469464] 3fc0: bea086f0 bea086bc 00000000 00000128 0062a278 bea086d0 5d5011f3 0062a000
[4144039.482590] 3fe0: 00000128 bea08680 b6dfc4cb b6d7d6f6
[4144039.492652] irq event stamp: 0
[4144039.500650] hardirqs last enabled at (0): [<00000000>] (null)
[4144039.511628] hardirqs last disabled at (0): [<c002e55c>] copy_process.part.4+0x30c/0x19e8
[4144039.524691] softirqs last enabled at (0): [<c002e55c>] copy_process.part.4+0x30c/0x19e8
[4144039.537691] softirqs last disabled at (0): [<00000000>] (null)
[4144039.548554] ---[ end trace b5e8d4b0f30ae00b ]---
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [BUG] fec mdio times out under system stress
From: Russell King - ARM Linux admin @ 2019-08-11 13:37 UTC (permalink / raw)
To: linux-arm-kernel, Fabio Estevam, netdev, Andrew Lunn,
Florian Fainelli, Heiner Kallweit
Hi Fabio,
When I woke up this morning, I found that one of the Hummingboards
had gone offline (as in, lost network link) during the night.
Investigating, I find that the system had gone into OOM, and at
that time, triggered an unrelated:
[4111697.698776] fec 2188000.ethernet eth0: MDIO read timeout
[4111697.712996] MII_DATA: 0x6006796d
[4111697.729415] MII_SPEED: 0x0000001a
[4111697.745232] IEVENT: 0x00000000
[4111697.745242] IMASK: 0x0a8000aa
[4111698.002233] Atheros 8035 ethernet 2188000.ethernet-1:00: PHY state change RUNNING -> HALTED
[4111698.009882] fec 2188000.ethernet eth0: Link is Down
This is on a dual-core iMX6.
It looks like the read actually completed (since MII_DATA contains
the register data) but we somehow lost the interrupt (or maybe
received the interrupt after wait_for_completion_timeout() timed
out.)
From what I can see, the OOM events happened on CPU1, CPU1 was
allocated the FEC interrupt, and the PHY polling that suffered the
MDIO timeout was on CPU0.
Given that IEVENT is zero, it seems that CPU1 had read serviced the
interrupt, but it is not clear how far through processing that it
was - it may be that fec_enet_interrupt() had been delayed by the
OOM condition.
This seems rather fragile - as the system slowing down due to OOM
triggers the network to completely collapse by phylib taking the
PHY offline, making the system inaccessible except through the
console.
In my case, even serial console wasn't operational (except for
magic sysrq). Not sure what agetty was playing at... so the only
way I could recover any information from the system was to connect
the HDMI and plug in a USB keyboard.
Any thoughts on how FEC MDIO accesses could be made more robust?
Maybe phylib should retry a number of times - but with read-sensitive
registers, if the read has already completed successfully, and its
just a problem with the FEC MDIO hardware, that could cause issues.
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4] firmware: imx: Add DSP IPC protocol interface
From: Daniel Baluta @ 2019-08-11 13:21 UTC (permalink / raw)
To: Daniel Baluta
Cc: Aisheng Dong, Anson Huang, Shawn Guo, Sascha Hauer,
Sridharan, Ranjani, Linux Kernel Mailing List,
Pierre-Louis Bossart, Oleksij Rempel, dl-linux-imx,
Pengutronix Kernel Team, Greg Kroah-Hartman, tglx, Fabio Estevam,
linux-arm-kernel, sound-open-firmware
In-Reply-To: <20190801095636.22944-1-daniel.baluta@nxp.com>
Hi Shawn,
Can you please have a look at this when you have some time?
Basically, we need this patch for imx8 SOF Linux driver:
https://github.com/thesofproject/linux/pull/1048
I already got:
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
For an older version of this patch.
thanks,
Daniel.
On Thu, Aug 1, 2019 at 1:02 PM Daniel Baluta <daniel.baluta@nxp.com> wrote:
>
> Some of i.MX8 processors (e.g i.MX8QM, i.MX8QXP) contain
> the Tensilica HiFi4 DSP for advanced pre- and post-audio
> processing.
>
> The communication between Host CPU and DSP firmware is
> taking place using a shared memory area for message passing
> and a dedicated Messaging Unit for notifications.
>
> DSP IPC protocol offers a doorbell interface using
> imx-mailbox API.
>
> We use 4 MU channels (2 x TXDB, 2 x RXDB) to implement a
> request-reply protocol.
>
> Connection 0 (txdb0, rxdb0):
> - Host writes messasge to shared memory [SHMEM]
> - Host sends a request [MU]
> - DSP handles request [SHMEM]
> - DSP sends reply [MU]
>
> Connection 1 (txdb1, rxdb1):
> - DSP writes a message to shared memory [SHMEM]
> - DSP sends a request [MU]
> - Host handles request [SHMEM]
> - Host sends reply [MU]
>
> The protocol interface will be used by a Host client to
> communicate with the DSP. First client will be the i.MX8
> part from Sound Open Firmware infrastructure.
>
> The protocol offers the following interface:
>
> On Tx:
> - imx_dsp_ring_doorbell, will be called to notify the DSP
> that it needs to handle a request.
>
> On Rx:
> - clients need to provide two callbacks:
> .handle_reply
> .handle_request
> - the callbacks will be used by the protocol on
> notification arrival from DSP.
>
> Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
> ---
> Changes since v3:
> - Added remove function
>
> drivers/firmware/imx/Kconfig | 11 +++
> drivers/firmware/imx/Makefile | 1 +
> drivers/firmware/imx/imx-dsp.c | 155 +++++++++++++++++++++++++++++++
> include/linux/firmware/imx/dsp.h | 67 +++++++++++++
> 4 files changed, 234 insertions(+)
> create mode 100644 drivers/firmware/imx/imx-dsp.c
> create mode 100644 include/linux/firmware/imx/dsp.h
>
> diff --git a/drivers/firmware/imx/Kconfig b/drivers/firmware/imx/Kconfig
> index 42b566f8903f..0dbee32da4c6 100644
> --- a/drivers/firmware/imx/Kconfig
> +++ b/drivers/firmware/imx/Kconfig
> @@ -1,4 +1,15 @@
> # SPDX-License-Identifier: GPL-2.0-only
> +config IMX_DSP
> + bool "IMX DSP Protocol driver"
> + depends on IMX_MBOX
> + help
> + This enables DSP IPC protocol between host AP (Linux)
> + and the firmware running on DSP.
> + DSP exists on some i.MX8 processors (e.g i.MX8QM, i.MX8QXP).
> +
> + It acts like a doorbell. Client might use shared memory to
> + exchange information with DSP side.
> +
> config IMX_SCU
> bool "IMX SCU Protocol driver"
> depends on IMX_MBOX
> diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile
> index 802c4ad8e8f9..08bc9ddfbdfb 100644
> --- a/drivers/firmware/imx/Makefile
> +++ b/drivers/firmware/imx/Makefile
> @@ -1,3 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
> +obj-$(CONFIG_IMX_DSP) += imx-dsp.o
> obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o
> obj-$(CONFIG_IMX_SCU_PD) += scu-pd.o
> diff --git a/drivers/firmware/imx/imx-dsp.c b/drivers/firmware/imx/imx-dsp.c
> new file mode 100644
> index 000000000000..a43d2db5cbdb
> --- /dev/null
> +++ b/drivers/firmware/imx/imx-dsp.c
> @@ -0,0 +1,155 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2019 NXP
> + * Author: Daniel Baluta <daniel.baluta@nxp.com>
> + *
> + * Implementation of the DSP IPC interface (host side)
> + */
> +
> +#include <linux/firmware/imx/dsp.h>
> +#include <linux/kernel.h>
> +#include <linux/mailbox_client.h>
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +
> +/*
> + * imx_dsp_ring_doorbell - triggers an interrupt on the other side (DSP)
> + *
> + * @dsp: DSP IPC handle
> + * @chan_idx: index of the channel where to trigger the interrupt
> + *
> + * Returns non-negative value for success, negative value for error
> + */
> +int imx_dsp_ring_doorbell(struct imx_dsp_ipc *ipc, unsigned int idx)
> +{
> + int ret;
> + struct imx_dsp_chan *dsp_chan;
> +
> + if (idx >= DSP_MU_CHAN_NUM)
> + return -EINVAL;
> +
> + dsp_chan = &ipc->chans[idx];
> + ret = mbox_send_message(dsp_chan->ch, NULL);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(imx_dsp_ring_doorbell);
> +
> +/*
> + * imx_dsp_handle_rx - rx callback used by imx mailbox
> + *
> + * @c: mbox client
> + * @msg: message received
> + *
> + * Users of DSP IPC will need to privde handle_reply and handle_request
> + * callbacks.
> + */
> +static void imx_dsp_handle_rx(struct mbox_client *c, void *msg)
> +{
> + struct imx_dsp_chan *chan = container_of(c, struct imx_dsp_chan, cl);
> +
> + if (chan->idx == 0) {
> + chan->ipc->ops->handle_reply(chan->ipc);
> + } else {
> + chan->ipc->ops->handle_request(chan->ipc);
> + imx_dsp_ring_doorbell(chan->ipc, 1);
> + }
> +}
> +
> +static int imx_dsp_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct imx_dsp_ipc *dsp_ipc;
> + struct imx_dsp_chan *dsp_chan;
> + struct mbox_client *cl;
> + char *chan_name;
> + int ret;
> + int i, j;
> +
> + device_set_of_node_from_dev(&pdev->dev, pdev->dev.parent);
> +
> + dsp_ipc = devm_kzalloc(dev, sizeof(*dsp_ipc), GFP_KERNEL);
> + if (!dsp_ipc)
> + return -ENOMEM;
> +
> + for (i = 0; i < DSP_MU_CHAN_NUM; i++) {
> + if (i < 2)
> + chan_name = kasprintf(GFP_KERNEL, "txdb%d", i);
> + else
> + chan_name = kasprintf(GFP_KERNEL, "rxdb%d", i - 2);
> +
> + if (!chan_name)
> + return -ENOMEM;
> +
> + dsp_chan = &dsp_ipc->chans[i];
> + cl = &dsp_chan->cl;
> + cl->dev = dev;
> + cl->tx_block = false;
> + cl->knows_txdone = true;
> + cl->rx_callback = imx_dsp_handle_rx;
> +
> + dsp_chan->ipc = dsp_ipc;
> + dsp_chan->idx = i % 2;
> + dsp_chan->ch = mbox_request_channel_byname(cl, chan_name);
> + if (IS_ERR(dsp_chan->ch)) {
> + ret = PTR_ERR(dsp_chan->ch);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to request mbox chan %s ret %d\n",
> + chan_name, ret);
> + goto out;
> + }
> +
> + dev_dbg(dev, "request mbox chan %s\n", chan_name);
> + /* chan_name is not used anymore by framework */
> + kfree(chan_name);
> + }
> +
> + dsp_ipc->dev = dev;
> +
> + dev_set_drvdata(dev, dsp_ipc);
> +
> + dev_info(dev, "NXP i.MX DSP IPC initialized\n");
> +
> + return devm_of_platform_populate(dev);
> +out:
> + kfree(chan_name);
> + for (j = 0; j < i; j++) {
> + dsp_chan = &dsp_ipc->chans[j];
> + mbox_free_channel(dsp_chan->ch);
> + }
> +
> + return ret;
> +}
> +
> +static int imx_dsp_remove(struct platform_device *pdev)
> +{
> + struct imx_dsp_chan *dsp_chan;
> + struct imx_dsp_ipc *dsp_ipc;
> + int i;
> +
> + dsp_ipc = dev_get_drvdata(&pdev->dev);
> +
> + for (i = 0; i < DSP_MU_CHAN_NUM; i++) {
> + dsp_chan = &dsp_ipc->chans[i];
> + mbox_free_channel(dsp_chan->ch);
> + }
> +
> + return 0;
> +}
> +
> +static struct platform_driver imx_dsp_driver = {
> + .driver = {
> + .name = "imx-dsp",
> + },
> + .probe = imx_dsp_probe,
> + .remove = imx_dsp_remove,
> +};
> +builtin_platform_driver(imx_dsp_driver);
> +
> +MODULE_AUTHOR("Daniel Baluta <daniel.baluta@nxp.com>");
> +MODULE_DESCRIPTION("IMX DSP IPC protocol driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/firmware/imx/dsp.h b/include/linux/firmware/imx/dsp.h
> new file mode 100644
> index 000000000000..7562099c9e46
> --- /dev/null
> +++ b/include/linux/firmware/imx/dsp.h
> @@ -0,0 +1,67 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright 2019 NXP
> + *
> + * Header file for the DSP IPC implementation
> + */
> +
> +#ifndef _IMX_DSP_IPC_H
> +#define _IMX_DSP_IPC_H
> +
> +#include <linux/device.h>
> +#include <linux/types.h>
> +#include <linux/mailbox_client.h>
> +
> +#define DSP_MU_CHAN_NUM 4
> +
> +struct imx_dsp_chan {
> + struct imx_dsp_ipc *ipc;
> + struct mbox_client cl;
> + struct mbox_chan *ch;
> + char *name;
> + int idx;
> +};
> +
> +struct imx_dsp_ops {
> + void (*handle_reply)(struct imx_dsp_ipc *ipc);
> + void (*handle_request)(struct imx_dsp_ipc *ipc);
> +};
> +
> +struct imx_dsp_ipc {
> + /* Host <-> DSP communication uses 2 txdb and 2 rxdb channels */
> + struct imx_dsp_chan chans[DSP_MU_CHAN_NUM];
> + struct device *dev;
> + struct imx_dsp_ops *ops;
> + void *private_data;
> +};
> +
> +static inline void imx_dsp_set_data(struct imx_dsp_ipc *ipc, void *data)
> +{
> + if (!ipc)
> + return;
> +
> + ipc->private_data = data;
> +}
> +
> +static inline void *imx_dsp_get_data(struct imx_dsp_ipc *ipc)
> +{
> + if (!ipc)
> + return NULL;
> +
> + return ipc->private_data;
> +}
> +
> +#if IS_ENABLED(CONFIG_IMX_DSP)
> +
> +int imx_dsp_ring_doorbell(struct imx_dsp_ipc *dsp, unsigned int chan_idx);
> +
> +#else
> +
> +static inline int imx_dsp_ring_doorbell(struct imx_dsp_ipc *ipc,
> + unsigned int chan_idx)
> +{
> + return -ENOTSUPP;
> +}
> +
> +#endif
> +#endif /* _IMX_DSP_IPC_H */
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 2/7] drm/mediatek: fixes CMDQ reg address of mt8173 is different with mt2701
From: Jitao Shi @ 2019-08-11 10:40 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
devicetree, Jitao Shi, Philipp Zabel, Inki Dae, linux-mediatek,
yingjoe.chen, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Sean Paul
In-Reply-To: <20190811104008.53372-1-jitao.shi@mediatek.com>
Config the different CMDQ reg address in driver data.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 29 ++++++++++++++++++++++++-----
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 52b49daeed9f..ac8e80e379f7 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -123,7 +123,6 @@
#define VM_CMD_EN BIT(0)
#define TS_VFP_EN BIT(5)
-#define DSI_CMDQ0 0x180
#define CONFIG (0xff << 0)
#define SHORT_PACKET 0
#define LONG_PACKET 2
@@ -148,6 +147,10 @@
struct phy;
+struct mtk_dsi_driver_data {
+ const u32 reg_cmdq_off;
+};
+
struct mtk_dsi {
struct mtk_ddp_comp ddp_comp;
struct device *dev;
@@ -174,6 +177,7 @@ struct mtk_dsi {
bool enabled;
u32 irq_data;
wait_queue_head_t irq_wait_queue;
+ const struct mtk_dsi_driver_data *driver_data;
};
static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
@@ -936,6 +940,7 @@ static void mtk_dsi_cmdq(struct mtk_dsi *dsi, const struct mipi_dsi_msg *msg)
const char *tx_buf = msg->tx_buf;
u8 config, cmdq_size, cmdq_off, type = msg->type;
u32 reg_val, cmdq_mask, i;
+ u32 reg_cmdq_off = dsi->driver_data->reg_cmdq_off;
if (MTK_DSI_HOST_IS_READ(type))
config = BTA;
@@ -955,9 +960,11 @@ static void mtk_dsi_cmdq(struct mtk_dsi *dsi, const struct mipi_dsi_msg *msg)
}
for (i = 0; i < msg->tx_len; i++)
- writeb(tx_buf[i], dsi->regs + DSI_CMDQ0 + cmdq_off + i);
+ mtk_dsi_mask(dsi, (reg_cmdq_off + cmdq_off + i) & (~0x3U),
+ (0xffUL << (((i + cmdq_off) & 3U) * 8U)),
+ tx_buf[i] << (((i + cmdq_off) & 3U) * 8U));
- mtk_dsi_mask(dsi, DSI_CMDQ0, cmdq_mask, reg_val);
+ mtk_dsi_mask(dsi, reg_cmdq_off, cmdq_mask, reg_val);
mtk_dsi_mask(dsi, DSI_CMDQ_SIZE, CMDQ_SIZE, cmdq_size);
}
@@ -1101,6 +1108,8 @@ static int mtk_dsi_probe(struct platform_device *pdev)
if (ret)
goto err_unregister_host;
+ dsi->driver_data = of_device_get_match_data(dev);
+
dsi->engine_clk = devm_clk_get(dev, "engine");
if (IS_ERR(dsi->engine_clk)) {
ret = PTR_ERR(dsi->engine_clk);
@@ -1194,9 +1203,19 @@ static int mtk_dsi_remove(struct platform_device *pdev)
return 0;
}
+static const struct mtk_dsi_driver_data mt8173_dsi_driver_data = {
+ .reg_cmdq_off = 0x200,
+};
+
+static const struct mtk_dsi_driver_data mt2701_dsi_driver_data = {
+ .reg_cmdq_off = 0x180,
+};
+
static const struct of_device_id mtk_dsi_of_match[] = {
- { .compatible = "mediatek,mt2701-dsi" },
- { .compatible = "mediatek,mt8173-dsi" },
+ { .compatible = "mediatek,mt2701-dsi",
+ .data = &mt2701_dsi_driver_data },
+ { .compatible = "mediatek,mt8173-dsi",
+ .data = &mt8173_dsi_driver_data },
{ },
};
--
2.21.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 v6 5/7] drm/mediatek: add mt8183 dsi driver support
From: Jitao Shi @ 2019-08-11 10:40 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
devicetree, Jitao Shi, Philipp Zabel, Inki Dae, linux-mediatek,
yingjoe.chen, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Sean Paul
In-Reply-To: <20190811104008.53372-1-jitao.shi@mediatek.com>
Add mt8183 dsi driver data. Enable size control and
reg commit control.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 68794edecf96..b3676426aeb5 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -1227,11 +1227,19 @@ static const struct mtk_dsi_driver_data mt2701_dsi_driver_data = {
.reg_cmdq_off = 0x180,
};
+static const struct mtk_dsi_driver_data mt8183_dsi_driver_data = {
+ .reg_cmdq_off = 0x200,
+ .has_shadow_ctl = true,
+ .has_size_ctl = true,
+};
+
static const struct of_device_id mtk_dsi_of_match[] = {
{ .compatible = "mediatek,mt2701-dsi",
.data = &mt2701_dsi_driver_data },
{ .compatible = "mediatek,mt8173-dsi",
.data = &mt8173_dsi_driver_data },
+ { .compatible = "mediatek,mt8183-dsi",
+ .data = &mt8183_dsi_driver_data },
{ },
};
--
2.21.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 v6 3/7] drm/mediatek: add dsi reg commit disable control
From: Jitao Shi @ 2019-08-11 10:40 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
devicetree, Jitao Shi, Philipp Zabel, Inki Dae, linux-mediatek,
yingjoe.chen, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Sean Paul
In-Reply-To: <20190811104008.53372-1-jitao.shi@mediatek.com>
New DSI IP has shadow register and working reg. The register
values are writen to shadow register. And then trigger with
commit reg, the register values will be moved working register.
This fucntion is defualt on. But this driver doesn't use this
function. So add the disable control.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index ac8e80e379f7..314bfb1c827b 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -123,6 +123,10 @@
#define VM_CMD_EN BIT(0)
#define TS_VFP_EN BIT(5)
+#define DSI_SHADOW_DEBUG 0x190U
+#define FORCE_COMMIT BIT(0)
+#define BYPASS_SHADOW BIT(1)
+
#define CONFIG (0xff << 0)
#define SHORT_PACKET 0
#define LONG_PACKET 2
@@ -149,6 +153,7 @@ struct phy;
struct mtk_dsi_driver_data {
const u32 reg_cmdq_off;
+ bool has_shadow_ctl;
};
struct mtk_dsi {
@@ -586,6 +591,11 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
}
mtk_dsi_enable(dsi);
+
+ if (dsi->driver_data->has_shadow_ctl)
+ writel(FORCE_COMMIT | BYPASS_SHADOW,
+ dsi->regs + DSI_SHADOW_DEBUG);
+
mtk_dsi_reset_engine(dsi);
mtk_dsi_phy_timconfig(dsi);
--
2.21.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 v6 7/7] drm: mediatek: adjust dsi and mipi_tx probe sequence
From: Jitao Shi @ 2019-08-11 10:40 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
devicetree, Jitao Shi, Philipp Zabel, Inki Dae, linux-mediatek,
yingjoe.chen, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Sean Paul
In-Reply-To: <20190811104008.53372-1-jitao.shi@mediatek.com>
mtk_mipi_tx is the phy of mtk_dsi.
mtk_dsi get the phy(mtk_mipi_tx) in probe().
So, mtk_mipi_tx init should be ahead of mtk_dsi. Or mtk_dsi will
defer to wait mtk_mipi_tx probe done.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 95fdbd0fbcac..a762fd9111ff 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -630,8 +630,8 @@ static struct platform_driver * const mtk_drm_drivers[] = {
&mtk_disp_rdma_driver,
&mtk_dpi_driver,
&mtk_drm_platform_driver,
- &mtk_dsi_driver,
&mtk_mipi_tx_driver,
+ &mtk_dsi_driver,
};
static int __init mtk_drm_init(void)
--
2.21.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 v6 6/7] drm/mediatek: change the dsi phytiming calculate method
From: Jitao Shi @ 2019-08-11 10:40 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
devicetree, Jitao Shi, Philipp Zabel, Inki Dae, linux-mediatek,
yingjoe.chen, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Ryan Case, Sascha Hauer, Sean Paul
In-Reply-To: <20190811104008.53372-1-jitao.shi@mediatek.com>
Change the method of frame rate calc which can get more accurate
frame rate.
data rate = pixel_clock * bit_per_pixel / lanes
Adjust hfp_wc to adapt the additional phy_data
if MIPI_DSI_MODE_VIDEO_BURST
hfp_wc = hfp * bpp - data_phy_cycles * lanes - 12 - 6;
else
hfp_wc = hfp * bpp - data_phy_cycles * lanes - 12;
Note:
//(2: 1 for sync, 1 for phy idle)
data_phy_cycles = T_hs_exit + T_lpx + T_hs_prepare + T_hs_zero + 2;
bpp: bit per pixel
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Tested-by: Ryan Case <ryandcase@chromium.org>
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 118 ++++++++++++++++++++---------
1 file changed, 81 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index b3676426aeb5..4d98ea08635a 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -136,12 +136,6 @@
#define DATA_0 (0xff << 16)
#define DATA_1 (0xff << 24)
-#define T_LPX 5
-#define T_HS_PREP 6
-#define T_HS_TRAIL 8
-#define T_HS_EXIT 7
-#define T_HS_ZERO 10
-
#define NS_TO_CYCLE(n, c) ((n) / (c) + (((n) % (c)) ? 1 : 0))
#define MTK_DSI_HOST_IS_READ(type) \
@@ -150,6 +144,25 @@
(type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
(type == MIPI_DSI_DCS_READ))
+struct mtk_phy_timing {
+ u32 lpx;
+ u32 da_hs_prepare;
+ u32 da_hs_zero;
+ u32 da_hs_trail;
+
+ u32 ta_go;
+ u32 ta_sure;
+ u32 ta_get;
+ u32 da_hs_exit;
+
+ u32 clk_hs_zero;
+ u32 clk_hs_trail;
+
+ u32 clk_hs_prepare;
+ u32 clk_hs_post;
+ u32 clk_hs_exit;
+};
+
struct phy;
struct mtk_dsi_driver_data {
@@ -180,6 +193,7 @@ struct mtk_dsi {
enum mipi_dsi_pixel_format format;
unsigned int lanes;
struct videomode vm;
+ struct mtk_phy_timing phy_timing;
int refcount;
bool enabled;
u32 irq_data;
@@ -213,17 +227,36 @@ static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
{
u32 timcon0, timcon1, timcon2, timcon3;
u32 ui, cycle_time;
+ struct mtk_phy_timing *timing = &dsi->phy_timing;
+
+ ui = DIV_ROUND_UP(1000000000, dsi->data_rate);
+ cycle_time = div_u64(8000000000ULL, dsi->data_rate);
+
+ timing->lpx = NS_TO_CYCLE(60, cycle_time);
+ timing->da_hs_prepare = NS_TO_CYCLE(50 + 5 * ui, cycle_time);
+ timing->da_hs_zero = NS_TO_CYCLE(110 + 6 * ui, cycle_time);
+ timing->da_hs_trail = NS_TO_CYCLE(90 + 4 * ui, cycle_time);
- ui = 1000 / dsi->data_rate + 0x01;
- cycle_time = 8000 / dsi->data_rate + 0x01;
+ timing->ta_go = 4 * timing->lpx;
+ timing->ta_sure = 3 * timing->lpx / 2;
+ timing->ta_get = 5 * timing->lpx;
+ timing->da_hs_exit = 2 * timing->lpx;
- timcon0 = T_LPX | T_HS_PREP << 8 | T_HS_ZERO << 16 | T_HS_TRAIL << 24;
- timcon1 = 4 * T_LPX | (3 * T_LPX / 2) << 8 | 5 * T_LPX << 16 |
- T_HS_EXIT << 24;
- timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
- (NS_TO_CYCLE(0x150, cycle_time) << 16);
- timcon3 = NS_TO_CYCLE(0x40, cycle_time) | (2 * T_LPX) << 16 |
- NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8;
+ timing->clk_hs_zero = NS_TO_CYCLE(336, cycle_time);
+ timing->clk_hs_trail = NS_TO_CYCLE(100, cycle_time) + 10;
+
+ timing->clk_hs_prepare = NS_TO_CYCLE(64, cycle_time);
+ timing->clk_hs_post = NS_TO_CYCLE(80 + 52 * ui, cycle_time);
+ timing->clk_hs_exit = 2 * timing->lpx;
+
+ timcon0 = timing->lpx | timing->da_hs_prepare << 8 |
+ timing->da_hs_zero << 16 | timing->da_hs_trail << 24;
+ timcon1 = timing->ta_go | timing->ta_sure << 8 |
+ timing->ta_get << 16 | timing->da_hs_exit << 24;
+ timcon2 = 1 << 8 | timing->clk_hs_zero << 16 |
+ timing->clk_hs_trail << 24;
+ timcon3 = timing->clk_hs_prepare | timing->clk_hs_post << 8 |
+ timing->clk_hs_exit << 16;
writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
@@ -410,7 +443,8 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
u32 horizontal_sync_active_byte;
u32 horizontal_backporch_byte;
u32 horizontal_frontporch_byte;
- u32 dsi_tmp_buf_bpp;
+ u32 dsi_tmp_buf_bpp, data_phy_cycles;
+ struct mtk_phy_timing *timing = &dsi->phy_timing;
struct videomode *vm = &dsi->vm;
@@ -437,7 +471,34 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
horizontal_backporch_byte = ((vm->hback_porch + vm->hsync_len) *
dsi_tmp_buf_bpp - 10);
- horizontal_frontporch_byte = (vm->hfront_porch * dsi_tmp_buf_bpp - 12);
+ data_phy_cycles = timing->lpx + timing->da_hs_prepare +
+ timing->da_hs_zero + timing->da_hs_exit + 2;
+
+ if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
+ if (vm->hfront_porch * dsi_tmp_buf_bpp >
+ data_phy_cycles * dsi->lanes + 18) {
+ horizontal_frontporch_byte = vm->hfront_porch *
+ dsi_tmp_buf_bpp -
+ data_phy_cycles *
+ dsi->lanes - 18;
+ } else {
+ DRM_WARN("HFP less than d-phy, FPS will under 60Hz\n");
+ horizontal_frontporch_byte = vm->hfront_porch *
+ dsi_tmp_buf_bpp;
+ }
+ } else {
+ if (vm->hfront_porch * dsi_tmp_buf_bpp >
+ data_phy_cycles * dsi->lanes + 12) {
+ horizontal_frontporch_byte = vm->hfront_porch *
+ dsi_tmp_buf_bpp -
+ data_phy_cycles *
+ dsi->lanes - 12;
+ } else {
+ DRM_WARN("HFP less than d-phy, FPS will under 60Hz\n");
+ horizontal_frontporch_byte = vm->hfront_porch *
+ dsi_tmp_buf_bpp;
+ }
+ }
writel(horizontal_sync_active_byte, dsi->regs + DSI_HSA_WC);
writel(horizontal_backporch_byte, dsi->regs + DSI_HBP_WC);
@@ -537,8 +598,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
{
struct device *dev = dsi->host.dev;
int ret;
- u64 pixel_clock, total_bits;
- u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
+ u32 bit_per_pixel;
if (++dsi->refcount != 1)
return 0;
@@ -557,24 +617,8 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
break;
}
- /**
- * htotal_time = htotal * byte_per_pixel / num_lanes
- * overhead_time = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
- * mipi_ratio = (htotal_time + overhead_time) / htotal_time
- * data_rate = pixel_clock * bit_per_pixel * mipi_ratio / num_lanes;
- */
- pixel_clock = dsi->vm.pixelclock;
- htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
- dsi->vm.hsync_len;
- htotal_bits = htotal * bit_per_pixel;
-
- overhead_cycles = T_LPX + T_HS_PREP + T_HS_ZERO + T_HS_TRAIL +
- T_HS_EXIT;
- overhead_bits = overhead_cycles * dsi->lanes * 8;
- total_bits = htotal_bits + overhead_bits;
-
- dsi->data_rate = DIV_ROUND_UP_ULL(pixel_clock * total_bits,
- htotal * dsi->lanes);
+ dsi->data_rate = DIV_ROUND_UP_ULL(dsi->vm.pixelclock * bit_per_pixel,
+ dsi->lanes);
ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
if (ret < 0) {
--
2.21.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
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