* Re: [PATCH v3 0/6] Add Synopsys DesignWare HDMI RX Controller
From: Krzysztof Kozlowski @ 2024-04-04 8:17 UTC (permalink / raw)
To: Shreeya Patel
Cc: Heiko Stübner, mchehab, hverkuil, hverkuil-cisco, robh,
krzysztof.kozlowski+dt, conor+dt, mturquette, sboyd, p.zabel,
shawn.wen, kernel, linux-kernel, linux-media, devicetree,
linux-arm-kernel, linux-rockchip, linux-clk, linux-arm
In-Reply-To: <36bd27-660e6000-3-6c1c1e00@12777057>
On 04/04/2024 10:07, Shreeya Patel wrote:
> On Thursday, April 04, 2024 11:45 IST, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
>
>> On 04/04/2024 00:48, Heiko Stübner wrote:
>>> Am Mittwoch, 3. April 2024, 13:24:05 CEST schrieb Krzysztof Kozlowski:
>>>> On 03/04/2024 13:20, Shreeya Patel wrote:
>>>>> On Wednesday, April 03, 2024 15:51 IST, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
>>>>>
>>>>>> On 03/04/2024 11:24, Shreeya Patel wrote:
>>>>>>> On Thursday, March 28, 2024 04:20 IST, Shreeya Patel <shreeya.patel@collabora.com> wrote:
>>>>>>>
>>>>>>>> This series implements support for the Synopsys DesignWare
>>>>>>>> HDMI RX Controller, being compliant with standard HDMI 1.4b
>>>>>>>> and HDMI 2.0.
>>>>>>>>
>>>>>>>
>>>>>>> Hi Mauro and Hans,
>>>>>>>
>>>>>>> I haven't received any reviews so far. Hence, this is just a gentle reminder to review this patch series.
>>>>>>
>>>>>> Why did you put clk changes here? These go via different subsystem. That
>>>>>> might be one of obstacles for your patchset.
>>>>>>
>>>>>
>>>>> I added clock changes in this patch series because HDMIRX driver depends on it.
>>>>> I thought it is wrong to send the driver patches which don't even compile?
>>>>
>>>> Hm, why HDMIRX driver depends on clock? How? This sounds really wrong.
>>>> Please get it reviewed internally first.
>>>
>>> For the change in question, the clock controller on the soc also handles
>>> the reset controls (hence its name CRU, clock-and-reset-unit) .
>>>
>>> There are at least 660 reset lines in the unit and it seems the hdmi-rx one
>>> was overlooked on the initial submission, hence patches 1+2 add the
>>> reset-line.
>>>
>>> Of course, here only the "arm64: dts:" patch depends on the clock
>>> change, is it references the new reset-id.
>>
>> Wait, that's expected, but it is not what was written. Claim was HDMIRX
>> driver depends *build time* ("don't even compile").
>>
>
> For some context, when I was testing the downstream driver against the
> device tree, I saw some failures because of the missing reset ( which I am trying
> to add in the first two patches for this series )
>
> ...
> hdmirx_dev->rst_biu = devm_reset_control_get(hdmirx_dev->dev, "rst_biu");
> if (IS_ERR(hdmirx_dev->rst_biu)) {
> dev_err(dev, "failed to get rst_biu control\n");
> return PTR_ERR(hdmirx_dev->rst_biu);
> }
That's a driver....
> shreeya@shreeya:~/collabora/rd/rockchip/linux$ make dtbs
> DTC arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dtb
and that's a DTS.
> Error: arch/arm64/boot/dts/rockchip/rk3588.dtsi:187.23-24 syntax error
> FATAL ERROR: Unable to parse input tree
> make[3]: *** [scripts/Makefile.lib:419: arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dtb] Error 1
> make[2]: *** [scripts/Makefile.build:481: arch/arm64/boot/dts/rockchip] Error 2
> make[1]: *** [/home/shreeya/collabora/rd/rockchip/linux/Makefile:1392: dtbs] Error 2
> make: *** [Makefile:240: __sub-make] Error 2
They are not related anyhow. Look above which Makefile target produced
error. Which file failed to build. This is a expressed in make[3] line.
Directory is expressed in other places.
>
> Sorry for referring this as a driver build failure but I am sure you would
> also have not been okay with the above issues.
> Ofcourse I can simply remove this dependency from the driver but maybe
> that will affect the functionality and I didn't want to send a buggy patch series.
What dependency?
It seems you did not understand anything from Heiko's message, so please
reach to your colleagues for explanation where is the dependency.
>
> My intention here was just like Heiko said, to keep all the dependent patches
> together. I didn't know that would be a trouble for Maintainers.
They are not dependent.
>
> FWIW, HDMIRX patch series was reviewed multiple times and that is why you
> see a Reviewed-by tag from a Collabora Engineer. Sometimes the things that look
> problematic to one might not look the same to others and that is why I asked you
> to provide some more details about the problem that you were seeing.
>
> https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/merge_requests/21
> https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/merge_requests/17
Sorry, that's some third party gitlab... I don't know what does it prove.
>
>
>>>
>>>
>>> Am Mittwoch, 3. April 2024, 12:22:57 CEST schrieb Krzysztof Kozlowski:
>>>> Please do not engage multiple subsystems in one patchset, if not
>>>> necessary. Especially do not mix DTS into media or USB subsystems. And
>>>> do not put DTS in the middle!
>>>
>>> picking up your reply from patch 4/6, there seem to be different "schools
>>> of thought" for this. Some maintainers might want to really only see
>>> patches that are explicitly for their subsystem - I guess networking
>>> might be a prime example for that, who will essentially apply whole series'
>>> if nobody protests in time (including dts patches)
>>
>> There is no school saying DTS is allowed to be in the middle.
>>
>> Other schools are indeed saying that seeing DTS is good and
>> recommendation is to post it separate and provide a link. That's way you
>> avoid DTS being pulled by Greg, media or networking.
>>
>
> This was my mistake and I simply forgot to remove the DTS when I was
> testing the driver for the last time before sending the v3 upstream.
> Adding it in the middle was incorrect, I should have added it as a separate
> patch but honestly this has always been very confusing and the expectation
> differs from maintainers to maintainers.
There were guidelines - presented in the conferences, mailing list and
even SoC maintainer profile explains how patches eventually end up. I
agree that it still might be confusing, but these are the basics of
submitting patches to anything touching SoC. Anyone working with SoC
will need to know them, so how about Collabora creates some internal
guideline explaining this, so such confusions could be avoided?
I know that such guidelines exist in other companies...
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] dt-bindings: pwm: mediatek,pwm-disp: Document power-domains property
From: AngeloGioacchino Del Regno @ 2024-04-04 8:18 UTC (permalink / raw)
To: u.kleine-koenig
Cc: robh, krzysztof.kozlowski+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, jitao.shi, thierry.reding, miles.chen,
xinlei.lee, linux-pwm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, wenst, kernel
Allow the power-domains property to the PWM_DISP block as on some SoCs
this does need at most one power domain.
Fixes: b09b179bac0a ("dt-bindings: pwm: Convert pwm-mtk-disp.txt to mediatek,pwm-disp.yaml format")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml
index afcdeed4e88a..bc813fe74fab 100644
--- a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml
+++ b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml
@@ -52,6 +52,9 @@ properties:
- const: main
- const: mm
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
--
2.44.0
^ permalink raw reply related
* [PATCH v2] arm64: dts: ti: k3-am62p: use eFuse MAC Address for CPSW3G Port 1
From: Siddharth Vadapalli @ 2024-04-04 8:18 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: devicetree, linux-kernel, linux-arm-kernel, srk, s-vadapalli
Add the "cpsw-mac-efuse" node within "wkup_conf" node corresponding to the
CTRLMMR_MAC_IDx registers within the CTRL_MMR space. Assign the compatible
"ti,am62p-cpsw-mac-efuse" to enable "syscon_regmap" operations on these
registers. The MAC Address programmed in the eFuse is accessible through
the CTRLMMR_MAC_IDx registers. The "ti,syscon-efuse" device-tree property
points to the CTRLMMR_MAC_IDx registers, allowing the CPSW driver to fetch
the MAC Address and assign it to the network interface associated with
CPSW3G MAC Port 1.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
---
This patch is based on linux-next tagged next-20240404.
Patch depends on:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20240402105708.4114146-1-s-vadapalli@ti.com/
for the newly added "ti,am62p-cpsw-mac-efuse" compatible.
v1:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20240402094200.4036076-1-s-vadapalli@ti.com/
Changes since v1:
- Since "wkup_conf" is modelled as a "simple-bus" rather than being
modelled as a System Controller node with the "syscon" compatible,
directly passing the reference to the "wkup_conf" node using the
"ti,syscon-efuse" device-tree property will not work.
Therefore, I posted the patch at:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20240402105708.4114146-1-s-vadapalli@ti.com/
in order to add a new compatible to be used for modelling the
CTRLMMR_MAC_IDx registers as System Controller nodes, thereby
allowing the existing "ti,syscon-efuse" property to be used.
Now, "ti,syscon-efuse" points to the "cpsw_mac_efuse" node within
"wkup_conf" node, with "cpsw_mac_efuse" being a "syscon" node.
Logs verifying that the CPSW driver assigns the MAC Address from the
eFuse based on the CTRLMMR_MAC_IDx registers at 0x43000200 and 0x43000204
to the interface eth0 corresponding to CPSW3G MAC Port 1:
https://gist.github.com/Siddharth-Vadapalli-at-TI/9982c6f13bf9b8cfaf97e8517e7dea13
Regards,
Siddharth.
arch/arm64/boot/dts/ti/k3-am62p-main.dtsi | 1 +
arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi | 5 +++++
2 files changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
index 7337a9e13535..848ca454a411 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
@@ -696,6 +696,7 @@ cpsw_port1: port@1 {
label = "port1";
phys = <&phy_gmii_sel 1>;
mac-address = [00 00 00 00 00 00];
+ ti,syscon-efuse = <&cpsw_mac_efuse 0x0>;
};
cpsw_port2: port@2 {
diff --git a/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi
index a84756c336d0..df9d40f64e3b 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi
@@ -18,6 +18,11 @@ chipid: chipid@14 {
reg = <0x14 0x4>;
bootph-all;
};
+
+ cpsw_mac_efuse: cpsw-mac-efuse@200 {
+ compatible = "ti,am62p-cpsw-mac-efuse", "syscon";
+ reg = <0x200 0x8>;
+ };
};
wkup_uart0: serial@2b300000 {
--
2.40.1
^ permalink raw reply related
* Re: [PATCH v3 0/6] Add Synopsys DesignWare HDMI RX Controller
From: Heiko Stübner @ 2024-04-04 8:19 UTC (permalink / raw)
To: Shreeya Patel, Krzysztof Kozlowski
Cc: mchehab, hverkuil, hverkuil-cisco, robh, krzysztof.kozlowski+dt,
conor+dt, mturquette, sboyd, p.zabel, shawn.wen, kernel,
linux-kernel, linux-media, devicetree, linux-arm-kernel,
linux-rockchip, linux-clk, linux-arm
In-Reply-To: <c790c8ba-a9bd-4820-8084-1294e5e523d9@linaro.org>
Am Donnerstag, 4. April 2024, 08:15:50 CEST schrieb Krzysztof Kozlowski:
> On 04/04/2024 00:48, Heiko Stübner wrote:
> > Am Mittwoch, 3. April 2024, 13:24:05 CEST schrieb Krzysztof Kozlowski:
> >> On 03/04/2024 13:20, Shreeya Patel wrote:
> >>> On Wednesday, April 03, 2024 15:51 IST, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
> >>>
> >>>> On 03/04/2024 11:24, Shreeya Patel wrote:
> >>>>> On Thursday, March 28, 2024 04:20 IST, Shreeya Patel <shreeya.patel@collabora.com> wrote:
> >>>>>
> >>>>>> This series implements support for the Synopsys DesignWare
> >>>>>> HDMI RX Controller, being compliant with standard HDMI 1.4b
> >>>>>> and HDMI 2.0.
> >>>>>>
> >>>>>
> >>>>> Hi Mauro and Hans,
> >>>>>
> >>>>> I haven't received any reviews so far. Hence, this is just a gentle reminder to review this patch series.
> >>>>
> >>>> Why did you put clk changes here? These go via different subsystem. That
> >>>> might be one of obstacles for your patchset.
> >>>>
> >>>
> >>> I added clock changes in this patch series because HDMIRX driver depends on it.
> >>> I thought it is wrong to send the driver patches which don't even compile?
> >>
> >> Hm, why HDMIRX driver depends on clock? How? This sounds really wrong.
> >> Please get it reviewed internally first.
> >
> > For the change in question, the clock controller on the soc also handles
> > the reset controls (hence its name CRU, clock-and-reset-unit) .
> >
> > There are at least 660 reset lines in the unit and it seems the hdmi-rx one
> > was overlooked on the initial submission, hence patches 1+2 add the
> > reset-line.
> >
> > Of course, here only the "arm64: dts:" patch depends on the clock
> > change, is it references the new reset-id.
>
> Wait, that's expected, but it is not what was written. Claim was HDMIRX
> driver depends *build time* ("don't even compile").
Trying to do a full build (kernel + dts) will fail, because the the
device-tree patch references the newly added reset-id .
So you end up with a dtc error. Same with the binding.
I think in the past to uncouple this we did reference the id by number
first:
+ resets = <&cru SRST_A_HDMIRX>, <&cru SRST_P_HDMIRX>,
+ <&cru SRST_HDMIRX_REF>, <&cru 660>;
Had the id-addition separately and then a later series for kernel x+1
to convert from 660 to SRST_A_HDMIRX_BIU .
> > Am Mittwoch, 3. April 2024, 12:22:57 CEST schrieb Krzysztof Kozlowski:
> >> Please do not engage multiple subsystems in one patchset, if not
> >> necessary. Especially do not mix DTS into media or USB subsystems. And
> >> do not put DTS in the middle!
> >
> > picking up your reply from patch 4/6, there seem to be different "schools
> > of thought" for this. Some maintainers might want to really only see
> > patches that are explicitly for their subsystem - I guess networking
> > might be a prime example for that, who will essentially apply whole series'
> > if nobody protests in time (including dts patches)
>
> There is no school saying DTS is allowed to be in the middle.
I think I wrote exactly that in my original reply :-)
Am Donnerstag, 4. April 2024, 00:48:38 CEST schrieb Heiko Stübner:
> Of course you're right, the "arm64: dts:" patch should be the last in the
> series and not be in the middle of it.
Heiko
^ permalink raw reply
* Re: [PATCH v12 2/7] clk: meson: add vclk driver
From: Jerome Brunet @ 2024-04-04 8:13 UTC (permalink / raw)
To: Neil Armstrong
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Martin Blumenstingl, Jerome Brunet, Kevin Hilman,
Michael Turquette, Stephen Boyd, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Jagan Teki,
Nicolas Belin, devicetree, linux-kernel, linux-amlogic, linux-clk,
linux-arm-kernel, dri-devel
In-Reply-To: <20240403-amlogic-v6-4-upstream-dsi-ccf-vim3-v12-2-99ecdfdc87fc@linaro.org>
On Wed 03 Apr 2024 at 09:46, Neil Armstrong <neil.armstrong@linaro.org> wrote:
> The VCLK and VCLK_DIV clocks have supplementary bits.
>
> The VCLK gate has a "SOFT RESET" bit to toggle after the whole
> VCLK sub-tree rate has been set, this is implemented in
> the gate enable callback.
>
> The VCLK_DIV clocks as enable and reset bits used to disable
> and reset the divider, associated with CLK_SET_RATE_GATE it ensures
> the rate is set while the divider is disabled and in reset mode.
>
> The VCLK_DIV enable bit isn't implemented as a gate since it's part
> of the divider logic and vendor does this exact sequence to ensure
> the divider is correctly set.
The checkpatch warning is still there. Is it a choice or a mistake ?
Documentation says "GPL v2" exists for historic reason which seems to
hint "GPL" is preferred, and I suppose this is why checkpatch warns for
it.
>
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
> drivers/clk/meson/Kconfig | 4 ++
> drivers/clk/meson/Makefile | 1 +
> drivers/clk/meson/vclk.c | 141 +++++++++++++++++++++++++++++++++++++++++++++
> drivers/clk/meson/vclk.h | 51 ++++++++++++++++
> 4 files changed, 197 insertions(+)
>
> diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
> index 29ffd14d267b..8a9823789fa3 100644
> --- a/drivers/clk/meson/Kconfig
> +++ b/drivers/clk/meson/Kconfig
> @@ -30,6 +30,10 @@ config COMMON_CLK_MESON_VID_PLL_DIV
> tristate
> select COMMON_CLK_MESON_REGMAP
>
> +config COMMON_CLK_MESON_VCLK
> + tristate
> + select COMMON_CLK_MESON_REGMAP
> +
> config COMMON_CLK_MESON_CLKC_UTILS
> tristate
>
> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
> index 9ee4b954c896..9ba43fe7a07a 100644
> --- a/drivers/clk/meson/Makefile
> +++ b/drivers/clk/meson/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_COMMON_CLK_MESON_PLL) += clk-pll.o
> obj-$(CONFIG_COMMON_CLK_MESON_REGMAP) += clk-regmap.o
> obj-$(CONFIG_COMMON_CLK_MESON_SCLK_DIV) += sclk-div.o
> obj-$(CONFIG_COMMON_CLK_MESON_VID_PLL_DIV) += vid-pll-div.o
> +obj-$(CONFIG_COMMON_CLK_MESON_VCLK) += vclk.o
>
> # Amlogic Clock controllers
>
> diff --git a/drivers/clk/meson/vclk.c b/drivers/clk/meson/vclk.c
> new file mode 100644
> index 000000000000..45dc216941ea
> --- /dev/null
> +++ b/drivers/clk/meson/vclk.c
> @@ -0,0 +1,141 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2024 Neil Armstrong <neil.armstrong@linaro.org>
> + */
> +
> +#include <linux/module.h>
> +#include "vclk.h"
> +
> +/* The VCLK gate has a supplementary reset bit to pulse after ungating */
> +
> +static inline struct meson_vclk_gate_data *
> +clk_get_meson_vclk_gate_data(struct clk_regmap *clk)
> +{
> + return (struct meson_vclk_gate_data *)clk->data;
> +}
> +
> +static int meson_vclk_gate_enable(struct clk_hw *hw)
> +{
> + struct clk_regmap *clk = to_clk_regmap(hw);
> + struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
> +
> + meson_parm_write(clk->map, &vclk->enable, 1);
> +
> + /* Do a reset pulse */
> + meson_parm_write(clk->map, &vclk->reset, 1);
> + meson_parm_write(clk->map, &vclk->reset, 0);
> +
> + return 0;
> +}
> +
> +static void meson_vclk_gate_disable(struct clk_hw *hw)
> +{
> + struct clk_regmap *clk = to_clk_regmap(hw);
> + struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
> +
> + meson_parm_write(clk->map, &vclk->enable, 0);
> +}
> +
> +static int meson_vclk_gate_is_enabled(struct clk_hw *hw)
> +{
> + struct clk_regmap *clk = to_clk_regmap(hw);
> + struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
> +
> + return meson_parm_read(clk->map, &vclk->enable);
> +}
> +
> +const struct clk_ops meson_vclk_gate_ops = {
> + .enable = meson_vclk_gate_enable,
> + .disable = meson_vclk_gate_disable,
> + .is_enabled = meson_vclk_gate_is_enabled,
> +};
> +EXPORT_SYMBOL_GPL(meson_vclk_gate_ops);
> +
> +/* The VCLK Divider has supplementary reset & enable bits */
> +
> +static inline struct meson_vclk_div_data *
> +clk_get_meson_vclk_div_data(struct clk_regmap *clk)
> +{
> + return (struct meson_vclk_div_data *)clk->data;
> +}
> +
> +static unsigned long meson_vclk_div_recalc_rate(struct clk_hw *hw,
> + unsigned long prate)
> +{
> + struct clk_regmap *clk = to_clk_regmap(hw);
> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
> +
> + return divider_recalc_rate(hw, prate, meson_parm_read(clk->map, &vclk->div),
> + vclk->table, vclk->flags, vclk->div.width);
> +}
> +
> +static int meson_vclk_div_determine_rate(struct clk_hw *hw,
> + struct clk_rate_request *req)
> +{
> + struct clk_regmap *clk = to_clk_regmap(hw);
> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
> +
> + return divider_determine_rate(hw, req, vclk->table, vclk->div.width,
> + vclk->flags);
> +}
> +
> +static int meson_vclk_div_set_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long parent_rate)
> +{
> + struct clk_regmap *clk = to_clk_regmap(hw);
> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
> + int ret;
> +
> + ret = divider_get_val(rate, parent_rate, vclk->table, vclk->div.width,
> + vclk->flags);
> + if (ret < 0)
> + return ret;
> +
> + meson_parm_write(clk->map, &vclk->div, ret);
> +
> + return 0;
> +};
> +
> +static int meson_vclk_div_enable(struct clk_hw *hw)
> +{
> + struct clk_regmap *clk = to_clk_regmap(hw);
> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
> +
> + /* Unreset the divider when ungating */
> + meson_parm_write(clk->map, &vclk->reset, 0);
> + meson_parm_write(clk->map, &vclk->enable, 1);
> +
> + return 0;
> +}
> +
> +static void meson_vclk_div_disable(struct clk_hw *hw)
> +{
> + struct clk_regmap *clk = to_clk_regmap(hw);
> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
> +
> + /* Reset the divider when gating */
> + meson_parm_write(clk->map, &vclk->enable, 0);
> + meson_parm_write(clk->map, &vclk->reset, 1);
> +}
> +
> +static int meson_vclk_div_is_enabled(struct clk_hw *hw)
> +{
> + struct clk_regmap *clk = to_clk_regmap(hw);
> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
> +
> + return meson_parm_read(clk->map, &vclk->enable);
> +}
> +
> +const struct clk_ops meson_vclk_div_ops = {
> + .recalc_rate = meson_vclk_div_recalc_rate,
> + .determine_rate = meson_vclk_div_determine_rate,
> + .set_rate = meson_vclk_div_set_rate,
> + .enable = meson_vclk_div_enable,
> + .disable = meson_vclk_div_disable,
> + .is_enabled = meson_vclk_div_is_enabled,
> +};
> +EXPORT_SYMBOL_GPL(meson_vclk_div_ops);
> +
> +MODULE_DESCRIPTION("Amlogic vclk clock driver");
> +MODULE_AUTHOR("Neil Armstrong <neil.armstrong@linaro.org>");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/clk/meson/vclk.h b/drivers/clk/meson/vclk.h
> new file mode 100644
> index 000000000000..20b0b181db09
> --- /dev/null
> +++ b/drivers/clk/meson/vclk.h
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) 2024 Neil Armstrong <neil.armstrong@linaro.org>
> + */
> +
> +#ifndef __VCLK_H
> +#define __VCLK_H
> +
> +#include "clk-regmap.h"
> +#include "parm.h"
> +
> +/**
> + * struct meson_vclk_gate_data - vclk_gate regmap backed specific data
> + *
> + * @enable: vclk enable field
> + * @reset: vclk reset field
> + * @flags: hardware-specific flags
> + *
> + * Flags:
> + * Same as clk_gate except CLK_GATE_HIWORD_MASK which is ignored
> + */
> +struct meson_vclk_gate_data {
> + struct parm enable;
> + struct parm reset;
> + u8 flags;
> +};
> +
> +extern const struct clk_ops meson_vclk_gate_ops;
> +
> +/**
> + * struct meson_vclk_div_data - vclk_div regmap back specific data
> + *
> + * @div: divider field
> + * @enable: vclk divider enable field
> + * @reset: vclk divider reset field
> + * @table: array of value/divider pairs, last entry should have div = 0
> + *
> + * Flags:
> + * Same as clk_divider except CLK_DIVIDER_HIWORD_MASK which is ignored
> + */
> +struct meson_vclk_div_data {
> + struct parm div;
> + struct parm enable;
> + struct parm reset;
> + const struct clk_div_table *table;
> + u8 flags;
> +};
> +
> +extern const struct clk_ops meson_vclk_div_ops;
> +
> +#endif /* __VCLK_H */
--
Jerome
^ permalink raw reply
* Re: [PATCH v3 0/6] Add Synopsys DesignWare HDMI RX Controller
From: Krzysztof Kozlowski @ 2024-04-04 8:22 UTC (permalink / raw)
To: Heiko Stübner, Shreeya Patel
Cc: mchehab, hverkuil, hverkuil-cisco, robh, krzysztof.kozlowski+dt,
conor+dt, mturquette, sboyd, p.zabel, shawn.wen, kernel,
linux-kernel, linux-media, devicetree, linux-arm-kernel,
linux-rockchip, linux-clk, linux-arm
In-Reply-To: <28071718.gRfpFWEtPU@diego>
On 04/04/2024 10:19, Heiko Stübner wrote:
> Am Donnerstag, 4. April 2024, 08:15:50 CEST schrieb Krzysztof Kozlowski:
>> On 04/04/2024 00:48, Heiko Stübner wrote:
>>> Am Mittwoch, 3. April 2024, 13:24:05 CEST schrieb Krzysztof Kozlowski:
>>>> On 03/04/2024 13:20, Shreeya Patel wrote:
>>>>> On Wednesday, April 03, 2024 15:51 IST, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
>>>>>
>>>>>> On 03/04/2024 11:24, Shreeya Patel wrote:
>>>>>>> On Thursday, March 28, 2024 04:20 IST, Shreeya Patel <shreeya.patel@collabora.com> wrote:
>>>>>>>
>>>>>>>> This series implements support for the Synopsys DesignWare
>>>>>>>> HDMI RX Controller, being compliant with standard HDMI 1.4b
>>>>>>>> and HDMI 2.0.
>>>>>>>>
>>>>>>>
>>>>>>> Hi Mauro and Hans,
>>>>>>>
>>>>>>> I haven't received any reviews so far. Hence, this is just a gentle reminder to review this patch series.
>>>>>>
>>>>>> Why did you put clk changes here? These go via different subsystem. That
>>>>>> might be one of obstacles for your patchset.
>>>>>>
>>>>>
>>>>> I added clock changes in this patch series because HDMIRX driver depends on it.
>>>>> I thought it is wrong to send the driver patches which don't even compile?
>>>>
>>>> Hm, why HDMIRX driver depends on clock? How? This sounds really wrong.
>>>> Please get it reviewed internally first.
>>>
>>> For the change in question, the clock controller on the soc also handles
>>> the reset controls (hence its name CRU, clock-and-reset-unit) .
>>>
>>> There are at least 660 reset lines in the unit and it seems the hdmi-rx one
>>> was overlooked on the initial submission, hence patches 1+2 add the
>>> reset-line.
>>>
>>> Of course, here only the "arm64: dts:" patch depends on the clock
>>> change, is it references the new reset-id.
>>
>> Wait, that's expected, but it is not what was written. Claim was HDMIRX
>> driver depends *build time* ("don't even compile").
>
> Trying to do a full build (kernel + dts) will fail, because the the
> device-tree patch references the newly added reset-id .
>
> So you end up with a dtc error. Same with the binding.
Which is quite expected, nothing special, most patchsets have exactly
the same dependency. It's not a HDMIRX driver dependency. It's DTS and
clock provider on the binding header, not clock consumer.
We solved it many times and different SoC subsystems have their own
guidelines. Putting here media is not the right approach and not justified.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: syscon: Add ti,am62p-cpsw-mac-efuse compatible
From: Siddharth Vadapalli @ 2024-04-04 8:32 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Siddharth Vadapalli, lee, robh, krzk+dt, conor+dt, devicetree,
linux-kernel, linux-arm-kernel, srk
In-Reply-To: <9bca7d94-142e-4717-aea7-437805717a00@ti.com>
On Wed, Apr 03, 2024 at 12:18:10PM +0530, Siddharth Vadapalli wrote:
> On Wed, Apr 03, 2024 at 08:40:19AM +0200, Krzysztof Kozlowski wrote:
> > On 03/04/2024 08:32, Siddharth Vadapalli wrote:
> > > On Wed, Apr 03, 2024 at 08:27:06AM +0200, Krzysztof Kozlowski wrote:
> > >> On 03/04/2024 07:35, Siddharth Vadapalli wrote:
> > >>> On Tue, Apr 02, 2024 at 08:06:27PM +0200, Krzysztof Kozlowski wrote:
> > >>>> On 02/04/2024 14:30, Siddharth Vadapalli wrote:
> > >>>>> On Tue, Apr 02, 2024 at 02:08:32PM +0200, Krzysztof Kozlowski wrote:
> > >>>>>> On 02/04/2024 12:57, Siddharth Vadapalli wrote:
> > >>>>>>> The CTRLMMR_MAC_IDx registers within the CTRL_MMR space of TI's AM62p SoC
> > >>>>>>> contain the MAC Address programmed in the eFuse. Add compatible for
> > >>>>>>> allowing the CPSW driver to obtain a regmap for the CTRLMMR_MAC_IDx
> > >>>>>>> registers within the System Controller device-tree node. The default MAC
> > >>>>>>> Address for the interface corresponding to the first MAC port will be set
> > >>>>>>> to the value programmed in the eFuse.
> > >>>>>>>
> > >>>>>>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> > >>>>>>> ---
> > >>>>>>>
> > >>>>>>> This patch is based on linux-next tagged next-20240402.
> > >>>>>>
> > >>>>>> Where is the DTS using it?
> > >>>>>
> > >>>>> The current implementation in the device-tree for older TI K3 SoCs is as
> > >>>>> follows:
> > >>>>>
> > >>>>> cpsw_port1: port@1 {
> > >>>>> reg = <1>;
> > >>>>> ti,mac-only;
> > >>>>> label = "port1";
> > >>>>> phys = <&phy_gmii_sel 1>;
> > >>>>> mac-address = [00 00 00 00 00 00];
> > >>>>> ti,syscon-efuse = <&wkup_conf 0x200>;
> > >>>>> };
> > >>>>>
> > >>>>> The "ti,syscon-efuse" property passes the reference to the System
> > >>>>> Controller node as well as the offset to the CTRLMMR_MAC_IDx registers
> > >>>>> within the CTRL_MMR space.
> > >>>>
> > >>>> Please reference upstream DTS or lore link to patch under review.
> > >>>
> > >>> An example of the existing implementation in the device-tree for AM64x
> > >>> is:
> > >>> https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L697
> > >>> It uses:
> > >>> ti,syscon-efuse = <&main_conf 0x200>;
> > >>>
> > >>> and "main_conf" node is defined at:
> > >>> https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L40
> > >>
> > >> It is quite different than your bindings, so your bindings are incorrect.
> > >
> > > Sorry I didn't understand what you mean. The references I have provided
> > > are for existing DTS where "main_conf"/"wkup_conf" (System Controller
> > > nodes) have the compatible "syscon", unlike in AM62p at:
> > > https://github.com/torvalds/linux/blob/20f8173afaac90dd9dca11be4aa602a47776077f/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi#L8
> > > which has the "simple-bus" compatible for the "wkup_conf" node.
> > >
> > > Also, shouldn't the device-tree bindings patches be posted first and get
> > > merged before I post the device-tree patches that utilize the
> > > compatible/properties that have been added in the bindings? That is the
> > > reason why I had shared the "DIFF" for the DTS changes that I will be
> > > posting once this patch for the new compatible is accepted.
> > >
> >
> > That's not the process. I will be NAKing bindings which do not have any
> > users, because I do not trust you test them.
> >
> > The process is almost always:
> > 1. Send bindings,
> > 2. Send driver changes (if applicable) in the same patchset.
> > 3. Send DTS, usually in separate patches and provide lore link to the
> > bindings in the changelog or cover letter.
>
> Thank you for clarifying. I will post the DTS patches corresponding to
> this patch and reference this patch in the DTS patch series.
I have posted the DTS patch at:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20240404081845.622707-1-s-vadapalli@ti.com/
indicating the dependency on this bindings patch.
Regards,
Siddharth.
^ permalink raw reply
* Re: [PATCH] arm64: dts: ti: k3-am62p-main: use eFuse MAC Address for CPSW3G Port 1
From: Siddharth Vadapalli @ 2024-04-04 8:34 UTC (permalink / raw)
To: Vignesh Raghavendra
Cc: Siddharth Vadapalli, nm, kristo, robh, krzysztof.kozlowski+dt,
conor+dt, devicetree, linux-kernel, linux-arm-kernel, srk
In-Reply-To: <f7cadda8-c3cf-48a0-846a-1ff317a28292@ti.com>
On Tue, Apr 02, 2024 at 04:02:07PM +0530, Siddharth Vadapalli wrote:
> On Tue, Apr 02, 2024 at 03:25:41PM +0530, Vignesh Raghavendra wrote:
> >
> >
> > On 02/04/24 15:12, Siddharth Vadapalli wrote:
> > > Assign the MAC Address programmed in the eFuse registers as the default
> > > MAC Address for CPSW3G MAC Port 1. Utilize the "ti,syscon-efuse"
> > > device-tree property to do so.
> > >
> > > Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> > > ---
> > >
> > > This patch is based on linux-next tagged next-20240402.
> > >
> > > Regards,
> > > Siddharth.
> > >
> > > arch/arm64/boot/dts/ti/k3-am62p-main.dtsi | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
> > > index 7337a9e13535..eb126f4a04dd 100644
> > > --- a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
> > > +++ b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
> > > @@ -696,6 +696,7 @@ cpsw_port1: port@1 {
> > > label = "port1";
> > > phys = <&phy_gmii_sel 1>;
> > > mac-address = [00 00 00 00 00 00];
> > > + ti,syscon-efuse = <&wkup_conf 0x200>;
> >
> > Sorry, how does this work? wkup_conf is not marked as "syscon" compatible?
>
> Sorry I failed to realize that. So this will also require adding a
> custom property similar to:
> https://github.com/torvalds/linux/commit/cc1965b02d6cb18d9220dae06f7e2e0b0ebbea48
> followed by adding a new sub-node within wkup_conf corresponding to the
> MAC Address CTRL_MMR registers.
>
> Thank you for reviewing the patch and pointing this out.
I have posted the v2 patch at:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20240404081845.622707-1-s-vadapalli@ti.com/
verifying that the MAC Address present in the CTRLMMR_MAC_IDx registers
is assigned to the network interface corresponding to CPSW3G MAC Port 1.
Regards,
Siddharth.
^ permalink raw reply
* [PATCH 2/2] arm64: dts: rockchip: add Protonic MECSBC device-tree
From: Sascha Hauer @ 2024-04-04 8:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
David Jander, Sascha Hauer
In-Reply-To: <20240404-protonic-mecsbc-v1-0-ad5b42ade6c6@pengutronix.de>
From: David Jander <david@protonic.nl>
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.
Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
arch/arm64/boot/dts/rockchip/rk3568-mecsbc.dts | 394 +++++++++++++++++++++++++
2 files changed, 395 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index f906a868b71ac..1152e0f6a25cb 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -104,6 +104,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-nanopi-r5c.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-nanopi-r5s.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-odroid-m1.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-qnap-ts433.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-mecsbc.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-radxa-e25.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-roc-pc.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-rock-3a.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-mecsbc.dts b/arch/arm64/boot/dts/rockchip/rk3568-mecsbc.dts
new file mode 100644
index 0000000000000..e50d135042ec7
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568-mecsbc.dts
@@ -0,0 +1,394 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/pwm/pwm.h>
+#include "rk3568.dtsi"
+
+/ {
+ model = "Protonic MECSBC";
+ compatible = "prt,mecsbc", "rockchip,rk3568";
+
+ aliases {
+ mmc0 = &sdhci;
+ mmc1 = &sdmmc0;
+ };
+
+ chosen: chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+
+ tas2562-sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,name = "Speaker";
+ simple-audio-card,mclk-fs = <256>;
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s1_8ch>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&tas2562>;
+ };
+ };
+
+ vdd_gpu: regulator-vdd-gpu {
+ compatible = "pwm-regulator";
+ pwms = <&pwm1 0 5000 PWM_POLARITY_INVERTED>;
+ regulator-name = "vdd_gpu";
+ regulator-min-microvolt = <915000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-settling-time-up-us = <250>;
+ pwm-dutycycle-range = <0 100>; /* dutycycle inverted 0% => 0.915V */
+ };
+
+ vdd_npu: regulator-vdd-npu {
+ compatible = "pwm-regulator";
+ pwms = <&pwm2 0 5000 PWM_POLARITY_INVERTED>;
+ regulator-name = "vdd_npu";
+ regulator-min-microvolt = <915000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-settling-time-up-us = <250>;
+ pwm-dutycycle-range = <0 100>; /* dutycycle inverted 0% => 0.915V */
+ };
+
+ p3v3: p3v3-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "p3v3";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ p1v8: p1v8-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "p1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+};
+
+&combphy0 {
+ status = "okay";
+};
+
+&combphy1 {
+ status = "okay";
+};
+
+&combphy2 {
+ status = "okay";
+};
+
+&cpu0 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&cpu1 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&cpu2 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&cpu3 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&gmac1 {
+ assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>;
+ assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>, <&cru CLK_MAC1_2TOP>;
+ phy-handle = <&rgmii_phy1>;
+ phy-mode = "rgmii";
+ clock_in_out = "output";
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac1m1_miim
+ &gmac1m1_tx_bus2
+ &gmac1m1_rx_bus2
+ &gmac1m1_rgmii_clk
+ &gmac1m1_clkinout
+ &gmac1m1_rgmii_bus>;
+ status = "okay";
+ tx_delay = <0x30>;
+ rx_delay = <0x10>;
+};
+
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ vdd_cpu: regulator@60 {
+ compatible = "fcs,fan53555";
+ reg = <0x60>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-name = "vdd_cpu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1150000>;
+ regulator-ramp-delay = <2300>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+};
+
+&i2c2 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2m0_xfer>;
+};
+
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3m0_xfer>;
+ status = "okay";
+
+ tas2562: tas2562@4c {
+ compatible = "ti,tas2562";
+ reg = <0x4c>;
+ #sound-dai-cells = <0>;
+ shutdown-gpios = <&gpio1 RK_PD4 GPIO_ACTIVE_HIGH>;
+ interrupt-parent = <&gpio1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tas2562>;
+ interrupts = <RK_PD1 IRQ_TYPE_LEVEL_LOW>;
+ ti,imon-slot-no = <0>;
+ };
+};
+
+&i2c5 {
+ status = "okay";
+
+ tmp1075n@48 {
+ compatible = "ti,tmp1075";
+ reg = <0x48>;
+ };
+
+ pcf8563: rtc@51 {
+ compatible = "nxp,pcf85363";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ clock-output-names = "rtcic_32kout";
+ };
+};
+
+&i2s1_8ch {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s1m0_sclktx &i2s1m0_lrcktx &i2s1m0_sdi0 &i2s1m0_sdo0>;
+ rockchip,trcm-sync-tx-only;
+ status = "okay";
+};
+
+&mdio1 {
+ rgmii_phy1: ethernet-phy@2 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0x2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <ð_phy1_rst>;
+ reset-assert-us = <20000>;
+ reset-deassert-us = <100000>;
+ reset-gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&pcie2x1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie20m1_pins>;
+ reset-gpios = <&gpio3 RK_PC1 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+};
+
+&pcie30phy {
+ status = "okay";
+};
+
+&pcie3x2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie30x2m1_pins>;
+ reset-gpios = <&gpio2 RK_PD6 GPIO_ACTIVE_HIGH>;
+ vpcie3v3-supply = <&p3v3>;
+ status = "okay";
+};
+
+&pinctrl {
+ ethernet {
+ eth_phy1_rst: eth_phy1_rst {
+ rockchip,pins = <4 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ tas2562 {
+ pinctrl_tas2562: tas2562 {
+ rockchip,pins = <1 RK_PD4 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+};
+
+&pmu_io_domains {
+ pmuio1-supply = <&p3v3>;
+ pmuio2-supply = <&p3v3>;
+ vccio1-supply = <&p1v8>;
+ vccio2-supply = <&p1v8>;
+ vccio3-supply = <&p3v3>;
+ vccio4-supply = <&p1v8>;
+ vccio5-supply = <&p3v3>;
+ vccio6-supply = <&p1v8>;
+ vccio7-supply = <&p3v3>;
+ status = "okay";
+};
+
+&saradc {
+ vref-supply = <&p1v8>;
+ status = "okay";
+};
+
+&sdhci {
+ bus-width = <8>;
+ max-frequency = <200000000>;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>;
+ vmmc-supply = <&p3v3>;
+ vqmmc-supply = <&p1v8>;
+ mmc-hs200-1_8v;
+ non-removable;
+ no-sd;
+ no-sdio;
+ status = "okay";
+};
+
+&sdmmc0 {
+ bus-width = <4>;
+ cap-sd-highspeed;
+ cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
+ disable-wp;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc0_bus4 &sdmmc0_clk &sdmmc0_cmd &sdmmc0_det>;
+ sd-uhs-sdr50;
+ vmmc-supply = <&p3v3>;
+ vqmmc-supply = <&p3v3>;
+ status = "okay";
+};
+
+&tsadc {
+ rockchip,hw-tshut-mode = <1>;
+ rockchip,hw-tshut-polarity = <0>;
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&usb_host0_ehci {
+ status = "okay";
+};
+
+&usb_host0_ohci {
+ status = "okay";
+};
+
+&usb_host0_xhci {
+ extcon = <&usb2phy0>;
+ status = "okay";
+ dr_mode = "host";
+};
+
+&usb_host1_ehci {
+ status = "okay";
+};
+
+&usb_host1_ohci {
+ status = "okay";
+};
+
+&usb_host1_xhci {
+ status = "okay";
+};
+
+&usb2phy0 {
+ status = "okay";
+};
+
+&usb2phy0_host {
+ status = "okay";
+};
+
+&usb2phy0_otg {
+ status = "okay";
+};
+
+&usb2phy1 {
+ status = "okay";
+};
+
+&usb2phy1_host {
+ status = "okay";
+};
+
+&usb2phy1_otg {
+ status = "okay";
+};
+
+&pwm1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm1m0_pins>;
+};
+
+&pwm2 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm2m0_pins>;
+};
+
+&gpu_opp_table {
+ compatible = "operating-points-v2";
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ opp-microvolt = <915000>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ opp-microvolt = <915000>;
+ };
+
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-microvolt = <915000>;
+ };
+
+ opp-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <920000>;
+ };
+
+ opp-700000000 {
+ opp-hz = /bits/ 64 <700000000>;
+ opp-microvolt = <950000>;
+ };
+
+ opp-800000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-microvolt = <1000000>;
+ };
+};
--
2.39.2
^ permalink raw reply related
* [PATCH 0/2] Add Protonic MECSBC board support
From: Sascha Hauer @ 2024-04-04 8:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
David Jander, Sascha Hauer
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.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
David Jander (1):
arm64: dts: rockchip: add Protonic MECSBC device-tree
Sascha Hauer (1):
dt-bindings: arm: rockchip: Add Protonic MECSBC board
.../devicetree/bindings/arm/rockchip.yaml | 5 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
arch/arm64/boot/dts/rockchip/rk3568-mecsbc.dts | 394 +++++++++++++++++++++
3 files changed, 400 insertions(+)
---
base-commit: 39cd87c4eb2b893354f3b850f916353f2658ae6f
change-id: 20240404-protonic-mecsbc-6cfa56a48fb7
Best regards,
--
Sascha Hauer <s.hauer@pengutronix.de>
^ permalink raw reply
* [PATCH 1/2] dt-bindings: arm: rockchip: Add Protonic MECSBC board
From: Sascha Hauer @ 2024-04-04 8:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
David Jander, Sascha Hauer
In-Reply-To: <20240404-protonic-mecsbc-v1-0-ad5b42ade6c6@pengutronix.de>
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.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index fcf7316ecd74c..4847fe072d550 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -700,6 +700,11 @@ properties:
- powkiddy,x55
- const: rockchip,rk3566
+ - description: Protonic MECSBC board
+ items:
+ - const: prt,mecsbc
+ - const: rockchip,rk3568
+
- description: QNAP TS-433-4G 4-Bay NAS
items:
- const: qnap,ts433
--
2.39.2
^ permalink raw reply related
* Re: [PATCH net-next v6 11/17] dt-bindings: net: pse-pd: Add another way of describing several PSE PIs
From: Kory Maincent @ 2024-04-04 8:38 UTC (permalink / raw)
To: Rob Herring
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Krzysztof Kozlowski,
Conor Dooley, Oleksij Rempel, Mark Brown, Frank Rowand,
Andrew Lunn, Heiner Kallweit, Russell King, Thomas Petazzoni,
netdev, linux-kernel, linux-doc, devicetree, Dent Project
In-Reply-To: <20240403143142.GA3508225-robh@kernel.org>
On Wed, 3 Apr 2024 09:31:42 -0500
Rob Herring <robh@kernel.org> wrote:
> On Wed, Apr 03, 2024 at 11:15:48AM +0200, Kory Maincent wrote:
> > On Tue, 2 Apr 2024 08:26:37 -0500
> > Rob Herring <robh@kernel.org> wrote:
> >
> > > > + pairset-names:
> > > > + $ref: /schemas/types.yaml#/definitions/string-array
> > > > + description:
> > > > + Names of the pairsets as per IEEE 802.3-2022, Section
> > > > 145.2.4.
> > > > + Valid values are "alternative-a" and "alternative-b".
> > > > Each name
> > >
> > > Don't state constraints in prose which are defined as schema
> > > constraints.
> >
> > Ok, I will remove the line.
> >
> > > > + pairsets:
> > > > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > > > + description:
> > > > + List of phandles, each pointing to the power supply for
> > > > the
> > > > + corresponding pairset named in 'pairset-names'. This
> > > > property
> > > > + aligns with IEEE 802.3-2022, Section 33.2.3 and 145.2.4.
> > > > + PSE Pinout Alternatives (as per IEEE 802.3-2022 Table
> > > > 145\u20133)
> > > > +
> > > > |-----------|---------------|---------------|---------------|---------------|
> > > > + | Conductor | Alternative A | Alternative A |
> > > > Alternative B | Alternative B |
> > > > + | | (MDI-X) | (MDI) | (X)
> > > > | (S) |
> > > > +
> > > > |-----------|---------------|---------------|---------------|---------------|
> > > > + | 1 | Negative VPSE | Positive VPSE | \u2014
> > > > | \u2014 |
> > > > + | 2 | Negative VPSE | Positive VPSE | \u2014
> > > > | \u2014 |
> > > > + | 3 | Positive VPSE | Negative VPSE | \u2014
> > > > | \u2014 |
> > > > + | 4 | \u2014 | \u2014 |
> > > > Negative VPSE | Positive VPSE |
> > > > + | 5 | \u2014 | \u2014 |
> > > > Negative VPSE | Positive VPSE |
> > > > + | 6 | Positive VPSE | Negative VPSE | \u2014
> > > > | \u2014 |
> > > > + | 7 | \u2014 | \u2014 |
> > > > Positive VPSE | Negative VPSE |
> > > > + | 8 | \u2014 | \u2014 |
> > > > Positive VPSE | Negative VPSE |
> > > > + minItems: 1
> > > > + maxItems: 2
> > >
> > > "pairsets" does not follow the normal design pattern of foos, foo-names,
> > > and #foo-cells. You could add #foo-cells I suppose, but what would cells
> > > convey? I don't think it's a good fit for what you need.
> > >
> > > The other oddity is the number of entries and the names are fixed. That
> > > is usually defined per consumer.
> >
> > Theoretically if the RJ45 port binding was supported it would make more
> > sense, but in reality it's not feasible as the PSE controller need this
> > information in its init process.
> > The PSE controller reset all its port to apply a configuration so we can't
> > do it when the consumer (RJ45) probe. It would reset the other ports if one
> > consumer is probed later in the process.
>
> There is no reason other than convenience that all information some
> driver needs has to be in one node or one hierarchy of nodes. You can
> fetch anything from anywhere in the DT. It does feel like some of this
> belongs in a connector node. We often haven't described connectors in DT
> and stick connector properties in the controller node associated with
> the connector. Then as things get more complicated, it becomes a mess.
Right, we could indeed put all the informations of the pse_pi node in the future
RJ45 port abstraction node. Then, this series will be put aside until we manage
to have the port abstraction get merged.
I am not glad about this as it will stuck my work until then, but indeed
removing this pse_pi wrapper node which is between the pse_controller node and
the connector node seems cleaner.
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: clock: airoha: add EN7581 binding
From: Lorenzo Bianconi @ 2024-04-04 8:43 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-clk, mturquette, sboyd, linux-arm-kernel, robh+dt,
krzysztof.kozlowski+dt, conor+dt, nbd, john, devicetree, dd,
catalin.marinas, will, upstream, lorenzo.bianconi83,
angelogioacchino.delregno
In-Reply-To: <65e7617a-9e7b-4dea-a98c-31502222543a@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1769 bytes --]
> On 03/04/2024 18:20, Lorenzo Bianconi wrote:
> > Introduce Airoha EN7581 entry in Airoha EN7523 clock binding
> >
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > ---
> > .../bindings/clock/airoha,en7523-scu.yaml | 26 +++++++++++++++++--
> > 1 file changed, 24 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml b/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml
> > index 79b0752faa91..cf893d4c74cd 100644
> > --- a/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml
> > +++ b/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml
> > @@ -29,10 +29,13 @@ description: |
> > properties:
> > compatible:
> > items:
> > - - const: airoha,en7523-scu
> > + - enum:
> > + - airoha,en7523-scu
> > + - airoha,en7581-scu
> >
> > reg:
> > - maxItems: 2
> > + minItems: 2
> > + maxItems: 3
> >
> > "#clock-cells":
> > description:
> > @@ -45,6 +48,25 @@ required:
> > - reg
> > - '#clock-cells'
> >
> > +allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + const: airoha,en7523-scu
> > + then:
> > + properties:
> > + reg:
> > + maxItems: 2
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + const: airoha,en7581-scu
> > + then:
> > + properties:
> > + reg:
> > + maxItems: 3
>
> Original code had here issue - lack of description of the items. You are
> now growing it. Please instead list the items (items: - description: foo
> bar .....).
ack, I will fix it.
Regards,
Lorenzo
>
> Best regards,
> Krzysztof
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: ti: k3-am62p: use eFuse MAC Address for CPSW3G Port 1
From: Krzysztof Kozlowski @ 2024-04-04 8:43 UTC (permalink / raw)
To: Siddharth Vadapalli, nm, vigneshr, kristo, robh, krzk+dt,
conor+dt
Cc: devicetree, linux-kernel, linux-arm-kernel, srk
In-Reply-To: <20240404081845.622707-1-s-vadapalli@ti.com>
On 04/04/2024 10:18, Siddharth Vadapalli wrote:
> Add the "cpsw-mac-efuse" node within "wkup_conf" node corresponding to the
> CTRLMMR_MAC_IDx registers within the CTRL_MMR space. Assign the compatible
> "ti,am62p-cpsw-mac-efuse" to enable "syscon_regmap" operations on these
> registers. The MAC Address programmed in the eFuse is accessible through
> the CTRLMMR_MAC_IDx registers. The "ti,syscon-efuse" device-tree property
> points to the CTRLMMR_MAC_IDx registers, allowing the CPSW driver to fetch
> the MAC Address and assign it to the network interface associated with
> CPSW3G MAC Port 1.
>
> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> ---
>
> This patch is based on linux-next tagged next-20240404.
> Patch depends on:
> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20240402105708.4114146-1-s-vadapalli@ti.com/
> for the newly added "ti,am62p-cpsw-mac-efuse" compatible.
>
> v1:
> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20240402094200.4036076-1-s-vadapalli@ti.com/
> Changes since v1:
> - Since "wkup_conf" is modelled as a "simple-bus" rather than being
And maybe the hardware representation is not correct? What bus is it?
> modelled as a System Controller node with the "syscon" compatible,
> directly passing the reference to the "wkup_conf" node using the
> "ti,syscon-efuse" device-tree property will not work.
> Therefore, I posted the patch at:
> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20240402105708.4114146-1-s-vadapalli@ti.com/
> in order to add a new compatible to be used for modelling the
> CTRLMMR_MAC_IDx registers as System Controller nodes, thereby
> allowing the existing "ti,syscon-efuse" property to be used.
> Now, "ti,syscon-efuse" points to the "cpsw_mac_efuse" node within
> "wkup_conf" node, with "cpsw_mac_efuse" being a "syscon" node.
>
> Logs verifying that the CPSW driver assigns the MAC Address from the
> eFuse based on the CTRLMMR_MAC_IDx registers at 0x43000200 and 0x43000204
> to the interface eth0 corresponding to CPSW3G MAC Port 1:
> https://gist.github.com/Siddharth-Vadapalli-at-TI/9982c6f13bf9b8cfaf97e8517e7dea13
>
> Regards,
> Siddharth.
>
> arch/arm64/boot/dts/ti/k3-am62p-main.dtsi | 1 +
> arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi | 5 +++++
> 2 files changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
> index 7337a9e13535..848ca454a411 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
> @@ -696,6 +696,7 @@ cpsw_port1: port@1 {
> label = "port1";
> phys = <&phy_gmii_sel 1>;
> mac-address = [00 00 00 00 00 00];
> + ti,syscon-efuse = <&cpsw_mac_efuse 0x0>;
Why this is not nvmem cell, like or efuses?
> };
>
> cpsw_port2: port@2 {
> diff --git a/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi
> index a84756c336d0..df9d40f64e3b 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi
> @@ -18,6 +18,11 @@ chipid: chipid@14 {
> reg = <0x14 0x4>;
> bootph-all;
> };
> +
> + cpsw_mac_efuse: cpsw-mac-efuse@200 {
Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
> + compatible = "ti,am62p-cpsw-mac-efuse", "syscon";
> + reg = <0x200 0x8>;
> + };
> };
>
> wkup_uart0: serial@2b300000 {
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 0/2] Add support for QCM6490 and QCS6490
From: Mohammad Rafi Shaik @ 2024-04-04 8:46 UTC (permalink / raw)
To: Srinivas Kandagatla, Banajit Goswami, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela,
Takashi Iwai
Cc: linux-arm-msm, alsa-devel, linux-sound, devicetree, linux-kernel,
quic_rohkumar, Mohammad Rafi Shaik
This patchset adds support for sound card on Qualcomm QCM6490 IDP and
QCS6490 RB3Gen2 boards.
Changes since v1:
- Use existing sc8280xp machine driver instead of separate driver.
- Modify qcs6490 compatible name as qcs6490-rb3gen2.
Mohammad Rafi Shaik (2):
ASoC: dt-bindings: qcom,sm8250: Add QCM6490 snd QCS6490 sound card
ASoC: qcom: sc8280xp: Add support for QCM6490 and QCS6490
Documentation/devicetree/bindings/sound/qcom,sm8250.yaml | 2 ++
sound/soc/qcom/sc8280xp.c | 2 ++
2 files changed, 4 insertions(+)
--
2.25.1
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: rockchip: Add Protonic MECSBC board
From: Krzysztof Kozlowski @ 2024-04-04 8:47 UTC (permalink / raw)
To: Sascha Hauer, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
David Jander
In-Reply-To: <20240404-protonic-mecsbc-v1-1-ad5b42ade6c6@pengutronix.de>
On 04/04/2024 10:34, Sascha Hauer wrote:
> 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.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 1/2] ASoC: dt-bindings: qcom,sm8250: Add QCM6490 snd QCS6490 sound card
From: Mohammad Rafi Shaik @ 2024-04-04 8:46 UTC (permalink / raw)
To: Srinivas Kandagatla, Banajit Goswami, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela,
Takashi Iwai
Cc: linux-arm-msm, alsa-devel, linux-sound, devicetree, linux-kernel,
quic_rohkumar, Mohammad Rafi Shaik
In-Reply-To: <20240404084631.417779-1-quic_mohs@quicinc.com>
Document the bindings for the Qualcomm QCM6490 IDP and QCS6490 RB3Gen2
soc platforms sound card.
The bindings are the same as for other newer Qualcomm ADSP sound cards,
thus keep them in existing qcom,sm8250.yaml file, even though Linux driver
is separate.
Signed-off-by: Mohammad Rafi Shaik <quic_mohs@quicinc.com>
---
Documentation/devicetree/bindings/sound/qcom,sm8250.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
index 2ab6871e89e5..ff1a27f26bc2 100644
--- a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
@@ -29,6 +29,8 @@ properties:
- enum:
- qcom,apq8016-sbc-sndcard
- qcom,msm8916-qdsp6-sndcard
+ - qcom,qcm6490-sndcard
+ - qcom,qcs6490-rb3gen2-sndcard
- qcom,qrb5165-rb5-sndcard
- qcom,sc7180-qdsp6-sndcard
- qcom,sc8280xp-sndcard
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 2/4] arm64: dts: airoha: Add EN7581 clock node
From: AngeloGioacchino Del Regno @ 2024-04-04 8:47 UTC (permalink / raw)
To: Lorenzo Bianconi, linux-clk
Cc: mturquette, sboyd, linux-arm-kernel, robh+dt,
krzysztof.kozlowski+dt, conor+dt, nbd, john, devicetree, dd,
catalin.marinas, will, upstream, lorenzo.bianconi83
In-Reply-To: <8465b7562bcf53a0adfdd4ae01b3ed94d6d5bc54.1712160869.git.lorenzo@kernel.org>
Il 03/04/24 18:20, Lorenzo Bianconi ha scritto:
> Introduce the Airoha EN7581 clock node in Airoha EN7581 dtsi
>
> Tested-by: Zhengping Zhang <zhengping.zhang@airoha.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> arch/arm64/boot/dts/airoha/en7581.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/airoha/en7581.dtsi b/arch/arm64/boot/dts/airoha/en7581.dtsi
> index 55eb1762fb11..a1daaaef0de0 100644
> --- a/arch/arm64/boot/dts/airoha/en7581.dtsi
> +++ b/arch/arm64/boot/dts/airoha/en7581.dtsi
> @@ -2,6 +2,7 @@
>
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/clock/en7523-clk.h>
>
> / {
> interrupt-parent = <&gic>;
> @@ -150,5 +151,13 @@ uart1: serial@1fbf0000 {
> interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
> clock-frequency = <1843200>;
> };
> +
> + scu: system-controller@1fa20000 {
Uhm, why is this not a clock-controller but a system-controller?
Cheers,
Angelo
> + compatible = "airoha,en7581-scu";
> + reg = <0x0 0x1fa20000 0x0 0x400>,
> + <0x0 0x1fb00000 0x0 0x1000>,
> + <0x0 0x1fbe3400 0x0 0xfc>;
> + #clock-cells = <1>;
> + };
> };
> };
^ permalink raw reply
* [PATCH v2 2/2] ASoC: qcom: sc8280xp: Add support for QCM6490 and QCS6490
From: Mohammad Rafi Shaik @ 2024-04-04 8:46 UTC (permalink / raw)
To: Srinivas Kandagatla, Banajit Goswami, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela,
Takashi Iwai
Cc: linux-arm-msm, alsa-devel, linux-sound, devicetree, linux-kernel,
quic_rohkumar, Mohammad Rafi Shaik
In-Reply-To: <20240404084631.417779-1-quic_mohs@quicinc.com>
Add compatibles for sound card on Qualcomm QCM6490 IDP and
QCS6490 RB3Gen2 boards.
Signed-off-by: Mohammad Rafi Shaik <quic_mohs@quicinc.com>
---
sound/soc/qcom/sc8280xp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/qcom/sc8280xp.c b/sound/soc/qcom/sc8280xp.c
index b7fd503a1666..09c949e01479 100644
--- a/sound/soc/qcom/sc8280xp.c
+++ b/sound/soc/qcom/sc8280xp.c
@@ -169,6 +169,8 @@ static int sc8280xp_platform_probe(struct platform_device *pdev)
}
static const struct of_device_id snd_sc8280xp_dt_match[] = {
+ {.compatible = "qcom,qcm6490-sndcard", "qcm6490"},
+ {.compatible = "qcom,qcs6490-rb3gen2-sndcard", "qcs6490"},
{.compatible = "qcom,sc8280xp-sndcard", "sc8280xp"},
{.compatible = "qcom,sm8450-sndcard", "sm8450"},
{.compatible = "qcom,sm8550-sndcard", "sm8550"},
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 2/2] arm64: dts: rockchip: add Protonic MECSBC device-tree
From: Krzysztof Kozlowski @ 2024-04-04 8:49 UTC (permalink / raw)
To: Sascha Hauer, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
David Jander
In-Reply-To: <20240404-protonic-mecsbc-v1-2-ad5b42ade6c6@pengutronix.de>
On 04/04/2024 10:34, Sascha Hauer wrote:
> From: David Jander <david@protonic.nl>
>
> 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.
>
> Signed-off-by: David Jander <david@protonic.nl>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
...
> + vdd_gpu: regulator-vdd-gpu {
> + compatible = "pwm-regulator";
> + pwms = <&pwm1 0 5000 PWM_POLARITY_INVERTED>;
> + regulator-name = "vdd_gpu";
> + regulator-min-microvolt = <915000>;
> + regulator-max-microvolt = <1000000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-settling-time-up-us = <250>;
> + pwm-dutycycle-range = <0 100>; /* dutycycle inverted 0% => 0.915V */
> + };
> +
> + vdd_npu: regulator-vdd-npu {
> + compatible = "pwm-regulator";
> + pwms = <&pwm2 0 5000 PWM_POLARITY_INVERTED>;
> + regulator-name = "vdd_npu";
> + regulator-min-microvolt = <915000>;
> + regulator-max-microvolt = <1000000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-settling-time-up-us = <250>;
> + pwm-dutycycle-range = <0 100>; /* dutycycle inverted 0% => 0.915V */
> + };
> +
> + p3v3: p3v3-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "p3v3";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + p1v8: p1v8-regulator {
Please keep consistent naming - your other regulators are
"regulator-foo", not "foo-regulator". The "regulator-foo" is preferred
usually, because it groups devices nicely.
> + compatible = "regulator-fixed";
> + regulator-name = "p1v8";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
...
> +&i2c3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c3m0_xfer>;
> + status = "okay";
> +
> + tas2562: tas2562@4c {
Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
e.g. audio-codec, speaker, amplifier
> + compatible = "ti,tas2562";
> + reg = <0x4c>;
> + #sound-dai-cells = <0>;
> + shutdown-gpios = <&gpio1 RK_PD4 GPIO_ACTIVE_HIGH>;
> + interrupt-parent = <&gpio1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_tas2562>;
> + interrupts = <RK_PD1 IRQ_TYPE_LEVEL_LOW>;
> + ti,imon-slot-no = <0>;
> + };
> +};
> +
> +&i2c5 {
> + status = "okay";
> +
> + tmp1075n@48 {
Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
> + compatible = "ti,tmp1075";
> + reg = <0x48>;
> + };
> +
> + pcf8563: rtc@51 {
> + compatible = "nxp,pcf85363";
> + reg = <0x51>;
> + #clock-cells = <0>;
> + clock-output-names = "rtcic_32kout";
> + };
> +};
> +
...
> +&pcie3x2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pcie30x2m1_pins>;
> + reset-gpios = <&gpio2 RK_PD6 GPIO_ACTIVE_HIGH>;
> + vpcie3v3-supply = <&p3v3>;
> + status = "okay";
> +};
> +
> +&pinctrl {
> + ethernet {
> + eth_phy1_rst: eth_phy1_rst {
No underscores in node names.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] ASoC: dt-bindings: qcom,sm8250: Add QCM6490 snd QCS6490 sound card
From: Dmitry Baryshkov @ 2024-04-04 8:53 UTC (permalink / raw)
To: Mohammad Rafi Shaik
Cc: Srinivas Kandagatla, Banajit Goswami, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela,
Takashi Iwai, linux-arm-msm, alsa-devel, linux-sound, devicetree,
linux-kernel, quic_rohkumar
In-Reply-To: <20240404084631.417779-2-quic_mohs@quicinc.com>
On Thu, 4 Apr 2024 at 11:48, Mohammad Rafi Shaik <quic_mohs@quicinc.com> wrote:
>
> Document the bindings for the Qualcomm QCM6490 IDP and QCS6490 RB3Gen2
> soc platforms sound card.
>
> The bindings are the same as for other newer Qualcomm ADSP sound cards,
> thus keep them in existing qcom,sm8250.yaml file, even though Linux driver
> is separate.
>
> Signed-off-by: Mohammad Rafi Shaik <quic_mohs@quicinc.com>
> ---
> Documentation/devicetree/bindings/sound/qcom,sm8250.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
> index 2ab6871e89e5..ff1a27f26bc2 100644
> --- a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
> +++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
> @@ -29,6 +29,8 @@ properties:
> - enum:
> - qcom,apq8016-sbc-sndcard
> - qcom,msm8916-qdsp6-sndcard
> + - qcom,qcm6490-sndcard
> + - qcom,qcs6490-rb3gen2-sndcard
My 2c: you are adding one soundcard for the SoC family (qcm6490) and
another one for the particular board kind (qcs6490-rb3gen2). That
doesn't seem logical.
> - qcom,qrb5165-rb5-sndcard
> - qcom,sc7180-qdsp6-sndcard
> - qcom,sc8280xp-sndcard
> --
> 2.25.1
>
>
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v5 0/2] iio: temperature: ltc2983: small improvements
From: Nuno Sa @ 2024-04-04 8:58 UTC (permalink / raw)
To: linux-iio, devicetree
Cc: Jonathan Cameron, Lars-Peter Clausen, Michael Hennerich,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Krzysztof Kozlowski
Hi Jonathan,
As suggested by you, v5 only has the regulator stuff. I'll send another
series for the new dev_errp_helper().
---
Changes in v5:
- Dropped patches 1,2,5 and 6.
- Link to v4: https://lore.kernel.org/all/20240328-ltc2983-misc-improv-v4-0-0cc428c07cd5@analog.com/
---
Nuno Sa (2):
dt-bindings: iio: temperature: ltc2983: document power supply
iio: temperature: ltc2983: support vdd regulator
Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml | 4 ++++
drivers/iio/temperature/ltc2983.c | 5 +++++
2 files changed, 9 insertions(+)
---
base-commit: 6020ca4de8e5404b20f15a6d9873cd6eb5f6d8d6
change-id: 20240222-ltc2983-misc-improv-1c7a78ece93f
--
Thanks!
- Nuno Sá
^ permalink raw reply
* [PATCH v5 1/2] dt-bindings: iio: temperature: ltc2983: document power supply
From: Nuno Sa @ 2024-04-04 8:58 UTC (permalink / raw)
To: linux-iio, devicetree
Cc: Jonathan Cameron, Lars-Peter Clausen, Michael Hennerich,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Krzysztof Kozlowski
In-Reply-To: <20240404-ltc2983-misc-improv-v5-0-c1f58057fcea@analog.com>
Add a property for the VDD power supply regulator.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
---
Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
index dbb85135fd66..312febeeb3bb 100644
--- a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
+++ b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
@@ -57,6 +57,8 @@ properties:
interrupts:
maxItems: 1
+ vdd-supply: true
+
adi,mux-delay-config-us:
description: |
Extra delay prior to each conversion, in addition to the internal 1ms
@@ -460,6 +462,7 @@ required:
- compatible
- reg
- interrupts
+ - vdd-supply
additionalProperties: false
@@ -489,6 +492,7 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
+ vdd-supply = <&supply>;
interrupts = <20 IRQ_TYPE_EDGE_RISING>;
interrupt-parent = <&gpio>;
--
2.44.0
^ permalink raw reply related
* [PATCH v5 2/2] iio: temperature: ltc2983: support vdd regulator
From: Nuno Sa @ 2024-04-04 8:58 UTC (permalink / raw)
To: linux-iio, devicetree
Cc: Jonathan Cameron, Lars-Peter Clausen, Michael Hennerich,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20240404-ltc2983-misc-improv-v5-0-c1f58057fcea@analog.com>
Add support for the power supply regulator.
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
---
drivers/iio/temperature/ltc2983.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/iio/temperature/ltc2983.c b/drivers/iio/temperature/ltc2983.c
index 3c4524d57b8e..24d19f3c7292 100644
--- a/drivers/iio/temperature/ltc2983.c
+++ b/drivers/iio/temperature/ltc2983.c
@@ -16,6 +16,7 @@
#include <linux/module.h>
#include <linux/property.h>
#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
#include <linux/spi/spi.h>
#include <asm/byteorder.h>
@@ -1597,6 +1598,10 @@ static int ltc2983_probe(struct spi_device *spi)
if (ret)
return ret;
+ ret = devm_regulator_get_enable(&spi->dev, "vdd");
+ if (ret)
+ return ret;
+
gpio = devm_gpiod_get_optional(&st->spi->dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(gpio))
return PTR_ERR(gpio);
--
2.44.0
^ permalink raw reply related
* Re: [PATCH v7 1/5] dt-bindings: interconnect: Add Qualcomm IPQ9574 support
From: Varadarajan Narayanan @ 2024-04-04 8:55 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: andersson, konrad.dybcio, mturquette, sboyd, robh, krzk+dt,
conor+dt, djakov, dmitry.baryshkov, quic_anusha, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-pm
In-Reply-To: <58c9b754-b9a7-444d-9545-9e6648010630@kernel.org>
On Wed, Apr 03, 2024 at 04:59:40PM +0200, Krzysztof Kozlowski wrote:
> On 03/04/2024 12:42, Varadarajan Narayanan wrote:
> > Add interconnect-cells to clock provider so that it can be
> > used as icc provider.
> >
> > Add master/slave ids for Qualcomm IPQ9574 Network-On-Chip
> > interfaces. This will be used by the gcc-ipq9574 driver
> > that will for providing interconnect services using the
> > icc-clk framework.
> >
> > Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
> > ---
> > v7:
> > Fix macro names to be consistent with other bindings
> > v6:
> > Removed Reviewed-by: Krzysztof Kozlowski
> > Redefine the bindings such that driver and DT can share them
> >
> > v3:
> > Squash Documentation/ and include/ changes into same patch
> >
> > qcom,ipq9574.h
> > Move 'first id' to clock driver
> >
> > ---
> > .../bindings/clock/qcom,ipq9574-gcc.yaml | 3 +
> > .../dt-bindings/interconnect/qcom,ipq9574.h | 87 +++++++++++++++++++
> > 2 files changed, 90 insertions(+)
> > create mode 100644 include/dt-bindings/interconnect/qcom,ipq9574.h
> >
> > diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
> > index 944a0ea79cd6..824781cbdf34 100644
> > --- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
> > +++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
> > @@ -33,6 +33,9 @@ properties:
> > - description: PCIE30 PHY3 pipe clock source
> > - description: USB3 PHY pipe clock source
> >
> > + '#interconnect-cells':
> > + const: 1
> > +
> > required:
> > - compatible
> > - clocks
> > diff --git a/include/dt-bindings/interconnect/qcom,ipq9574.h b/include/dt-bindings/interconnect/qcom,ipq9574.h
> > new file mode 100644
> > index 000000000000..0b076b0cf880
> > --- /dev/null
> > +++ b/include/dt-bindings/interconnect/qcom,ipq9574.h
> > @@ -0,0 +1,87 @@
> > +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> > +#ifndef INTERCONNECT_QCOM_IPQ9574_H
> > +#define INTERCONNECT_QCOM_IPQ9574_H
> > +
> > +#define ICC_ANOC_PCIE0 0
> > +#define ICC_SNOC_PCIE0 1
> > +#define ICC_ANOC_PCIE1 2
> > +#define ICC_SNOC_PCIE1 3
> > +#define ICC_ANOC_PCIE2 4
> > +#define ICC_SNOC_PCIE2 5
> > +#define ICC_ANOC_PCIE3 6
> > +#define ICC_SNOC_PCIE3 7
> > +#define ICC_SNOC_USB 8
> > +#define ICC_ANOC_USB_AXI 9
> > +#define ICC_NSSNOC_NSSCC 10
> > +#define ICC_NSSNOC_SNOC_0 11
> > +#define ICC_NSSNOC_SNOC_1 12
> > +#define ICC_NSSNOC_PCNOC_1 13
> > +#define ICC_NSSNOC_QOSGEN_REF 14
> > +#define ICC_NSSNOC_TIMEOUT_REF 15
> > +#define ICC_NSSNOC_XO_DCD 16
> > +#define ICC_NSSNOC_ATB 17
> > +#define ICC_MEM_NOC_NSSNOC 18
> > +#define ICC_NSSNOC_MEMNOC 19
> > +#define ICC_NSSNOC_MEM_NOC_1 20
> > +
> > +#define ICC_NSSNOC_PPE 0
> > +#define ICC_NSSNOC_PPE_CFG 1
> > +#define ICC_NSSNOC_NSS_CSR 2
> > +#define ICC_NSSNOC_IMEM_QSB 3
> > +#define ICC_NSSNOC_IMEM_AHB 4
> > +
> > +#define MASTER_ANOC_PCIE0 (ICC_ANOC_PCIE0 * 2)
> > +#define SLAVE_ANOC_PCIE0 ((ICC_ANOC_PCIE0 * 2) + 1)
>
> Which existing Qualcomm platform has such code?
Existing Qualcomm platforms don't use icc-clk. They use icc-rpm
or icc-rpmh. clk-cbf-msm8996.c is the only driver that uses icc-clk.
The icc_clk_register automatically creates master & slave nodes
for each clk entry provided as input with the node-ids 'n' and
'n+1'. Since clk-cbf-msm8996.c has only one entry, it could just
define MASTER_CBF_M4M and SLAVE_CBF_M4M with 0 and 1 and avoid these
calculations.
However, ipq9574 gives an array of clock entries as input to
icc_clk_register. To tie the order/sequence of these clock
entries correctly with the node-ids, this calculation is needed.
> This is the third time I am asking for consistent headers. Open
> existing, recently added headers and look how it is done there. Why?
> Because I am against such calculations and see no reason for them.
Apologies. Regret that I have to trouble you.
In this ipq9574 case, have to reconcile between the following
feedbacks.
1. https://lore.kernel.org/linux-arm-msm/fe40b307-26d0-4b2a-869b-5d093415b9d1@linaro.org/
We could probably use indexed identifiers here to avoid confusion:
[ICC_BINDING_NAME] = CLK_BINDING_NAME
2. https://lore.kernel.org/linux-arm-msm/95f4e99a60cc97770fc3cee850b62faf.sboyd@kernel.org/
Are these supposed to be in a dt-binding header?
3. https://lore.kernel.org/linux-arm-msm/031d0a35-b192-4161-beef-97b89d5d1da6@linaro.org/
Do you use them as well in the DTS?
Having the defines (with the calculations) seemed to to comply
with the above three feedbacks.
Please let me know if this can be handled in a different way that
would be consistent with other Qualcomm platforms.
Thanks
Varada
^ 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