* Re: (EXT) Re: (EXT) Re: [PATCH] arm64: dts: imx8mm-venice-gw73xx-0x: add dt overlays for serial modes
From: Shawn Guo @ 2022-01-26 7:44 UTC (permalink / raw)
To: Alexander Stein
Cc: Tim Harvey, Rob Herring, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, NXP Linux Team, Device Tree Mailing List,
open list, Linux ARM Mailing List
In-Reply-To: <6686721.lOV4Wx5bFT@steina-w>
On Wed, Jan 12, 2022 at 07:58:00AM +0100, Alexander Stein wrote:
> Am Dienstag, 11. Januar 2022, 18:53:29 CET schrieb Tim Harvey:
> > On Mon, Jan 10, 2022 at 11:20 PM Alexander Stein
> >
> > <alexander.stein@ew.tq-group.com> wrote:
> > > Am Dienstag, 11. Januar 2022, 01:00:21 CET schrieb Tim Harvey:
> > > > [SNIP]
> > > >
> > > > > diff --git a/arch/arm64/boot/dts/freescale/Makefile
> > > > > b/arch/arm64/boot/dts/freescale/Makefile index
> > > > > a14a6173b765..5ec8d59347b6
> > > > > 100644
> > > > > --- a/arch/arm64/boot/dts/freescale/Makefile
> > > > > +++ b/arch/arm64/boot/dts/freescale/Makefile
> > > > > @@ -44,6 +44,9 @@ dtb-$(CONFIG_ARCH_MXC) +=
> > > > > imx8mm-var-som-symphony.dtb
> > > > >
> > > > > dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw71xx-0x.dtb
> > > > > dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw72xx-0x.dtb
> > > > > dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw73xx-0x.dtb
> > > > >
> > > > > +dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw73xx-0x-rs232-rts.dtbo
> > > > > +dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw73xx-0x-rs422.dtbo
> > > > > +dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw73xx-0x-rs485.dtbo
> > > > >
> > > > > dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw7901.dtb
> > > > > dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw7902.dtb
> > > > > dtb-$(CONFIG_ARCH_MXC) += imx8mn-beacon-kit.dtb
> > > >
> > > > [SNIP]
> > > > I'm mostly interested to see if my approach to dt fragments here and
> > > > the naming of the files makes sense to others.
> > > >
> > > > This patch causes the kernel to build dtbo files for:
> > > > arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx-0x-rs232-rts.dtbo
> > > > arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx-0x-rs422.dtbo
> > > > arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx-0x-rs485.dtbo
> > > >
> > > > The intention is that these files are used by boot firmware (U-Boot)
> > > > to adjust the dtb before passing it to the kernel.
> > >
> > > Hi Tim,
> > >
> > > do these dtbo actually work? I'm wondering because I was trying to
> > > useoverlays myself and noticed that the had to be compiled with -@ for
> > > u-boot to be able
> > > to apply them. Apparently there are 2 possibilities:
> > Alexander,
> >
> > Yes, they work, but I do manually set DTC_FLAGS=-@ when building
> > kernel dtbs to make them work.
>
> I see, I expected something like this. That's why I responded to you.
>
> > > * Set "DTC_FLAGS_[dtb] := -@" yourself
> > > See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
> > > commit/?id=e426d63e752bdbe7d5ba2d872319dde9ab844a07
> > >
> > > * Use dedicated overlay target
> > > See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
> > > commit/?id=15d16d6dadf6947ac7f9a686c615995c5a426ce2
> > >
> > > You use neither of them. IIRC just naming the target file .dtbo will not
> > > apply symbols (-Q) during dtc call. Can you verify using 'V=1'
> > > Also I'm wondering which way is the best to go.
> >
> > I wasn't aware there was a way to do this via Makefiles. It seems that
> > perhaps Rob's approach with 'kbuild: Add generic rule to apply
> > fdtoverlay' is a way to avoid having to add them all manually in the
> > first approach? I must admit I'm not sure how to use that.
>
> I tried using this myself for my custom board. I feel it is a bit cumbersome
> to get it right.
> See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/
> arch/arm64/boot/dts/xilinx/Makefile for an example.
>
> Essentially you define your .dtb as before and add another target (e.g. sm-
> k26-revA-sck-kv-g-revA-dtbs) where you add your .dtbo _after_ the original
> .dtb. This target needs to be added to 'dtb-y' as before.
>
> I suspect this way is needed to check the .dtbo against the base .dtb if it
> actually matches.
Yeah, I like this check. Tim, could you update your patch to follow
this pattern?
Shawn
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] net: macb: Added ZynqMP-specific initialization
From: Michal Simek @ 2022-01-26 7:30 UTC (permalink / raw)
To: Robert Hancock, netdev
Cc: davem, kuba, robh+dt, michal.simek, nicolas.ferre, claudiu.beznea,
devicetree
In-Reply-To: <20220125170533.256468-3-robert.hancock@calian.com>
On 1/25/22 18:05, Robert Hancock wrote:
> The GEM controllers on ZynqMP were missing some initialization steps which
> are required in some cases when using SGMII mode, which uses the PS-GTR
> transceivers managed by the phy-zynqmp driver.
>
> The GEM core appears to need a hardware-level reset in order to work
> properly in SGMII mode in cases where the GT reference clock was not
> present at initial power-on. This can be done using a reset mapped to
> the zynqmp-reset driver in the device tree.
>
> Also, when in SGMII mode, the GEM driver needs to ensure the PHY is
> initialized and powered on when it is initializing.
>
> Signed-off-by: Robert Hancock <robert.hancock@calian.com>
> ---
> drivers/net/ethernet/cadence/macb_main.c | 48 +++++++++++++++++++++++-
> 1 file changed, 47 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index a363da928e8b..80882908a68f 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -34,7 +34,9 @@
> #include <linux/udp.h>
> #include <linux/tcp.h>
> #include <linux/iopoll.h>
> +#include <linux/phy/phy.h>
> #include <linux/pm_runtime.h>
> +#include <linux/reset.h>
> #include "macb.h"
>
> /* This structure is only used for MACB on SiFive FU540 devices */
> @@ -4455,6 +4457,50 @@ static int fu540_c000_init(struct platform_device *pdev)
> return macb_init(pdev);
> }
>
> +static int zynqmp_init(struct platform_device *pdev)
> +{
> + struct net_device *dev = platform_get_drvdata(pdev);
> + struct macb *bp = netdev_priv(dev);
> + int ret;
> +
> + if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII) {
> + /* Ensure PS-GTR PHY device used in SGMII mode is ready */
> + struct phy *sgmii_phy = devm_phy_get(&pdev->dev, "sgmii-phy");
> +
> + if (IS_ERR(sgmii_phy)) {
> + ret = PTR_ERR(sgmii_phy);
> + dev_err_probe(&pdev->dev, ret,
> + "failed to get PS-GTR PHY\n");
> + return ret;
> + }
> +
> + ret = phy_init(sgmii_phy);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to init PS-GTR PHY: %d\n",
> + ret);
> + return ret;
> + }
I think reset below should be here to follow correct startup sequence.
Thanks,
Michal
> +
> + ret = phy_power_on(sgmii_phy);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to power on PS-GTR PHY: %d\n",
> + ret);
> + return ret;
> + }
> + }
> +
> + /* Fully reset GEM controller at hardware level using zynqmp-reset driver,
> + * if mapped in device tree.
> + */
> + ret = device_reset_optional(&pdev->dev);
> + if (ret) {
> + dev_err_probe(&pdev->dev, ret, "failed to reset controller");
> + return ret;
> + }
> +
> + return macb_init(pdev);
> +}
> +
> static const struct macb_usrio_config sama7g5_usrio = {
> .mii = 0,
> .rmii = 1,
> @@ -4550,7 +4596,7 @@ static const struct macb_config zynqmp_config = {
> MACB_CAPS_GEM_HAS_PTP | MACB_CAPS_BD_RD_PREFETCH,
> .dma_burst_length = 16,
> .clk_init = macb_clk_init,
> - .init = macb_init,
> + .init = zynqmp_init,
> .jumbo_max_len = 10240,
> .usrio = &macb_default_usrio,
> };
^ permalink raw reply
* Re: [PATCH v8 8/8] arm64: dts: mt6359: add PMIC MT6359 related nodes
From: Macpaul Lin @ 2022-01-26 7:28 UTC (permalink / raw)
To: Hsin-hsiung Wang, Matthias Brugger, hui.liu, sen.chu
Cc: Lee Jones, Rob Herring, Liam Girdwood, Mark Brown, Eddie Huang,
Alessandro Zummo, Alexandre Belloni, Fei Shao, Sean Wang,
Yuchen Huang, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-rtc, srv_heupstream,
Project_Global_Chrome_Upstream_Group, Wen Su, Wens Tsai,
Rex-BC Chen, Macpaul Lin
In-Reply-To: <2a7c0936-55a5-8448-3ffa-2a854f5a57ee@mediatek.com>
On 1/25/22 4:32 PM, Macpaul Lin wrote:
>
> On 6/16/21 10:07 PM, Hsin-hsiung Wang wrote:
>> Hi,
>>
>> On Fri, 2021-06-11 at 16:09 +0200, Matthias Brugger wrote:
>>>
>>> On 26/05/2021 08:52, Hsin-Hsiung Wang wrote:
>>>> From: Wen Su <wen.su@mediatek.com>
>>>>
>>>> add PMIC MT6359 related nodes which is for MT6779 platform
>>>>
>>>> Signed-off-by: Wen Su <wen.su@mediatek.com>
>>>> Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
>>>> ---
>>>> changes since v7:
>>>> - no change.
>>>> ---
>>>> arch/arm64/boot/dts/mediatek/mt6359.dtsi | 298
>>>> ++++++++++++++++++++++++++++
>>>> arch/arm64/boot/dts/mediatek/mt8192-evb.dts | 1 +
>>>> 2 files changed, 299 insertions(+)
>>>> create mode 100644 arch/arm64/boot/dts/mediatek/mt6359.dtsi
>>>>
>>>> diff --git a/arch/arm64/boot/dts/mediatek/mt6359.dtsi
>>>> b/arch/arm64/boot/dts/mediatek/mt6359.dtsi
>>>> new file mode 100644
>>>> index 0000000..18c0d53
>>>> --- /dev/null
>>>> +++ b/arch/arm64/boot/dts/mediatek/mt6359.dtsi
>>>> @@ -0,0 +1,298 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>
>>> Any specific reason for not setting it "SPDX-License-Identifier:
>>> (GPL-2.0+ OR
>>> MIT)" ?
>>>
>>> Other then that, looks good.
>>>
>>> Matthias
>>>
>>
>> Thanks for the review, there is no special reason for the writing.
>> I will update it in the next patch.
>>
> [The content of the patch has been deleted...]
>
> According to the reviewing note of PMIC wrap, URL:
> https://patchwork.kernel.org/project/linux-mediatek/cover/1615563286-22126-1-git-send-email-hsin-hsiung.wang@mediatek.com
>
>
> Dear Hui and Sen,
> could you help update and upstream the mt6359.dtsi and mt8192-evb.dts
> with the necessary fixes?
>
> Thanks!
> Macpaul Lin
Dear Hui,
I've found patch v8 will cause build fail because pwrap node hasn't been
merged according to [1] and [2] (mt8192). However, the pwrap node for
mt8195 is already in [3] mt8195.dtsi. The mt8195 boards using mt6359
will need mt6359.dtsi for enabling more peripherals.
I think to split the mt8192 part into the other patch in next version
could reduce the dependencies between mt6359.dtsi and mt8192.dtsi at
this stage. Hence we don't need to wait pwrap node be merged in mt8192.dtsi.
[1]
https://lore.kernel.org/all/1615563286-22126-6-git-send-email-hsin-hsiung.wang@mediatek.com/
[2]
https://lore.kernel.org/all/e33053cf-f337-d7f6-fbf6-93d385f7e683@gmail.com/
[3]
https://lore.kernel.org/all/20220112114724.1953-4-tinghan.shen@mediatek.com/
After that, you can have my Reviewed-by tag in next version.
Reviewed-by: Macpaul Lin <macpaul.lin@mediatek.com>
Thanks :)
Macpaul Lin
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: meson-gx: add ATF BL32 reserved-memory region
From: Christian Hewitt @ 2022-01-26 7:12 UTC (permalink / raw)
To: Vyacheslav
Cc: Rob Herring, Mark Rutland, Kevin Hilman, Neil Armstrong,
devicetree, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <a279c365-0615-1c7f-5596-dec9ad1c8229@lexina.in>
> On 26 Jan 2022, at 9:35 am, Vyacheslav <adeep@lexina.in> 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?
Are they booting using Amlogic (vendor) u-boot sources that
include bl32.img in the FIP signing recipe?
If booting from upstream u-boot, like JetHome boards, it’s
nothing to worry about.
Christian
^ permalink raw reply
* [PATCH REBASED 2/2] dt-bindings: nvmem: cells: add MAC address cell
From: Rafał Miłecki @ 2022-01-26 7:07 UTC (permalink / raw)
To: Rob Herring, Srinivas Kandagatla, Michael Walle
Cc: linux-mtd, devicetree, linux-kernel, linux-arm-kernel, netdev,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra, Shawn Guo,
Li Yang, Frank Rowand, David S . Miller, Jakub Kicinski,
Ansuel Smith, Andrew Lunn, Florian Fainelli, Hauke Mehrtens,
Rafał Miłecki
In-Reply-To: <20220126070745.32305-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
This adds support for describing details of NVMEM cell containing MAC
address. Those are often device specific and could be nicely stored in
DT.
Initial documentation includes support for describing:
1. Cell data format (e.g. Broadcom's NVRAM uses ASCII to store MAC)
2. Reversed bytes flash (required for i.MX6/i.MX7 OCOTP support)
3. Source for multiple addresses (very common in home routers)
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
.../bindings/nvmem/cells/mac-address.yaml | 94 +++++++++++++++++++
1 file changed, 94 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/cells/mac-address.yaml
diff --git a/Documentation/devicetree/bindings/nvmem/cells/mac-address.yaml b/Documentation/devicetree/bindings/nvmem/cells/mac-address.yaml
new file mode 100644
index 000000000000..f8d19e87cdf0
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/cells/mac-address.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/cells/mac-address.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVMEM cell containing a MAC address
+
+maintainers:
+ - Rafał Miłecki <rafal@milecki.pl>
+
+properties:
+ compatible:
+ const: mac-address
+
+ format:
+ description: |
+ Some NVMEM cells contain MAC in a non-binary format.
+
+ ASCII should be specified if MAC is string formatted like:
+ - "01:23:45:67:89:AB" (30 31 3a 32 33 3a 34 35 3a 36 37 3a 38 39 3a 41 42)
+ - "01-23-45-67-89-AB"
+ - "0123456789AB"
+ enum:
+ - ascii
+
+ reversed-bytes:
+ type: boolean
+ description: |
+ MAC is stored in reversed bytes order. Example:
+ Stored value: AB 89 67 45 23 01
+ Actual MAC: 01 23 45 67 89 AB
+
+ base-address:
+ type: boolean
+ description: |
+ Marks NVMEM cell as provider of multiple addresses that are relative to
+ the one actually stored physically. Respective addresses can be requested
+ by specifying cell index of NVMEM cell.
+
+allOf:
+ - $ref: cell.yaml#
+ - if:
+ required:
+ - base-address
+ then:
+ properties:
+ "#nvmem-cell-cells":
+ const: 1
+ required:
+ - "#nvmem-cell-cells"
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@f00000 {
+ compatible = "nvmem-cells";
+ label = "calibration";
+ reg = <0xf00000 0x100000>;
+ ranges = <0 0xf00000 0x100000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ mac@100 {
+ compatible = "mac-address";
+ reg = <0x100 0x6>;
+ };
+
+ mac@200 {
+ compatible = "mac-address";
+ reg = <0x200 0x6>;
+ reversed-bytes;
+ };
+
+ mac@300 {
+ compatible = "mac-address";
+ reg = <0x300 0x11>;
+ format = "ascii";
+ };
+
+ mac@400 {
+ compatible = "mac-address";
+ reg = <0x400 0x6>;
+ base-address;
+ #nvmem-cell-cells = <1>;
+ };
+ };
+ };
--
2.31.1
^ permalink raw reply related
* [PATCH REBASED 1/2] dt-bindings: nvmem: extract NVMEM cell to separated file
From: Rafał Miłecki @ 2022-01-26 7:07 UTC (permalink / raw)
To: Rob Herring, Srinivas Kandagatla, Michael Walle
Cc: linux-mtd, devicetree, linux-kernel, linux-arm-kernel, netdev,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra, Shawn Guo,
Li Yang, Frank Rowand, David S . Miller, Jakub Kicinski,
Ansuel Smith, Andrew Lunn, Florian Fainelli, Hauke Mehrtens,
Rafał Miłecki
In-Reply-To: <20220125180114.12286-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
This will allow adding binding for more specific cells and reusing
(sharing) common code.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
.../devicetree/bindings/nvmem/cells/cell.yaml | 34 +++++++++++++++++++
.../devicetree/bindings/nvmem/nvmem.yaml | 22 +-----------
2 files changed, 35 insertions(+), 21 deletions(-)
create mode 100644 Documentation/devicetree/bindings/nvmem/cells/cell.yaml
diff --git a/Documentation/devicetree/bindings/nvmem/cells/cell.yaml b/Documentation/devicetree/bindings/nvmem/cells/cell.yaml
new file mode 100644
index 000000000000..adfc2e639f43
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/cells/cell.yaml
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/cells/cell.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVMEM cell
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description: NVMEM cell is a data entry of NVMEM device.
+
+properties:
+ reg:
+ maxItems: 1
+ description:
+ Offset and size in bytes within the storage device.
+
+ bits:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - minimum: 0
+ maximum: 7
+ description:
+ Offset in bit within the address range specified by reg.
+ - minimum: 1
+ description:
+ Size in bit within the address range specified by reg.
+
+required:
+ - reg
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
index 43ed7e32e5ac..b79b51e98ee8 100644
--- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml
+++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
@@ -41,27 +41,7 @@ properties:
patternProperties:
"@[0-9a-f]+(,[0-7])?$":
- type: object
-
- properties:
- reg:
- maxItems: 1
- description:
- Offset and size in bytes within the storage device.
-
- bits:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- items:
- - minimum: 0
- maximum: 7
- description:
- Offset in bit within the address range specified by reg.
- - minimum: 1
- description:
- Size in bit within the address range specified by reg.
-
- required:
- - reg
+ $ref: cells/cell.yaml#
additionalProperties: true
--
2.31.1
^ permalink raw reply related
* Re: [PATCH 01/12] arm64: dts: exynos: add USB DWC3 supplies to Espresso board
From: Alim Akhtar @ 2022-01-26 6:58 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Greg Kroah-Hartman, Rob Herring, linux-usb, devicetree,
linux-arm-kernel, linux-samsung-soc, open list
In-Reply-To: <20220123111644.25540-2-krzysztof.kozlowski@canonical.com>
Hi Krzysztof
On Mon, Jan 24, 2022 at 1:34 PM Krzysztof Kozlowski
<krzysztof.kozlowski@canonical.com> wrote:
>
> Add required voltage regulators for USB DWC3 block on Exynos7 Espresso
> board. Due to lack of schematics of Espresso board, the choice of
> regulators is approximate. What bindings call VDD10, for Exynos7 should
> be actually called VDD09 (0.9 V). Use regulators with a matching
> voltage range based on vendor sources for Meizu Pro 5 M576 handset (also
> with Exynos7420).
>
I checked Espresso board schematic, it is 0.9V for the USB and supplied by LDO4
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
> ---
> arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 5 +++++
> arch/arm64/boot/dts/exynos/exynos7.dtsi | 2 +-
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> index 125c03f351d9..4c45e689d34a 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> @@ -412,6 +412,11 @@ &ufs {
> status = "okay";
> };
>
> +&usbdrd {
> + vdd10-supply = <&ldo4_reg>;
> + vdd33-supply = <&ldo6_reg>;
> +};
> +
> &usbdrd_phy {
> vbus-supply = <&usb30_vbus_reg>;
> vbus-boost-supply = <&usb3drd_boost_5v>;
> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> index c3efbc8add38..01b4210d8b62 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> @@ -672,7 +672,7 @@ usbdrd_phy: phy@15500000 {
> #phy-cells = <1>;
> };
>
> - usbdrd3 {
> + usbdrd: usb {
> compatible = "samsung,exynos7-dwusb3";
> clocks = <&clock_fsys0 ACLK_USBDRD300>,
> <&clock_fsys0 SCLK_USBDRD300_SUSPENDCLK>,
> --
> 2.32.0
>
--
Regards,
Alim
^ permalink raw reply
* RE: [PATCH v5 00/16] Add support for Tesla Full Self-Driving (FSD) SoC
From: Alim Akhtar @ 2022-01-26 6:52 UTC (permalink / raw)
To: 'Krzysztof Kozlowski', linux-arm-kernel, linux-kernel
Cc: soc, linux-clk, devicetree, olof, arnd, linus.walleij,
catalin.marinas, robh+dt, s.nawrocki, linux-samsung-soc,
pankaj.dubey, sboyd
In-Reply-To: <d9682f16-13b7-b6dc-5afd-b2d319143de5@canonical.com>
>-----Original Message-----
>From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@canonical.com]
>Sent: Tuesday, January 25, 2022 10:42 PM
>To: Alim Akhtar <alim.akhtar@samsung.com>; linux-arm-
>kernel@lists.infradead.org; linux-kernel@vger.kernel.org
>Cc: soc@kernel.org; linux-clk@vger.kernel.org; devicetree@vger.kernel.org;
>olof@lixom.net; arnd@arndb.de; linus.walleij@linaro.org;
>catalin.marinas@arm.com; robh+dt@kernel.org; s.nawrocki@samsung.com;
>linux-samsung-soc@vger.kernel.org; pankaj.dubey@samsung.com;
>sboyd@kernel.org
>Subject: Re: [PATCH v5 00/16] Add support for Tesla Full Self-Driving (FSD) SoC
>
>On 24/01/2022 15:16, Alim Akhtar wrote:
>> Adds basic support for the Tesla Full Self-Driving (FSD) SoC. This SoC
>> contains three clusters of four Cortex-A72 CPUs, as well as several
>> IPs.
>>
>> Patches 1 to 9 provide support for the clock controller (which is
>> designed similarly to Exynos SoCs).
>>
>> The remaining changes provide pinmux support, initial device tree support.
>>
>> - Changes since v4
>> * fixed 'make dtbs_check' warnings on patch 14/16
>>
>> - Changes since v3
>> * Addressed Stefen's review comments on patch 14/16
>> * Fixed kernel test robot warning on patch 04/16
>> * rebsaed this series on Krzysztof's pinmux new binding schema work
>> [1]
>>
>> - Changes since v2
>> * Addressed Krzysztof's and Stephen's review comments
>> * Added Reviewed-by and Acked-by tags
>> * Rebased on next-20220120
>>
>> - Changes since v1
>> * fixed make dt_binding_check error as pointed by Rob
>> * Addressed Krzysztof's and Rob's review comments
>> * Added Reviewed-by and Acked-by tags
>> * Dropped SPI, MCT and ADC from this series (to be posted in small
>> sets)
>>
>> NOTE: These patches are based on Krzysztof's pinmux for-next branch
>> commit 832ae134ccc1 ("pinctrl: samsung: add support for Exynos850 and
>> ExynosAutov9 wake-ups") [1]
>> https://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/samsung.git/lo
>> g/?h=for-next
>>
>>
>
>Thanks, applied DTS/soc and pinctrl patches.
>
Thanks Krzysztof
>I expect Sylwester will pick up the clock ones. Otherwise please let me know
>to pick it up as well.
>
Hi Sylwester, hope you will be taking clock changes, or let Krzysztof know otherwise.
Thanks
>
>Best regards,
>Krzysztof
^ permalink raw reply
* RE: [PATCH v5 00/16] Add support for Tesla Full Self-Driving (FSD) SoC
From: Alim Akhtar @ 2022-01-26 6:50 UTC (permalink / raw)
To: 'Krzysztof Kozlowski', linux-arm-kernel, linux-kernel
Cc: soc, linux-clk, devicetree, olof, arnd, linus.walleij,
catalin.marinas, robh+dt, s.nawrocki, linux-samsung-soc,
pankaj.dubey, sboyd
In-Reply-To: <4cfcde38-50cb-646a-0d17-c2cb2977a2e4@canonical.com>
Hi Krzysztof
>-----Original Message-----
>From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@canonical.com]
>Sent: Tuesday, January 25, 2022 10:56 PM
>To: Alim Akhtar <alim.akhtar@samsung.com>; linux-arm-
>kernel@lists.infradead.org; linux-kernel@vger.kernel.org
>Cc: soc@kernel.org; linux-clk@vger.kernel.org; devicetree@vger.kernel.org;
>olof@lixom.net; arnd@arndb.de; linus.walleij@linaro.org;
>catalin.marinas@arm.com; robh+dt@kernel.org; s.nawrocki@samsung.com;
>linux-samsung-soc@vger.kernel.org; pankaj.dubey@samsung.com;
>sboyd@kernel.org
>Subject: Re: [PATCH v5 00/16] Add support for Tesla Full Self-Driving (FSD) SoC
>
>On 25/01/2022 18:12, Krzysztof Kozlowski wrote:
>> On 24/01/2022 15:16, Alim Akhtar wrote:
>>> Adds basic support for the Tesla Full Self-Driving (FSD) SoC. This
>>> SoC contains three clusters of four Cortex-A72 CPUs, as well as
>>> several IPs.
>>>
>>> Patches 1 to 9 provide support for the clock controller (which is
>>> designed similarly to Exynos SoCs).
>>>
>>> The remaining changes provide pinmux support, initial device tree support.
>>>
>>> - Changes since v4
>>> * fixed 'make dtbs_check' warnings on patch 14/16
>>>
>>> - Changes since v3
>>> * Addressed Stefen's review comments on patch 14/16
>>> * Fixed kernel test robot warning on patch 04/16
>>> * rebsaed this series on Krzysztof's pinmux new binding schema work
>>> [1]
>>>
>>> - Changes since v2
>>> * Addressed Krzysztof's and Stephen's review comments
>>> * Added Reviewed-by and Acked-by tags
>>> * Rebased on next-20220120
>>>
>>> - Changes since v1
>>> * fixed make dt_binding_check error as pointed by Rob
>>> * Addressed Krzysztof's and Rob's review comments
>>> * Added Reviewed-by and Acked-by tags
>>> * Dropped SPI, MCT and ADC from this series (to be posted in small
>>> sets)
>>>
>>> NOTE: These patches are based on Krzysztof's pinmux for-next branch
>>> commit 832ae134ccc1 ("pinctrl: samsung: add support for Exynos850 and
>>> ExynosAutov9 wake-ups") [1]
>>> https://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/samsung.git/l
>>> og/?h=for-next
>>>
>>>
>>
>> Thanks, applied DTS/soc and pinctrl patches.
>>
>> I expect Sylwester will pick up the clock ones. Otherwise please let
>> me know to pick it up as well.
>
>I forgot that clock macros are used in DTS. This does not compile and I cannot
>take drivers into DTS branch.
>
>Alim,
>DTS changes dropped. Please resend with the same trick we did for
>Exynos850 board - hard-coded clock IDs as defines. See:
>
>https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git/diff/arch/arm6
>4/boot/dts/exynos/exynos850.dtsi?h=samsung-dt64-5.17-
>2&id=e3493220fd3e474abcdcefbe14fb60485097ce06
>
Ok, I will resend patch 14 and 15 (DTS changes) only as suggested above.
>
>Best regards,
>Krzysztof
^ permalink raw reply
* Re: (EXT) [PATCH V4 09/11] dt-bindings: media: nxp, imx8mq-vpu: Add support for G1 on imx8mm
From: Alexander Stein @ 2022-01-26 6:45 UTC (permalink / raw)
To: Adam Ford
Cc: linux-media, aford, cphealy, Adam Ford, Ezequiel Garcia,
Philipp Zabel, Mauro Carvalho Chehab, Rob Herring, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Greg Kroah-Hartman, Lucas Stach, linux-rockchip,
devicetree, linux-arm-kernel, linux-kernel, linux-staging
In-Reply-To: <20220125171129.472775-10-aford173@gmail.com>
Am Dienstag, 25. Januar 2022, 18:11:26 CET schrieb Adam Ford:
> The i.MX8M mini appears to have a similar G1 decoder but the
> post-processing isn't present, so different compatible flag is required.
> Since all the other parameters are the same with imx8mq, just add
> the new compatible flag to nxp,imx8mq-vpu.yaml.
>
> Signed-off-by: Adam Ford <aford173@gmail.com>
> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
>
> diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml
> b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml index
> 9c28d562112b..7dc13a4b1805 100644
> --- a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml
> +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml
> @@ -5,7 +5,7 @@
> $id: "http://devicetree.org/schemas/media/nxp,imx8mq-vpu.yaml#"
> $schema: "http://devicetree.org/meta-schemas/core.yaml#"
>
> -title: Hantro G1/G2 VPU codecs implemented on i.MX8MQ SoCs
> +title: Hantro G1/G2 VPU codecs implemented on i.MX8M SoCs
>
> maintainers:
> - Philipp Zabel <p.zabel@pengutronix.de>
> @@ -20,6 +20,7 @@ properties:
> deprecated: true
> - const: nxp,imx8mq-vpu-g1
> - const: nxp,imx8mq-vpu-g2
> + - const: nxp,imx8mm-vpu-g1
>
> reg:
> maxItems: 1
Is there no rule that items are sorted alphabetically?
Regards,
Alexander
^ permalink raw reply
* Re: (EXT) [PATCH V4 01/11] arm64: dts: imx8mq-tqma8mq: Remove redundant vpu reference
From: Alexander Stein @ 2022-01-26 6:42 UTC (permalink / raw)
To: Adam Ford
Cc: linux-media, aford, cphealy, Adam Ford, Ezequiel Garcia,
Philipp Zabel, Mauro Carvalho Chehab, Rob Herring, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Greg Kroah-Hartman, Lucas Stach, linux-rockchip,
devicetree, linux-arm-kernel, linux-kernel, linux-staging
In-Reply-To: <20220125171129.472775-2-aford173@gmail.com>
Am Dienstag, 25. Januar 2022, 18:11:18 CET schrieb Adam Ford:
> The vpu is enabled by default, so there is no need to manually
> enable it.
>
> Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq-tqma8mq.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mq-tqma8mq.dtsi index
> 8aedcddfeab8..38ffcd145b33 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq-tqma8mq.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq-tqma8mq.dtsi
> @@ -272,10 +272,6 @@ &usdhc1 {
> status = "okay";
> };
>
> -&vpu {
> - status = "okay";
> -};
> -
> /* Attention: wdog reset forcing POR needs baseboard support */
> &wdog1 {
> status = "okay";
^ permalink raw reply
* [PATCH v5 08/10] bindings: spmi: spmi-pmic-arb: mark interrupt properties as optional
From: Fenglin Wu @ 2022-01-26 6:31 UTC (permalink / raw)
To: linux-arm-msm, linux-kernel, sboyd, Andy Gross, Bjorn Andersson,
Rob Herring, devicetree
Cc: collinsd, subbaram, quic_fenglinw, tglx, maz
In-Reply-To: <1643178713-17178-1-git-send-email-quic_fenglinw@quicinc.com>
From: David Collins <collinsd@codeaurora.org>
Mark all interrupt related properties as optional instead of
required. Some boards do not required PMIC IRQ support and it
isn't needed to handle SPMI bus transactions, so specify it as
optional.
Signed-off-by: David Collins <collinsd@codeaurora.org>
Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
---
Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
index ca645e2..6332507 100644
--- a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
+++ b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
@@ -29,6 +29,8 @@ Required properties:
- #size-cells : must be set to 0
- qcom,ee : indicates the active Execution Environment identifier (0-5)
- qcom,channel : which of the PMIC Arb provided channels to use for accesses (0-5)
+
+Optional properties:
- interrupts : interrupt list for the PMIC Arb controller, must contain a
single interrupt entry for the peripheral interrupt
- interrupt-names : corresponding interrupt names for the interrupts
--
2.7.4
^ permalink raw reply related
* [PATCH V1 Create empty OF root 1/1] of: create empty of root
From: Lizhi Hou @ 2022-01-26 5:48 UTC (permalink / raw)
To: devicetree, robh
Cc: Lizhi Hou, linux-kernel, yilun.xu, maxz, sonal.santan, yliu,
michal.simek, stefanos, trix, mdf, dwmw2, Max Zhen
In-Reply-To: <20220126054807.492651-1-lizhi.hou@xilinx.com>
Add OF_EMPTY_ROOT config. When it is selected and there is not a device
tree, create an empty device tree root node.
Signed-off-by: Sonal Santan <sonal.santan@xilinx.com>
Signed-off-by: Max Zhen <max.zhen@xilinx.com>
Signed-off-by: Lizhi Hou <lizhi.hou@xilinx.com>
---
drivers/of/Kconfig | 3 +++
drivers/of/Makefile | 1 +
drivers/of/of_empty_root.c | 51 ++++++++++++++++++++++++++++++++++++++
3 files changed, 55 insertions(+)
create mode 100644 drivers/of/of_empty_root.c
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 80b5fd44ab1c..42afb126f91a 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -94,4 +94,7 @@ config OF_DMA_DEFAULT_COHERENT
# arches should select this if DMA is coherent by default for OF devices
bool
+config OF_EMPTY_ROOT
+ bool
+
endif # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index e0360a44306e..c65364f32935 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
obj-$(CONFIG_OF_RESOLVE) += resolver.o
obj-$(CONFIG_OF_OVERLAY) += overlay.o
obj-$(CONFIG_OF_NUMA) += of_numa.o
+obj-$(CONFIG_OF_EMPTY_ROOT) += of_empty_root.o
ifdef CONFIG_KEXEC_FILE
ifdef CONFIG_OF_FLATTREE
diff --git a/drivers/of/of_empty_root.c b/drivers/of/of_empty_root.c
new file mode 100644
index 000000000000..5c429c7a27bd
--- /dev/null
+++ b/drivers/of/of_empty_root.c
@@ -0,0 +1,51 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Xilinx, Inc.
+ */
+
+#include <linux/of.h>
+#include <linux/slab.h>
+
+#include "of_private.h"
+
+static int __init of_root_init(void)
+{
+ struct property *prop = NULL;
+ struct device_node *node;
+ __be32 *val = NULL;
+
+ if (of_root)
+ return 0;
+
+ pr_info("Create empty OF root node\n");
+ node = kzalloc(sizeof(*node), GFP_KERNEL);
+ if (!node)
+ return -ENOMEM;
+ of_node_init(node);
+ node->full_name = "/";
+
+ prop = kcalloc(2, sizeof(*prop), GFP_KERNEL);
+ if (!prop)
+ return -ENOMEM;
+
+ val = kzalloc(sizeof(*val), GFP_KERNEL);
+ if (!val)
+ return -ENOMEM;
+ *val = cpu_to_be32(sizeof(void *) / sizeof(u32));
+
+ prop->name = "#address-cells";
+ prop->value = val;
+ prop->length = sizeof(u32);
+ of_add_property(node, prop);
+ prop++;
+ prop->name = "#size-cells";
+ prop->value = val;
+ prop->length = sizeof(u32);
+ of_add_property(node, prop);
+ of_root = node;
+ for_each_of_allnodes(node)
+ __of_attach_node_sysfs(node);
+
+ return 0;
+}
+pure_initcall(of_root_init);
--
2.27.0
^ permalink raw reply related
* [PATCH V1 Create empty OF root 0/1] XRT Alveo driver infrastructure overview
From: Lizhi Hou @ 2022-01-26 5:48 UTC (permalink / raw)
To: devicetree, robh
Cc: Lizhi Hou, linux-kernel, yilun.xu, maxz, sonal.santan, yliu,
michal.simek, stefanos, trix, mdf, dwmw2
Hello,
Xilinx Alveo PCIe accelerator cards use flattened device tree to describe
HW subsystems or endpoints. Each device tree node represents a hardware
endpoint and each endpoint is an hardware unit which requires a driver.
The product detail:
https://www.xilinx.com/products/boards-and-kits/alveo.html
The feedback from the previous patches was to create a base tree if there
is not one and apply the unflattened device nodes by existing Linux
platform device and OF infrastructure. Please refer to previous discussion
with device tree and fpga maintainers.
https://lore.kernel.org/lkml/CAL_JsqJfyRymB=VxLuQqLpep+Q1Eie48dobv9sC5OizDz0d2DQ@mail.gmail.com/
https://lore.kernel.org/lkml/20220105225013.1567871-1-lizhi.hou@xilinx.com/
This patch adds OF_EMPTY_ROOT config. When it is selected and there is not
a device tree, create an empty device tree root node.
Lizhi Hou (1):
of: create empty of root
drivers/of/Kconfig | 3 +++
drivers/of/Makefile | 1 +
drivers/of/of_empty_root.c | 51 ++++++++++++++++++++++++++++++++++++++
3 files changed, 55 insertions(+)
create mode 100644 drivers/of/of_empty_root.c
--
2.27.0
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: meson-gx: add ATF BL32 reserved-memory region
From: Vyacheslav @ 2022-01-26 5:35 UTC (permalink / raw)
To: Christian Hewitt, Rob Herring, Mark Rutland, Kevin Hilman,
Neil Armstrong, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20220126044954.19069-2-christianshewitt@gmail.com>
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;
>
^ permalink raw reply
* [PATCH 2/3] arm64: dts: meson-g12: add ATF BL32 reserved-memory region
From: Christian Hewitt @ 2022-01-26 4:49 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, Neil Armstrong,
devicetree, linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Christian Hewitt
In-Reply-To: <20220126044954.19069-1-christianshewitt@gmail.com>
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;
--
2.17.1
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: meson-g12: drop BL32 region from SEI510/SEI610
From: Christian Hewitt @ 2022-01-26 4:49 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, Neil Armstrong,
devicetree, linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Christian Hewitt
In-Reply-To: <20220126044954.19069-1-christianshewitt@gmail.com>
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>;
--
2.17.1
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: meson-gx: add ATF BL32 reserved-memory region
From: Christian Hewitt @ 2022-01-26 4:49 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, Neil Armstrong,
devicetree, linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Christian Hewitt
In-Reply-To: <20220126044954.19069-1-christianshewitt@gmail.com>
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;
--
2.17.1
^ permalink raw reply related
* [PATCH 0/3] arm64: dts: meson: add ATF BL32 reserved-memory regions
From: Christian Hewitt @ 2022-01-26 4:49 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, Neil Armstrong,
devicetree, linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Christian Hewitt
This series supersedes [0] which fixed a long-running kernel panic issue
seen with Beelink G12B devices booted from Amlogic vendor firmware. The
same issue exists with a wider set of devices from GXBB to SM1, although
it is not often seen due to my kernel fork including 'catch-all' patches
for some time (the meson-gx patch was suggested by Matheusz in 2019) and
many distros actively supporting Amlogic hardware consuming some or all
of my regular patchset.
I've also included a cleanup to the SEI510/SEI610 board files. If that's
not desirable feel free to ignore that patch. I also dropped the fixes
tagging as I'm not sure what original commits could be targetted. If you
think fixes are good please provide some guidance and I'll be happy to
send a revised series.
[0] https://patchwork.kernel.org/project/linux-amlogic/list/?series=607446
Christian Hewitt (3):
arm64: dts: meson-gx: add ATF BL32 reserved-memory region
arm64: dts: meson-g12: add ATF BL32 reserved-memory region
arm64: dts: meson-g12: drop BL32 region from SEI510/SEI610
arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 6 ++++++
arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts | 8 --------
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 6 ++++++
arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts | 8 --------
4 files changed, 12 insertions(+), 16 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH V4 3/6] soc: qcom: eud: Add driver support for Embedded USB Debugger(EUD)
From: Bjorn Andersson @ 2022-01-26 4:47 UTC (permalink / raw)
To: Souradeep Chowdhury
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: <7ccee5ae484e6917f5838c8abde368680ec63d05.1642768837.git.quic_schowdhu@quicinc.com>
On Fri 21 Jan 07:53 CST 2022, Souradeep Chowdhury wrote:
> Add support for control peripheral of EUD (Embedded USB Debugger) to
> listen to events such as USB attach/detach, pet EUD to indicate software
> is functional.Reusing the platform device kobj, sysfs entry 'enable' is
> created to enable or disable EUD.
>
> To enable the eud the following needs to be done
> echo 1 > /sys/bus/platform/.../enable
>
> To disable eud, following is the command
> echo 0 > /sys/bus/platform/.../enable
>
> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
> ---
> Documentation/ABI/testing/sysfs-driver-eud | 9 ++
> drivers/soc/qcom/Kconfig | 10 ++
> drivers/soc/qcom/Makefile | 1 +
> drivers/soc/qcom/qcom_eud.c | 250 +++++++++++++++++++++++++++++
> 4 files changed, 270 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-driver-eud
> create mode 100644 drivers/soc/qcom/qcom_eud.c
>
> diff --git a/Documentation/ABI/testing/sysfs-driver-eud b/Documentation/ABI/testing/sysfs-driver-eud
> new file mode 100644
> index 0000000..2381552
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-driver-eud
> @@ -0,0 +1,9 @@
> +What: /sys/bus/platform/drivers/eud/.../enable
> +Date: January 2022
> +Contact: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
> +Description:
> + The Enable/Disable sysfs interface for Embedded
> + USB Debugger(EUD). This enables and disables the
> + EUD based on a 1 or a 0 value. By enabling EUD,
> + the user is able to activate the mini-usb hub of
> + EUD for debug and trace capabilities.
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index e718b87..abc6be0 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -42,6 +42,16 @@ config QCOM_CPR
> To compile this driver as a module, choose M here: the module will
> be called qcom-cpr
>
> +config QCOM_EUD
> + tristate "QCOM Embedded USB Debugger(EUD) Driver"
The indentation looks off here.
> + select USB_ROLE_SWITCH
> + help
> + This module enables support for Qualcomm Technologies, Inc.
> + Embedded USB Debugger (EUD). The EUD is a control peripheral
> + which reports VBUS attach/detach events and has USB-based
> + debug and trace capabilities. On selecting m, the module name
> + that is built is qcom_eud.ko
> +
> config QCOM_GENI_SE
> tristate "QCOM GENI Serial Engine Driver"
> depends on ARCH_QCOM || COMPILE_TEST
> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
> index 70d5de6..e0c7d2d 100644
> --- a/drivers/soc/qcom/Makefile
> +++ b/drivers/soc/qcom/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_QCOM_AOSS_QMP) += qcom_aoss.o
> obj-$(CONFIG_QCOM_GENI_SE) += qcom-geni-se.o
> obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
> obj-$(CONFIG_QCOM_CPR) += cpr.o
> +obj-$(CONFIG_QCOM_EUD) += qcom_eud.o
> obj-$(CONFIG_QCOM_GSBI) += qcom_gsbi.o
> obj-$(CONFIG_QCOM_MDT_LOADER) += mdt_loader.o
> obj-$(CONFIG_QCOM_OCMEM) += ocmem.o
> diff --git a/drivers/soc/qcom/qcom_eud.c b/drivers/soc/qcom/qcom_eud.c
> new file mode 100644
> index 0000000..a538645
> --- /dev/null
> +++ b/drivers/soc/qcom/qcom_eud.c
> @@ -0,0 +1,250 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2015-2021, The Linux Foundation. All rights reserved.
> + */
> +
> +#include <linux/bitops.h>
> +#include <linux/err.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/sysfs.h>
> +#include <linux/usb/role.h>
> +
> +#define EUD_REG_INT1_EN_MASK 0x0024
> +#define EUD_REG_INT_STATUS_1 0x0044
> +#define EUD_REG_CTL_OUT_1 0x0074
> +#define EUD_REG_VBUS_INT_CLR 0x0080
> +#define EUD_REG_CSR_EUD_EN 0x1014
> +#define EUD_REG_SW_ATTACH_DET 0x1018
> +#define EUD_REG_EUD_EN2 0x0000
> +
> +#define EUD_ENABLE BIT(0)
> +#define EUD_INT_PET_EUD BIT(0)
> +#define EUD_INT_VBUS BIT(2)
> +#define EUD_INT_SAFE_MODE BIT(4)
> +#define EUD_INT_ALL (EUD_INT_VBUS|EUD_INT_SAFE_MODE)
> +
> +struct eud_chip {
> + struct device *dev;
> + struct usb_role_switch *role_sw;
> + void __iomem *base;
> + void __iomem *mode_mgr;
> + unsigned int int_status;
> + int irq;
> + bool enabled;
> + bool usb_attached;
> +};
> +
> +static int enable_eud(struct eud_chip *priv)
> +{
> + writel(EUD_ENABLE, priv->base + EUD_REG_CSR_EUD_EN);
> + writel(EUD_INT_VBUS | EUD_INT_SAFE_MODE,
> + priv->base + EUD_REG_INT1_EN_MASK);
> + writel(1, priv->mode_mgr + EUD_REG_EUD_EN2);
> +
> + return usb_role_switch_set_role(priv->role_sw, USB_ROLE_DEVICE);
So we won't get EUD_INT_VBUS when we enable the EUD and can rely on the
irq handler to set the role?
> +}
> +
> +static void disable_eud(struct eud_chip *priv)
> +{
> + writel(0, priv->base + EUD_REG_CSR_EUD_EN);
> + writel(0, priv->mode_mgr + EUD_REG_EUD_EN2);
> +}
> +
> +static ssize_t enable_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct eud_chip *chip = dev_get_drvdata(dev);
> +
> + return sysfs_emit(buf, "%d\n", chip->enabled);
> +}
> +
> +static ssize_t enable_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct eud_chip *chip = dev_get_drvdata(dev);
> + bool enable;
> + int ret;
> +
> + if (kstrtobool(buf, &enable))
> + return -EINVAL;
> +
> + if (enable) {
> + ret = enable_eud(chip);
> + if (!ret)
> + chip->enabled = enable;
> + else
> + disable_eud(chip);
> + } else {
> + disable_eud(chip);
> + }
> +
> + return count;
> +}
> +
> +static DEVICE_ATTR_RW(enable);
> +
> +static struct attribute *eud_attrs[] = {
> + &dev_attr_enable.attr,
> + NULL,
> +};
> +ATTRIBUTE_GROUPS(eud);
> +
> +static void usb_attach_detach(struct eud_chip *chip)
> +{
> + u32 reg;
> +
> + /* read ctl_out_1[4] to find USB attach or detach event */
> + reg = readl(chip->base + EUD_REG_CTL_OUT_1);
> + chip->usb_attached = reg & EUD_INT_SAFE_MODE;
> +}
> +
> +static void pet_eud(struct eud_chip *chip)
> +{
> + u32 reg;
> + int ret;
> +
> + /* When the EUD_INT_PET_EUD in SW_ATTACH_DET is set, the cable has been
> + * disconnected and we need to detach the pet to check if EUD is in safe
> + * mode before attaching again.
> + */
> + reg = readl(chip->base + EUD_REG_SW_ATTACH_DET);
> + if (reg & EUD_INT_PET_EUD) {
> + /* Detach & Attach pet for EUD */
> + writel(0, chip->base + EUD_REG_SW_ATTACH_DET);
> + /* Delay to make sure detach pet is done before attach pet */
> + ret = readl_poll_timeout(chip->base + EUD_REG_SW_ATTACH_DET,
> + reg, (reg == 0), 1, 100);
> + if (ret) {
> + dev_err(chip->dev, "Detach pet failed\n");
> + return;
> + }
> + }
> + /* Attach pet for EUD */
> + writel(EUD_INT_PET_EUD, chip->base +EUD_REG_SW_ATTACH_DET);
> +}
> +
> +static irqreturn_t handle_eud_irq(int irq, void *data)
> +{
> + struct eud_chip *chip = data;
> + u32 reg;
> +
> + reg = readl(chip->base + EUD_REG_INT_STATUS_1);
> + switch (reg & EUD_INT_ALL) {
> + case EUD_INT_VBUS:
> + chip->int_status = EUD_INT_VBUS;
The first time that reg & EUD_INT_VBUS is set, you assign int_status
EUD_INT_VBUS, you never clear it again.
This is also the only path where you wake up the thread, so int_status
will always be EUD_INT_VBUS when you reach handle_eud_irq_thread().
Which means that int_status serves no purpose and if you're happy with
how this implementation currently works you can just drop "int_status"
and the conditional below.
> + usb_attach_detach(chip);
> + return IRQ_WAKE_THREAD;
> + case EUD_INT_SAFE_MODE:
> + pet_eud(chip);
> + return IRQ_HANDLED;
> + default:
> + return IRQ_NONE;
> + }
> +}
> +
> +static irqreturn_t handle_eud_irq_thread(int irq, void *data)
> +{
> + struct eud_chip *chip = data;
> + int ret;
> +
> + if (chip->int_status == EUD_INT_VBUS) {
> + if (chip->usb_attached)
> + ret = usb_role_switch_set_role(chip->role_sw, USB_ROLE_DEVICE);
> + else
> + ret = usb_role_switch_set_role(chip->role_sw, USB_ROLE_HOST);
> + if (ret)
> + dev_err(chip->dev, "failed to set role switch\n");
> + }
> +
> + /* set and clear vbus_int_clr[0] to clear interrupt */
> + writel(BIT(0), chip->base + EUD_REG_VBUS_INT_CLR);
> + writel(0, chip->base + EUD_REG_VBUS_INT_CLR);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int eud_probe(struct platform_device *pdev)
> +{
> + struct eud_chip *chip;
> + struct fwnode_handle *fwnode = pdev->dev.fwnode, *dwc3;
> + int ret;
> +
> + chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
> + if (!chip)
> + return -ENOMEM;
> +
> + chip->dev = &pdev->dev;
> +
> + dwc3 = fwnode_graph_get_next_endpoint(fwnode, NULL);
This will pick the first endpoint, but if you instead use
chip->role_sw = usb_role_switch_get(&pdev->dev);
you should get whichever port that points to a usb-role-switch node,
without having to do the fwnode dance (and refcounting, which you forgot
to release).
> + if (!dwc3)
> + return -ENODEV;
> +
> + chip->role_sw = fwnode_usb_role_switch_get(dwc3);
> + if (IS_ERR(chip->role_sw)) {
> + ret = PTR_ERR(chip->role_sw);
> + usb_role_switch_put(chip->role_sw);
You don't need to return the role_sw if it's IS_ERR().
> + return dev_err_probe(chip->dev, ret,
> + "failed to get role switch\n");
> + }
> +
> + chip->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(chip->base))
You're not usb_role_switch_put() your role_sw here, or below return
cases. I would recommend devm_add_action_or_reset() to avoid the hassle
of adding the necessary cleanup logic.
> + return PTR_ERR(chip->base);
> +
> + chip->mode_mgr = devm_platform_ioremap_resource(pdev, 1);
> + if (IS_ERR(chip->mode_mgr))
> + return PTR_ERR(chip->mode_mgr);
> +
> + chip->irq = platform_get_irq(pdev, 0);
> + ret = devm_request_threaded_irq(&pdev->dev, chip->irq, handle_eud_irq,
> + handle_eud_irq_thread, IRQF_ONESHOT, NULL, chip);
> + if (ret)
> + return dev_err_probe(chip->dev, ret, "failed to allocate irq\n");
> +
> + enable_irq_wake(chip->irq);
> +
> + platform_set_drvdata(pdev, chip);
> +
> + return 0;
Per the updated binding, the EUD would now be a usb-role-switch as well
and when not enabled should simply propagate the incoming requests. So I
was expecting this to register as a usb_role_switch as well...
> +}
> +
> +static int eud_remove(struct platform_device *pdev)
> +{
> + struct eud_chip *chip = platform_get_drvdata(pdev);
> +
> + if (chip->enabled)
> + disable_eud(chip);
> +
> + device_init_wakeup(&pdev->dev, false);
> + disable_irq_wake(chip->irq);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id eud_dt_match[] = {
> + { .compatible = "qcom,sc7280-eud" },
Do you see any reason for not just adding qcom,eud here? Are there any
differences from other platforms that has this block that means that we
need per-platform driver support (the dts should have both
compatibles still)?
Regards,
Bjorn
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, eud_dt_match);
> +
> +static struct platform_driver eud_driver = {
> + .probe = eud_probe,
> + .remove = eud_remove,
> + .driver = {
> + .name = "qcom_eud",
> + .dev_groups = eud_groups,
> + .of_match_table = eud_dt_match,
> + },
> +};
> +module_platform_driver(eud_driver);
> +
> +MODULE_DESCRIPTION("QTI EUD driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH V4 6/6] MAINTAINERS: Add maintainer entry for EUD
From: Bjorn Andersson @ 2022-01-26 4:29 UTC (permalink / raw)
To: Souradeep Chowdhury
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: <d8079cb1001675cd876f1e051647a65a7733b81c.1642768837.git.quic_schowdhu@quicinc.com>
On Fri 21 Jan 07:53 CST 2022, Souradeep Chowdhury wrote:
> Add the entry for maintainer for EUD driver
> and other associated files.
>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
> ---
> MAINTAINERS | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b84e2d5..0fa9d54 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7227,6 +7227,14 @@ F: include/uapi/linux/mdio.h
> F: include/uapi/linux/mii.h
> F: net/core/of_net.c
>
> +QCOM EMBEDDED USB DEBUGGER(EUD)
> +M: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
> +L: linux-arm-msm@vger.kernel.org
> +S: Maintained
> +F: Documentation/ABI/testing/sysfs-driver-eud
> +F: Documentation/devicetree/bindings/arm/msm/qcom,eud.yaml
> +F: drivers/usb/common/qcom_eud.c
> +
> EXEC & BINFMT API
> R: Eric Biederman <ebiederm@xmission.com>
> R: Kees Cook <keescook@chromium.org>
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH V4 5/6] arm64: dts: qcom: sc7280: Set the default dr_mode for usb2
From: Bjorn Andersson @ 2022-01-26 4:29 UTC (permalink / raw)
To: Souradeep Chowdhury
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: <232f37a6f76c3f24a122f32978b5c1e73dc7e7c4.1642768837.git.quic_schowdhu@quicinc.com>
On Fri 21 Jan 07:53 CST 2022, Souradeep Chowdhury wrote:
> Set the default dr_mode for usb2 node to "otg" to enable
> role-switch for EUD(Embedded USB Debugger) connector node.
>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
> ---
> arch/arm64/boot/dts/qcom/sc7280-idp.dts | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7280-idp.dts b/arch/arm64/boot/dts/qcom/sc7280-idp.dts
> index 9b991ba..f40eaa5 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280-idp.dts
> +++ b/arch/arm64/boot/dts/qcom/sc7280-idp.dts
> @@ -61,6 +61,10 @@
> modem-init;
> };
>
> +&usb_2_dwc3 {
> + dr_mode = "otg";
> +};
> +
> &pmk8350_rtc {
> status = "okay";
> };
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH V4 4/6] arm64: dts: qcom: sc7280: Add EUD dt node and dwc3 connector
From: Bjorn Andersson @ 2022-01-26 4:28 UTC (permalink / raw)
To: Souradeep Chowdhury
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: <3ca56ffa9e4aa73f3c3f36d0edad0827ee11d953.1642768837.git.quic_schowdhu@quicinc.com>
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.
> + 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!
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 1/6] dt-bindings: Add the yaml bindings for EUD
From: Bjorn Andersson @ 2022-01-26 4:22 UTC (permalink / raw)
To: Souradeep Chowdhury
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: <91c61d815123fb0b7e067e368d784e3434997068.1642768837.git.quic_schowdhu@quicinc.com>
On Fri 21 Jan 07:53 CST 2022, Souradeep Chowdhury wrote:
> Documentation for Embedded USB Debugger(EUD) device tree
> bindings in yaml format.
>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
> ---
> .../devicetree/bindings/soc/qcom/qcom,eud.yaml | 77 ++++++++++++++++++++++
> 1 file changed, 77 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml
>
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml
> new file mode 100644
> index 0000000..c98aab2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml
> @@ -0,0 +1,77 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/soc/qcom/qcom,eud.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Qualcomm Embedded USB Debugger
> +
> +maintainers:
> + - Souradeep Chowdhury <quic_schowdhu@quicinc.com>
> +
> +description:
> + This binding is used to describe the Qualcomm Embedded USB Debugger, which is
> + mini USB-hub implemented on chip to support USB-based debug capabilities.
> +
> +properties:
> + compatible:
> + items:
> + - enum:
> + - qcom,sc7280-eud
> + - const: qcom,eud
> +
> + reg:
> + items:
> + - description: EUD Base Register Region
> + - description: EUD Mode Manager Register
> +
> + interrupts:
> + description: EUD interrupt
> + maxItems: 1
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> + description:
> + These ports are to be attached to the endpoint of the DWC3 controller node
> + and type C connector node. The controller has the "usb-role-switch"
> + property.
> +
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: This port is to be attached to the DWC3 controller.
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: This port is to be attached to the type C connector.
> +
> +required:
> + - compatible
> + - reg
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + eud@88e0000 {
> + compatible = "qcom,sc7280-eud","qcom,eud";
> + reg = <0x88e0000 0x2000>,
> + <0x88e2000 0x1000>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + eud_ep: endpoint {
> + remote-endpoint = <&usb2_role_switch>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + eud_con: endpoint {
> + remote-endpoint = <&con_eud>;
> + };
> + };
> + };
> + };
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH V4 2/6] bindings: usb: dwc3: Update dwc3 properties for EUD connector
From: Bjorn Andersson @ 2022-01-26 4:21 UTC (permalink / raw)
To: Souradeep Chowdhury
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: <7ddaf7dc192c5f03f70d27297551e758a39a4ab5.1642768837.git.quic_schowdhu@quicinc.com>
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...
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
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