* Re: [PATCH v2] watchdog: imx2_wdg: Alow ping on suspend
From: Alistair @ 2022-01-27 10:35 UTC (permalink / raw)
To: Guenter Roeck, linux-arm-kernel, shawnguo,
Linux Kernel Mailing List, s.hauer, linux-watchdog, wim
Cc: devicetree, festevam, linux-imx, Rob Herring, kernel
In-Reply-To: <1a8ee480-b066-8da9-cd63-079e07b7d88a@roeck-us.net>
On Tue, 25 Jan 2022, at 2:21 AM, Guenter Roeck wrote:
> On 1/24/22 04:00, Alistair Francis wrote:
> > The i.MX watchdog cannot be disabled by softwrae once it has been
>
> s/softwrae/software/
>
> > enabled. This means that it can't be stopped before suspend.
> >
> > For systems that enter low power mode this is fine, as the watchdog will
> > be automatically stopped by hardwrae in low power mode. Not all i.MX
>
> s/hardwrae/hardware/
>
> > platforms support low power mode in the mainline kernel. For example the
> > i.MX7D does not enter low power mode and so will be rebooted 2 minutes
> > after entering freeze or mem sleep states.
>
> I don't think "mem" adds any value here. Just make it sleep states.
>
> >
> > This patch introduces a device tree property "fsl,ping-during-suspend"
> > that can be used to enable ping on suspend support for these systems.
> >
> > Signed-off-by: Alistair Francis <alistair@alistair23.me>
> > ---
>
> Change log goes here.
>
> > drivers/watchdog/imx2_wdt.c | 27 ++++++++++++++++++++-------
> > 1 file changed, 20 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
> > index 51bfb796898b..d0c5d47ddede 100644
> > --- a/drivers/watchdog/imx2_wdt.c
> > +++ b/drivers/watchdog/imx2_wdt.c
> > @@ -66,6 +66,7 @@ struct imx2_wdt_device {
> > struct watchdog_device wdog;
> > bool ext_reset;
> > bool clk_is_on;
>
> I don't see the purpose of this variable. Unless I am missing something is is set
> but never used.
clk_is_on is used in imx2_wdt_ping(), it disables the access if
the clock isn't running.
>
> > + bool no_ping;
> > };
> >
> > static bool nowayout = WATCHDOG_NOWAYOUT;
> > @@ -312,12 +313,18 @@ static int __init imx2_wdt_probe(struct platform_device *pdev)
> >
> > wdev->ext_reset = of_property_read_bool(dev->of_node,
> > "fsl,ext-reset-output");
> > + /*
> > + * The i.MX7D doesn't support low power mode, so we need to ping the watchdog
> > + * during suspend.
> > + */
> > + wdev->no_ping = !of_device_is_compatible(dev->of_node, "fsl,imx7d-wdt");
>
> This is ok as long as there is only a single chip requiring this change.
> If there are more, the 'data' field in struct of_device_id should be used
> instead.
I only know of one now, so this should be fine then.
Alistair
>
> > platform_set_drvdata(pdev, wdog);
> > watchdog_set_drvdata(wdog, wdev);
> > watchdog_set_nowayout(wdog, nowayout);
> > watchdog_set_restart_priority(wdog, 128);
> > watchdog_init_timeout(wdog, timeout, dev);
> > - watchdog_stop_ping_on_suspend(wdog);
> > + if (wdev->no_ping)
> > + watchdog_stop_ping_on_suspend(wdog);
> >
> > if (imx2_wdt_is_running(wdev)) {
> > imx2_wdt_set_timeout(wdog, wdog->timeout);
> > @@ -366,9 +373,11 @@ static int __maybe_unused imx2_wdt_suspend(struct device *dev)
> > imx2_wdt_ping(wdog);
> > }
> >
> > - clk_disable_unprepare(wdev->clk);
> > + if (wdev->no_ping) {
> > + clk_disable_unprepare(wdev->clk);
> >
> > - wdev->clk_is_on = false;
> > + wdev->clk_is_on = false;
> > + }
> >
> > return 0;
> > }
> > @@ -380,11 +389,14 @@ static int __maybe_unused imx2_wdt_resume(struct device *dev)
> > struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
> > int ret;
> >
> > - ret = clk_prepare_enable(wdev->clk);
> > - if (ret)
> > - return ret;
> > + if (wdev->no_ping) {
> > + ret = clk_prepare_enable(wdev->clk);
> >
> > - wdev->clk_is_on = true;
> > + if (ret)
> > + return ret;
> > +
> > + wdev->clk_is_on = true;
> > + }
> >
> > if (watchdog_active(wdog) && !imx2_wdt_is_running(wdev)) {
> > /*
> > @@ -407,6 +419,7 @@ static SIMPLE_DEV_PM_OPS(imx2_wdt_pm_ops, imx2_wdt_suspend,
> >
> > static const struct of_device_id imx2_wdt_dt_ids[] = {
> > { .compatible = "fsl,imx21-wdt", },
> > + { .compatible = "fsl,imx7d-wdt", },
> > { /* sentinel */ }
> > };
> > MODULE_DEVICE_TABLE(of, imx2_wdt_dt_ids);
>
>
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: meson-gx: add ATF BL32 reserved-memory region
From: Neil Armstrong @ 2022-01-27 10:44 UTC (permalink / raw)
To: Vyacheslav, Christian Hewitt, Rob Herring, Mark Rutland,
Kevin Hilman, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <a279c365-0615-1c7f-5596-dec9ad1c8229@lexina.in>
Hi,
On 26/01/2022 06:35, Vyacheslav wrote:
> Hi!
>
> 26.01.2022 07:49, Christian Hewitt wrote:
>> Add an additional reserved memory region for the BL32 trusted firmware
>> present in many devices that boot from Amlogic vendor u-boot.
>>
>> Suggested-by: Mateusz Krzak <kszaquitto@gmail.com>
>> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
>> ---
>> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> index 6b457b2c30a4..aa14ea017a61 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> @@ -49,6 +49,12 @@
>> no-map;
>> };
>> + /* 32 MiB reserved for ARM Trusted Firmware (BL32) */
>> + secmon_reserved_bl32: secmon@5300000 {
>> + reg = <0x0 0x05300000 0x0 0x2000000>;
>> + no-map;
>> + };
>> +
> How do I check if we need a similar patch for axg boards?
>
>
>> linux,cma {
>> compatible = "shared-dma-pool";
>> reusable;
>>
>
For AXG board with BL32 booting from vendor u-boot, yes.
Neil
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: meson-gx: add ATF BL32 reserved-memory region
From: Neil Armstrong @ 2022-01-27 10:46 UTC (permalink / raw)
To: Christian Hewitt, Rob Herring, Mark Rutland, Kevin Hilman,
devicetree, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <20220126044954.19069-2-christianshewitt@gmail.com>
On 26/01/2022 05:49, Christian Hewitt wrote:
> Add an additional reserved memory region for the BL32 trusted firmware
> present in many devices that boot from Amlogic vendor u-boot.
>
> Suggested-by: Mateusz Krzak <kszaquitto@gmail.com>
> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> index 6b457b2c30a4..aa14ea017a61 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> @@ -49,6 +49,12 @@
> no-map;
> };
>
> + /* 32 MiB reserved for ARM Trusted Firmware (BL32) */
> + secmon_reserved_bl32: secmon@5300000 {
> + reg = <0x0 0x05300000 0x0 0x2000000>;
> + no-map;
> + };
> +
> linux,cma {
> compatible = "shared-dma-pool";
> reusable;
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: meson-g12: add ATF BL32 reserved-memory region
From: Neil Armstrong @ 2022-01-27 10:46 UTC (permalink / raw)
To: Christian Hewitt, Rob Herring, Mark Rutland, Kevin Hilman,
devicetree, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <20220126044954.19069-3-christianshewitt@gmail.com>
On 26/01/2022 05:49, Christian Hewitt wrote:
> Add an additional reserved memory region for the BL32 trusted firmware
> present in many devices that boot from Amlogic vendor u-boot.
>
> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
> index 6d99c23261fb..45947c1031c4 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
> @@ -107,6 +107,12 @@
> no-map;
> };
>
> + /* 32 MiB reserved for ARM Trusted Firmware (BL32) */
> + secmon_reserved_bl32: secmon@5300000 {
> + reg = <0x0 0x05300000 0x0 0x2000000>;
> + no-map;
> + };
> +
> linux,cma {
> compatible = "shared-dma-pool";
> reusable;
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: meson-g12: drop BL32 region from SEI510/SEI610
From: Neil Armstrong @ 2022-01-27 10:46 UTC (permalink / raw)
To: Christian Hewitt, Rob Herring, Mark Rutland, Kevin Hilman,
devicetree, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <20220126044954.19069-4-christianshewitt@gmail.com>
On 26/01/2022 05:49, Christian Hewitt wrote:
> The BL32/TEE reserved-memory region is now inherited from the common
> family dtsi (meson-g12-common) so we can drop it from board files.
>
> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts | 8 --------
> arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts | 8 --------
> 2 files changed, 16 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts b/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
> index d8838dde0f0f..4fb31c2ba31c 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
> @@ -157,14 +157,6 @@
> regulator-always-on;
> };
>
> - reserved-memory {
> - /* TEE Reserved Memory */
> - bl32_reserved: bl32@5000000 {
> - reg = <0x0 0x05300000 0x0 0x2000000>;
> - no-map;
> - };
> - };
> -
> sdio_pwrseq: sdio-pwrseq {
> compatible = "mmc-pwrseq-simple";
> reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
> diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts b/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
> index 427475846fc7..a5d79f2f7c19 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
> @@ -203,14 +203,6 @@
> regulator-always-on;
> };
>
> - reserved-memory {
> - /* TEE Reserved Memory */
> - bl32_reserved: bl32@5000000 {
> - reg = <0x0 0x05300000 0x0 0x2000000>;
> - no-map;
> - };
> - };
> -
> sdio_pwrseq: sdio-pwrseq {
> compatible = "mmc-pwrseq-simple";
> reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* [PATCH v3] watchdog: imx2_wdg: Alow ping on suspend
From: Alistair Francis @ 2022-01-27 10:47 UTC (permalink / raw)
To: linux-arm-kernel, linux-watchdog, linux-kernel, shawnguo, wim,
linux, s.hauer
Cc: robh+dt, linux-imx, devicetree, kernel, festevam,
Alistair Francis
The i.MX watchdog cannot be disabled by software once it has been
enabled. This means that it can't be stopped before suspend.
For systems that enter low power mode this is fine, as the watchdog will
be automatically stopped by hardware in low power mode. Not all i.MX
platforms support low power mode in the mainline kernel. For example the
i.MX7D does not enter low power mode and so will be rebooted 2 minutes
after entering sleep states.
This patch introduces a device tree property "fsl,ping-during-suspend"
that can be used to enable ping on suspend support for these systems.
Signed-off-by: Alistair Francis <alistair@alistair23.me>
---
v3:
- Fixup typos in commit message
v2:
- Remove custom property
drivers/watchdog/imx2_wdt.c | 27 ++++++++++++++++++++-------
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
index 51bfb796898b..d0c5d47ddede 100644
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -66,6 +66,7 @@ struct imx2_wdt_device {
struct watchdog_device wdog;
bool ext_reset;
bool clk_is_on;
+ bool no_ping;
};
static bool nowayout = WATCHDOG_NOWAYOUT;
@@ -312,12 +313,18 @@ static int __init imx2_wdt_probe(struct platform_device *pdev)
wdev->ext_reset = of_property_read_bool(dev->of_node,
"fsl,ext-reset-output");
+ /*
+ * The i.MX7D doesn't support low power mode, so we need to ping the watchdog
+ * during suspend.
+ */
+ wdev->no_ping = !of_device_is_compatible(dev->of_node, "fsl,imx7d-wdt");
platform_set_drvdata(pdev, wdog);
watchdog_set_drvdata(wdog, wdev);
watchdog_set_nowayout(wdog, nowayout);
watchdog_set_restart_priority(wdog, 128);
watchdog_init_timeout(wdog, timeout, dev);
- watchdog_stop_ping_on_suspend(wdog);
+ if (wdev->no_ping)
+ watchdog_stop_ping_on_suspend(wdog);
if (imx2_wdt_is_running(wdev)) {
imx2_wdt_set_timeout(wdog, wdog->timeout);
@@ -366,9 +373,11 @@ static int __maybe_unused imx2_wdt_suspend(struct device *dev)
imx2_wdt_ping(wdog);
}
- clk_disable_unprepare(wdev->clk);
+ if (wdev->no_ping) {
+ clk_disable_unprepare(wdev->clk);
- wdev->clk_is_on = false;
+ wdev->clk_is_on = false;
+ }
return 0;
}
@@ -380,11 +389,14 @@ static int __maybe_unused imx2_wdt_resume(struct device *dev)
struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
int ret;
- ret = clk_prepare_enable(wdev->clk);
- if (ret)
- return ret;
+ if (wdev->no_ping) {
+ ret = clk_prepare_enable(wdev->clk);
- wdev->clk_is_on = true;
+ if (ret)
+ return ret;
+
+ wdev->clk_is_on = true;
+ }
if (watchdog_active(wdog) && !imx2_wdt_is_running(wdev)) {
/*
@@ -407,6 +419,7 @@ static SIMPLE_DEV_PM_OPS(imx2_wdt_pm_ops, imx2_wdt_suspend,
static const struct of_device_id imx2_wdt_dt_ids[] = {
{ .compatible = "fsl,imx21-wdt", },
+ { .compatible = "fsl,imx7d-wdt", },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, imx2_wdt_dt_ids);
--
2.31.1
^ permalink raw reply related
* [PATCH net-next v1 3/4] dt-bindings: net: add "label" property for all usbnet Ethernet controllers
From: Oleksij Rempel @ 2022-01-27 10:49 UTC (permalink / raw)
To: Oliver Neukum, David S. Miller, Jakub Kicinski, Rob Herring
Cc: Oleksij Rempel, kernel, linux-kernel, linux-usb, netdev,
devicetree
In-Reply-To: <20220127104905.899341-1-o.rempel@pengutronix.de>
For hard wired Ethernet controllers it is helpful to assign name related
to port description on the board. Or name, related to the special
internal function, if the USB ethernet controller attached to the CPU
port of some DSA switch.
This patch provides documentation for "label" property, reusable for all
usbnet controllers.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
.../devicetree/bindings/net/asix,ax88178.yaml | 4 ++-
.../bindings/net/microchip,lan95xx.yaml | 4 ++-
.../devicetree/bindings/net/usbnet.yaml | 36 +++++++++++++++++++
3 files changed, 42 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/usbnet.yaml
diff --git a/Documentation/devicetree/bindings/net/asix,ax88178.yaml b/Documentation/devicetree/bindings/net/asix,ax88178.yaml
index 74b6806006e3..c8ad767a2e45 100644
--- a/Documentation/devicetree/bindings/net/asix,ax88178.yaml
+++ b/Documentation/devicetree/bindings/net/asix,ax88178.yaml
@@ -13,7 +13,7 @@ description: |
Device tree properties for hard wired USB Ethernet devices.
allOf:
- - $ref: ethernet-controller.yaml#
+ - $ref: usbnet.yaml#
properties:
compatible:
@@ -58,6 +58,7 @@ properties:
- usb6189,182d # Sitecom LN-029
reg: true
+ label: true
local-mac-address: true
mac-address: true
@@ -77,6 +78,7 @@ examples:
ethernet@1 {
compatible = "usbdb0,a877";
reg = <1>;
+ label = "LAN0";
local-mac-address = [00 00 00 00 00 00];
};
};
diff --git a/Documentation/devicetree/bindings/net/microchip,lan95xx.yaml b/Documentation/devicetree/bindings/net/microchip,lan95xx.yaml
index b185c7068a8a..259879bba3a0 100644
--- a/Documentation/devicetree/bindings/net/microchip,lan95xx.yaml
+++ b/Documentation/devicetree/bindings/net/microchip,lan95xx.yaml
@@ -14,7 +14,7 @@ description: |
controller.
allOf:
- - $ref: ethernet-controller.yaml#
+ - $ref: usbnet.yaml#
properties:
compatible:
@@ -40,6 +40,7 @@ properties:
- usb424,ec00 # SMSC9512/9514 USB Hub & Ethernet Device
reg: true
+ label: true
local-mac-address: true
mac-address: true
@@ -59,6 +60,7 @@ examples:
ethernet@1 {
compatible = "usb424,ec00";
reg = <1>;
+ label = "LAN0";
local-mac-address = [00 00 00 00 00 00];
};
};
diff --git a/Documentation/devicetree/bindings/net/usbnet.yaml b/Documentation/devicetree/bindings/net/usbnet.yaml
new file mode 100644
index 000000000000..fe0848433263
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/usbnet.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/usbnet.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: The device tree bindings for the USB Ethernet controllers
+
+maintainers:
+ - Oleksij Rempel <o.rempel@pengutronix.de>
+
+description: |
+ Device tree properties for hard wired USB Ethernet devices.
+
+allOf:
+ - $ref: ethernet-controller.yaml#
+
+properties:
+ compatible: true
+
+ reg:
+ description: Port number
+
+ label:
+ description:
+ Describes the label associated with this port, which will become
+ the netdev name
+ $ref: /schemas/types.yaml#/definitions/string
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: true
+
+...
--
2.30.2
^ permalink raw reply related
* [PATCH net-next v1 0/4] usbnet: add "label" support
From: Oleksij Rempel @ 2022-01-27 10:49 UTC (permalink / raw)
To: Oliver Neukum, David S. Miller, Jakub Kicinski, Rob Herring
Cc: Oleksij Rempel, kernel, linux-kernel, linux-usb, netdev,
devicetree
Add devicetree label property for usbnet devices and related yaml
schema.
Oleksij Rempel (4):
dt-bindings: net: add schema for ASIX USB Ethernet controllers
dt-bindings: net: add schema for Microchip/SMSC LAN95xx USB Ethernet
controllers
dt-bindings: net: add "label" property for all usbnet Ethernet
controllers
usbnet: add support for label from device tree
.../devicetree/bindings/net/asix,ax88178.yaml | 102 ++++++++++++++++++
.../bindings/net/microchip,lan95xx.yaml | 84 +++++++++++++++
.../devicetree/bindings/net/usbnet.yaml | 36 +++++++
drivers/net/usb/usbnet.c | 15 +++
4 files changed, 237 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/asix,ax88178.yaml
create mode 100644 Documentation/devicetree/bindings/net/microchip,lan95xx.yaml
create mode 100644 Documentation/devicetree/bindings/net/usbnet.yaml
--
2.30.2
^ permalink raw reply
* [PATCH net-next v1 2/4] dt-bindings: net: add schema for Microchip/SMSC LAN95xx USB Ethernet controllers
From: Oleksij Rempel @ 2022-01-27 10:49 UTC (permalink / raw)
To: Oliver Neukum, David S. Miller, Jakub Kicinski, Rob Herring
Cc: Oleksij Rempel, kernel, linux-kernel, linux-usb, netdev,
devicetree
In-Reply-To: <20220127104905.899341-1-o.rempel@pengutronix.de>
Create initial schema for Microchip/SMSC LAN95xx USB Ethernet controllers and
import all currently supported USB IDs form drivers/net/usb/smsc95xx.c
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
.../bindings/net/microchip,lan95xx.yaml | 82 +++++++++++++++++++
1 file changed, 82 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/microchip,lan95xx.yaml
diff --git a/Documentation/devicetree/bindings/net/microchip,lan95xx.yaml b/Documentation/devicetree/bindings/net/microchip,lan95xx.yaml
new file mode 100644
index 000000000000..b185c7068a8a
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/microchip,lan95xx.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/microchip,lan95xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: The device tree bindings for the USB Ethernet controllers
+
+maintainers:
+ - Oleksij Rempel <o.rempel@pengutronix.de>
+
+description: |
+ Device tree properties for hard wired SMSC95xx compatible USB Ethernet
+ controller.
+
+allOf:
+ - $ref: ethernet-controller.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - usb424,9500 # SMSC9500 USB Ethernet Device
+ - usb424,9505 # SMSC9505 USB Ethernet Device
+ - usb424,9530 # SMSC LAN9530 USB Ethernet Device
+ - usb424,9730 # SMSC LAN9730 USB Ethernet Device
+ - usb424,9900 # SMSC9500 USB Ethernet Device (SAL10)
+ - usb424,9901 # SMSC9505 USB Ethernet Device (SAL10)
+ - usb424,9902 # SMSC9500A USB Ethernet Device (SAL10)
+ - usb424,9903 # SMSC9505A USB Ethernet Device (SAL10)
+ - usb424,9904 # SMSC9512/9514 USB Hub & Ethernet Device (SAL10)
+ - usb424,9905 # SMSC9500A USB Ethernet Device (HAL)
+ - usb424,9906 # SMSC9505A USB Ethernet Device (HAL)
+ - usb424,9907 # SMSC9500 USB Ethernet Device (Alternate ID)
+ - usb424,9908 # SMSC9500A USB Ethernet Device (Alternate ID)
+ - usb424,9909 # SMSC9512/9514 USB Hub & Ethernet Devic. ID)
+ - usb424,9e00 # SMSC9500A USB Ethernet Device
+ - usb424,9e01 # SMSC9505A USB Ethernet Device
+ - usb424,9e08 # SMSC LAN89530 USB Ethernet Device
+ - usb424,ec00 # SMSC9512/9514 USB Hub & Ethernet Device
+
+ reg: true
+ local-mac-address: true
+ mac-address: true
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ usb@11270000 {
+ reg = <0x11270000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet@1 {
+ compatible = "usb424,ec00";
+ reg = <1>;
+ local-mac-address = [00 00 00 00 00 00];
+ };
+ };
+ - |
+ usb@11270000 {
+ reg = <0x11270000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb1@1 {
+ compatible = "usb424,9514";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet@1 {
+ compatible = "usb424,ec00";
+ reg = <1>;
+ };
+ };
+ };
--
2.30.2
^ permalink raw reply related
* [PATCH net-next v1 1/4] dt-bindings: net: add schema for ASIX USB Ethernet controllers
From: Oleksij Rempel @ 2022-01-27 10:49 UTC (permalink / raw)
To: Oliver Neukum, David S. Miller, Jakub Kicinski, Rob Herring
Cc: Oleksij Rempel, kernel, linux-kernel, linux-usb, netdev,
devicetree
In-Reply-To: <20220127104905.899341-1-o.rempel@pengutronix.de>
Create initial schema for ASIX USB Ethernet controllers and import all
currently supported USB IDs form drivers/net/usb/asix_devices.c
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
.../devicetree/bindings/net/asix,ax88178.yaml | 100 ++++++++++++++++++
1 file changed, 100 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/asix,ax88178.yaml
diff --git a/Documentation/devicetree/bindings/net/asix,ax88178.yaml b/Documentation/devicetree/bindings/net/asix,ax88178.yaml
new file mode 100644
index 000000000000..74b6806006e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/asix,ax88178.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/asix,ax88178.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: The device tree bindings for the USB Ethernet controllers
+
+maintainers:
+ - Oleksij Rempel <o.rempel@pengutronix.de>
+
+description: |
+ Device tree properties for hard wired USB Ethernet devices.
+
+allOf:
+ - $ref: ethernet-controller.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - usb411,3d # Buffalo LUA-U2-KTX
+ - usb411,6e # Buffalo LUA-U2-GT 10/100/1000
+ - usb4bb,930 # IO-DATA ETG-US2
+ - usb4f1,3008 # JVC MP-PRX1 Port Replicator
+ - usb50d,5055 # Belkin F5D5055
+ - usb557,2009 # ATEN UC210T
+ - usb5ac,1402 # Apple USB Ethernet Adapter
+ - usb66b,20f9 # USBLINK HG20F9
+ - usb77b,2226 # Linksys USB200M
+ - usb789,160 # Logitec LAN-GTJ/U2A
+ - usb7aa,17 # corega FEther USB2-TX
+ - usb7b8,420a # Hawking UF200, TrendNet TU2-ET100
+ - usb7d1,3c05 # DLink DUB-E100 H/W Ver B1
+ - usb846,1040 # Netgear FA120
+ - usb8dd,114 # Billionton Systems, GUSB2AM-1G-B
+ - usb8dd,90ff # Billionton Systems, USB2AR
+ - usbb95,1720 # Intellinet, ST Lab USB Ethernet
+ - usbb95,172a # ASIX 88172a demo board
+ - usbb95,1780 # ASIX AX88178 10/100/1000
+ - usbb95,7720 # ASIX AX88772 10/100
+ - usbb95,772a # Cables-to-Go USB Ethernet Adapter
+ - usbb95,772b # ASIX AX88772B 10/100
+ - usbb95,7e2b # Asus USB Ethernet Adapter
+ - usbdb0,a877 # ASIX 88772a
+ - usbdf6,56 # Sitecom LN-031
+ - usbdf6,61c # Sitecom LN-028
+ - usb1189,893 # Surecom EP-1427X-2
+ - usb13b1,18 # Linksys USB200M Rev 2
+ - usb14ea,ab11 # ABOCOM for pci
+ - usb1557,7720 # 0Q0 cable ethernet
+ - usb1631,6200 # goodway corp usb gwusb2e
+ - usb1737,39 # Linksys USB1000
+ - usb17ef,7203 # Lenovo U2L100P 10/100
+ - usb2001,1a00 # DLink DUB-E100
+ - usb2001,1a02 # DLink DUB-E100 H/W Ver C1
+ - usb2001,3c05 # DLink DUB-E100 H/W Ver B1 Alternate
+ - usb6189,182d # Sitecom LN-029
+
+ reg: true
+ local-mac-address: true
+ mac-address: true
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ usb@11270000 {
+ reg = <0x11270000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet@1 {
+ compatible = "usbdb0,a877";
+ reg = <1>;
+ local-mac-address = [00 00 00 00 00 00];
+ };
+ };
+ - |
+ usb@11270000 {
+ reg = <0x11270000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb1@1 {
+ compatible = "usb1234,5678";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet@1 {
+ compatible = "usbdb0,a877";
+ reg = <1>;
+ };
+ };
+ };
--
2.30.2
^ permalink raw reply related
* [PATCH net-next v1 4/4] usbnet: add support for label from device tree
From: Oleksij Rempel @ 2022-01-27 10:49 UTC (permalink / raw)
To: Oliver Neukum, David S. Miller, Jakub Kicinski, Rob Herring
Cc: Oleksij Rempel, kernel, linux-kernel, linux-usb, netdev,
devicetree
In-Reply-To: <20220127104905.899341-1-o.rempel@pengutronix.de>
Similar to the option to set a netdev name in device tree for switch
ports by using the property "label" in the DSA framework, this patch
adds this functionality to the usbnet infrastructure.
This will help to name the interfaces properly throughout supported
devices. This provides stable interface names which are useful
especially in embedded use cases.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
drivers/net/usb/usbnet.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 9a6450f796dc..3fdca0cfda88 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -33,6 +33,7 @@
#include <linux/slab.h>
#include <linux/kernel.h>
#include <linux/pm_runtime.h>
+#include <linux/of.h>
/*-------------------------------------------------------------------------*/
@@ -1762,6 +1763,20 @@ usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
if ((dev->driver_info->flags & FLAG_WWAN) != 0)
strscpy(net->name, "wwan%d", sizeof(net->name));
+ if (IS_ENABLED(CONFIG_OF)) {
+ const char *label = NULL;
+
+ /* try reading label from device tree node */
+ if (xdev->dev.of_node)
+ label = of_get_property(xdev->dev.of_node,
+ "label", NULL);
+ if (label) {
+ strscpy(net->name, label, sizeof(net->name));
+ dev_info(&udev->dev, "netdev name from dt: %s\n",
+ net->name);
+ }
+ }
+
/* devices that cannot do ARP */
if ((dev->driver_info->flags & FLAG_NOARP) != 0)
net->flags |= IFF_NOARP;
--
2.30.2
^ permalink raw reply related
* Re: [PATCH v11 2/3] dts: arm64: mt8183: add Mediatek MDP3 nodes
From: AngeloGioacchino Del Regno @ 2022-01-27 10:57 UTC (permalink / raw)
To: moudy ho, Mauro Carvalho Chehab, Rob Herring, Matthias Brugger,
Hans Verkuil, Jernej Skrabec
Cc: Chun-Kuang Hu, Geert Uytterhoeven, Rob Landley, Laurent Pinchart,
linux-media, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, Alexandre Courbot, tfiga, drinkcat, pihsun, hsinyi,
Maoguang Meng, daoyuan huang, Ping-Hsun Wu, menghui.lin, sj.huang,
allen-kh.cheng, randy.wu, jason-jh.lin, roy-cw.yeh, river.cheng,
srv_heupstream
In-Reply-To: <356f512b549f90b329775e249fd48eb2954ade02.camel@mediatek.com>
Il 25/01/22 09:20, moudy ho ha scritto:
> On Fri, 2022-01-21 at 12:58 +0100, AngeloGioacchino Del Regno wrote:
>> Il 05/01/22 10:37, Moudy Ho ha scritto:
>>> Add device nodes for Media Data Path 3 (MDP3) modules.
>>>
>>> Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
>>> ---
>>> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 108
>>> ++++++++++++++++++++++-
>>> 1 file changed, 107 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> index ba4584faca5a..b872ef1ff6b3 100644
>>> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> @@ -1325,6 +1325,79 @@
>>> mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX
>>> 0 0x1000>;
>>> };
>>>
>>> + mdp3_rdma0: mdp3_rdma0@14001000 {
>>> + compatible = "mediatek,mt8183-mdp3",
>>> + "mediatek,mt8183-mdp3-rdma0";
>>> + mediatek,scp = <&scp>;
>>> + mediatek,mdp3-comps = "mediatek,mt8183-mdp3-
>>> dl1",
>>> + "mediatek,mt8183-mdp3-
>>> dl2",
>>> + "mediatek,mt8183-mdp3-
>>> path1",
>>> + "mediatek,mt8183-mdp3-
>>> path2",
>>> + "mediatek,mt8183-mdp3-
>>> imgi",
>>> + "mediatek,mt8183-mdp3-
>>> exto";
>>> + reg = <0 0x14001000 0 0x1000>,
>>> + <0 0x14000000 0 0x1000>,
>>> + <0 0x14005000 0 0x1000>,
>>> + <0 0x14006000 0 0x1000>,
>>> + <0 0x15020000 0 0x1000>;
>>> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX
>>> 0x1000 0x1000>,
>>> + <&gce SUBSYS_1400XXXX
>>> 0 0x1000>,
>>> + <&gce SUBSYS_1400XXXX
>>> 0x5000 0x1000>,
>>> + <&gce SUBSYS_1400XXXX
>>> 0x6000 0x1000>,
>>> + <&gce SUBSYS_1502XXXX
>>> 0 0x1000>;
>>> + power-domains = <&spm
>>> MT8183_POWER_DOMAIN_DISP>;
>>> + clocks = <&mmsys CLK_MM_MDP_RDMA0>,
>>> + <&mmsys CLK_MM_MDP_RSZ1>,
>>> + <&mmsys CLK_MM_MDP_DL_TXCK>,
>>> + <&mmsys CLK_MM_MDP_DL_RX>,
>>> + <&mmsys CLK_MM_IPU_DL_TXCK>,
>>> + <&mmsys CLK_MM_IPU_DL_RX>;
>>> + iommus = <&iommu M4U_PORT_MDP_RDMA0>;
>>> + mediatek,mmsys = <&mmsys>;
>>> + mediatek,mm-mutex = <&mutex>;
>>> + mediatek,mailbox-gce = <&gce>;
>>> + mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST 0>,
>>> + <&gce 21 CMDQ_THR_PRIO_LOWEST>,
>>> + <&gce 22 CMDQ_THR_PRIO_LOWEST>,
>>> + <&gce 23 CMDQ_THR_PRIO_LOWEST>;
>>
>> Hello Moudy,
>> the mboxes for gce 21, 22, 23 are missing the third cell. Please fix.
>>
>> Regards,
>> Angelo
>
> Hi Angelo,
> Thanks for the reminder, but I'm a bit confused, the previous
> version(v10) mentioned that the current upstream mbox has only 2
> cells.
> So I should follow this rule to remove the extra 0 in the first item as
> follows:
> + mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST>,
> + <&gce 21 CMDQ_THR_PRIO_LOWEST>,
> + <&gce 22 CMDQ_THR_PRIO_LOWEST>,
> + <&gce 23 CMDQ_THR_PRIO_LOWEST>;
>
> Thanks,
> Moudy Ho
Hello Moudy,
I'm sorry for this confusion and you are totally right in the proposed solution,
which is the exact opposite of what I said.
Thanks for understanding,
Angelo
>>
>>> + gce-subsys = <&gce 0x14000000 SUBSYS_1400XXXX>,
>>> + <&gce 0x14010000 SUBSYS_1401XXXX>,
>>> + <&gce 0x14020000 SUBSYS_1402XXXX>,
>>> + <&gce 0x15020000 SUBSYS_1502XXXX>;
>>> + };
>>> +
>>
>>
>
^ permalink raw reply
* Re: [PATCH net-next v1 4/4] usbnet: add support for label from device tree
From: Greg KH @ 2022-01-27 10:57 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Oliver Neukum, David S. Miller, Jakub Kicinski, Rob Herring,
kernel, linux-kernel, linux-usb, netdev, devicetree
In-Reply-To: <20220127104905.899341-5-o.rempel@pengutronix.de>
On Thu, Jan 27, 2022 at 11:49:05AM +0100, Oleksij Rempel wrote:
> Similar to the option to set a netdev name in device tree for switch
> ports by using the property "label" in the DSA framework, this patch
> adds this functionality to the usbnet infrastructure.
>
> This will help to name the interfaces properly throughout supported
> devices. This provides stable interface names which are useful
> especially in embedded use cases.
Stable interface names are for userspace to set, not the kernel.
Why would USB care about this? If you need something like this, get it
from the USB device itself, not DT, which should have nothing to do with
USB as USB is a dynamic, self-describing, bus. Unlike DT.
So I do not think this is a good idea.
greg k-h
^ permalink raw reply
* Re: [PATCH net-next v1 0/4] usbnet: add "label" support
From: Greg KH @ 2022-01-27 10:57 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Oliver Neukum, David S. Miller, Jakub Kicinski, Rob Herring,
kernel, linux-kernel, linux-usb, netdev, devicetree
In-Reply-To: <20220127104905.899341-1-o.rempel@pengutronix.de>
On Thu, Jan 27, 2022 at 11:49:01AM +0100, Oleksij Rempel wrote:
> Add devicetree label property for usbnet devices and related yaml
> schema.
That says _what_ you are doing, but not _why_ you would want to do such
a crazy thing, nor what problem you are attempting to solve here.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net-next v1 2/4] dt-bindings: net: add schema for Microchip/SMSC LAN95xx USB Ethernet controllers
From: Greg KH @ 2022-01-27 10:59 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Oliver Neukum, David S. Miller, Jakub Kicinski, Rob Herring,
kernel, linux-kernel, linux-usb, netdev, devicetree
In-Reply-To: <20220127104905.899341-3-o.rempel@pengutronix.de>
On Thu, Jan 27, 2022 at 11:49:03AM +0100, Oleksij Rempel wrote:
> Create initial schema for Microchip/SMSC LAN95xx USB Ethernet controllers and
> import all currently supported USB IDs form drivers/net/usb/smsc95xx.c
That is a loosing game to play. There is a reason that kernel drivers
only require a device id in 1 place, instead of multiple places like
other operating systems. Please do not go back and make the same
mistakes others have.
Not to mention that I think overall this is a bad idea anyway. USB
devices are self-describing, don't add them to DT.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH V4 2/6] bindings: usb: dwc3: Update dwc3 properties for EUD connector
From: Souradeep Chowdhury @ 2022-01-27 10:58 UTC (permalink / raw)
To: Bjorn Andersson
Cc: linux-arm-msm, linux-usb, devicetree, pure.logic, greg, robh,
linux-kernel, quic_tsoni, quic_psodagud, quic_satyap,
quic_pheragu, quic_rjendra, quic_sibis, quic_saipraka
In-Reply-To: <YfDMQIFiCfzQy91y@builder.lan>
On 1/26/2022 9:51 AM, Bjorn Andersson wrote:
> On Fri 21 Jan 07:53 CST 2022, Souradeep Chowdhury wrote:
>
>> Add the ports property for dwc3 node. This port can be used
>> by the Embedded USB Debugger for role switching the controller
>> from device to host mode and vice versa.
>>
>> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
>> ---
>> Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
>> index d29ffcd..ccb1236 100644
>> --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
>> +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
>> @@ -332,6 +332,16 @@ properties:
>> items:
>> enum: [1, 4, 8, 16, 32, 64, 128, 256]
>>
>> + ports:
>> + $ref: /schemas/graph.yaml#/properties/ports
>> + description:
>> + This port is to be attached to the endpoint of the Embedded USB Debugger.
> More generally this is used together with the already documented
> usb-role-switch property to connect the dwc3 to the Type-C connector.
>
> Which makes me feel that we don't actually need ports/port, but could do
> with just port? Perhaps I'm missing some usecase?
>
>
> I'm somewhat confused to why this isn't already documented...
Ack. Will document this as a port.
>
> Regards,
> Bjorn
>
>> +
>> + properties:
>> + port@0:
>> + $ref: /schemas/graph.yaml#/properties/port
>> + description: Connector endpoint of Embedded USB debugger.
>> +
>> unevaluatedProperties: false
>>
>> required:
>> --
>> 2.7.4
>>
^ permalink raw reply
* Re: [PATCH net-next v1 1/4] dt-bindings: net: add schema for ASIX USB Ethernet controllers
From: Greg KH @ 2022-01-27 10:59 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Oliver Neukum, David S. Miller, Jakub Kicinski, Rob Herring,
kernel, linux-kernel, linux-usb, netdev, devicetree
In-Reply-To: <20220127104905.899341-2-o.rempel@pengutronix.de>
On Thu, Jan 27, 2022 at 11:49:02AM +0100, Oleksij Rempel wrote:
> Create initial schema for ASIX USB Ethernet controllers and import all
> currently supported USB IDs form drivers/net/usb/asix_devices.c
Again, you are setting yourself to play a game you are always going to
loose and be behind on. This is not acceptable, sorry.
greg k-h
^ permalink raw reply
* Re: [PATCH v4 03/35] iommu/mediatek: Fix 2 HW sharing pgtable issue
From: AngeloGioacchino Del Regno @ 2022-01-27 10:59 UTC (permalink / raw)
To: Yong Wu, Joerg Roedel, Rob Herring, Matthias Brugger, Will Deacon
Cc: Robin Murphy, Krzysztof Kozlowski, Tomasz Figa, linux-mediatek,
srv_heupstream, devicetree, linux-kernel, linux-arm-kernel, iommu,
Hsin-Yi Wang, youlin.pei, anan.sun, xueqi.zhang, yen-chang.chen,
mingyuan.ma, yf.wang, libo.kang, chengci.xu
In-Reply-To: <20220125085634.17972-4-yong.wu@mediatek.com>
Il 25/01/22 09:56, Yong Wu ha scritto:
> In the commit 4f956c97d26b ("iommu/mediatek: Move domain_finalise into
> attach_device"), I overlooked the sharing pgtable case.
> After that commit, the "data" in the mtk_iommu_domain_finalise always is
> the data of the current IOMMU HW. Fix this for the sharing pgtable case.
>
> Only affect mt2712 which is the only SoC that share pgtable currently.
>
> Fixes: 4f956c97d26b ("iommu/mediatek: Move domain_finalise into attach_device")
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH 27/27] drm: rockchip: Add VOP2 driver
From: Sascha Hauer @ 2022-01-27 11:00 UTC (permalink / raw)
To: Piotr Oniszczuk
Cc: dri-devel, linux-arm-kernel@lists.infradead.org, linux-rockchip,
devicetree@vger.kernel.org, kernel, Andy Yan, Benjamin Gaignard,
Michael Riesch, Sandy Huang, Heiko Stübner, Peter Geis
In-Reply-To: <6588D77C-D3CB-4FB0-8B00-5EDD6ABD6923@gmail.com>
On Thu, Jan 27, 2022 at 10:17:13AM +0100, Piotr Oniszczuk wrote:
> Sascha,
>
> FYI
> small report regarding 4k modes support in v4:
>
> -on rk3399 it gives me 4k screen where right vertical 1/3 part of screen is garbage
> -on rk3566 my samsung 4k monitor has black screen and cycle of OSD msgs: HDMI2 connected; HDMI2 disconnected; ....
Same here on my rk3568, also with a samsung monitor. Was it 4k@60Hz or
4k@30Hz? If the former, could you give 4k@30Hz a try? That mode works
well here.
>
> I would suggest split v4 into 2 separated series:
Yeah, splitting up the series makes sense. At the moment I have it all
in one series to ease others testing it.
Sascha
>
> -VOP2 support
> -HDMI 4k modes support
>
> BTW: getting well working 4k HDMI modes on rk3399 was real story for me.
> There is many different series of patches to address this - but all have some subtle issues for me (i.e. 4k HDMI modes works but i.e. Qt is failing with DRM atomic commits in EGLFS)
> I developed well working [1] giving me reliable 4k on rk3399 (including working Qt DRM drawing in EGLFS mode)
> Maybe it will be somehow helpful to get 4k modes solution for rk3566 _and_ rk3399 (on single kernel binary)?
>
> [1] https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-5.16/files/0730-drm-rockchip-add-4k-videomodes-support.patch
At least there are patches in it that I have in my series as well and
keep popping up everywhere like "drm/rockchip: dw_hdmi: Use
auto-generated tables" and "drm/rockchip: dw_hdmi: Set cur_ctr to 0
always"
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH V4 4/6] arm64: dts: qcom: sc7280: Add EUD dt node and dwc3 connector
From: Souradeep Chowdhury @ 2022-01-27 11:00 UTC (permalink / raw)
To: Bjorn Andersson
Cc: linux-arm-msm, linux-usb, devicetree, pure.logic, greg, robh,
linux-kernel, quic_tsoni, quic_psodagud, quic_satyap,
quic_pheragu, quic_rjendra, quic_sibis, quic_saipraka
In-Reply-To: <YfDOBuT/9dEEDG6/@builder.lan>
On 1/26/2022 9:58 AM, Bjorn Andersson wrote:
> On Fri 21 Jan 07:53 CST 2022, Souradeep Chowdhury wrote:
>
>> Add the Embedded USB Debugger(EUD) device tree node. The
>> node contains EUD base register region and EUD mode
>> manager register regions along with the interrupt entry.
>> Also add the typec connector node for EUD which is attached to
>> EUD node via port. EUD is also attached to DWC3 node via port.
>> Also add the role-switch property to dwc3 node.
>>
>> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
>> ---
>> arch/arm64/boot/dts/qcom/sc7280.dtsi | 39 ++++++++++++++++++++++++++++++++++++
>> 1 file changed, 39 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> index 937c2e0..daac831 100644
>> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> @@ -2583,6 +2583,14 @@
>> phys = <&usb_2_hsphy>;
>> phy-names = "usb2-phy";
>> maximum-speed = "high-speed";
>> + usb-role-switch;
>> + ports {
>> + port@0 {
>> + usb2_role_switch: endpoint {
>> + remote-endpoint = <&eud_ep>;
>> + };
>> + };
>> + };
>> };
>> };
>>
>> @@ -2624,6 +2632,37 @@
>> interrupts = <GIC_SPI 582 IRQ_TYPE_LEVEL_HIGH>;
>> };
>>
>> + eud: eud@88e0000 {
>> + compatible = "qcom,sc7280-eud","qcom,eud";
>> + reg = <0 0x88e0000 0 0x2000>,
>> + <0 0x88e2000 0 0x1000>;
>> + interrupt-parent = <&pdc>;
>> + interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
> I find "interrupts-extended = <&pdc 11 IRQ_TYPE_LEVEL_HIGH>;" cleaner
> than having to specify both parent and interrupts.
Ack
>
>> + ports {
>> + port@0 {
>> + eud_ep: endpoint {
>> + remote-endpoint = <&usb2_role_switch>;
>> + };
>> + };
>> + port@1 {
>> + eud_con: endpoint {
>> + remote-endpoint = <&con_eud>;
>> + };
>> + };
>> + };
>> + };
>> +
>> + eud_typec: connector {
> The connector should be a child of the Type-C controller, which I know
> differs between the various devices on this platform. So you should
> leave &eud_con without a remote-endpoint and then fill that in for each
> device, based on respective Type-C controller.
>
>
> But beyond that, I think this design looks good now!
Ack
>
> Regards,
> Bjorn
>
>> + compatible = "usb-c-connector";
>> + ports {
>> + port@0 {
>> + con_eud: endpoint {
>> + remote-endpoint = <&eud_con>;
>> + };
>> + };
>> + };
>> + };
>> +
>> nsp_noc: interconnect@a0c0000 {
>> reg = <0 0x0a0c0000 0 0x10000>;
>> compatible = "qcom,sc7280-nsp-noc";
>> --
>> 2.7.4
>>
^ permalink raw reply
* Re: [PATCH v4 06/35] iommu/mediatek: Add mutex for m4u_group and m4u_dom in data
From: AngeloGioacchino Del Regno @ 2022-01-27 11:02 UTC (permalink / raw)
To: Yong Wu, Joerg Roedel, Rob Herring, Matthias Brugger, Will Deacon
Cc: Robin Murphy, Krzysztof Kozlowski, Tomasz Figa, linux-mediatek,
srv_heupstream, devicetree, linux-kernel, linux-arm-kernel, iommu,
Hsin-Yi Wang, youlin.pei, anan.sun, xueqi.zhang, yen-chang.chen,
mingyuan.ma, yf.wang, libo.kang, chengci.xu
In-Reply-To: <20220125085634.17972-7-yong.wu@mediatek.com>
Il 25/01/22 09:56, Yong Wu ha scritto:
> Add a mutex to protect the data in the structure mtk_iommu_data,
> like ->"m4u_group" ->"m4u_dom". For the internal data, we should
> protect it in ourselves driver. Add a mutex for this.
> This could be a fix for the multi-groups support.
>
> Fixes: c3045f39244e ("iommu/mediatek: Support for multi domains")
> Signed-off-by: Yunfei Wang <yf.wang@mediatek.com>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.c | 13 +++++++++++--
> drivers/iommu/mtk_iommu.h | 2 ++
> 2 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index ec2c387abf60..095736bfb7b4 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -464,15 +464,16 @@ static int mtk_iommu_attach_device(struct iommu_domain *domain,
> dom->data = data;
> }
>
> + mutex_lock(&data->mutex);
> if (!data->m4u_dom) { /* Initialize the M4U HW */
> ret = pm_runtime_resume_and_get(m4udev);
> if (ret < 0)
> - return ret;
> + goto data_unlock;
In order to enhance human readability, I would rather propose:
goto err_unlock;
Apart from this,
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>
> ret = mtk_iommu_hw_init(data);
> if (ret) {
> pm_runtime_put(m4udev);
> - return ret;
> + goto data_unlock;
> }
> data->m4u_dom = dom;
> writel(dom->cfg.arm_v7s_cfg.ttbr & MMU_PT_ADDR_MASK,
> @@ -480,9 +481,14 @@ static int mtk_iommu_attach_device(struct iommu_domain *domain,
>
> pm_runtime_put(m4udev);
> }
> + mutex_unlock(&data->mutex);
>
> mtk_iommu_config(data, dev, true, domid);
> return 0;
> +
> +data_unlock:
> + mutex_unlock(&data->mutex);
> + return ret;
> }
>
> static void mtk_iommu_detach_device(struct iommu_domain *domain,
> @@ -592,6 +598,7 @@ static struct iommu_group *mtk_iommu_device_group(struct device *dev)
> if (domid < 0)
> return ERR_PTR(domid);
>
> + mutex_lock(&data->mutex);
> group = data->m4u_group[domid];
> if (!group) {
> group = iommu_group_alloc();
> @@ -600,6 +607,7 @@ static struct iommu_group *mtk_iommu_device_group(struct device *dev)
> } else {
> iommu_group_ref_get(group);
> }
> + mutex_unlock(&data->mutex);
> return group;
> }
>
> @@ -874,6 +882,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> }
>
> platform_set_drvdata(pdev, data);
> + mutex_init(&data->mutex);
>
> ret = iommu_device_sysfs_add(&data->iommu, dev, NULL,
> "mtk-iommu.%pa", &ioaddr);
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index f81fa8862ed0..f413546ac6e5 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -80,6 +80,8 @@ struct mtk_iommu_data {
>
> struct dma_iommu_mapping *mapping; /* For mtk_iommu_v1.c */
>
> + struct mutex mutex; /* Protect m4u_group/m4u_dom above */
> +
> struct list_head list;
> struct mtk_smi_larb_iommu larb_imu[MTK_LARB_NR_MAX];
> };
>
^ permalink raw reply
* Re: [PATCH v4 07/35] iommu/mediatek: Add mutex for data in the mtk_iommu_domain
From: AngeloGioacchino Del Regno @ 2022-01-27 11:02 UTC (permalink / raw)
To: Yong Wu, Joerg Roedel, Rob Herring, Matthias Brugger, Will Deacon
Cc: Robin Murphy, Krzysztof Kozlowski, Tomasz Figa, linux-mediatek,
srv_heupstream, devicetree, linux-kernel, linux-arm-kernel, iommu,
Hsin-Yi Wang, youlin.pei, anan.sun, xueqi.zhang, yen-chang.chen,
mingyuan.ma, yf.wang, libo.kang, chengci.xu
In-Reply-To: <20220125085634.17972-8-yong.wu@mediatek.com>
Il 25/01/22 09:56, Yong Wu ha scritto:
> Same with the previous patch, add a mutex for the "data" in the
> mtk_iommu_domain. Just improve the safety for multi devices
> enter attach_device at the same time. We don't get the real issue
> for this.
>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: iommu: renesas,ipmmu-vmsa: add r8a779f0 support
From: Geert Uytterhoeven @ 2022-01-27 11:05 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: Joerg Roedel, Will Deacon, Rob Herring, Linux IOMMU,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux-Renesas, Laurent Pinchart, Magnus Damm
In-Reply-To: <20220125125602.4144793-2-yoshihiro.shimoda.uh@renesas.com>
Hi Shimoda-san,
CC Laurent, Magnus.
On Tue, Jan 25, 2022 at 6:33 PM Yoshihiro Shimoda
<yoshihiro.shimoda.uh@renesas.com> wrote:
> Document the compatible values for the IPMMU-VMSA blocks in
> the Renesas R-Car S4-8 (R8A779F0) SoC and R-Car Gen4.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Thanks for your patch!
> --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> @@ -44,6 +44,10 @@ properties:
> - renesas,ipmmu-r8a77990 # R-Car E3
> - renesas,ipmmu-r8a77995 # R-Car D3
> - renesas,ipmmu-r8a779a0 # R-Car V3U
> + - items:
> + - enum:
> + - renesas,ipmmu-r8a779f0 # R-Car S4-8
> + - const: renesas,rcar-gen4-ipmmu-vmsa # R-Car Gen4
>
I'm wondering if we need the family-specific fallback.
For R-Car Gen3, we don't have it, and match on (all) the SoC-specific
compatible values instead.
Do you remember why we decided to do it that way?
At least R-Car V3M/V3H/D3 have slight differences in the register bits,
but I don't think that was the reason.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 09/27] drm/rockchip: dw_hdmi: Set cur_ctr to 0 always
From: Sascha Hauer @ 2022-01-27 11:06 UTC (permalink / raw)
To: Doug Anderson
Cc: dri-devel,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Benjamin Gaignard, Peter Geis, Sandy Huang,
open list:ARM/Rockchip SoC..., Michael Riesch, Sascha Hauer,
Yakir Yang, Andy Yan, Linux ARM
In-Reply-To: <CAD=FV=VCWW4c3iqfzezU5=KKVFNP+EhPGTBZ7uZdQ=bSCJHQVA@mail.gmail.com>
On Wed, Jan 26, 2022 at 07:42:48AM -0800, Doug Anderson wrote:
> Hi,
>
> On Wed, Jan 26, 2022 at 6:58 AM Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >
> > From: Douglas Anderson <dianders@chromium.org>
> >
> > Jitter was improved by lowering the MPLL bandwidth to account for high
> > frequency noise in the rk3288 PLL. In each case MPLL bandwidth was
> > lowered only enough to get us a comfortable margin. We believe that
> > lowering the bandwidth like this is safe given sufficient testing.
> >
> > Changes since v3:
> > - new patch
> >
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > Signed-off-by: Yakir Yang <ykk@rock-chips.com>
> > (am from https://patchwork.kernel.org/patch/9223301/)
>
> Probably remove the "am from" line? It's not standard in upstream and
> that link doesn't seem to go anywhere anymore...
>
>
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > ---
> > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 16 ++--------------
> > 1 file changed, 2 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> > index c44eb4d2e2d5..77f82a4fd027 100644
> > --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> > +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> > @@ -176,20 +176,8 @@ static const struct dw_hdmi_mpll_config rockchip_mpll_cfg[] = {
> > static const struct dw_hdmi_curr_ctrl rockchip_cur_ctr[] = {
> > /* pixelclk bpp8 bpp10 bpp12 */
> > {
> > - 40000000, { 0x0018, 0x0018, 0x0018 },
> > - }, {
> > - 65000000, { 0x0028, 0x0028, 0x0028 },
> > - }, {
> > - 66000000, { 0x0038, 0x0038, 0x0038 },
> > - }, {
> > - 74250000, { 0x0028, 0x0038, 0x0038 },
> > - }, {
> > - 83500000, { 0x0028, 0x0038, 0x0038 },
> > - }, {
> > - 146250000, { 0x0038, 0x0038, 0x0038 },
> > - }, {
> > - 148500000, { 0x0000, 0x0038, 0x0038 },
> > - }, {
> > + 600000000, { 0x0000, 0x0000, 0x0000 },
> > + }, {
>
> This is what we did for rk3288. I can't personally vouch for the
> effects on other SoCs.
Fair enough. Rockchip has this patch in their downstream Kernel, so I am
confident it works on SoCs newer as the rk3288 as well. I don't know how
much they care about the older SoCs, but it seems there is only the
rk3228 that is older than the rk3288 that is supported by this driver.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH v4 08/35] iommu/mediatek: Use kmalloc for protect buffer
From: AngeloGioacchino Del Regno @ 2022-01-27 11:08 UTC (permalink / raw)
To: Yong Wu, Joerg Roedel, Rob Herring, Matthias Brugger, Will Deacon
Cc: Robin Murphy, Krzysztof Kozlowski, Tomasz Figa, linux-mediatek,
srv_heupstream, devicetree, linux-kernel, linux-arm-kernel, iommu,
Hsin-Yi Wang, youlin.pei, anan.sun, xueqi.zhang, yen-chang.chen,
mingyuan.ma, yf.wang, libo.kang, chengci.xu
In-Reply-To: <20220125085634.17972-9-yong.wu@mediatek.com>
Il 25/01/22 09:56, Yong Wu ha scritto:
> No need zero for the protect buffer that is only accessed by the IOMMU HW
> translation fault happened.
>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
I would rather keep this a devm_kzalloc instead... the cost is very minimal and
this will be handy when new hardware will be introduced, as it may require a bigger
buffer: in that case, "older" platforms will use only part of it and we may get
garbage data at the end.
Regards,
Angelo
^ 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