* Re: [PATCH net-next v2 3/5] net: stmmac: dwmac-socfpga: use pcs_init/pcs_exit
From: Jakub Kicinski @ 2024-04-10 1:34 UTC (permalink / raw)
To: Romain Gantois
Cc: David S. Miller, Eric Dumazet, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Alexandre Torgue, Jose Abreu, Maxime Coquelin,
Russell King, Clément Léger, Thomas Petazzoni, netdev,
devicetree, linux-kernel, linux-renesas-soc, linux-stm32,
linux-arm-kernel, Russell King (Oracle), Maxime Chevallier
In-Reply-To: <20240409-rzn1-gmac1-v2-3-79ca45f2fc79@bootlin.com>
On Tue, 09 Apr 2024 11:21:46 +0200 Romain Gantois wrote:
> + struct regmap_config pcs_regmap_cfg = {
> + .reg_bits = 16,
> + .val_bits = 16,
> + .reg_shift = regmap_upshift(1),
This appears to displease the compiler:
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:389:16: error: call to undeclared function 'regmap_upshift'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
389 | .reg_shift = regmap_upshift(1),
| ^
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCHv3 1/2] dt-bindings: usb: typec: anx7688: start a binding document
From: Ondřej Jirman @ 2024-04-10 2:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Pavel Machek, phone-devel, kernel list, fiona.klute, martijn,
samuel, heikki.krogerus, gregkh, linux-usb, robh+dt,
krzysztof.kozlowski+dt, devicetree
In-Reply-To: <97f2d38d-c863-4c76-91f1-52cd250759d7@linaro.org>
On Mon, Apr 08, 2024 at 10:12:30PM GMT, Krzysztof Kozlowski wrote:
> On 08/04/2024 17:17, Ondřej Jirman wrote:
> >
> > Now for things to not fail during suspend/resume based on PM callbacks
> > invocation order, anx7688 driver needs to enable this regulator too, as long
> > as it needs it.
>
> No, the I2C bus driver needs to manage it. Not one individual I2C
> device. Again, why anx7688 is specific? If you next phone has anx8867,
> using different driver, you also add there i2c-supply? And if it is
> nxp,ptn5100 as well?
Yes, that could work, if I2C core would manage this.
> >
> > I can put bus-supply to I2C controller node, and read it from the ANX7688 driver
> > I guess, by going up a DT node. Whether that's going to be acceptable, I don't
> > know.
> >
> >
> > VCONN regulator I don't know where else to put either. It doesn't seem to belong
> > anywhere. It's not something directly connected to Type-C connector, so
> > not part of connector bindings, and there's nothing else I can see, other
> > than anx7688 device which needs it for core functionality.
>
> That sounds like a GPIO, not regulator. anx7688 has GPIOs, right? On
> Pinephone they go to regulator, but on FooPhone also using anx7688 they
> go somewhere else, so why this anx7688 assumes this is a regulator?
CC1/CC2_VCONN control pins are "GPIO" of anx7688, sort of. They have fixed
purpose of switching external 5V regulator output to one of the CC pins
on type-c port. I don't care what other purpose with some other firmware
someone puts to those pins. It's irrelevant to the use case of anx7688
as a type-c controller/HDMI bridge, which we're describing here.
VCONN regulator is an actual GPIO controlled regulator on the board, and
needs to be controlled by the anx7688 driver. So that CC1/CC2_VCONN control
pins driven by the firmware actually do what they're supposed to do.
Not sure why it would be a business of anything else but anx7688 driver
enabling this regulator, because only this driver knows and cares about this.
If some other board doesn't have the need to manually enable the regulator, or
doesn't have the regulator, it can simply be optional.
There are also some other funky supplies in the bindings, that are not connected
to the chip in any way, but need to be controlled by the driver:
+ vbus-supply: true
+ vbus-in-supply: true
First one can be on the connector node instead, where the driver can fetch
it from.
The purpose of the second one is to link the Phone's PMIC's USB power input with
the type-c controller (anx7688), to make sure the PMIC has information about how
much power it can draw from external PSU.
The second one can be replaced by rewriting the anx7688 driver so that it
creates a power supply representing the USB PSU connected to the phone, and by
linking to anx7688 DT node from x-powers,axp813-usb-power-supply via
a power-supplies property, which would mean that USB input of the phone is
supplied by the external USB PSU. PMIC driver can be modified to watch
the power supply provided by anx7688 driver for information it detected
via USB-PD and update its input current limit via a standard helper function.
This is how eg. fusb302 works. Not sure if that's any better from the PoV of
DT bindings, though. Because power-supplies = <&anx7688>; will not look any
greater in DT bindings, IMO. It will just link the same nodes in the other
direction.
Anyway, the HW is that there's an external PSU (detected by type c controller)
and internal USB power input, and they are connected and one has to respect the
limits of the other. I guess I shouldn't be adding a device node for external PSU,
since it's not part of the phone. But that's what's trully being linked on
HW level.
Kind regards,
o.
>
> >
> > ANX7688 chip desing doesn't have integrated VCONN mosfet switches so it always
> > needs external supply + switches that are controlled by the chip itself. There's
> > no sensible design where someone would not want this and the driver needs
> > to get this regulator reference from somewhere. The switches are sort of an
> > extension of the chip.
>
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [RFC PATCH v2 1/5] clk: meson: axg: move reset controller's code to separate module
From: Stephen Boyd @ 2024-04-10 2:27 UTC (permalink / raw)
To: Conor Dooley
Cc: Jan Dakinevich, Jerome Brunet, Philipp Zabel, Neil Armstrong,
Michael Turquette, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kevin Hilman, Martin Blumenstingl, linux-amlogic, linux-clk,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20240409-shallow-voice-c84ed791bc7d@spud>
Quoting Conor Dooley (2024-04-09 05:05:37)
> On Mon, Apr 08, 2024 at 06:05:51PM +0100, Conor Dooley wrote:
>
> > > > Seconded, the clk-mpfs/reset-mpfs and clk-starfive-jh7110-sys/reset-
> > > > starfive-jh7110 drivers are examples of this.
> > > >
> > > > > The auxiliary device creation function can also be in the
> > > > > drivers/reset/ directory so that the clk driver calls some function
> > > > > to create and register the device.
> > > >
> > > > I'm undecided about this, do you think mpfs_reset_controller_register()
> > > > and jh7110_reset_controller_register() should rather live with the
> > > > reset aux drivers in drivers/reset/ ?
> > >
> > > Yes, and also mpfs_reset_read() and friends. We should pass the base
> > > iomem pointer and parent device to mpfs_reset_adev_alloc() instead and
> > > then move all that code into drivers/reset with some header file
> > > exported function to call. That way the clk driver hands over the data
> > > without having to implement half the implementation.
> >
> > I'll todo list that :)
>
> Something like the below?
>
> -- >8 --
> From a12f281d2cb869bcd9a6ffc45d0c6a0d3aa2e9e2 Mon Sep 17 00:00:00 2001
> From: Conor Dooley <conor.dooley@microchip.com>
> Date: Tue, 9 Apr 2024 11:54:34 +0100
> Subject: [PATCH] clock, reset: microchip: move all mpfs reset code to the
> reset subsystem
>
> <insert something here>
>
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Looks pretty good.
> static const struct of_device_id mpfs_clk_of_match_table[] = {
> diff --git a/drivers/reset/reset-mpfs.c b/drivers/reset/reset-mpfs.c
> index 7f3fb2d472f4..27cd68b4ee81 100644
> --- a/drivers/reset/reset-mpfs.c
> +++ b/drivers/reset/reset-mpfs.c
> @@ -137,9 +139,67 @@ static int mpfs_reset_probe(struct auxiliary_device *adev,
> return devm_reset_controller_register(dev, rcdev);
> }
>
> +static void mpfs_reset_unregister_adev(void *_adev)
> +{
> + struct auxiliary_device *adev = _adev;
> +
> + auxiliary_device_delete(adev);
> + auxiliary_device_uninit(adev);
> +}
> +
> +static void mpfs_reset_adev_release(struct device *dev)
> +{
> + struct auxiliary_device *adev = to_auxiliary_dev(dev);
> +
> + kfree(adev);
> +}
> +
> +static struct auxiliary_device *mpfs_reset_adev_alloc(struct device *clk_dev)
> +{
> + struct auxiliary_device *adev;
> + int ret;
> +
> + adev = kzalloc(sizeof(*adev), GFP_KERNEL);
> + if (!adev)
> + return ERR_PTR(-ENOMEM);
> +
> + adev->name = "reset-mpfs";
> + adev->dev.parent = clk_dev;
> + adev->dev.release = mpfs_reset_adev_release;
> + adev->id = 666u;
> +
> + ret = auxiliary_device_init(adev);
> + if (ret) {
> + kfree(adev);
> + return ERR_PTR(ret);
> + }
> +
> + return adev;
> +}
> +
> +int mpfs_reset_controller_register(struct device *clk_dev, void __iomem *base)
> +{
> + struct auxiliary_device *adev;
> + int ret;
> +
> + mpfs_reset_addr = base;
Instead of a global this can be stashed in adev->dev.platform_data and
grabbed in the driver probe?
> +
> + adev = mpfs_reset_adev_alloc(clk_dev);
> + if (IS_ERR(adev))
> + return PTR_ERR(adev);
> +
> + ret = auxiliary_device_add(adev);
> + if (ret) {
> + auxiliary_device_uninit(adev);
> + return ret;
> + }
> +
> + return devm_add_action_or_reset(clk_dev, mpfs_reset_unregister_adev, adev);
> +}
> +
> static const struct auxiliary_device_id mpfs_reset_ids[] = {
> {
> - .name = "clk_mpfs.reset-mpfs",
> + .name = "reset_mpfs.reset-mpfs",
> },
> { }
> };
> diff --git a/include/soc/microchip/mpfs.h b/include/soc/microchip/mpfs.h
> index 09722f83b0ca..0b756bf5e9bd 100644
> --- a/include/soc/microchip/mpfs.h
> +++ b/include/soc/microchip/mpfs.h
> @@ -43,11 +43,11 @@ struct mtd_info *mpfs_sys_controller_get_flash(struct mpfs_sys_controller *mpfs_
> #endif /* if IS_ENABLED(CONFIG_POLARFIRE_SOC_SYS_CTRL) */
>
> #if IS_ENABLED(CONFIG_MCHP_CLK_MPFS)
> -
> -u32 mpfs_reset_read(struct device *dev);
> -
> -void mpfs_reset_write(struct device *dev, u32 val);
> -
> +#if IS_ENABLED(CONFIG_RESET_CONTROLLER)
> +int mpfs_reset_controller_register(struct device *clk_dev, void __iomem *base);
> +#else
> +int mpfs_reset_controller_register(struct device *clk_dev, void* __iomem base) { return 0;}
static inline
^ permalink raw reply
* Re: [PATCH v7 2/3] dt-bindings: pinctrl: Document nuvoton ma35d1 pin control
From: Jacky Huang @ 2024-04-10 2:53 UTC (permalink / raw)
To: Rob Herring
Cc: linus.walleij, krzysztof.kozlowski+dt, conor+dt, p.zabel,
j.neuschaefer, linux-arm-kernel, linux-gpio, devicetree,
linux-kernel, ychuang3, schung, Krzysztof Kozlowski
In-Reply-To: <20240409162959.GA1370985-robh@kernel.org>
Dear Rob,
Thanks for your review.
On 2024/4/10 上午 12:29, Rob Herring wrote:
> On Tue, Apr 09, 2024 at 09:56:36AM +0000, Jacky Huang wrote:
>> From: Jacky Huang <ychuang3@nuvoton.com>
>>
>> Add documentation to describe nuvoton ma35d1 pin control and GPIO.
>>
>> Signed-off-by: Jacky Huang <ychuang3@nuvoton.com>
>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>> ---
>> .../pinctrl/nuvoton,ma35d1-pinctrl.yaml | 163 ++++++++++++++++++
>> 1 file changed, 163 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pinctrl/nuvoton,ma35d1-pinctrl.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/pinctrl/nuvoton,ma35d1-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/nuvoton,ma35d1-pinctrl.yaml
>> new file mode 100644
>> index 000000000000..8b9ec263213f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pinctrl/nuvoton,ma35d1-pinctrl.yaml
>> @@ -0,0 +1,163 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/pinctrl/nuvoton,ma35d1-pinctrl.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Nuvoton MA35D1 pin control and GPIO
>> +
>> +maintainers:
>> + - Shan-Chun Hung <schung@nuvoton.com>
>> + - Jacky Huang <ychuang3@nuvoton.com>
>> +
>> +allOf:
>> + - $ref: pinctrl.yaml#
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - nuvoton,ma35d1-pinctrl
>> +
>> + '#address-cells':
>> + const: 1
>> +
>> + '#size-cells':
>> + const: 1
>> +
>> + nuvoton,sys:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + description:
>> + phandle of the system-management node.
> If these are the *only* registers to access the pinctrl functions, then
> this binding should be a child node of the system-management node and
> then you don't need this property.
>
> And if the registers for pinctrl are a defined range, you should add a
> 'reg' property (even though Linux and regmap don't use it).
I will add a 'reg' property for this.
>> +
>> + ranges: true
> This property makes no sense with the binding as-is. You don't have
> any address to translate. Maybe with the above changes it will.
I will fix the
ranges = <0 0x40040000 0xc00>;
as
reg = <0 0x40040000 0xc00>;
ranges;
>> +
>> +patternProperties:
>> + "^gpio@[0-9a-f]+$":
>> + type: object
>> + additionalProperties: false
>> + properties:
>> + gpio-controller: true
>> +
>> + '#gpio-cells':
>> + const: 2
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + clocks:
>> + maxItems: 1
>> +
>> + interrupt-controller: true
>> +
>> + '#interrupt-cells':
>> + const: 2
>> +
>> + interrupts:
>> + description:
>> + The interrupt outputs to sysirq.
>> + maxItems: 1
>> +
>> + required:
>> + - gpio-controller
>> + - '#gpio-cells'
>> + - reg
>> + - clocks
>> + - interrupt-controller
>> + - '#interrupt-cells'
>> + - interrupts
>> +
>> + "^pin-[a-z0-9]+$":
>> + type: object
>> + description:
>> + A pinctrl node should contain at least one subnodes representing the
>> + pinctrl groups available on the machine. Each subnode will list the
>> + pins it needs, and how they should be configured, with regard to muxer
>> + configuration, pullups, drive strength, input enable/disable and input
>> + schmitt.
>> +
>> + $ref: pincfg-node.yaml#
>> +
>> + properties:
>> + power-source:
>> + description: |
>> + Valid arguments are described as below:
>> + 0: power supply of 1.8V
>> + 1: power supply of 3.3V
>> + enum: [0, 1]
>> +
>> + drive-strength-microamp:
>> + oneOf:
>> + - enum: [ 2900, 4400, 5800, 7300, 8600, 10100, 11500, 13000 ]
>> + description: 1.8V I/O driving strength
>> + - enum: [ 17100, 25600, 34100, 42800, 48000, 56000, 77000, 82000 ]
>> + description: 3.3V I/O driving strength
>> +
>> + unevaluatedProperties: false
> In the indented cases, it's preferred to put this before 'properties'.
>
I will fix it.
>> +
>> + "-grp$":
>> + type: object
>> + description:
>> + Pinctrl node's client devices use subnodes for desired pin configuration.
>> + Client device subnodes use below standard properties.
> Missing $ref to common properties and 'unevaluatedProperties'.
I will fix it.
>> + properties:
>> + nuvoton,pins:
>> + description:
>> + Each entry consists of 4 parameters and represents the mux and config
>> + setting for one pin.
>> + $ref: /schemas/types.yaml#/definitions/uint32-matrix
>> + minItems: 1
>> + items:
>> + items:
>> + - minimum: 0
>> + maximum: 13
>> + description:
>> + Pin bank.
>> + - minimum: 0
>> + maximum: 15
>> + description:
>> + Pin bank index.
>> + - minimum: 0
>> + maximum: 15
>> + description:
>> + Mux 0 means GPIO and mux 1 to 15 means the specific device function.
>> +
>> +required:
>> + - compatible
>> + - nuvoton,sys
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>> + #include <dt-bindings/gpio/gpio.h>
>> + #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
>> +
>> + pinctrl@40040000 {
>> + compatible = "nuvoton,ma35d1-pinctrl";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + nuvoton,sys = <&sys>;
>> + ranges = <0 0x40040000 0xc00>;
>> +
>> + gpio@0 {
>> + reg = <0x0 0x40>;
>> + interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&clk GPA_GATE>;
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + interrupt-controller;
>> + #interrupt-cells = <2>;
>> + };
>> +
>> + uart-grp {
>> + uart11-pins {
> This is not what the schema says.
>> + nuvoton,pins = <11 0 2>,
>> + <11 1 2>,
>> + <11 2 2>,
>> + <11 3 2>;
>> + bias-disable;
>> + power-source = <1>;
>> + };
>> + };
> Include a pin-* node in the example.
This is my mistake. "pin-*" was the naming convention used in previous
versions, which
has now been changed to "-pins". Additionally, its hierarchy should be
under "-grp".
I will make corrections for these two issues.
>> + };
>> --
>> 2.34.1
>>
Best Regards,
Jacky Huang
^ permalink raw reply
* Re: [PATCH v2 0/4] HID: Add support for Himax HX83102j touchscreen
From: Allen Lin @ 2024-04-10 2:58 UTC (permalink / raw)
To: Jiri Kosina
Cc: dmitry.torokhov, robh, krzysztof.kozlowski+dt, conor,
benjamin.tissoires, linux-input, devicetree, linux-kernel
In-Reply-To: <nycvar.YFH.7.76.2404031347540.20263@cbobk.fhfr.pm>
Jiri Kosina <jikos@kernel.org> 於 2024年4月3日 週三 下午7:48寫道：
>
> On Tue, 2 Apr 2024, Allen_Lin wrote:
>
> > Hi,
> > This driver implements for Himax HID touchscreen HX83102j.
> >
> > Using SPI interface to receive/send HID packets.
> >
> > Changes in v2 :
> > -Added power description in YAML document.
> > -Added ddreset-gpios property in YAML document.
> > -Added firmware-name property in YAML document.
> > -Modified the description of pid.
> > -Modified the example.
> >
> > Allen_Lin (4):
> > dt-bindings: input: Add Himax HX83102J touchscreen
> > HID: Add Himax HX83102J touchscreen driver
> > HID: Add DRM panel follower function
> > HID: Load firmware directly from file to IC
> >
> > .../input/touchscreen/himax,hx83102j.yaml | 100 +
> > MAINTAINERS | 7 +
> > drivers/hid/Kconfig | 7 +
> > drivers/hid/Makefile | 2 +
> > drivers/hid/hid-himax-83102j.c | 3071 +++++++++++++++++
> > drivers/hid/hid-himax-83102j.h | 460 +++
>
> My only nit here -- could we please call the driver just hid-himax, to
> follow the pattern we generally use in this subsystem (drivers named after
> vendors).
>
83102j is our IC name, we add it to our driver name to distinguish
different ICs,
Can we just reserve this in driver name?
Thanks
Allen
> Please add Ack from Rob, rename the driver, resend, and I'll apply it.
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
>
^ permalink raw reply
* [PATCH v2 0/1] Add rtc PCF2131 support
From: Joy Zou @ 2024-04-10 3:32 UTC (permalink / raw)
To: ping.bai, robh+dt, krzysztof.kozlowski+dt, conor+dt, shawnguo,
s.hauer
Cc: kernel, festevam, linux-imx, devicetree, imx, linux-arm-kernel,
linux-kernel
The patchset supports RTC PCF2131 on board dts.
For the details, please check the patch commit log.
Joy Zou (1):
arm64: dts: imx93-11x11-evk: add rtc PCF2131 support
.../boot/dts/freescale/imx93-11x11-evk.dts | 24 +++++++++++++++++++
1 file changed, 24 insertions(+)
--
2.37.1
^ permalink raw reply
* [PATCH v2 1/1] arm64: dts: imx93-11x11-evk: add rtc PCF2131 support
From: Joy Zou @ 2024-04-10 3:32 UTC (permalink / raw)
To: ping.bai, robh+dt, krzysztof.kozlowski+dt, conor+dt, shawnguo,
s.hauer
Cc: kernel, festevam, linux-imx, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20240410033256.1341662-1-joy.zou@nxp.com>
Support rtc PCF2131 on imx93-11x11-evk.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
---
Changes in v2:
1. remove unnecessary status property.
---
.../boot/dts/freescale/imx93-11x11-evk.dts | 24 +++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
index 07e85a30a25f..e66723ed25c2 100644
--- a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
@@ -281,6 +281,23 @@ ldo5: LDO5 {
};
};
+&lpi2c3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <400000>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pinctrl_lpi2c3>;
+ pinctrl-1 = <&pinctrl_lpi2c3>;
+ status = "okay";
+
+ pcf2131: rtc@53 {
+ compatible = "nxp,pcf2131";
+ reg = <0x53>;
+ interrupt-parent = <&pcal6524>;
+ interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
+
&iomuxc {
pinctrl_eqos: eqosgrp {
fsl,pins = <
@@ -343,6 +360,13 @@ MX93_PAD_I2C2_SDA__LPI2C2_SDA 0x40000b9e
>;
};
+ pinctrl_lpi2c3: lpi2c3grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO28__LPI2C3_SDA 0x40000b9e
+ MX93_PAD_GPIO_IO29__LPI2C3_SCL 0x40000b9e
+ >;
+ };
+
pinctrl_pcal6524: pcal6524grp {
fsl,pins = <
MX93_PAD_CCM_CLKO2__GPIO3_IO27 0x31e
--
2.37.1
^ permalink raw reply related
* [PATCH v4 0/2] Add notifier for PLL0 clock and set it 1.5GHz on
From: Xingyu Wu @ 2024-04-10 3:31 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Conor Dooley,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski
Cc: Emil Renner Berthing, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Hal Feng, Xingyu Wu, linux-kernel, linux-clk, linux-riscv,
devicetree
This patch is to add the notifier for PLL0 clock and set the PLL0 rate
to 1.5GHz to fix the lower rate of CPUfreq on the JH7110 SoC.
The first patch is to add the notifier for PLL0 clock. Setting the PLL0
rate need the son clock (cpu_root) to switch its parent clock to OSC
clock and switch it back after setting PLL0 rate. It need to use the
cpu_root clock from SYSCRG and register the notifier in the SYSCRG
driver.
The second patch is to set cpu_core rate to 500MHz and PLL0 rate to
1.5GHz to fix the problem about the lower rate of CPUfreq on the
visionfive board. The cpu_core clock rate is set to 500MHz first to
ensure that the cpu frequency will not suddenly become high and the cpu
voltage is not enough to cause a crash when the PLL0 is set to 1.5GHz.
The cpu voltage and frequency are then adjusted together by CPUfreq.
Changes since v3:
- Added the notifier for PLL0 clock.
- Set cpu_core rate in DTS
v3: https://lore.kernel.org/all/20240402090920.11627-1-xingyu.wu@starfivetech.com/
Changes since v2:
- Made the steps into the process into the process of setting PLL0 rate
v2: https://lore.kernel.org/all/20230821152915.208366-1-xingyu.wu@starfivetech.com/
Changes since v1:
- Added the fixes tag in the commit.
v1: https://lore.kernel.org/all/20230811033631.160912-1-xingyu.wu@starfivetech.com/
Xingyu Wu (2):
clk: starfive: jh7110-sys: Add notifier for PLL clock
riscv: dts: starfive: visionfive-2: Fix lower rate of CPUfreq by
setting PLL0 rate to 1.5GHz
.../jh7110-starfive-visionfive-2.dtsi | 6 ++++
.../clk/starfive/clk-starfive-jh7110-sys.c | 31 ++++++++++++++++++-
drivers/clk/starfive/clk-starfive-jh71x0.h | 2 ++
3 files changed, 38 insertions(+), 1 deletion(-)
--
2.25.1
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: panel-simple-dsi: add New Khadas TS050 panel bindings
From: Christian Hewitt @ 2024-04-10 4:22 UTC (permalink / raw)
To: Jacobe Zang
Cc: Neil Armstrong, Neil Armstrong, David Airlie, Daniel Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, quic_jesszhan, sam, nick,
thierry.reding, dri-devel, devicetree, LKML, AML
In-Reply-To: <20240409082641.359627-1-jacobe.zang@wesion.com>
> On 9 Apr 2024, at 12:26 PM, Jacobe Zang <jacobe.zang@wesion.com> wrote:
>
> This add the bindings for the New Khadas TS050 1080x1920 5" LCD DSI panel
> designed to work with the Khadas VIM3 and VIM3L Single Board Computers.
>
> Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com>
> ---
> .../devicetree/bindings/display/panel/panel-simple-dsi.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
> index f9160d7bac3ca..e194309f31b72 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
> @@ -36,6 +36,8 @@ properties:
> - jdi,fhd-r63452
> # Khadas TS050 5" 1080x1920 LCD panel
> - khadas,ts050
> + # Khadas NEW TS050 5" 1080x1920 LCD panel
> + - khadas,newts050
Products are only new until they are old. At some future point there will
inevitably be a third iteration requiring a ‘new new’ name. IMHO it would
be better to use something like khadas,ts050v2.
CH.
> # Kingdisplay KD097D04 9.7" 1536x2048 TFT LCD panel
> - kingdisplay,kd097d04
> # LG ACX467AKM-7 4.95" 1080×1920 LCD Panel
> --
> 2.34.1
>
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply
* Re: [PATCH] arm64: dts: rockchip: remove startup-delay-us from vcc3v3_pcie2x1l0 on rock-5b
From: Heiko Stuebner @ 2024-04-10 4:31 UTC (permalink / raw)
To: Jianfeng Liu
Cc: conor+dt, devicetree, krzysztof.kozlowski+dt, linux-arm-kernel,
linux-kernel, linux-rockchip, liujianfeng1994, robh, sfr
In-Reply-To: <20240403075916.1025550-1-liujianfeng1994@gmail.com>
Am Mittwoch, 3. April 2024, 09:59:16 CEST schrieb Jianfeng Liu:
> Hi Heiko,
>
> Tue, 02 Apr 2024 12:39:17 +0200, Heiko Stübner wrote:
> >Does the pcie driver enable the regulator too late somehow?
> The pcie driver will enable the regulator imediately when it is probed.
> I added log at when driver is probed and when regulator is enabled.
> Here is the log with "startup-delay-us = <50000>":
> ```
> [ 1.572991] rockchip-dw-pcie a40800000.pcie: rockchip_pcie_probe start
> [ 1.573697] rockchip-dw-pcie a40800000.pcie: going to enable vpcie3v3 regulator
> [ 1.575194] rockchip-dw-pcie a40800000.pcie: enable vpcie3v3 regulator done
> ```
>
> And here is the log without "startup-delay-us":
> ```
> [ 1.518490] rockchip-dw-pcie a40800000.pcie: rockchip_pcie_probe start
> [ 1.518603] rockchip-dw-pcie a40800000.pcie: going to enable vpcie3v3 regulator
> [ 1.518610] rockchip-dw-pcie a40800000.pcie: enable vpcie3v3 regulator done
> ```
>
> We can see startup-delay-us will delay the driver probe.
>
> I also take a look at rockchip's SDK kernel, their pci driver is probed
> very late:
> ```
> [ 3.398682] dw-pcie fe170000.pcie: invalid resource
> [ 3.398686] dw-pcie fe170000.pcie: Failed to initialize host
> [ 3.398688] dw-pcie: probe of fe170000.pcie failed with error -22
> [ 3.399396] rk-pcie fe170000.pcie: invalid prsnt-gpios property in node
> [ 3.399410] rk-pcie fe170000.pcie: Looking up vpcie3v3-supply from device tree
> [ 3.405195] rk-pcie fe170000.pcie: host bridge /pcie@fe170000 ranges:
> [ 3.405253] rk-pcie fe170000.pcie: IO 0x00f2100000..0x00f21fffff -> 0x00f2100000
> [ 3.405283] rk-pcie fe170000.pcie: MEM 0x00f2200000..0x00f2ffffff -> 0x00f2200000
> [ 3.405310] rk-pcie fe170000.pcie: MEM 0x0980000000..0x09bfffffff -> 0x0980000000
> [ 3.405372] rk-pcie fe170000.pcie: iATU unroll: enabled
> [ 3.405381] rk-pcie fe170000.pcie: iATU regions: 8 ob, 8 ib, align 64K, limit 8G
> [ 3.666917] rk-pcie fe170000.pcie: PCIe Link up, LTSSM is 0x30011
> [ 3.666932] rk-pcie fe170000.pcie: PCIe Gen.1 x1 link up
> [ 3.667139] rk-pcie fe170000.pcie: PCI host bridge to bus 0002:20
> ```
>
> And it is reported that startup-delay-us is necessary in rockchip's SDK
> kernel. But in mainline kernel it is different.
that's not directly what I meant.
I.e. if the behaviour changes with arbitary delay changes, it points
very much to some sort of timing issue in the pcie driver itself.
That's why I asked about the regulator turning on, because if the enable
call returns 50ms earlier or later should never influence the behaviour
of the driver.
For example other threads could also just hinder the kernel from
continuing the pcie probe even after the regulator is on - again
leading to undefined behaviour, as you seem to be experiencing as
described in your mail from yesterday.
^ permalink raw reply
* Re: [PATCH v20 4/9] usb: dwc3: core: Refactor PHY logic to support Multiport Controller
From: Krishna Kurapati PSSNV @ 2024-04-10 4:40 UTC (permalink / raw)
To: Thinh Nguyen
Cc: Krzysztof Kozlowski, Rob Herring, Bjorn Andersson, Wesley Cheng,
Konrad Dybcio, Greg Kroah-Hartman, Conor Dooley, Felipe Balbi,
Johan Hovold, devicetree@vger.kernel.org,
linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, quic_ppratap@quicinc.com,
quic_jackp@quicinc.com, Johan Hovold
In-Reply-To: <20240409181342.wmjvi6rwtxphnv3z@synopsys.com>
On 4/9/2024 11:43 PM, Thinh Nguyen wrote:
> On Tue, Apr 09, 2024, Krishna Kurapati PSSNV wrote:
>>
>>
>> On 4/9/2024 6:41 AM, Thinh Nguyen wrote:
>>> On Mon, Apr 08, 2024, Krishna Kurapati wrote:
>>>> Currently the DWC3 driver supports only single port controller
>>>> which requires at least one HS PHY and at most one SS PHY.
>>>>
>>>> But the DWC3 USB controller can be connected to multiple ports and
>>>> each port can have their own PHYs. Each port of the multiport
>>>> controller can either be HS+SS capable or HS only capable
>>>> Proper quantification of them is required to modify GUSB2PHYCFG
>>>> and GUSB3PIPECTL registers appropriately.
>>>>
>>>> Add support for detecting, obtaining and configuring PHYs supported
>>>> by a multiport controller. Limit support to multiport controllers
>>>> with up to four ports for now (e.g. as needed for SC8280XP).
>>>>
>>>> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
>>>> Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
>>>> ---
>>>> drivers/usb/dwc3/core.c | 251 ++++++++++++++++++++++++++++------------
>>>> drivers/usb/dwc3/core.h | 14 ++-
>>>> drivers/usb/dwc3/drd.c | 15 ++-
>>>> 3 files changed, 193 insertions(+), 87 deletions(-)
>>>>
>>>
>>> <snip>
>>>
>>>> @@ -1937,6 +2020,10 @@ static int dwc3_get_num_ports(struct dwc3 *dwc)
>>>> iounmap(base);
>>>> + if (dwc->num_usb2_ports > DWC3_MAX_PORTS ||
>>>> + dwc->num_usb3_ports > DWC3_MAX_PORTS)
>>>> + return -ENOMEM;
>>>
>>> This should be -EINVAL.
>>>
>>>> +
>>>> return 0;
>>>> }
>>>
>>> <snip>
>>>
>>>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>>>> index 341e4c73cb2e..df2e111aa848 100644
>>>> --- a/drivers/usb/dwc3/core.h
>>>> +++ b/drivers/usb/dwc3/core.h
>>>> @@ -33,6 +33,12 @@
>>>> #include <linux/power_supply.h>
>>>> +/*
>>>> + * Maximum number of ports currently supported for multiport
>>>> + * controllers.
>>>
>>> This macro here is being used per USB2 vs USB3 ports rather than USB2 +
>>> USB3, unlike the xHCI MAXPORTS. You can clarify in the comment and
>>> rename the macro to avoid any confusion. You can also create 2 separate
>>> macros for number of USB2 and USB3 ports even if they share the same
>>> value.
>>>
>>> As noted[*], we support have different max number of usb2 ports vs usb3
>>> ports. I would suggest splitting the macros.
>>>
>>
>> Hi Thinh,
>>
>> This macro was intended only to identify how many USB2 (or USB3) Phy's were
>> serviced/operated by this driver, not how many logical ports present (like
>
> That's not what you described in the comment right above the macro...
>
>> in xHCI). I don't think it would be confusing currently given that it is
>> only used to identify number of generic phy instances to allocate and not
>> used for any other purpose. Once the num_usb2_ports and num_usb3_ports are
>> read by get_num_ports(...) call, they directly indicate how many ports are
>
> Those fields are clear. But for DWC3_MAX_PORTS, based on the name and
> comment of the macro, it's not clear.
>
>> HS and SS respectively. Keeping the same in mind, I returned ENOMEM above
>> (as you mentioned) because we don't allocate more than DWC3_MAX_PORTS and if
>> the number of hs or ss ports is more than that, we simply return ENOMEM
>> saying the driver doesn't support operating those many phy's.
>
> The error code -ENOMEM indicates out of memory failure. The check
> condition dwc->num_usb2_ports > DWC3_MAX_PORTS indicates invalid config.
> There's no allocation in that check.
>
>>
>>> [*] https://urldefense.com/v3/__https://lore.kernel.org/linux-usb/20230801013031.ft3zpoatiyfegmh6@synopsys.com/__;!!A4F2R9G_pg!azHqgm92ENkFQrpv6Fhs6PCe210VGOAIrsuGFhrgmfaor8N_kWLu6rxkPpbeCBTLL4NbUpOWlQ0ufmP9DFwO9iFc0XdSEg$
>>>
>>>> + */
>>>> +#define DWC3_MAX_PORTS 4
>>>> +
>>>>
>>>
>>> But it's not a big issue whether you decided to push a new version or a
>>> create a separate patch for the comments above. Here's my Ack:
>>>
>>
>> Since this is not a bug, I would prefer to make a separate patch to rename
>> the macros. (If that is fine).
>>
>
> That is fine with me. Thanks for your effort pursuing and continue
> working on this series.
>
Thanks Thinh. If there are no other issues, I will wait till Greg picks
the series up. Thanks for the reviews throughout the series.
Regards,
Krishna,
^ permalink raw reply
* Re: [PATCH 1/4] arm64: dts: ti: k3-j721e-mcu: Add the WKUP ESM instance
From: Kumar, Udit @ 2024-04-10 5:12 UTC (permalink / raw)
To: Neha Malcom Francis, robh, conor+dt, krzysztof.kozlowski+dt,
vigneshr, nm
Cc: linux-arm-kernel, devicetree, linux-kernel, kristo
In-Reply-To: <20240326122723.2329402-2-n-francis@ti.com>
Hi Neha
On 3/26/2024 5:57 PM, Neha Malcom Francis wrote:
> Add the WKUP ESM instance for J721E. It has three instances in total,
> one in the MAIN domain (main_esm) and two in the MCU-WKUP domain
> (mcu_esm and wkup_esm).
>
> Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
> ---
> arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
> index 4618b697fbc4..b0f41e9829cc 100644
> --- a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
> @@ -689,4 +689,9 @@ mcu_esm: esm@40800000 {
> ti,esm-pins = <95>;
> bootph-pre-ram;
> };
> +
> + wkup_esm: esm@42080000 {
> + compatible = "ti,j721e-esm";
> + reg = <0x00 0x42080000 0x00 0x1000>;
I think , only esm@40800000 should be good for this SOC.
I am not sure, why you want to add this. If you still want to add this
for completeness ,
then two options, I suggest
1) If you plan to use this mention bootph-pre-ram and ti,esm-pins
2) In case , no plan to use this then please mark node as disabled
> + };
> };
^ permalink raw reply
* Re: [PATCH v2 0/3] arm64: dts: rockchip: add Forlinx OK3588-C
From: Heiko Stuebner @ 2024-04-10 5:15 UTC (permalink / raw)
To: linux-rockchip, Dmitry Yashin
Cc: Heiko Stuebner, devicetree, linux-kernel, linux-arm-kernel,
Conor Dooley, Krzysztof Kozlowski, Rob Herring
In-Reply-To: <20240403151229.30577-1-dmt.yashin@gmail.com>
On Wed, 3 Apr 2024 20:12:26 +0500, Dmitry Yashin wrote:
> This series add support for Forlinx RK3588 based SoM and carrier board.
> Devicetree split into .dtsi (FET3588-C SoM) and .dts (OK3588-C Board).
>
> v1 Link: https://lore.kernel.org/all/cover.1710506373.git.dmt.yashin@gmail.com/
>
> Changes in v2:
> Patch 1:
> - no changes
> Patch 2:
> - rename dtsi to rk3588-fet3588-c.dtsi
> - reorder regulator nodes
> - reorder properties in sdhci
> - drop regulator-always-on from vdd_gpu_s0
> - enable tsadc
> Patch 3:
> - update dtsi include
> - set more generic names for tca6424a, nau8822 and sound nodes
> - reorder regulator and nodes in pinctrl
> - reorder properties in gmac and sdmmc
> - drop vmmc-supply from sdmmc and update max-frequency
> - enable gpu (depends on for-next branch)
> - enable usb_host nodes
>
> [...]
Applied, thanks!
[1/3] dt-bindings: arm: rockchip: add Forlinx FET3588-C
commit: dbda7254e7df661fd4022c07dda3a7c9660eee47
[2/3] arm64: dts: rockchip: add Forlinx FET3588-C
commit: f7a9a80da93178fe43b72f13dd55d717b5efff21
[3/3] arm64: dts: rockchip: add Forlinx OK3588-C
commit: ae914513b2f566d995a41638b643ac8589b6275e
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH] arm64: dts: rockchip: Designate the system power controller on QuartzPro64
From: Heiko Stuebner @ 2024-04-10 5:15 UTC (permalink / raw)
To: Dragan Simic, linux-rockchip
Cc: Heiko Stuebner, devicetree, robh+dt, krzysztof.kozlowski+dt,
linux-arm-kernel, conor+dt
In-Reply-To: <c602dfb3972a0844f2a87b6245bdc5c3378c5989.1712512497.git.dsimic@manjaro.org>
On Sun, 7 Apr 2024 19:56:24 +0200, Dragan Simic wrote:
> Designate the primary RK806 PMIC on the Pine64 QuartzPro64 as the system
> power controller, so the board shuts down properly on poweroff(8).
>
>
Applied, thanks!
[1/1] arm64: dts: rockchip: Designate the system power controller on QuartzPro64
commit: c2b6d3a2bbf6352f7cddff2abe81dc4af4887672
Added a Fixes-tag
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: (subset) [PATCH 1/4] arm64: dts: rockchip: drop redundant pcie-reset-suspend in Scarlet Dumo
From: Heiko Stuebner @ 2024-04-10 5:15 UTC (permalink / raw)
To: Krzysztof Kozlowski, devicetree, linux-rockchip, Rob Herring,
Krzysztof Kozlowski, linux-kernel, linux-arm-kernel, Conor Dooley
Cc: Heiko Stuebner
In-Reply-To: <20240407102854.38672-1-krzysztof.kozlowski@linaro.org>
On Sun, 7 Apr 2024 12:28:51 +0200, Krzysztof Kozlowski wrote:
> There is no "pcie-reset-suspend" property in the PCI bindings or Linux
> driver, so assume this was copied from downstream. Drop the property,
> but leave the comment, because it might be useful for someone.
>
> This fixes dtbs_check warning:
>
> rk3399-gru-scarlet-dumo.dtb: pcie@f8000000: Unevaluated properties are not allowed ('pcie-reset-suspend' was unexpected)
>
> [...]
Applied, thanks!
[1/4] arm64: dts: rockchip: drop redundant pcie-reset-suspend in Scarlet Dumo
commit: 29148d841edea9335141fae86a0742f539fe1327
[3/4] arm64: dts: rockchip: drop redundant disable-gpios in Lubancat 1
commit: cd0793fc3b03985d90f24232056853ef79ff555e
[4/4] arm64: dts: rockchip: drop redundant disable-gpios in Lubancat 2
commit: d892a6f34adc371ee0dbaa5ba684d02c4431f2e3
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH] dt-bindings: rockchip: grf: Add missing type to 'pcie-phy' node
From: Heiko Stuebner @ 2024-04-10 5:15 UTC (permalink / raw)
To: Conor Dooley, Krzysztof Kozlowski, Rob Herring
Cc: Heiko Stuebner, devicetree, linux-rockchip, linux-kernel,
linux-arm-kernel
In-Reply-To: <20240401204959.1698106-1-robh@kernel.org>
On Mon, 1 Apr 2024 15:49:58 -0500, Rob Herring wrote:
> 'pcie-phy' is missing any type. Add 'type: object' to indicate it's a
> node.
>
>
Applied, thanks!
[1/1] dt-bindings: rockchip: grf: Add missing type to 'pcie-phy' node
commit: d41201c90f825f19a46afbfb502f22f612d8ccc4
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH] arm64: dts: rockchip: mark system power controller and fix typo on orangepi-5-plus
From: Heiko Stuebner @ 2024-04-10 5:15 UTC (permalink / raw)
To: linux-rockchip, efectn
Cc: Heiko Stuebner, devicetree, conor+dt, robh+dt, linux-kernel,
krzysztof.kozlowski+dt, linux-arm-kernel, sebastian.reichel,
Muhammed Efe Cetin
In-Reply-To: <20240407173210.372585-1-efectn@6tel.net>
On Sun, 7 Apr 2024 20:32:10 +0300, efectn@6tel.net wrote:
> From: Muhammed Efe Cetin <efectn@protonmail.com>
>
> Mark the PMIC as system power controller, so the board will shut-down
> properly and fix the typo on rk806_dvs1_null pins property.
>
>
Applied, thanks!
[1/1] arm64: dts: rockchip: mark system power controller and fix typo on orangepi-5-plus
commit: 08cd20bdecd9cfde5c1aec6146fa22ca753efea1
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH v2 0/2] Add Protonic MECSBC board support
From: Heiko Stuebner @ 2024-04-10 5:15 UTC (permalink / raw)
To: Conor Dooley, Krzysztof Kozlowski, Sascha Hauer, Rob Herring
Cc: Heiko Stuebner, devicetree, linux-rockchip, Krzysztof Kozlowski,
linux-kernel, linux-arm-kernel, David Jander
In-Reply-To: <20240405-protonic-mecsbc-v2-0-0a6fedc78b9f@pengutronix.de>
On Fri, 05 Apr 2024 12:14:24 +0200, Sascha Hauer wrote:
> This series adds support for the Protonic MECSBC. MECSBC is a single
> board computer for blood analysis machines from RR-Mechatronics,
> designed and manufactured by Protonic Holland, based on the Rockchip
> RK3568 SoC.
>
>
Applied, thanks!
[1/2] dt-bindings: arm: rockchip: Add Protonic MECSBC board
commit: 6eb006d7c8271d4ff811b8f13b40e527d35d88e1
[2/2] arm64: dts: rockchip: add Protonic MECSBC device-tree
commit: 6f9dfb7358535136e49d6fe9d31409f20f8cb9a7
Adjusted the node-sorting some more to honor our alphabetical
paradigm.
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH 0/2] clk: rockchip: clk-rk3568.c: Add missing USB480M_PHY mux
From: Heiko Stuebner @ 2024-04-10 5:15 UTC (permalink / raw)
To: Stephen Boyd, Rob Herring, Sascha Hauer, Conor Dooley,
Krzysztof Kozlowski, Michael Turquette
Cc: Heiko Stuebner, devicetree, linux-rockchip, linux-clk,
linux-kernel, linux-arm-kernel, David Jander
In-Reply-To: <20240405-clk-rk3568-usb480m-phy-mux-v1-0-6c89de20a6ff@pengutronix.de>
On Fri, 05 Apr 2024 09:38:35 +0200, Sascha Hauer wrote:
> This series adds a missing clock for the Rockchip RK3568.
>
>
Applied, thanks!
[1/2] dt-bindings: clock: rockchip: add USB480M_PHY mux
commit: 575bc7b477e3f6c505f49c3d99d7be965594d640
[2/2] clk: rockchip: clk-rk3568.c: Add missing USB480M_PHY mux
commit: 007bd99669eae90f23817023dc78dbb38e76437d
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH] arm64: dts: rockchip: rk3588s: Fix ordering of nodes
From: Heiko Stuebner @ 2024-04-10 5:14 UTC (permalink / raw)
To: Conor Dooley, Krzysztof Kozlowski, Diederik de Haas, Rob Herring
Cc: Heiko Stuebner, devicetree, linux-rockchip, linux-arm-kernel
In-Reply-To: <20240406172821.34173-1-didi.debian@cknow.org>
On Sat, 6 Apr 2024 19:28:04 +0200, Diederik de Haas wrote:
> Fix the ordering of the main nodes by sorting them alphabetically and
> then the ones with a memory address sequentially by that address.
>
>
Applied, thanks!
[1/1] arm64: dts: rockchip: rk3588s: Fix ordering of nodes
commit: cbb97fe18e299ece1c0074924c630de6a19b320f
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: (subset) [PATCH v3 0/6] Add Synopsys DesignWare HDMI RX Controller
From: Heiko Stuebner @ 2024-04-10 5:15 UTC (permalink / raw)
To: hverkuil-cisco, mchehab, Shreeya Patel, sebastian.reichel,
jose.abreu, nelson.costa, p.zabel, dmitry.osipenko,
nicolas.dufresne, krzysztof.kozlowski+dt, hverkuil, mturquette,
sboyd, robh, conor+dt, shawn.wen
Cc: Heiko Stuebner, devicetree, linux-rockchip, linux-media,
linux-clk, linux-kernel, linux-arm-kernel, linux-arm, kernel
In-Reply-To: <20240327225057.672304-1-shreeya.patel@collabora.com>
On Thu, 28 Mar 2024 04:20:51 +0530, Shreeya Patel wrote:
> This series implements support for the Synopsys DesignWare
> HDMI RX Controller, being compliant with standard HDMI 1.4b
> and HDMI 2.0.
>
> Features that are currently supported by the HDMI RX driver
> have been tested on rock5b board using a HDMI to micro-HDMI cable.
> It is recommended to use a good quality cable as there were
> multiple issues seen during testing the driver.
>
> [...]
Applied, thanks!
[1/6] dt-bindings: reset: Define reset id used for HDMI Receiver
commit: ca151fd56b5736a7adbdba5675b9d87d70f20b23
[2/6] clk: rockchip: rst-rk3588: Add reset line for HDMI Receiver
commit: 7af67019cd78d028ef377df689ac103d51905518
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH] arm64: dts: rockchip: Designate the system power controller on QuartzPro64
From: Dragan Simic @ 2024-04-10 5:24 UTC (permalink / raw)
To: Heiko Stuebner
Cc: linux-rockchip, devicetree, robh+dt, krzysztof.kozlowski+dt,
linux-arm-kernel, conor+dt
In-Reply-To: <171272604789.1867483.1717225065687252209.b4-ty@sntech.de>
On 2024-04-10 07:15, Heiko Stuebner wrote:
> On Sun, 7 Apr 2024 19:56:24 +0200, Dragan Simic wrote:
>> Designate the primary RK806 PMIC on the Pine64 QuartzPro64 as the
>> system
>> power controller, so the board shuts down properly on poweroff(8).
>
> Applied, thanks!
>
> [1/1] arm64: dts: rockchip: Designate the system power controller on
> QuartzPro64
> commit: c2b6d3a2bbf6352f7cddff2abe81dc4af4887672
>
> Added a Fixes-tag
Great, thanks!
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: riscv: add Milk-V Duo S board compatibles
From: michael.opdenacker @ 2024-04-10 5:25 UTC (permalink / raw)
To: Conor Dooley, Rob Herring, Krzysztof Kozlowski, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Chen Wang, Inochi Amaoto, Chao Wei
Cc: Michael Opdenacker, linux-riscv, devicetree, linux-kernel
In-Reply-To: <20240410052518.2945789-1-michael.opdenacker@bootlin.com>
From: Michael Opdenacker <michael.opdenacker@bootlin.com>
Document the compatible strings for the Milk-V Duo S board[1] which uses
the SOPHGO SG2000 SoC, compatible with the SOPHGO CV1800B SoC[2].
Link: https://milkv.io/duo-s [1]
Link: https://en.sophgo.com/product/introduce/cv180xB.html [2]
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
Documentation/devicetree/bindings/riscv/sophgo.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/riscv/sophgo.yaml b/Documentation/devicetree/bindings/riscv/sophgo.yaml
index 9bc813dad098..2bf58bd6f3a0 100644
--- a/Documentation/devicetree/bindings/riscv/sophgo.yaml
+++ b/Documentation/devicetree/bindings/riscv/sophgo.yaml
@@ -22,6 +22,10 @@ properties:
- enum:
- milkv,duo
- const: sophgo,cv1800b
+ - items:
+ - enum:
+ - milkv,duos
+ - const: sophgo,cv1800b
- items:
- enum:
- sophgo,huashan-pi
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/2] riscv: dts: sophgo: add initial Milk-V Duo S board support
From: michael.opdenacker @ 2024-04-10 5:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Chen Wang, Inochi Amaoto
Cc: Michael Opdenacker, devicetree, linux-riscv, linux-kernel
In-Reply-To: <20240410052518.2945789-1-michael.opdenacker@bootlin.com>
From: Michael Opdenacker <michael.opdenacker@bootlin.com>
This adds initial support for the Milk-V Duo S board
(https://milkv.io/duo-s), enabling the serial port and
SD card support, allowing to boot Linux to the command line.
Link: https://lore.kernel.org/linux-riscv/171266958507.1032617.9460749136730849811.robh@kernel.org/T/#t
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
arch/riscv/boot/dts/sophgo/Makefile | 1 +
.../boot/dts/sophgo/sg2000-milkv-duos.dts | 39 +++++++++++++++++++
2 files changed, 40 insertions(+)
create mode 100644 arch/riscv/boot/dts/sophgo/sg2000-milkv-duos.dts
diff --git a/arch/riscv/boot/dts/sophgo/Makefile b/arch/riscv/boot/dts/sophgo/Makefile
index 57ad82a61ea6..e008acb5240f 100644
--- a/arch/riscv/boot/dts/sophgo/Makefile
+++ b/arch/riscv/boot/dts/sophgo/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
dtb-$(CONFIG_ARCH_SOPHGO) += cv1800b-milkv-duo.dtb
dtb-$(CONFIG_ARCH_SOPHGO) += cv1812h-huashan-pi.dtb
+dtb-$(CONFIG_ARCH_SOPHGO) += sg2000-milkv-duos.dtb
dtb-$(CONFIG_ARCH_SOPHGO) += sg2042-milkv-pioneer.dtb
diff --git a/arch/riscv/boot/dts/sophgo/sg2000-milkv-duos.dts b/arch/riscv/boot/dts/sophgo/sg2000-milkv-duos.dts
new file mode 100644
index 000000000000..679d2854938a
--- /dev/null
+++ b/arch/riscv/boot/dts/sophgo/sg2000-milkv-duos.dts
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2024 Michael Opdenacker <michael.opdenacker@bootlin.com>
+ */
+
+/dts-v1/;
+
+#include "cv1800b.dtsi"
+
+/ {
+ model = "Milk-V Duo S";
+ compatible = "milkv,duos", "sophgo,cv1800b";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x80000000 0x20000000>;
+ };
+};
+
+&osc {
+ clock-frequency = <25000000>;
+};
+
+&sdhci0 {
+ status = "okay";
+ disable-wp;
+};
+
+&uart0 {
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 3/4] arm64: dts: ti: k3-j721e-main: Add the MAIN domain watchdog instances
From: Kumar, Udit @ 2024-04-10 5:36 UTC (permalink / raw)
To: Neha Malcom Francis, robh, conor+dt, krzysztof.kozlowski+dt,
vigneshr, nm
Cc: linux-arm-kernel, devicetree, linux-kernel, kristo
In-Reply-To: <20240326122723.2329402-4-n-francis@ti.com>
Hi Neha
On 3/26/2024 5:57 PM, Neha Malcom Francis wrote:
> There are 10 watchdog instances in the MAIN domain:
> * one each for the 2 A72 cores
> * one for the GPU core
> * one for the C7x core
> * one each for the 2 C66x cores
> * one each for the 4 R5F cores
>
> Currently, the devicetree only describes watchdog instances for the A72
> cores and enables them. Describe the remaining but reserve them as they
> will be used by their respective firmware.
>
> Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
> ---
> arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 93 +++++++++++++++++++++++
> 1 file changed, 93 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
> index c7eafbc862f9..d8930b8ea8ec 100644
> --- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
> @@ -2157,6 +2157,99 @@ watchdog1: watchdog@2210000 {
> assigned-clock-parents = <&k3_clks 253 5>;
> };
>
Looking at TRM, SPRUIJ7*3–December 2018–Revised March 2019,
Table 12-22646. RTI Instances, says There is gap in numbering
RTI0, RTI1, RTI15 and so on
IMO, labels for watchdog should be as per TRM.
eg watchdog2 to watchdog15, But I don't have strong opinion on either .
Let maintainer suggest on this
> + /*
> + * The following RTI instances are coupled with MCU R5Fs, c7x and
> + * GPU so keeping them reserved as these will be used by their
> + * respective firmware
> + */
> + watchdog2: watchdog@22f0000 {
> + compatible = "ti,j7-rti-wdt";
> + reg = <0x00 0x22f0000 0x00 0x100>;
> + clocks = <&k3_clks 257 1>;
> + power-domains = <&k3_pds 257 TI_SCI_PD_EXCLUSIVE>;
> + assigned-clocks = <&k3_clks 257 1>;
> + assigned-clock-parents = <&k3_clks 257 5>;
> + /* reserved for GPU */
> + status = "reserved";
> + };
Please help me to understand, where from you got it for GPU,
May be I am looking at wrong data, Again above TRM
Table 12-22645. RTI Hardware Requests. RTI-15 says esm0
> +
> + watchdog3: watchdog@2300000 {
> + compatible = "ti,j7-rti-wdt";
> + reg = <0x00 0x2300000 0x00 0x100>;
> + clocks = <&k3_clks 256 1>;
> + power-domains = <&k3_pds 256 TI_SCI_PD_EXCLUSIVE>;
> + assigned-clocks = <&k3_clks 256 1>;
> + assigned-clock-parents = <&k3_clks 256 5>;
> + /* reserved for C7X */
> + status = "reserved";
This I see in above table for Compute Cluster
> + };
> +
> + watchdog4: watchdog@2380000 {
> + compatible = "ti,j7-rti-wdt";
> + reg = <0x00 0x2380000 0x00 0x100>;
> + clocks = <&k3_clks 254 1>;
> + power-domains = <&k3_pds 254 TI_SCI_PD_EXCLUSIVE>;
> + assigned-clocks = <&k3_clks 254 1>;
> + assigned-clock-parents = <&k3_clks 254 5>;
> + /* reserved for C66X_0 */
> + status = "reserved";
> + };
> +
> + watchdog5: watchdog@2390000 {
> + compatible = "ti,j7-rti-wdt";
> + reg = <0x00 0x2390000 0x00 0x100>;
> + clocks = <&k3_clks 255 1>;
> + power-domains = <&k3_pds 255 TI_SCI_PD_EXCLUSIVE>;
> + assigned-clocks = <&k3_clks 255 1>;
> + assigned-clock-parents = <&k3_clks 255 5>;
> + /* reserved for C66X_1 */
> + status = "reserved";
> + };
> +
> + watchdog6: watchdog@23c0000 {
> + compatible = "ti,j7-rti-wdt";
> + reg = <0x00 0x23c0000 0x00 0x100>;
> + clocks = <&k3_clks 258 1>;
> + power-domains = <&k3_pds 258 TI_SCI_PD_EXCLUSIVE>;
> + assigned-clocks = <&k3_clks 258 1>;
> + assigned-clock-parents = <&k3_clks 258 5>;
> + /* reserved for MAIN_R5F0_0 */
TRM says, this covers both MAIN_R5F0_0 and MAIN_R5F0_1.
Suggest , if split is done at fw level
> + status = "reserved";
> + };
> +
> + watchdog7: watchdog@23d0000 {
> + compatible = "ti,j7-rti-wdt";
> + reg = <0x00 0x23d0000 0x00 0x100>;
> + clocks = <&k3_clks 259 1>;
> + power-domains = <&k3_pds 259 TI_SCI_PD_EXCLUSIVE>;
> + assigned-clocks = <&k3_clks 259 1>;
> + assigned-clock-parents = <&k3_clks 259 5>;
> + /* reserved for MAIN_R5F0_1 */
> + status = "reserved";
TRM says, this covers both MAIN_R5F0_0 and MAIN_R5F0_1.
Suggest , if split is done at fw level
> + };
> +
> + watchdog8: watchdog@23e0000 {
> + compatible = "ti,j7-rti-wdt";
> + reg = <0x00 0x23e0000 0x00 0x100>;
> + clocks = <&k3_clks 260 1>;
> + power-domains = <&k3_pds 260 TI_SCI_PD_EXCLUSIVE>;
> + assigned-clocks = <&k3_clks 260 1>;
> + assigned-clock-parents = <&k3_clks 260 5>;
> + /* reserved for MAIN_R5F1_0 */
> + status = "reserved";
> + };
TRM says, this covers both MAIN_R5F1_0 and MAIN_R5F1_1.
Suggest , if split is done at fw level
> +
> + watchdog9: watchdog@23f0000 {
> + compatible = "ti,j7-rti-wdt";
> + reg = <0x00 0x23f0000 0x00 0x100>;
> + clocks = <&k3_clks 261 1>;
> + power-domains = <&k3_pds 261 TI_SCI_PD_EXCLUSIVE>;
> + assigned-clocks = <&k3_clks 261 1>;
> + assigned-clock-parents = <&k3_clks 261 5>;
> + /* reserved for MAIN_R5F1_1 */
TRM says, this covers both MAIN_R5F1_0 and MAIN_R5F1_1.
Suggest , if split is done at fw level
> + status = "reserved";
> + };
> +
> main_r5fss0: r5fss@5c00000 {
> compatible = "ti,j721e-r5fss";
> ti,cluster-mode = <1>;
^ 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