* [PATCH] dt-bindings: hwmon: gpio-fan: convert to YAML
From: Corentin Labbe @ 2022-01-26 20:03 UTC (permalink / raw)
To: jdelvare, linux, robh+dt
Cc: devicetree, linux-hwmon, linux-kernel, Corentin Labbe
Converts hwmon/gpio-fan.txt to YAML
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
I didnt found any clear maintainer and since DT yaml mandates a
maintainer section, I set devicetree@vger.kernel.org.
.../devicetree/bindings/hwmon/gpio-fan.txt | 41 --------
.../devicetree/bindings/hwmon/gpio-fan.yaml | 96 +++++++++++++++++++
2 files changed, 96 insertions(+), 41 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/hwmon/gpio-fan.txt
create mode 100644 Documentation/devicetree/bindings/hwmon/gpio-fan.yaml
diff --git a/Documentation/devicetree/bindings/hwmon/gpio-fan.txt b/Documentation/devicetree/bindings/hwmon/gpio-fan.txt
deleted file mode 100644
index f4cfa350f6a1..000000000000
--- a/Documentation/devicetree/bindings/hwmon/gpio-fan.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-Bindings for fan connected to GPIO lines
-
-Required properties:
-- compatible : "gpio-fan"
-
-Optional properties:
-- gpios: Specifies the pins that map to bits in the control value,
- ordered MSB-->LSB.
-- gpio-fan,speed-map: A mapping of possible fan RPM speeds and the
- control value that should be set to achieve them. This array
- must have the RPM values in ascending order.
-- alarm-gpios: This pin going active indicates something is wrong with
- the fan, and a udev event will be fired.
-- #cooling-cells: If used as a cooling device, must be <2>
- Also see:
- Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
- min and max states are derived from the speed-map of the fan.
-
-Note: At least one the "gpios" or "alarm-gpios" properties must be set.
-
-Examples:
-
- gpio_fan {
- compatible = "gpio-fan";
- gpios = <&gpio1 14 1
- &gpio1 13 1>;
- gpio-fan,speed-map = <0 0
- 3000 1
- 6000 2>;
- alarm-gpios = <&gpio1 15 1>;
- };
- gpio_fan_cool: gpio_fan {
- compatible = "gpio-fan";
- gpios = <&gpio2 14 1
- &gpio2 13 1>;
- gpio-fan,speed-map = <0 0>,
- <3000 1>,
- <6000 2>;
- alarm-gpios = <&gpio2 15 1>;
- #cooling-cells = <2>; /* min followed by max */
- };
diff --git a/Documentation/devicetree/bindings/hwmon/gpio-fan.yaml b/Documentation/devicetree/bindings/hwmon/gpio-fan.yaml
new file mode 100644
index 000000000000..15bb5efd3cb4
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/gpio-fan.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/gpio-fan.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bindings for fan connected to GPIO lines
+
+maintainers:
+ - OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>
+
+properties:
+ compatible:
+ const: gpio-fan
+
+ gpios:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: Specifies the pins that map to bits in the control value,
+ ordered MSB-->LSB.
+
+ gpio-fan,speed-map:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: A mapping of possible fan RPM speeds and the
+ control value that should be set to achieve them. This array
+ must have the RPM values in ascending order.
+
+ alarm-gpios:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: This pin going active indicates something is wrong with
+ the fan, and a udev event will be fired.
+
+ "#cooling-cells":
+ const: 2
+ description: If used as a cooling device, must be <2>
+ Also see Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
+ min and max states are derived from the speed-map of the fan.
+
+anyOf:
+ - required:
+ - gpios
+ - required:
+ - alarm-gpios
+
+additionalProperties: False
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/cortina,gemini-clock.h>
+ #include <dt-bindings/reset/cortina,gemini-reset.h>
+ #include <dt-bindings/gpio/gpio.h>
+ gpio1: gpio@4d000000 {
+ compatible = "cortina,gemini-gpio", "faraday,ftgpio010";
+ reg = <0x4d000000 0x100>;
+ interrupts = <22 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&syscon GEMINI_RESET_GPIO0>;
+ clocks = <&syscon GEMINI_CLK_APB>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ gpio_fan {
+ compatible = "gpio-fan";
+ gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+ gpio-fan,speed-map = <0 0>,
+ <3000 1>,
+ <6000 2>;
+ alarm-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
+ };
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/cortina,gemini-clock.h>
+ #include <dt-bindings/reset/cortina,gemini-reset.h>
+ #include <dt-bindings/gpio/gpio.h>
+ gpio2: gpio@4d000000 {
+ compatible = "cortina,gemini-gpio", "faraday,ftgpio010";
+ reg = <0x4d000000 0x100>;
+ interrupts = <22 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&syscon GEMINI_RESET_GPIO0>;
+ clocks = <&syscon GEMINI_CLK_APB>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ gpio_fan_cool: gpio_fan {
+ compatible = "gpio-fan";
+ gpios = <&gpio2 8 GPIO_ACTIVE_HIGH
+ &gpio2 1 GPIO_ACTIVE_HIGH>;
+ gpio-fan,speed-map = <0 0
+ 3000 1
+ 6000 2>;
+ alarm-gpios = <&gpio2 15 GPIO_ACTIVE_HIGH>;
+ #cooling-cells = <2>; /* min followed by max */
+ };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 21/27] arm64: dts: rockchip: rk356x: Add HDMI nodes
From: Peter Geis @ 2022-01-26 20:00 UTC (permalink / raw)
To: Robin Murphy
Cc: Sascha Hauer, dri-devel, arm-mail-list,
open list:ARM/Rockchip SoC..., devicetree, kernel, Andy Yan,
Benjamin Gaignard, Michael Riesch, Sandy Huang,
Heiko Stübner
In-Reply-To: <45132d1f-626d-5fe3-3118-21c0b3f4c8f1@arm.com>
On Wed, Jan 26, 2022 at 2:25 PM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2022-01-26 18:44, Peter Geis wrote:
> > On Wed, Jan 26, 2022 at 12:56 PM Robin Murphy <robin.murphy@arm.com> wrote:
> >>
> >> On 2022-01-26 16:04, Peter Geis wrote:
> >>> On Wed, Jan 26, 2022 at 9:58 AM Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >>>>
> >>>> Add support for the HDMI port found on RK3568.
> >>>>
> >>>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> >>>> ---
> >>>> arch/arm64/boot/dts/rockchip/rk356x.dtsi | 37 +++++++++++++++++++++++-
> >>>> 1 file changed, 36 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> >>>> index 4008bd666d01..e38fb223e9b8 100644
> >>>> --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> >>>> +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> >>>> @@ -10,7 +10,6 @@
> >>>> #include <dt-bindings/pinctrl/rockchip.h>
> >>>> #include <dt-bindings/power/rk3568-power.h>
> >>>> #include <dt-bindings/soc/rockchip,boot-mode.h>
> >>>> -#include <dt-bindings/soc/rockchip,vop2.h>
> >>>> #include <dt-bindings/thermal/thermal.h>
> >>>>
> >>>> / {
> >>>> @@ -502,6 +501,42 @@ vop_mmu: iommu@fe043e00 {
> >>>> status = "disabled";
> >>>> };
> >>>>
> >>>> + hdmi: hdmi@fe0a0000 {
> >>>> + compatible = "rockchip,rk3568-dw-hdmi";
> >>>> + reg = <0x0 0xfe0a0000 0x0 0x20000>;
> >>>> + interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
> >>>> + clocks = <&cru PCLK_HDMI_HOST>,
> >>>> + <&cru CLK_HDMI_SFR>,
> >>>> + <&cru CLK_HDMI_CEC>,
> >>>> + <&pmucru CLK_HDMI_REF>,
> >>>> + <&cru HCLK_VOP>;
> >>>> + clock-names = "iahb", "isfr", "cec", "ref", "hclk";
> >>>> + pinctrl-names = "default";
> >>>> + pinctrl-0 = <&hdmitx_scl &hdmitx_sda &hdmitxm0_cec>;
> >>>
> >>> I looked into CEC support here, and it seems that it does work with one change.
> >>> Please add the two following lines to your patch:
> >>> assigned-clocks = <&cru CLK_HDMI_CEC>;
> >>> assigned-clock-rates = <32768>;
> >>>
> >>> The issue is the clk_rtc32k_frac clock that feeds clk_rtc_32k which
> >>> feeds clk_hdmi_cec is 24mhz at boot, which is too high for CEC to
> >>> function.
> >>
> >> Wouldn't it make far more sense to just stick a suitable clk_set_rate()
> >> call in the driver? AFAICS it's already explicitly aware of the CEC clock.
> >
> > This is handled purely in the
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c driver, so I'm hesitant to
> > touch it there as it would affect all users, not just Rockchip.
>
> I'd have a strong hunch that it's a standard thing for the DesignWare IP
> and not affected by platform integration. I don't have the magical
> Synopsys databook, but between the trusty old i.MX6 manual and most of
> the other in-tree DTs getting their dw-hdmi "cec" clock from
> suspiciously-obviously-named sources, I'd be somewhat surprised if it
> was ever anything other than 32KHz.
My main concern was similar to the other HDMI clock issues, mainly
setting the clock can propagate up and affect other users of the
upstream clock.
I'll spin up a quick patch for this method.
Thanks,
Peter
>
> Robin.
>
> > Could someone familiar with the dw-hdmi IP weigh in on the minimum and
> > maximum clock rate the CEC block can handle?
> >
> >>
> >> Robin.
> >>
> >>>> + power-domains = <&power RK3568_PD_VO>;
> >>>> + reg-io-width = <4>;
> >>>> + rockchip,grf = <&grf>;
> >>>> + #sound-dai-cells = <0>;
> >>>> + status = "disabled";
> >>>> +
> >>>> + ports {
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> +
> >>>> + hdmi_in: port@0 {
> >>>> + reg = <0>;
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> + };
> >>>> +
> >>>> + hdmi_out: port@1 {
> >>>> + reg = <1>;
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> + };
> >>>> + };
> >>>> + };
> >>>> +
> >>>> qos_gpu: qos@fe128000 {
> >>>> compatible = "rockchip,rk3568-qos", "syscon";
> >>>> reg = <0x0 0xfe128000 0x0 0x20>;
> >>>> --
> >>>> 2.30.2
> >>>>
> >>>
> >>> _______________________________________________
> >>> Linux-rockchip mailing list
> >>> Linux-rockchip@lists.infradead.org
> >>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: timer: sifive,clint: Fix number of interrupts
From: Rob Herring @ 2022-01-26 19:36 UTC (permalink / raw)
To: Anup Patel, Geert Uytterhoeven
Cc: Daniel Lezcano, Thomas Gleixner, Palmer Dabbelt, Paul Walmsley,
Anup Patel, linux-kernel@vger.kernel.org List, DTML, linux-riscv
In-Reply-To: <CAAhSdy3g9WsBmQk7KOgdVNSw9qUouxF2i==q9M3WQq3iabXv7Q@mail.gmail.com>
On Fri, Dec 17, 2021 at 6:48 AM Anup Patel <anup@brainfault.org> wrote:
>
> On Fri, Dec 17, 2021 at 6:08 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >
> > The number of interrupts lacks an upper bound, thus assuming one,
> > causing properly grouped "interrupts-extended" properties to be flagged
> > as an error by "make dtbs_check".
> >
> > Fix this by adding the missing "maxItems". As the architectural maximum
> > is 4095 interrupts, using that as the limit would be unpractical. Hence
> > limit it to 10 interrupts (two interrupts for a system management core,
> > and two interrupts per core for other cores). This should be sufficient
> > for now, and the limit can always be increased when the need arises.
>
> Same comment as the PLIC DT binding patch.
>
> The "maxItems" should represent CLINT spec constraints so
> please don't add any synthetic value here.
I agree.
Geert, are you going to respin these?
Rob
^ permalink raw reply
* Re: [PATCH 1/1] of: unittest: rename overlay source files from .dts to .dtso
From: Rob Herring @ 2022-01-26 19:31 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Frank Rowand, David Gibson, Viresh Kumar, Masahiro Yamada,
Michal Marek, Vincent Guittot, Michal Simek, Anmar Oueja,
Bill Mills,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kbuild, Linux Kernel Mailing List, Pantelis Antoniou
In-Reply-To: <CAMuHMdU4oUKaGxmaPiC=cX0XpHG3KXhr+4MywEfeQ8sq-EG18A@mail.gmail.com>
On Fri, Jan 14, 2022 at 3:25 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Rob,
>
> On Fri, Jan 14, 2022 at 3:10 AM Rob Herring <robh@kernel.org> wrote:
> > On Thu, Jan 6, 2022 at 11:23 AM Frank Rowand <frowand.list@gmail.com> wrote:
> > > Patient Geert has pinged again.
> >
> > If it's not a patch to be reviewed, then I'm not going to see it most
> > likely. I don't read the DT list regularly...
>
> Fair enough...
>
> > > If I remember correctly you guys were not thrilled with this idea, but
> > > also did not seem strongly against it. Are you willing to go along
> > > with .dtso for overlay source files? If so, I will revive this patch
> > > series.
> > >
> > > David, if you are against supporting .dtso in the dtc compiler then
> > > the kernel can still support it through make rules.
> >
> > I'm not really interested in diverging from dtc. I'd suggest moving
> > the discussion to dtc list and/or devicetree-spec if you want to get
> > more attention on this.
>
> What needs to be supported in the dtc compiler?
> The fallback passed to guess_input_format() is "dts".
> So this has been working out-of-the-box since forever?
Ah, okay.
> > Also, keep in mind that extensions also affect MIME types which
> > someone was also asking about recently.
>
> You mean "MIME type of Devicetree Blobs and Sources"[1]?
> According to [2](2022-01-13), none of that has happened.
This is what I was thinking of:
https://github.com/devicetree-org/devicetree-specification/issues/46
In any case, given everyone is ambivalent, send me an updated patch
and I'll apply it.
Rob
^ permalink raw reply
* Re: [PATCH 21/27] arm64: dts: rockchip: rk356x: Add HDMI nodes
From: Robin Murphy @ 2022-01-26 19:24 UTC (permalink / raw)
To: Peter Geis
Cc: Sascha Hauer, dri-devel, arm-mail-list,
open list:ARM/Rockchip SoC..., devicetree, kernel, Andy Yan,
Benjamin Gaignard, Michael Riesch, Sandy Huang,
Heiko Stübner
In-Reply-To: <CAMdYzYrcsj5Vas+ysoK6iD3uEAdmhcmLVi-5LY7hfHEtjeB6Cg@mail.gmail.com>
On 2022-01-26 18:44, Peter Geis wrote:
> On Wed, Jan 26, 2022 at 12:56 PM Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> On 2022-01-26 16:04, Peter Geis wrote:
>>> On Wed, Jan 26, 2022 at 9:58 AM Sascha Hauer <s.hauer@pengutronix.de> wrote:
>>>>
>>>> Add support for the HDMI port found on RK3568.
>>>>
>>>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>>>> ---
>>>> arch/arm64/boot/dts/rockchip/rk356x.dtsi | 37 +++++++++++++++++++++++-
>>>> 1 file changed, 36 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
>>>> index 4008bd666d01..e38fb223e9b8 100644
>>>> --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
>>>> +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
>>>> @@ -10,7 +10,6 @@
>>>> #include <dt-bindings/pinctrl/rockchip.h>
>>>> #include <dt-bindings/power/rk3568-power.h>
>>>> #include <dt-bindings/soc/rockchip,boot-mode.h>
>>>> -#include <dt-bindings/soc/rockchip,vop2.h>
>>>> #include <dt-bindings/thermal/thermal.h>
>>>>
>>>> / {
>>>> @@ -502,6 +501,42 @@ vop_mmu: iommu@fe043e00 {
>>>> status = "disabled";
>>>> };
>>>>
>>>> + hdmi: hdmi@fe0a0000 {
>>>> + compatible = "rockchip,rk3568-dw-hdmi";
>>>> + reg = <0x0 0xfe0a0000 0x0 0x20000>;
>>>> + interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
>>>> + clocks = <&cru PCLK_HDMI_HOST>,
>>>> + <&cru CLK_HDMI_SFR>,
>>>> + <&cru CLK_HDMI_CEC>,
>>>> + <&pmucru CLK_HDMI_REF>,
>>>> + <&cru HCLK_VOP>;
>>>> + clock-names = "iahb", "isfr", "cec", "ref", "hclk";
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&hdmitx_scl &hdmitx_sda &hdmitxm0_cec>;
>>>
>>> I looked into CEC support here, and it seems that it does work with one change.
>>> Please add the two following lines to your patch:
>>> assigned-clocks = <&cru CLK_HDMI_CEC>;
>>> assigned-clock-rates = <32768>;
>>>
>>> The issue is the clk_rtc32k_frac clock that feeds clk_rtc_32k which
>>> feeds clk_hdmi_cec is 24mhz at boot, which is too high for CEC to
>>> function.
>>
>> Wouldn't it make far more sense to just stick a suitable clk_set_rate()
>> call in the driver? AFAICS it's already explicitly aware of the CEC clock.
>
> This is handled purely in the
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c driver, so I'm hesitant to
> touch it there as it would affect all users, not just Rockchip.
I'd have a strong hunch that it's a standard thing for the DesignWare IP
and not affected by platform integration. I don't have the magical
Synopsys databook, but between the trusty old i.MX6 manual and most of
the other in-tree DTs getting their dw-hdmi "cec" clock from
suspiciously-obviously-named sources, I'd be somewhat surprised if it
was ever anything other than 32KHz.
Robin.
> Could someone familiar with the dw-hdmi IP weigh in on the minimum and
> maximum clock rate the CEC block can handle?
>
>>
>> Robin.
>>
>>>> + power-domains = <&power RK3568_PD_VO>;
>>>> + reg-io-width = <4>;
>>>> + rockchip,grf = <&grf>;
>>>> + #sound-dai-cells = <0>;
>>>> + status = "disabled";
>>>> +
>>>> + ports {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> +
>>>> + hdmi_in: port@0 {
>>>> + reg = <0>;
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + };
>>>> +
>>>> + hdmi_out: port@1 {
>>>> + reg = <1>;
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + };
>>>> + };
>>>> + };
>>>> +
>>>> qos_gpu: qos@fe128000 {
>>>> compatible = "rockchip,rk3568-qos", "syscon";
>>>> reg = <0x0 0xfe128000 0x0 0x20>;
>>>> --
>>>> 2.30.2
>>>>
>>>
>>> _______________________________________________
>>> Linux-rockchip mailing list
>>> Linux-rockchip@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: dts: renesas: Prepare AA1024XD12 panel .dtsi for overlay support
From: Geert Uytterhoeven @ 2022-01-26 19:15 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Kieran Bingham, Geert Uytterhoeven, Magnus Damm,
Chris Paterson
In-Reply-To: <YfGZx9qHQdF8TzcT@pendragon.ideasonboard.com>
Hi Laurent,
On Wed, Jan 26, 2022 at 7:58 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Wed, Jan 26, 2022 at 01:18:56PM +0100, Geert Uytterhoeven wrote:
> > On Wed, Dec 29, 2021 at 8:31 PM Laurent Pinchart wrote:
> > > The Mitsubishi AA1024XD12 panel can be used for R-Car Gen2 and Gen3
> > > boards as an optional external panel. It is described in the
> > > arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi file as a direct child of the
> > > DT root node. This allows including r8a77xx-aa104xd12-panel.dtsi in
> > > board device trees, with other minor modifications, to enable the panel.
> > >
> > > This is however not how external components should be modelled. Instead
> > > of modifying the board device tree to enable the panel, it should be
> > > compiled as a DT overlay, to be loaded by the boot loader.
> > >
> > > Prepare the r8a77xx-aa104xd12-panel.dtsi file for this usage by
> > > declaring a panel node only, without hardcoding its path. Overlay
> > > sources can then include r8a77xx-aa104xd12-panel.dtsi where appropriate.
> > >
> > > This change doesn't cause any regression as r8a77xx-aa104xd12-panel.dtsi
> > > is currently unused. As overlay support for this panel has only been
> > > tested with Gen3 hardware, and Gen2 support will require more
> > > development, move the file to arch/arm64/boot/dts/renesas/.
> > >
> > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> I see you've reviewed the whole series. Can you pick it up ?
I believe it depends on the removal of the empty endpoints, for which
we're waiting for feedback from Rob, IIRC?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: dts: renesas: Prepare AA1024XD12 panel .dtsi for overlay support
From: Laurent Pinchart @ 2022-01-26 18:58 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Kieran Bingham, Geert Uytterhoeven, Magnus Damm,
Chris Paterson
In-Reply-To: <CAMuHMdWWRLdm+dAmso0dgf5QPqqV=txH-4Tryfm0USp7jZdbkw@mail.gmail.com>
Hi Geert,
On Wed, Jan 26, 2022 at 01:18:56PM +0100, Geert Uytterhoeven wrote:
> On Wed, Dec 29, 2021 at 8:31 PM Laurent Pinchart wrote:
> > The Mitsubishi AA1024XD12 panel can be used for R-Car Gen2 and Gen3
> > boards as an optional external panel. It is described in the
> > arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi file as a direct child of the
> > DT root node. This allows including r8a77xx-aa104xd12-panel.dtsi in
> > board device trees, with other minor modifications, to enable the panel.
> >
> > This is however not how external components should be modelled. Instead
> > of modifying the board device tree to enable the panel, it should be
> > compiled as a DT overlay, to be loaded by the boot loader.
> >
> > Prepare the r8a77xx-aa104xd12-panel.dtsi file for this usage by
> > declaring a panel node only, without hardcoding its path. Overlay
> > sources can then include r8a77xx-aa104xd12-panel.dtsi where appropriate.
> >
> > This change doesn't cause any regression as r8a77xx-aa104xd12-panel.dtsi
> > is currently unused. As overlay support for this panel has only been
> > tested with Gen3 hardware, and Gen2 support will require more
> > development, move the file to arch/arm64/boot/dts/renesas/.
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>
> Thanks for your patch!
>
> > --- a/arch/arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi
>
> > - * Copyright (C) 2014 Renesas Electronics Corp.
>
> > +++ b/arch/arm64/boot/dts/renesas/panel-aa104xd12.dtsi
>
> > + * Copyright (C) 2021 Renesas Electronics Corp.
>
> Shouldn't you keep the year? Not much has changed.
Indeed.
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
I see you've reviewed the whole series. Can you pick it up ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: arm: xen: document Xen iommu device
From: Stefano Stabellini @ 2022-01-26 18:56 UTC (permalink / raw)
To: Robin Murphy
Cc: Sergiy Kibrik, Stefano Stabellini, Julien Grall,
Oleksandr Tyshchenko, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
xen-devel@lists.xenproject.org
In-Reply-To: <447f89ca-86c0-dc35-e7ac-e6639a573670@arm.com>
On Wed, 26 Jan 2022, Robin Murphy wrote:
> On 2022-01-26 15:09, Sergiy Kibrik wrote:
> > Hi Robin,
> >
> > >
> > > This could break Linux guests, since depending on the deferred probe
> > > timeout setting it could lead to drivers never probing because the "IOMMU"
> > > never becomes available.
> > >
> >
> > I've noticed no deferred probe timeouts when booting with this patch. Could
> > you please explain more on how this would break guests?
>
> Right now I think it would actually require command-line intervention, e.g.
> "fw_devlink=on" or "deferred_probe_timeout=3600" (with modules enabled for the
> latter to take full effect), but I'm wary of the potential for future config
> options to control those behaviours by default.
If deferred_probe_timeout=3600 was specified, we would just need an
IOMMU driver in Linux for the "xen,iommu-el2-v1" node to solve the
problem, right? I guess I am trying to say that it wouldn't be a device
tree interface problem but rather a Linux implementation discussion.
^ permalink raw reply
* Re: [PATCH 21/27] arm64: dts: rockchip: rk356x: Add HDMI nodes
From: Peter Geis @ 2022-01-26 18:44 UTC (permalink / raw)
To: Robin Murphy
Cc: Sascha Hauer, dri-devel, arm-mail-list,
open list:ARM/Rockchip SoC..., devicetree, kernel, Andy Yan,
Benjamin Gaignard, Michael Riesch, Sandy Huang,
Heiko Stübner
In-Reply-To: <a1438d39-b670-1ca5-d3f7-4e3f54702e53@arm.com>
On Wed, Jan 26, 2022 at 12:56 PM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2022-01-26 16:04, Peter Geis wrote:
> > On Wed, Jan 26, 2022 at 9:58 AM Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >>
> >> Add support for the HDMI port found on RK3568.
> >>
> >> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> >> ---
> >> arch/arm64/boot/dts/rockchip/rk356x.dtsi | 37 +++++++++++++++++++++++-
> >> 1 file changed, 36 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> >> index 4008bd666d01..e38fb223e9b8 100644
> >> --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> >> +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> >> @@ -10,7 +10,6 @@
> >> #include <dt-bindings/pinctrl/rockchip.h>
> >> #include <dt-bindings/power/rk3568-power.h>
> >> #include <dt-bindings/soc/rockchip,boot-mode.h>
> >> -#include <dt-bindings/soc/rockchip,vop2.h>
> >> #include <dt-bindings/thermal/thermal.h>
> >>
> >> / {
> >> @@ -502,6 +501,42 @@ vop_mmu: iommu@fe043e00 {
> >> status = "disabled";
> >> };
> >>
> >> + hdmi: hdmi@fe0a0000 {
> >> + compatible = "rockchip,rk3568-dw-hdmi";
> >> + reg = <0x0 0xfe0a0000 0x0 0x20000>;
> >> + interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
> >> + clocks = <&cru PCLK_HDMI_HOST>,
> >> + <&cru CLK_HDMI_SFR>,
> >> + <&cru CLK_HDMI_CEC>,
> >> + <&pmucru CLK_HDMI_REF>,
> >> + <&cru HCLK_VOP>;
> >> + clock-names = "iahb", "isfr", "cec", "ref", "hclk";
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&hdmitx_scl &hdmitx_sda &hdmitxm0_cec>;
> >
> > I looked into CEC support here, and it seems that it does work with one change.
> > Please add the two following lines to your patch:
> > assigned-clocks = <&cru CLK_HDMI_CEC>;
> > assigned-clock-rates = <32768>;
> >
> > The issue is the clk_rtc32k_frac clock that feeds clk_rtc_32k which
> > feeds clk_hdmi_cec is 24mhz at boot, which is too high for CEC to
> > function.
>
> Wouldn't it make far more sense to just stick a suitable clk_set_rate()
> call in the driver? AFAICS it's already explicitly aware of the CEC clock.
This is handled purely in the
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c driver, so I'm hesitant to
touch it there as it would affect all users, not just Rockchip.
Could someone familiar with the dw-hdmi IP weigh in on the minimum and
maximum clock rate the CEC block can handle?
>
> Robin.
>
> >> + power-domains = <&power RK3568_PD_VO>;
> >> + reg-io-width = <4>;
> >> + rockchip,grf = <&grf>;
> >> + #sound-dai-cells = <0>;
> >> + status = "disabled";
> >> +
> >> + ports {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + hdmi_in: port@0 {
> >> + reg = <0>;
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + };
> >> +
> >> + hdmi_out: port@1 {
> >> + reg = <1>;
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + };
> >> + };
> >> + };
> >> +
> >> qos_gpu: qos@fe128000 {
> >> compatible = "rockchip,rk3568-qos", "syscon";
> >> reg = <0x0 0xfe128000 0x0 0x20>;
> >> --
> >> 2.30.2
> >>
> >
> > _______________________________________________
> > Linux-rockchip mailing list
> > Linux-rockchip@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [RFC PATCH v2 5/7] ARM: dts: bcm2711: Add unicam CSI nodes
From: Laurent Pinchart @ 2022-01-26 18:42 UTC (permalink / raw)
To: Dave Stevenson
Cc: Jean-Michel Hautbois, devicetree, kernel-list, linux-arm-kernel,
LKML, Linux Media Mailing List, linux-rpi-kernel, lukasz,
Mauro Carvalho Chehab, Naushir Patuck, robh, Tomi Valkeinen
In-Reply-To: <CAPY8ntDR5AsxGE5fh_KHMonoZait9evxQkpidu10F7EY9CPxZA@mail.gmail.com>
Hi Dave,
On Mon, Jan 24, 2022 at 12:31:34PM +0000, Dave Stevenson wrote:
> On Fri, 21 Jan 2022 at 22:45, Laurent Pinchart wrote:
> > On Fri, Jan 21, 2022 at 09:18:08AM +0100, Jean-Michel Hautbois wrote:
> > > Add both MIPI CSI-2 nodes in the core bcm2711 tree. Use the 3-cells
> > > interrupt declaration, corresponding clocks and default as disabled.
> > >
> > > Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
> > > ---
> > > arch/arm/boot/dts/bcm2711.dtsi | 31 +++++++++++++++++++++++++++++++
> > > 1 file changed, 31 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/bcm2711.dtsi b/arch/arm/boot/dts/bcm2711.dtsi
> > > index dff18fc9a906..077141df7024 100644
> > > --- a/arch/arm/boot/dts/bcm2711.dtsi
> > > +++ b/arch/arm/boot/dts/bcm2711.dtsi
> > > @@ -3,6 +3,7 @@
> > >
> > > #include <dt-bindings/interrupt-controller/arm-gic.h>
> > > #include <dt-bindings/soc/bcm2835-pm.h>
> > > +#include <dt-bindings/power/raspberrypi-power.h>
> > >
> > > / {
> > > compatible = "brcm,bcm2711";
> > > @@ -293,6 +294,36 @@ hvs: hvs@7e400000 {
> > > interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
> > > };
> > >
> > > + csi0: csi1@7e800000 {
> >
> > The node name should be csi@7e800000, not csi1@7e800000. Now, this will
> > probably cause issues with the firmware that looks for csi1 (and csi0 ?)
> > to hand over control of the Unicam CSI-2 receiver to the kernel. I
> > wonder if this is something that could be handled by a firmware update,
> > to also recognize nodes named "csi" ?
>
> It already looks for any node starting "csi". If you check the
> downstream DT [1], then the nodes are "csi0: csi@7e800000" and "csi1:
> csi@7e801000".
Oops, indeed. I think I was misled by
https://github.com/raspberrypi/linux/blob/rpi-5.10.y/Documentation/devicetree/bindings/media/bcm2835-unicam.txt
that mentions "csi0" and "csi1".
It's all good then. Jean-Michel, can you update the DT bindings in the
next iteration of the series to correct the DT node naming ?
> There is no actual action required to hand the peripheral over to the
> kernel, it just prevents the firmware from using it and causing
> problems (it masks out the interrupt, and that's checked as part of
> the firmware initialising the peripheral).
>
> If using imx219 or one of the other sensors supported by the firmware,
> "vcgencmd get_camera" should report that the sensor isn't detected,
> and "sudo vcdbg log msg" should have a line similar to
> "020174.613: camsubs: Ignoring camera 0 as unicam device not available"
>
> Dave
>
> [1] https://github.com/raspberrypi/linux/blob/rpi-5.10.y/arch/arm/boot/dts/bcm270x.dtsi#L88
>
> > > + compatible = "brcm,bcm2835-unicam";
> > > + reg = <0x7e800000 0x800>,
> > > + <0x7e802000 0x4>;
> > > + interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&clocks BCM2835_CLOCK_CAM0>,
> > > + <&firmware_clocks 4>;
> > > + clock-names = "lp", "vpu";
> > > + power-domains = <&power RPI_POWER_DOMAIN_UNICAM0>;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + #clock-cells = <1>;
> >
> > Why do you need #address-cells, #size-cells and #clock-cells ? They're
> > not mentioned in the binding.
> >
> > > + status="disabled";
> >
> > Missing spaces around the =.
> >
> > Same comment for the next node.
> >
> > > + };
> > > +
> > > + csi1: csi1@7e801000 {
> > > + compatible = "brcm,bcm2835-unicam";
> > > + reg = <0x7e801000 0x800>,
> > > + <0x7e802004 0x4>;
> > > + interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&clocks BCM2835_CLOCK_CAM1>,
> > > + <&firmware_clocks 4>;
> > > + clock-names = "lp", "vpu";
> > > + power-domains = <&power RPI_POWER_DOMAIN_UNICAM1>;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + #clock-cells = <1>;
> > > + status="disabled";
> > > + };
> > > +
> > > pixelvalve3: pixelvalve@7ec12000 {
> > > compatible = "brcm,bcm2711-pixelvalve3";
> > > reg = <0x7ec12000 0x100>;
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v4 3/5] dt-bindings: bus: add device tree bindings for qcom,ssc-block-bus
From: michael.srba @ 2022-01-26 18:32 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Rob Herring, Stephen Boyd,
Philipp Zabel
Cc: Linus Walleij, Florian Fainelli, Arnd Bergmann,
Greg Kroah-Hartman, Saravana Kannan, linux-arm-msm, linux-clk,
devicetree, Michael Srba
In-Reply-To: <20220126183250.11924-1-michael.srba@seznam.cz>
From: Michael Srba <Michael.Srba@seznam.cz>
This patch adds bindings for the AHB bus which exposes the SCC block in
the global address space. This bus (and the SSC block itself) is present
on certain qcom SoCs.
In typical configuration, this bus (as some of the clocks and registers
that we need to manipulate) is not accessible to the OS, and the
resources on this bus are indirectly accessed by communicating with a
hexagon CPU core residing in the SSC block. In this configuration, the
hypervisor is the one performing the bus initialization for the purposes
of bringing the haxagon CPU core out of reset.
However, it is possible to change the configuration, in which case this
binding serves to allow the OS to initialize the bus.
Signed-off-by: Michael Srba <Michael.Srba@seznam.cz>
---
CHANGES:
- v2: fix issues caught by by dt-schema
- v3: none
- v4: address the issues pointed out in the review
---
.../bindings/bus/qcom,ssc-block-bus.yaml | 150 ++++++++++++++++++
1 file changed, 150 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml
diff --git a/Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml b/Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml
new file mode 100644
index 000000000000..4bde169b1a19
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml
@@ -0,0 +1,150 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/qcom,ssc-block-bus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: The AHB Bus Providing a Global View of the SSC Block on (some) qcom SoCs
+
+maintainers:
+ - Michael Srba <Michael.Srba@seznam.cz>
+
+description: |
+ This binding describes the dependencies (clocks, resets, power domains) which
+ need to be turned on in a sequence before communication over the AHB bus
+ becomes possible.
+
+ Additionally, the reg property is used to pass to the driver the location of
+ two sadly undocumented registers which need to be poked as part of the sequence.
+
+properties:
+ compatible:
+ items:
+ - const: qcom,msm8998-ssc-block-bus
+ - const: qcom,ssc-block-bus
+
+ reg:
+ description: |
+ Shall contain the addresses of the SSCAON_CONFIG0 and SSCAON_CONFIG1
+ registers
+ minItems: 2
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: mpm_sscaon_config0
+ - const: mpm_sscaon_config1
+
+ '#address-cells':
+ enum: [ 1, 2 ]
+
+ '#size-cells':
+ enum: [ 1, 2 ]
+
+ ranges: true
+
+ clocks:
+ minItems: 6
+ maxItems: 6
+
+ clock-names:
+ items:
+ - const: xo
+ - const: aggre2
+ - const: gcc_im_sleep
+ - const: aggre2_north
+ - const: ssc_xo
+ - const: ssc_ahbs
+
+ power-domains:
+ description: Power domain phandles for the ssc_cx and ssc_mx power domains
+ minItems: 2
+ maxItems: 2
+
+ power-domain-names:
+ items:
+ - const: ssc_cx
+ - const: ssc_mx
+
+ resets:
+ description: |
+ Reset phandles for the ssc_reset and ssc_bcr resets (note: ssc_bcr is the
+ branch control register associated with the ssc_xo and ssc_ahbs clocks)
+ minItems: 2
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: ssc_reset
+ - const: ssc_bcr
+
+ qcom,halt-regs:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: describes how to locate the ssc AXI halt register
+ items:
+ - items:
+ - description: Phandle reference to a syscon representing TCSR
+ - description: offset for the ssc AXI halt register
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - '#address-cells'
+ - '#size-cells'
+ - ranges
+ - clocks
+ - clock-names
+ - power-domains
+ - power-domain-names
+ - resets
+ - reset-names
+ - qcom,halt-regs
+
+additionalProperties: true
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-msm8998.h>
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ // devices under this node are physically located in the SSC block, connected to an ssc-internal bus;
+ ssc_ahb_slave: bus@10ac008 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ compatible = "qcom,msm8998-ssc-block-bus", "qcom,ssc-block-bus";
+ reg = <0x10ac008 0x4>, <0x10ac010 0x4>;
+ reg-names = "mpm_sscaon_config0", "mpm_sscaon_config1";
+
+ clocks = <&xo>,
+ <&rpmcc RPM_SMD_AGGR2_NOC_CLK>,
+ <&gcc GCC_IM_SLEEP>,
+ <&gcc AGGRE2_SNOC_NORTH_AXI>,
+ <&gcc SSC_XO>,
+ <&gcc SSC_CNOC_AHBS_CLK>;
+ clock-names = "xo", "aggre2", "gcc_im_sleep", "aggre2_north", "ssc_xo", "ssc_ahbs";
+
+ resets = <&gcc GCC_SSC_RESET>, <&gcc GCC_SSC_BCR>;
+ reset-names = "ssc_reset", "ssc_bcr";
+
+ power-domains = <&rpmpd MSM8998_SSCCX>, <&rpmpd MSM8998_SSCMX>;
+ power-domain-names = "ssc_cx", "ssc_mx";
+
+ qcom,halt-regs = <&tcsr_mutex_regs 0x26000>;
+
+ ssc_tlmm: pinctrl@5e10000 {
+ compatible = "qcom,msm8998-ssc-tlmm-pinctrl";
+ reg = <0x5E10000 0x10000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&ssc_tlmm 0 0 20>;
+ };
+ };
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH v4 2/5] clk: qcom: gcc-msm8998: add SSC-related clocks
From: michael.srba @ 2022-01-26 18:32 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Rob Herring, Stephen Boyd,
Philipp Zabel
Cc: Linus Walleij, Florian Fainelli, Arnd Bergmann,
Greg Kroah-Hartman, Saravana Kannan, linux-arm-msm, linux-clk,
devicetree, Michael Srba
In-Reply-To: <20220126183250.11924-1-michael.srba@seznam.cz>
From: Michael Srba <Michael.Srba@seznam.cz>
This patch adds four clocks which need to be manipulated in order to
initialize the AHB bus which exposes the SCC block in the global address
space.
If a device is known to be configured such that writing to these
registers from Linux is not permitted, the 'protected-clocks'
device tree property must be used to denote that fact.
Signed-off-by: Michael Srba <Michael.Srba@seznam.cz>
---
CHANGES:
- v2: none
- v3: none
- v4: reword the commit message
---
drivers/clk/qcom/gcc-msm8998.c | 56 ++++++++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/drivers/clk/qcom/gcc-msm8998.c b/drivers/clk/qcom/gcc-msm8998.c
index 407e2c5caea4..2d14c3d672fc 100644
--- a/drivers/clk/qcom/gcc-msm8998.c
+++ b/drivers/clk/qcom/gcc-msm8998.c
@@ -2833,6 +2833,58 @@ static struct clk_branch gcc_rx1_usb2_clkref_clk = {
},
};
+static struct clk_branch gcc_im_sleep_clk = {
+ .halt_reg = 0x4300C,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x4300C,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "gcc_im_sleep_clk",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch aggre2_snoc_north_axi_clk = {
+ .halt_reg = 0x83010,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x83010,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "aggre2_snoc_north_axi_clk",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch ssc_xo_clk = {
+ .halt_reg = 0x63018,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x63018,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "ssc_xo_clk",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch ssc_cnoc_ahbs_clk = {
+ .halt_reg = 0x6300C,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x6300C,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "ssc_cnoc_ahbs_clk",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
static struct gdsc pcie_0_gdsc = {
.gdscr = 0x6b004,
.gds_hw_ctrl = 0x0,
@@ -3036,6 +3088,10 @@ static struct clk_regmap *gcc_msm8998_clocks[] = {
[GCC_MSS_MNOC_BIMC_AXI_CLK] = &gcc_mss_mnoc_bimc_axi_clk.clkr,
[GCC_MMSS_GPLL0_CLK] = &gcc_mmss_gpll0_clk.clkr,
[HMSS_GPLL0_CLK_SRC] = &hmss_gpll0_clk_src.clkr,
+ [GCC_IM_SLEEP] = &gcc_im_sleep_clk.clkr,
+ [AGGRE2_SNOC_NORTH_AXI] = &aggre2_snoc_north_axi_clk.clkr,
+ [SSC_XO] = &ssc_xo_clk.clkr,
+ [SSC_CNOC_AHBS_CLK] = &ssc_cnoc_ahbs_clk.clkr,
};
static struct gdsc *gcc_msm8998_gdscs[] = {
--
2.34.1
^ permalink raw reply related
* [PATCH v4 5/5] arm64: dts: qcom: msm8998: reserve potentially inaccessible clocks
From: michael.srba @ 2022-01-26 18:32 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Rob Herring, Stephen Boyd,
Philipp Zabel
Cc: Linus Walleij, Florian Fainelli, Arnd Bergmann,
Greg Kroah-Hartman, Saravana Kannan, linux-arm-msm, linux-clk,
devicetree, Michael Srba, Michael Srba
In-Reply-To: <20220126183250.11924-1-michael.srba@seznam.cz>
From: Michael Srba <michael.srba@seznam.cz>
With the gcc driver now being more complete and describing clocks which
might not always be write-accessible to the OS, conservatively specify
all such clocks as protected in the SoC dts.
The board dts - or even user-supplied dts - can override this property
to reflect the actual configuration.
Signed-off-by: Michael Srba <Michael.Srba@seznam.cz>
---
CHANGES:
- v2: add this patch
- v3: fix missing Signed-off-by
- v4: add a proper explanation as per review, (hopefully) fix the subject and commit message
---
arch/arm64/boot/dts/qcom/msm8998.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index f273bc1ff629..16dccf9d881e 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -863,6 +863,21 @@ gcc: clock-controller@100000 {
clock-names = "xo", "sleep_clk";
clocks = <&xo>, <&sleep_clk>;
+
+ /*
+ * The hypervisor typically configures the memory region where these clocks
+ * reside as read-only for the HLOS. If the HLOS tried to enable or disable
+ * these clocks on a device with such configuration (e.g. because they are
+ * enabled but unused during boot-up), the device will most likely decide
+ * to reboot.
+ * In light of that, we are conservative here and we list all such clocks
+ * as protected. The board dts (or a user-supplied dts) can override the
+ * list of protected clocks if it differs from the norm, and it is in fact
+ * desired for the HLOS to manage these clocks
+ */
+ protected-clocks = <AGGRE2_SNOC_NORTH_AXI>,
+ <SSC_XO>,
+ <SSC_CNOC_AHBS_CLK>;
};
rpm_msg_ram: sram@778000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v4 1/5] dt-bindings: clock: gcc-msm8998: Add definitions of SSC-related clocks
From: michael.srba @ 2022-01-26 18:32 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Rob Herring, Stephen Boyd,
Philipp Zabel
Cc: Linus Walleij, Florian Fainelli, Arnd Bergmann,
Greg Kroah-Hartman, Saravana Kannan, linux-arm-msm, linux-clk,
devicetree, Michael Srba
From: Michael Srba <Michael.Srba@seznam.cz>
This patch adds definitions of four clocks which need to be manipulated
in order to initialize the AHB bus which exposes the SCC block in the
global address space.
Signed-off-by: Michael Srba <Michael.Srba@seznam.cz>
---
CHANGES:
- v2: none
- v3: none
- v4: none
---
include/dt-bindings/clock/qcom,gcc-msm8998.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/dt-bindings/clock/qcom,gcc-msm8998.h b/include/dt-bindings/clock/qcom,gcc-msm8998.h
index 72c99e486d86..1badb4f9c58f 100644
--- a/include/dt-bindings/clock/qcom,gcc-msm8998.h
+++ b/include/dt-bindings/clock/qcom,gcc-msm8998.h
@@ -186,6 +186,10 @@
#define UFS_UNIPRO_CORE_CLK_SRC 177
#define GCC_MMSS_GPLL0_CLK 178
#define HMSS_GPLL0_CLK_SRC 179
+#define GCC_IM_SLEEP 180
+#define AGGRE2_SNOC_NORTH_AXI 181
+#define SSC_XO 182
+#define SSC_CNOC_AHBS_CLK 183
#define PCIE_0_GDSC 0
#define UFS_GDSC 1
--
2.34.1
^ permalink raw reply related
* [PATCH v4 4/5] drivers: bus: add driver for initializing the SSC bus on (some) qcom SoCs
From: michael.srba @ 2022-01-26 18:32 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Rob Herring, Stephen Boyd,
Philipp Zabel
Cc: Linus Walleij, Florian Fainelli, Arnd Bergmann,
Greg Kroah-Hartman, Saravana Kannan, linux-arm-msm, linux-clk,
devicetree, Michael Srba
In-Reply-To: <20220126183250.11924-1-michael.srba@seznam.cz>
From: Michael Srba <Michael.Srba@seznam.cz>
This patch adds bindings for the AHB bus which exposes the SCC block in
the global address space. This bus (and the SSC block itself) is present
on certain qcom SoCs.
In typical configuration, this bus (as some of the clocks and registers
that we need to manipulate) is not accessible to Linux, and the resources
on this bus are indirectly accessed by communicating with a hexagon CPU
core residing in the SSC block. In this configuration, the hypervisor is
the one performing the bus initialization for the purposes of bringing
the haxagon CPU core out of reset.
However, it is possible to change the configuration, in which case this
driver will initialize the bus.
In combination with drivers for resources on the SSC bus, this driver can
aid in debugging, and for example with a TLMM driver can be used to
directly access SSC-dedicated GPIO pins, removing the need to commit
to a particular usecase during hw design.
Finally, until open firmware for the hexagon core is available, this
approach allows for using sensors hooked up to SSC-dedicated GPIO pins
on mainline Linux simply by utilizing the existing in-tree drivers for
these sensors.
Signed-off-by: Michael Srba <Michael.Srba@seznam.cz>
---
CHANGES:
- v2: none
- v3: fix clang warning
- v4: address the issues pointed out in the review
---
drivers/bus/Kconfig | 6 +
drivers/bus/Makefile | 1 +
drivers/bus/qcom-ssc-block-bus.c | 383 +++++++++++++++++++++++++++++++
3 files changed, 390 insertions(+)
create mode 100644 drivers/bus/qcom-ssc-block-bus.c
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 3c68e174a113..f2b2e3098491 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -173,6 +173,12 @@ config SUNXI_RSB
with various RSB based devices, such as AXP223, AXP8XX PMICs,
and AC100/AC200 ICs.
+config QCOM_SSC_BLOCK_BUS
+ bool "Qualcomm SSC Block Bus Init Driver"
+ help
+ Say y here to enable support for initializing the bus that connects the SSC block's internal
+ bus to the cNoC on (some) qcom SoCs
+
config TEGRA_ACONNECT
tristate "Tegra ACONNECT Bus Driver"
depends on ARCH_TEGRA_210_SOC
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index 52c2f35a26a9..e6756e83a9c4 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_OMAP_INTERCONNECT) += omap_l3_smx.o omap_l3_noc.o
obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o
obj-$(CONFIG_QCOM_EBI2) += qcom-ebi2.o
+obj-$(CONFIG_QCOM_SSC_BLOCK_BUS) += qcom-ssc-block-bus.o
obj-$(CONFIG_SUN50I_DE2_BUS) += sun50i-de2.o
obj-$(CONFIG_SUNXI_RSB) += sunxi-rsb.o
obj-$(CONFIG_OF) += simple-pm-bus.o
diff --git a/drivers/bus/qcom-ssc-block-bus.c b/drivers/bus/qcom-ssc-block-bus.c
new file mode 100644
index 000000000000..e489f5614e90
--- /dev/null
+++ b/drivers/bus/qcom-ssc-block-bus.c
@@ -0,0 +1,383 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright (c) 2021, Michael Srba
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/pm_clock.h>
+#include <linux/pm_domain.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+
+/* AXI Halt Register Offsets */
+#define AXI_HALTREQ_REG 0x0
+#define AXI_HALTACK_REG 0x4
+#define AXI_IDLE_REG 0x8
+
+static const char *const qcom_ssc_block_pd_names[] = {
+ "ssc_cx",
+ "ssc_mx"
+};
+
+struct qcom_ssc_block_bus_data {
+ int num_pds;
+ const char *const *pd_names;
+ struct device *pds[ARRAY_SIZE(qcom_ssc_block_pd_names)];
+ char __iomem *reg_mpm_sscaon_config0; // MPM - msm power manager; AON - always-on
+ char __iomem *reg_mpm_sscaon_config1; // that's as much as we know about these
+ struct regmap *halt_map;
+ u32 ssc_axi_halt;
+ struct clk *xo_clk;
+ struct clk *aggre2_clk;
+ struct clk *gcc_im_sleep_clk;
+ struct clk *aggre2_north_clk;
+ struct clk *ssc_xo_clk;
+ struct clk *ssc_ahbs_clk;
+ struct reset_control *ssc_bcr;
+ struct reset_control *ssc_reset;
+};
+
+static void reg32_set_bits(char __iomem *reg, u32 value)
+{
+ u32 tmp = ioread32(reg);
+
+ iowrite32(tmp | value, reg);
+}
+
+static void reg32_clear_bits(char __iomem *reg, u32 value)
+{
+ u32 tmp = ioread32(reg);
+
+ iowrite32(tmp & (~value), reg);
+}
+
+
+static int qcom_ssc_block_bus_init(struct device *dev)
+{
+ int ret;
+
+ struct qcom_ssc_block_bus_data *data = dev_get_drvdata(dev);
+
+ ret = clk_prepare_enable(data->xo_clk);
+ if (ret) {
+ dev_err(dev, "error enabling xo_clk: %d\n", ret);
+ goto err_xo_clk;
+ }
+
+ ret = clk_prepare_enable(data->aggre2_clk);
+ if (ret) {
+ dev_err(dev, "error enabling aggre2_clk: %d\n", ret);
+ goto err_aggre2_clk;
+ }
+
+ ret = clk_prepare_enable(data->gcc_im_sleep_clk);
+ if (ret) {
+ dev_err(dev, "error enabling gcc_im_sleep_clk: %d\n", ret);
+ goto err_gcc_im_sleep_clk;
+ }
+
+ reg32_clear_bits(data->reg_mpm_sscaon_config0, BIT(4) | BIT(5));
+ reg32_clear_bits(data->reg_mpm_sscaon_config1, BIT(31));
+
+ ret = clk_prepare_enable(data->aggre2_north_clk);
+ if (ret) {
+ dev_err(dev, "error enabling aggre2_north_clk: %d\n", ret);
+ goto err_aggre2_north_clk;
+ }
+
+ ret = reset_control_deassert(data->ssc_reset);
+ if (ret) {
+ dev_err(dev, "error deasserting ssc_reset: %d\n", ret);
+ goto err_ssc_reset;
+ }
+
+ ret = reset_control_deassert(data->ssc_bcr);
+ if (ret) {
+ dev_err(dev, "error deasserting ssc_bcr: %d\n", ret);
+ goto err_ssc_bcr;
+ }
+
+ regmap_write(data->halt_map, data->ssc_axi_halt + AXI_HALTREQ_REG, 0);
+
+ ret = clk_prepare_enable(data->ssc_xo_clk);
+ if (ret) {
+ dev_err(dev, "error deasserting ssc_xo_clk: %d\n", ret);
+ goto err_ssc_xo_clk;
+ }
+
+ ret = clk_prepare_enable(data->ssc_ahbs_clk);
+ if (ret) {
+ dev_err(dev, "error deasserting ssc_ahbs_clk: %d\n", ret);
+ goto err_ssc_ahbs_clk;
+ }
+
+ return 0;
+
+err_ssc_ahbs_clk:
+ clk_disable(data->ssc_xo_clk);
+
+err_ssc_xo_clk:
+ regmap_write(data->halt_map, data->ssc_axi_halt + AXI_HALTREQ_REG, 1);
+
+ reset_control_assert(data->ssc_bcr);
+
+err_ssc_bcr:
+ reset_control_assert(data->ssc_reset);
+
+err_ssc_reset:
+ clk_disable(data->aggre2_north_clk);
+
+err_aggre2_north_clk:
+ reg32_set_bits(data->reg_mpm_sscaon_config0, BIT(4) | BIT(5));
+ reg32_set_bits(data->reg_mpm_sscaon_config1, BIT(31));
+
+ clk_disable(data->gcc_im_sleep_clk);
+
+err_gcc_im_sleep_clk:
+ clk_disable(data->aggre2_clk);
+
+err_aggre2_clk:
+ clk_disable(data->xo_clk);
+
+err_xo_clk:
+ return ret;
+}
+
+static void qcom_ssc_block_bus_deinit(struct device *dev)
+{
+ int ret;
+
+ struct qcom_ssc_block_bus_data *data = dev_get_drvdata(dev);
+
+ clk_disable(data->ssc_xo_clk);
+ clk_disable(data->ssc_ahbs_clk);
+
+ ret = reset_control_assert(data->ssc_bcr);
+ if (ret)
+ dev_err(dev, "error asserting ssc_bcr: %d\n", ret);
+
+ regmap_write(data->halt_map, data->ssc_axi_halt + AXI_HALTREQ_REG, 1);
+
+ reg32_set_bits(data->reg_mpm_sscaon_config1, BIT(31));
+ reg32_set_bits(data->reg_mpm_sscaon_config0, BIT(4) | BIT(5));
+
+ ret = reset_control_assert(data->ssc_reset);
+ if (ret)
+ dev_err(dev, "error asserting ssc_reset: %d\n", ret);
+
+ clk_disable(data->gcc_im_sleep_clk);
+
+ clk_disable(data->aggre2_north_clk);
+
+ clk_disable(data->aggre2_clk);
+ clk_disable(data->xo_clk);
+}
+
+
+static int qcom_ssc_block_bus_pds_attach(struct device *dev, struct device **pds,
+ const char *const *pd_names, size_t num_pds)
+{
+ int ret;
+ int i;
+
+ for (i = 0; i < num_pds; i++) {
+ pds[i] = dev_pm_domain_attach_by_name(dev, pd_names[i]);
+ if (IS_ERR_OR_NULL(pds[i])) {
+ ret = PTR_ERR(pds[i]) ? : -ENODATA;
+ goto unroll_attach;
+ }
+ }
+
+ return num_pds;
+
+unroll_attach:
+ for (i--; i >= 0; i--)
+ dev_pm_domain_detach(pds[i], false);
+
+ return ret;
+};
+
+static void qcom_ssc_block_bus_pds_detach(struct device *dev, struct device **pds, size_t num_pds)
+{
+ int i;
+
+ for (i = 0; i < num_pds; i++)
+ dev_pm_domain_detach(pds[i], false);
+}
+
+static int qcom_ssc_block_bus_pds_enable(struct device **pds, size_t num_pds)
+{
+ int ret;
+ int i;
+
+ for (i = 0; i < num_pds; i++) {
+ dev_pm_genpd_set_performance_state(pds[i], INT_MAX);
+ ret = pm_runtime_get_sync(pds[i]);
+ if (ret < 0)
+ goto unroll_pd_votes;
+ }
+
+ return 0;
+
+unroll_pd_votes:
+ for (i--; i >= 0; i--) {
+ dev_pm_genpd_set_performance_state(pds[i], 0);
+ pm_runtime_put(pds[i]);
+ }
+
+ return ret;
+};
+
+static void qcom_ssc_block_bus_pds_disable(struct device **pds, size_t num_pds)
+{
+ int i;
+
+ for (i = 0; i < num_pds; i++) {
+ dev_pm_genpd_set_performance_state(pds[i], 0);
+ pm_runtime_put(pds[i]);
+ }
+}
+
+static int qcom_ssc_block_bus_probe(struct platform_device *pdev)
+{
+ struct qcom_ssc_block_bus_data *data;
+ struct device_node *np = pdev->dev.of_node;
+ struct of_phandle_args halt_args;
+ struct resource *res;
+ int ret;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, data);
+
+ data->pd_names = qcom_ssc_block_pd_names;
+ data->num_pds = ARRAY_SIZE(qcom_ssc_block_pd_names);
+
+ // power domains
+ ret = qcom_ssc_block_bus_pds_attach(&pdev->dev, data->pds, data->pd_names, data->num_pds);
+ if (ret < 0)
+ return dev_err_probe(&pdev->dev, ret, "error when attaching power domains\n");
+
+ ret = qcom_ssc_block_bus_pds_enable(data->pds, data->num_pds);
+ if (ret < 0)
+ return dev_err_probe(&pdev->dev, ret, "error when enabling power domains\n");
+
+ // the meaning of the bits in these two registers is sadly not documented,
+ // the set/clear operations are just copying what qcom does
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mpm_sscaon_config0");
+ data->reg_mpm_sscaon_config0 = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(data->reg_mpm_sscaon_config0))
+ return dev_err_probe(&pdev->dev, PTR_ERR(data->reg_mpm_sscaon_config0),
+ "Failed to ioremap mpm_sscaon_config0\n");
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mpm_sscaon_config1");
+ data->reg_mpm_sscaon_config1 = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(data->reg_mpm_sscaon_config1))
+ return dev_err_probe(&pdev->dev, PTR_ERR(data->reg_mpm_sscaon_config1),
+ "Failed to ioremap mpm_sscaon_config1\n");
+
+ // resets
+ data->ssc_bcr = devm_reset_control_get_exclusive(&pdev->dev, "ssc_bcr");
+ if (IS_ERR(data->ssc_bcr))
+ return dev_err_probe(&pdev->dev, PTR_ERR(data->ssc_bcr),
+ "Failed to acquire reset: scc_bcr\n");
+
+ data->ssc_reset = devm_reset_control_get_exclusive(&pdev->dev, "ssc_reset");
+ if (IS_ERR(data->ssc_reset))
+ return dev_err_probe(&pdev->dev, PTR_ERR(data->ssc_reset),
+ "Failed to acquire reset: ssc_reset:\n");
+
+ // clocks
+ data->xo_clk = devm_clk_get(&pdev->dev, "xo");
+ if (IS_ERR(data->xo_clk))
+ return dev_err_probe(&pdev->dev, PTR_ERR(data->xo_clk),
+ "Failed to get clock: xo\n");
+
+ data->aggre2_clk = devm_clk_get(&pdev->dev, "aggre2");
+ if (IS_ERR(data->aggre2_clk))
+ return dev_err_probe(&pdev->dev, PTR_ERR(data->aggre2_clk),
+ "Failed to get clock: aggre2\n");
+
+ data->gcc_im_sleep_clk = devm_clk_get(&pdev->dev, "gcc_im_sleep");
+ if (IS_ERR(data->gcc_im_sleep_clk))
+ return dev_err_probe(&pdev->dev, PTR_ERR(data->gcc_im_sleep_clk),
+ "Failed to get clock: gcc_im_sleep\n");
+
+ data->aggre2_north_clk = devm_clk_get(&pdev->dev, "aggre2_north");
+ if (IS_ERR(data->aggre2_north_clk))
+ return dev_err_probe(&pdev->dev, PTR_ERR(data->aggre2_north_clk),
+ "Failed to get clock: aggre2_north\n");
+
+ data->ssc_xo_clk = devm_clk_get(&pdev->dev, "ssc_xo");
+ if (IS_ERR(data->ssc_xo_clk))
+ return dev_err_probe(&pdev->dev, PTR_ERR(data->ssc_xo_clk),
+ "Failed to get clock: ssc_xo\n");
+
+ data->ssc_ahbs_clk = devm_clk_get(&pdev->dev, "ssc_ahbs");
+ if (IS_ERR(data->ssc_ahbs_clk))
+ return dev_err_probe(&pdev->dev, PTR_ERR(data->ssc_ahbs_clk),
+ "Failed to get clock: ssc_ahbs\n");
+
+ ret = of_parse_phandle_with_fixed_args(pdev->dev.of_node, "qcom,halt-regs", 1, 0,
+ &halt_args);
+ if (ret < 0)
+ return dev_err_probe(&pdev->dev, ret, "Failed to parse qcom,halt-regs\n");
+
+ data->halt_map = syscon_node_to_regmap(halt_args.np);
+ of_node_put(halt_args.np);
+ if (IS_ERR(data->halt_map))
+ return PTR_ERR(data->halt_map);
+
+ data->ssc_axi_halt = halt_args.args[0];
+
+ qcom_ssc_block_bus_init(&pdev->dev);
+
+ of_platform_populate(np, NULL, NULL, &pdev->dev);
+
+ return 0;
+}
+
+static int qcom_ssc_block_bus_remove(struct platform_device *pdev)
+{
+ struct qcom_ssc_block_bus_data *data = platform_get_drvdata(pdev);
+
+ qcom_ssc_block_bus_deinit(&pdev->dev);
+
+ iounmap(data->reg_mpm_sscaon_config0);
+ iounmap(data->reg_mpm_sscaon_config1);
+
+ qcom_ssc_block_bus_pds_disable(data->pds, data->num_pds);
+ qcom_ssc_block_bus_pds_detach(&pdev->dev, data->pds, data->num_pds);
+ pm_runtime_disable(&pdev->dev);
+ pm_clk_destroy(&pdev->dev);
+
+ return 0;
+}
+
+static const struct of_device_id qcom_ssc_block_bus_of_match[] = {
+ { .compatible = "qcom,ssc-block-bus", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, qcom_ssc_block_bus_of_match);
+
+static struct platform_driver qcom_ssc_block_bus_driver = {
+ .probe = qcom_ssc_block_bus_probe,
+ .remove = qcom_ssc_block_bus_remove,
+ .driver = {
+ .name = "qcom-ssc-block-bus",
+ .of_match_table = qcom_ssc_block_bus_of_match,
+ },
+};
+
+module_platform_driver(qcom_ssc_block_bus_driver);
+
+MODULE_DESCRIPTION("A driver for handling the init sequence needed for accessing the SSC block on (some) qcom SoCs over AHB");
+MODULE_AUTHOR("Michael Srba <Michael.Srba@seznam.cz>");
+MODULE_LICENSE("GPL v2");
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 02/12] misc: fastrpc: add support for FASTRPC_IOCTL_MEM_MAP/UNMAP
From: kernel test robot @ 2022-01-26 18:00 UTC (permalink / raw)
To: Srinivas Kandagatla, robh+dt, gregkh
Cc: kbuild-all, devicetree, ekangupt, bkumar, linux-kernel, srini,
bjorn.andersson, linux-arm-msm, Jeya R
In-Reply-To: <20220126135304.16340-3-srinivas.kandagatla@linaro.org>
Hi Srinivas,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on char-misc/char-misc-testing]
[also build test WARNING on robh/for-next linux/master linus/master v5.17-rc1 next-20220125]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Srinivas-Kandagatla/misc-fastrpc-Add-missing-DSP-FastRPC-features/20220126-215705
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git 515a2f507491e7c3818e74ef4f4e088c1fecb190
config: nds32-randconfig-r014-20220126 (https://download.01.org/0day-ci/archive/20220127/202201270134.bsVprnF9-lkp@intel.com/config)
compiler: nds32le-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/b1c0b7969aa491881596e862a90a07afae4bdfd7
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Srinivas-Kandagatla/misc-fastrpc-Add-missing-DSP-FastRPC-features/20220126-215705
git checkout b1c0b7969aa491881596e862a90a07afae4bdfd7
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=nds32 SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
drivers/misc/fastrpc.c: In function 'fastrpc_req_mem_unmap_impl':
>> drivers/misc/fastrpc.c:1544:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1544 | args[0].ptr = (u64) &req_msg;
| ^
drivers/misc/fastrpc.c: In function 'fastrpc_req_mem_map':
>> drivers/misc/fastrpc.c:1594:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
1594 | map->va = (void *) req.vaddrin;
| ^
drivers/misc/fastrpc.c:1599:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1599 | args[0].ptr = (u64) &req_msg;
| ^
drivers/misc/fastrpc.c:1605:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1605 | args[1].ptr = (u64) &pages;
| ^
drivers/misc/fastrpc.c:1608:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1608 | args[2].ptr = (u64) &pages;
| ^
drivers/misc/fastrpc.c:1611:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1611 | args[3].ptr = (u64) &rsp_msg;
| ^
vim +1544 drivers/misc/fastrpc.c
1515
1516 static int fastrpc_req_mem_unmap_impl(struct fastrpc_user *fl, struct fastrpc_mem_unmap *req)
1517 {
1518 struct fastrpc_invoke_args args[1] = { [0] = { 0 } };
1519 struct fastrpc_map *map = NULL, *m;
1520 struct fastrpc_mem_unmap_req_msg req_msg = { 0 };
1521 int err = 0;
1522 u32 sc;
1523 struct device *dev = fl->sctx->dev;
1524
1525 spin_lock(&fl->lock);
1526 list_for_each_entry_safe(map, m, &fl->maps, node) {
1527 if ((req->fd < 0 || map->fd == req->fd) && (map->raddr == req->vaddr))
1528 break;
1529 map = NULL;
1530 }
1531
1532 spin_unlock(&fl->lock);
1533
1534 if (!map) {
1535 dev_err(dev, "map not in list\n");
1536 return -EINVAL;
1537 }
1538
1539 req_msg.pgid = fl->tgid;
1540 req_msg.len = map->len;
1541 req_msg.vaddrin = map->raddr;
1542 req_msg.fd = map->fd;
1543
> 1544 args[0].ptr = (u64) &req_msg;
1545 args[0].length = sizeof(req_msg);
1546
1547 sc = FASTRPC_SCALARS(FASTRPC_RMID_INIT_MEM_UNMAP, 1, 0);
1548 err = fastrpc_internal_invoke(fl, true, FASTRPC_INIT_HANDLE, sc,
1549 &args[0]);
1550 fastrpc_map_put(map);
1551 if (err)
1552 dev_err(dev, "unmmap\tpt fd = %d, 0x%09llx error\n", map->fd, map->raddr);
1553
1554 return err;
1555 }
1556
1557 static int fastrpc_req_mem_unmap(struct fastrpc_user *fl, char __user *argp)
1558 {
1559 struct fastrpc_mem_unmap req;
1560
1561 if (copy_from_user(&req, argp, sizeof(req)))
1562 return -EFAULT;
1563
1564 return fastrpc_req_mem_unmap_impl(fl, &req);
1565 }
1566
1567 static int fastrpc_req_mem_map(struct fastrpc_user *fl, char __user *argp)
1568 {
1569 struct fastrpc_invoke_args args[4] = { [0 ... 3] = { 0 } };
1570 struct fastrpc_mem_map_req_msg req_msg = { 0 };
1571 struct fastrpc_mmap_rsp_msg rsp_msg = { 0 };
1572 struct fastrpc_mem_unmap req_unmap = { 0 };
1573 struct fastrpc_phy_page pages = { 0 };
1574 struct fastrpc_mem_map req;
1575 struct device *dev = fl->sctx->dev;
1576 struct fastrpc_map *map = NULL;
1577 int err;
1578 u32 sc;
1579
1580 if (copy_from_user(&req, argp, sizeof(req)))
1581 return -EFAULT;
1582
1583 /* create SMMU mapping */
1584 err = fastrpc_map_create(fl, req.fd, req.length, &map);
1585 if (err) {
1586 dev_err(dev, "failed to map buffer, fd = %d\n", req.fd);
1587 return err;
1588 }
1589
1590 req_msg.pgid = fl->tgid;
1591 req_msg.fd = req.fd;
1592 req_msg.offset = req.offset;
1593 req_msg.vaddrin = req.vaddrin;
> 1594 map->va = (void *) req.vaddrin;
1595 req_msg.flags = req.flags;
1596 req_msg.num = sizeof(pages);
1597 req_msg.data_len = 0;
1598
1599 args[0].ptr = (u64) &req_msg;
1600 args[0].length = sizeof(req_msg);
1601
1602 pages.addr = map->phys;
1603 pages.size = map->size;
1604
1605 args[1].ptr = (u64) &pages;
1606 args[1].length = sizeof(pages);
1607
1608 args[2].ptr = (u64) &pages;
1609 args[2].length = 0;
1610
1611 args[3].ptr = (u64) &rsp_msg;
1612 args[3].length = sizeof(rsp_msg);
1613
1614 sc = FASTRPC_SCALARS(FASTRPC_RMID_INIT_MEM_MAP, 3, 1);
1615 err = fastrpc_internal_invoke(fl, true, FASTRPC_INIT_HANDLE, sc, &args[0]);
1616 if (err) {
1617 dev_err(dev, "mem mmap error, fd %d, vaddr %llx, size %lld\n",
1618 req.fd, req.vaddrin, map->size);
1619 goto err_invoke;
1620 }
1621
1622 /* update the buffer to be able to deallocate the memory on the DSP */
1623 map->raddr = rsp_msg.vaddr;
1624
1625 /* let the client know the address to use */
1626 req.vaddrout = rsp_msg.vaddr;
1627
1628 if (copy_to_user((void __user *)argp, &req, sizeof(req))) {
1629 /* unmap the memory and release the buffer */
1630 req_unmap.vaddr = (uintptr_t) rsp_msg.vaddr;
1631 req_unmap.length = map->size;
1632 fastrpc_req_mem_unmap_impl(fl, &req_unmap);
1633 return -EFAULT;
1634 }
1635
1636 return 0;
1637
1638 err_invoke:
1639 if (map)
1640 fastrpc_map_put(map);
1641
1642 return err;
1643 }
1644
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [PATCH v4 8/8] ARM: mstar: Extend opp_table for infinity2m
From: Romain Perier @ 2022-01-26 17:56 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, linux-clk, Arnd Bergmann,
Daniel Palmer, Romain Perier, Rob Herring
Cc: devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20220126175604.17919-1-romain.perier@gmail.com>
infinity2m are running up to 1.2Ghz, this extends opp_table with the
corresponding frequencies and enable operating-points table for cpu1
Signed-off-by: Romain Perier <romain.perier@gmail.com>
---
arch/arm/boot/dts/mstar-infinity2m.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/mstar-infinity2m.dtsi b/arch/arm/boot/dts/mstar-infinity2m.dtsi
index dc339cd29778..1b485efd7156 100644
--- a/arch/arm/boot/dts/mstar-infinity2m.dtsi
+++ b/arch/arm/boot/dts/mstar-infinity2m.dtsi
@@ -6,10 +6,25 @@
#include "mstar-infinity.dtsi"
+&cpu0_opp_table {
+ opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ };
+
+ opp-1200000000 {
+ opp-hz = /bits/ 64 <1200000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ };
+};
+
&cpus {
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a7";
+ operating-points-v2 = <&cpu0_opp_table>;
reg = <0x1>;
clocks = <&cpupll>;
clock-names = "cpuclk";
--
2.34.1
^ permalink raw reply related
* [PATCH v4 7/8] ARM: mstar: Add OPP table for infinity3
From: Romain Perier @ 2022-01-26 17:56 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, linux-clk, Arnd Bergmann,
Daniel Palmer, Romain Perier, Rob Herring
Cc: devicetree, linux-arm-kernel, linux-kernel, Willy Tarreau
In-Reply-To: <20220126175604.17919-1-romain.perier@gmail.com>
From: Daniel Palmer <daniel@0x0f.com>
The infinity3 has a slightly higher max frequency
compared to the infinity so extend the OPP table.
Co-authored-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Reviewed-by: Romain Perier <romain.perier@gmail.com>
---
arch/arm/boot/dts/mstar-infinity3.dtsi | 58 ++++++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/arch/arm/boot/dts/mstar-infinity3.dtsi b/arch/arm/boot/dts/mstar-infinity3.dtsi
index 9857e2a9934d..a56cf29e5d82 100644
--- a/arch/arm/boot/dts/mstar-infinity3.dtsi
+++ b/arch/arm/boot/dts/mstar-infinity3.dtsi
@@ -6,6 +6,64 @@
#include "mstar-infinity.dtsi"
+&cpu0_opp_table {
+ opp-1008000000 {
+ opp-hz = /bits/ 64 <1008000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ };
+
+ // overclock frequencies below, shown to work fine up to 1.3 GHz
+ opp-108000000 {
+ opp-hz = /bits/ 64 <1080000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ turbo-mode;
+ };
+
+ opp-1188000000 {
+ opp-hz = /bits/ 64 <1188000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ turbo-mode;
+ };
+
+ opp-1296000000 {
+ opp-hz = /bits/ 64 <1296000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ turbo-mode;
+ };
+
+ opp-1350000000 {
+ opp-hz = /bits/ 64 <1350000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ turbo-mode;
+ };
+
+ opp-1404000000 {
+ opp-hz = /bits/ 64 <1404000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ turbo-mode;
+ };
+
+ opp-1458000000 {
+ opp-hz = /bits/ 64 <1458000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ turbo-mode;
+ };
+
+ opp-1512000000 {
+ opp-hz = /bits/ 64 <1512000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ turbo-mode;
+ };
+};
+
&imi {
reg = <0xa0000000 0x20000>;
};
--
2.34.1
^ permalink raw reply related
* [PATCH v4 6/8] ARM: mstar: Add OPP table for infinity
From: Romain Perier @ 2022-01-26 17:56 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, linux-clk, Arnd Bergmann,
Daniel Palmer, Romain Perier, Rob Herring
Cc: devicetree, linux-arm-kernel, linux-kernel, Willy Tarreau
In-Reply-To: <20220126175604.17919-1-romain.perier@gmail.com>
From: Daniel Palmer <daniel@0x0f.com>
Add an OPP table for the inifinity chips so
that cpu frequency scaling can happen.
Co-authored-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Reviewed-by: Romain Perier <romain.perier@gmail.com>
---
arch/arm/boot/dts/mstar-infinity.dtsi | 34 +++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/mstar-infinity.dtsi b/arch/arm/boot/dts/mstar-infinity.dtsi
index 0bee517797f4..441a917b88ba 100644
--- a/arch/arm/boot/dts/mstar-infinity.dtsi
+++ b/arch/arm/boot/dts/mstar-infinity.dtsi
@@ -8,6 +8,40 @@
#include <dt-bindings/gpio/msc313-gpio.h>
+/ {
+ cpu0_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-240000000 {
+ opp-hz = /bits/ 64 <240000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ };
+
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ };
+ opp-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ };
+
+ opp-800000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ };
+ };
+};
+
+&cpu0 {
+ operating-points-v2 = <&cpu0_opp_table>;
+};
+
&imi {
reg = <0xa0000000 0x16000>;
};
--
2.34.1
^ permalink raw reply related
* [PATCH v4 5/8] ARM: mstar: Link cpupll to second core
From: Romain Perier @ 2022-01-26 17:56 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, linux-clk, Arnd Bergmann,
Daniel Palmer, Romain Perier, Rob Herring
Cc: devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20220126175604.17919-1-romain.perier@gmail.com>
From: Daniel Palmer <daniel@0x0f.com>
The second core also sources it's clock from the CPU PLL.
Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Reviewed-by: Romain Perier <romain.perier@gmail.com>
---
arch/arm/boot/dts/mstar-infinity2m.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/mstar-infinity2m.dtsi b/arch/arm/boot/dts/mstar-infinity2m.dtsi
index 6d4d1d224e96..dc339cd29778 100644
--- a/arch/arm/boot/dts/mstar-infinity2m.dtsi
+++ b/arch/arm/boot/dts/mstar-infinity2m.dtsi
@@ -11,6 +11,8 @@ cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x1>;
+ clocks = <&cpupll>;
+ clock-names = "cpuclk";
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH v4 4/8] ARM: mstar: Link cpupll to cpu
From: Romain Perier @ 2022-01-26 17:56 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, linux-clk, Arnd Bergmann,
Daniel Palmer, Romain Perier, Rob Herring
Cc: devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20220126175604.17919-1-romain.perier@gmail.com>
From: Daniel Palmer <daniel@0x0f.com>
The CPU clock is sourced from the CPU PLL.
Link cpupll to the cpu so that frequency scaling can happen.
Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Reviewed-by: Romain Perier <romain.perier@gmail.com>
---
arch/arm/boot/dts/mstar-v7.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/mstar-v7.dtsi b/arch/arm/boot/dts/mstar-v7.dtsi
index 2249faaa3aa7..c26ba9b7b6dd 100644
--- a/arch/arm/boot/dts/mstar-v7.dtsi
+++ b/arch/arm/boot/dts/mstar-v7.dtsi
@@ -21,6 +21,8 @@ cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x0>;
+ clocks = <&cpupll>;
+ clock-names = "cpuclk";
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH v4 3/8] ARM: mstar: Add cpupll to base dtsi
From: Romain Perier @ 2022-01-26 17:55 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, linux-clk, Arnd Bergmann,
Daniel Palmer, Romain Perier, Rob Herring
Cc: devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20220126175604.17919-1-romain.perier@gmail.com>
From: Daniel Palmer <daniel@0x0f.com>
All MStar/SigmaStar ARMv7 SoCs have the CPU PLL at the same
place so add it to the base dtsi.
Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Reviewed-by: Romain Perier <romain.perier@gmail.com>
---
arch/arm/boot/dts/mstar-v7.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/mstar-v7.dtsi b/arch/arm/boot/dts/mstar-v7.dtsi
index 89ebfe4f29da..2249faaa3aa7 100644
--- a/arch/arm/boot/dts/mstar-v7.dtsi
+++ b/arch/arm/boot/dts/mstar-v7.dtsi
@@ -155,6 +155,13 @@ mpll: mpll@206000 {
clocks = <&xtal>;
};
+ cpupll: cpupll@206400 {
+ compatible = "mstar,msc313-cpupll";
+ reg = <0x206400 0x200>;
+ #clock-cells = <0>;
+ clocks = <&mpll MSTAR_MSC313_MPLL_DIV2>;
+ };
+
gpio: gpio@207800 {
#gpio-cells = <2>;
reg = <0x207800 0x200>;
--
2.34.1
^ permalink raw reply related
* [PATCH v4 2/8] clk: mstar: msc313 cpupll clk driver
From: Romain Perier @ 2022-01-26 17:55 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, linux-clk, Arnd Bergmann,
Daniel Palmer, Romain Perier, Rob Herring
Cc: devicetree, linux-arm-kernel, linux-kernel, Willy Tarreau
In-Reply-To: <20220126175604.17919-1-romain.perier@gmail.com>
From: Daniel Palmer <daniel@0x0f.com>
Add a driver for the CPU pll/ARM pll/MIPS pll that is present
in MStar SoCs.
Currently there is no documentation for this block so it's possible
this driver isn't entirely correct.
Only tested on the version of this IP in the MStar/SigmaStar
ARMv7 SoCs.
Co-authored-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Daniel Palmer <daniel@0x0f.com>
---
drivers/clk/mstar/Kconfig | 8 +
drivers/clk/mstar/Makefile | 2 +-
drivers/clk/mstar/clk-msc313-cpupll.c | 221 ++++++++++++++++++++++++++
3 files changed, 230 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/mstar/clk-msc313-cpupll.c
diff --git a/drivers/clk/mstar/Kconfig b/drivers/clk/mstar/Kconfig
index de37e1bce2d2..146eeb637318 100644
--- a/drivers/clk/mstar/Kconfig
+++ b/drivers/clk/mstar/Kconfig
@@ -1,4 +1,11 @@
# SPDX-License-Identifier: GPL-2.0-only
+config MSTAR_MSC313_CPUPLL
+ bool "MStar CPUPLL driver"
+ depends on ARCH_MSTARV7 || COMPILE_TEST
+ default ARCH_MSTARV7
+ help
+ Support for the CPU PLL present on MStar/Sigmastar SoCs.
+
config MSTAR_MSC313_MPLL
bool "MStar MPLL driver"
depends on ARCH_MSTARV7 || COMPILE_TEST
@@ -7,3 +14,4 @@ config MSTAR_MSC313_MPLL
help
Support for the MPLL PLL and dividers block present on
MStar/Sigmastar SoCs.
+
diff --git a/drivers/clk/mstar/Makefile b/drivers/clk/mstar/Makefile
index f8dcd25ede1d..21296a04e65a 100644
--- a/drivers/clk/mstar/Makefile
+++ b/drivers/clk/mstar/Makefile
@@ -2,5 +2,5 @@
#
# Makefile for mstar specific clk
#
-
+obj-$(CONFIG_MSTAR_MSC313_CPUPLL) += clk-msc313-cpupll.o
obj-$(CONFIG_MSTAR_MSC313_MPLL) += clk-msc313-mpll.o
diff --git a/drivers/clk/mstar/clk-msc313-cpupll.c b/drivers/clk/mstar/clk-msc313-cpupll.c
new file mode 100644
index 000000000000..c57b509e8c20
--- /dev/null
+++ b/drivers/clk/mstar/clk-msc313-cpupll.c
@@ -0,0 +1,221 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Daniel Palmer <daniel@thingy.jp>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+
+/*
+ * This IP is not documented outside of the messy vendor driver.
+ * Below is what we think the registers look like based on looking at
+ * the vendor code and poking at the hardware:
+ *
+ * 0x140 -- LPF low. Seems to store one half of the clock transition
+ * 0x144 /
+ * 0x148 -- LPF high. Seems to store one half of the clock transition
+ * 0x14c /
+ * 0x150 -- vendor code says "toggle lpf enable"
+ * 0x154 -- mu?
+ * 0x15c -- lpf_update_count?
+ * 0x160 -- vendor code says "switch to LPF". Clock source config? Register bank?
+ * 0x164 -- vendor code says "from low to high" which seems to mean transition from LPF low to
+ * LPF high.
+ * 0x174 -- Seems to be the PLL lock status bit
+ * 0x180 -- Seems to be the current frequency, this might need to be populated by software?
+ * 0x184 / The vendor driver uses these to set the initial value of LPF low
+ *
+ * Frequency seems to be calculated like this:
+ * (parent clock (432mhz) / register_magic_value) * 16 * 524288
+ * Only the lower 24 bits of the resulting value will be used. In addition, the
+ * PLL doesn't seem to be able to lock on frequencies lower than 220 MHz, as
+ * divisor 0xfb586f (220 MHz) works but 0xfb7fff locks up.
+ *
+ * Vendor values:
+ * frequency - register value
+ *
+ * 400000000 - 0x0067AE14
+ * 600000000 - 0x00451EB8,
+ * 800000000 - 0x0033D70A,
+ * 1000000000 - 0x002978d4,
+ */
+
+#define REG_LPF_LOW_L 0x140
+#define REG_LPF_LOW_H 0x144
+#define REG_LPF_HIGH_BOTTOM 0x148
+#define REG_LPF_HIGH_TOP 0x14c
+#define REG_LPF_TOGGLE 0x150
+#define REG_LPF_MYSTERYTWO 0x154
+#define REG_LPF_UPDATE_COUNT 0x15c
+#define REG_LPF_MYSTERYONE 0x160
+#define REG_LPF_TRANSITIONCTRL 0x164
+#define REG_LPF_LOCK 0x174
+#define REG_CURRENT 0x180
+
+#define LPF_LOCK_TIMEOUT 100000000
+
+#define MULTIPLIER_1 16
+#define MULTIPLIER_2 524288
+#define MULTIPLIER (MULTIPLIER_1 * MULTIPLIER_2)
+
+struct msc313_cpupll {
+ void __iomem *base;
+ struct clk_hw clk_hw;
+};
+
+#define to_cpupll(_hw) container_of(_hw, struct msc313_cpupll, clk_hw)
+
+static u32 msc313_cpupll_reg_read32(struct msc313_cpupll *cpupll, unsigned int reg)
+{
+ u32 value;
+
+ value = ioread16(cpupll->base + reg + 4) << 16;
+ value |= ioread16(cpupll->base + reg);
+
+ return value;
+}
+
+static void msc313_cpupll_reg_write32(struct msc313_cpupll *cpupll, unsigned int reg, u32 value)
+{
+ u16 l = value & 0xffff, h = (value >> 16) & 0xffff;
+
+ iowrite16(l, cpupll->base + reg);
+ iowrite16(h, cpupll->base + reg + 4);
+}
+
+static void msc313_cpupll_setfreq(struct msc313_cpupll *cpupll, u32 regvalue)
+{
+ ktime_t timeout;
+
+ msc313_cpupll_reg_write32(cpupll, REG_LPF_HIGH_BOTTOM, regvalue);
+
+ iowrite16(0x1, cpupll->base + REG_LPF_MYSTERYONE);
+ iowrite16(0x6, cpupll->base + REG_LPF_MYSTERYTWO);
+ iowrite16(0x8, cpupll->base + REG_LPF_UPDATE_COUNT);
+ iowrite16(BIT(12), cpupll->base + REG_LPF_TRANSITIONCTRL);
+
+ iowrite16(0, cpupll->base + REG_LPF_TOGGLE);
+ iowrite16(1, cpupll->base + REG_LPF_TOGGLE);
+
+ timeout = ktime_add_ns(ktime_get(), LPF_LOCK_TIMEOUT);
+ while (!(ioread16(cpupll->base + REG_LPF_LOCK))) {
+ if (ktime_after(ktime_get(), timeout)) {
+ pr_err("timeout waiting for LPF_LOCK\n");
+ return;
+ }
+ cpu_relax();
+ }
+
+ iowrite16(0, cpupll->base + REG_LPF_TOGGLE);
+
+ msc313_cpupll_reg_write32(cpupll, REG_LPF_LOW_L, regvalue);
+}
+
+static unsigned long msc313_cpupll_frequencyforreg(u32 reg, unsigned long parent_rate)
+{
+ unsigned long long prescaled = ((unsigned long long)parent_rate) * MULTIPLIER;
+
+ if (prescaled == 0 || reg == 0)
+ return 0;
+ return DIV_ROUND_DOWN_ULL(prescaled, reg);
+}
+
+static u32 msc313_cpupll_regforfrequecy(unsigned long rate, unsigned long parent_rate)
+{
+ unsigned long long prescaled = ((unsigned long long)parent_rate) * MULTIPLIER;
+
+ if (prescaled == 0 || rate == 0)
+ return 0;
+ return DIV_ROUND_UP_ULL(prescaled, rate);
+}
+
+static unsigned long msc313_cpupll_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
+{
+ struct msc313_cpupll *cpupll = to_cpupll(hw);
+
+ return msc313_cpupll_frequencyforreg(msc313_cpupll_reg_read32(cpupll, REG_LPF_LOW_L),
+ parent_rate);
+}
+
+static long msc313_cpupll_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+{
+ u32 reg = msc313_cpupll_regforfrequecy(rate, *parent_rate);
+ long rounded = msc313_cpupll_frequencyforreg(reg, *parent_rate);
+
+ /*
+ * This is my poor attempt at making sure the resulting
+ * rate doesn't overshoot the requested rate.
+ */
+ for (; rounded >= rate && reg > 0; reg--)
+ rounded = msc313_cpupll_frequencyforreg(reg, *parent_rate);
+
+ return rounded;
+}
+
+static int msc313_cpupll_set_rate(struct clk_hw *hw, unsigned long rate, unsigned long parent_rate)
+{
+ struct msc313_cpupll *cpupll = to_cpupll(hw);
+ u32 reg = msc313_cpupll_regforfrequecy(rate, parent_rate);
+
+ msc313_cpupll_setfreq(cpupll, reg);
+
+ return 0;
+}
+
+static const struct clk_ops msc313_cpupll_ops = {
+ .recalc_rate = msc313_cpupll_recalc_rate,
+ .round_rate = msc313_cpupll_round_rate,
+ .set_rate = msc313_cpupll_set_rate,
+};
+
+static const struct of_device_id msc313_cpupll_of_match[] = {
+ { .compatible = "mstar,msc313-cpupll" },
+ {}
+};
+
+static const struct clk_parent_data cpupll_parent = {
+ .index = 0,
+};
+
+static int msc313_cpupll_probe(struct platform_device *pdev)
+{
+ struct clk_init_data clk_init = {};
+ struct device *dev = &pdev->dev;
+ struct msc313_cpupll *cpupll;
+ int ret;
+
+ cpupll = devm_kzalloc(&pdev->dev, sizeof(*cpupll), GFP_KERNEL);
+ if (!cpupll)
+ return -ENOMEM;
+
+ cpupll->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(cpupll->base))
+ return PTR_ERR(cpupll->base);
+
+ /* LPF might not contain the current frequency so fix that up */
+ msc313_cpupll_reg_write32(cpupll, REG_LPF_LOW_L,
+ msc313_cpupll_reg_read32(cpupll, REG_CURRENT));
+
+ clk_init.name = dev_name(dev);
+ clk_init.ops = &msc313_cpupll_ops;
+ clk_init.parent_data = &cpupll_parent;
+ clk_init.num_parents = 1;
+ cpupll->clk_hw.init = &clk_init;
+
+ ret = devm_clk_hw_register(dev, &cpupll->clk_hw);
+ if (ret)
+ return ret;
+
+ return of_clk_add_hw_provider(pdev->dev.of_node, of_clk_hw_simple_get, &cpupll->clk_hw);
+}
+
+static struct platform_driver msc313_cpupll_driver = {
+ .driver = {
+ .name = "mstar-msc313-cpupll",
+ .of_match_table = msc313_cpupll_of_match,
+ },
+ .probe = msc313_cpupll_probe,
+};
+builtin_platform_driver(msc313_cpupll_driver);
--
2.34.1
^ permalink raw reply related
* [PATCH v4 1/8] dt-bindings: clk: mstar msc313 cpupll binding description
From: Romain Perier @ 2022-01-26 17:55 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, linux-clk, Arnd Bergmann,
Daniel Palmer, Romain Perier, Rob Herring
Cc: devicetree, linux-arm-kernel, linux-kernel, Rob Herring
In-Reply-To: <20220126175604.17919-1-romain.perier@gmail.com>
From: Daniel Palmer <daniel@0x0f.com>
Add a binding description for the MStar/SigmaStar CPU PLL block.
Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../bindings/clock/mstar,msc313-cpupll.yaml | 45 +++++++++++++++++++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/mstar,msc313-cpupll.yaml
diff --git a/Documentation/devicetree/bindings/clock/mstar,msc313-cpupll.yaml b/Documentation/devicetree/bindings/clock/mstar,msc313-cpupll.yaml
new file mode 100644
index 000000000000..a9ad7ab5230c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mstar,msc313-cpupll.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mstar,msc313-cpupll.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MStar/Sigmastar MSC313 CPU PLL
+
+maintainers:
+ - Daniel Palmer <daniel@thingy.jp>
+
+description: |
+ The MStar/SigmaStar MSC313 and later ARMv7 chips have a scalable
+ PLL that can be used as the clock source for the CPU(s).
+
+properties:
+ compatible:
+ const: mstar,msc313-cpupll
+
+ "#clock-cells":
+ const: 1
+
+ clocks:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - "#clock-cells"
+ - clocks
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mstar-msc313-mpll.h>
+ cpupll: cpupll@206400 {
+ compatible = "mstar,msc313-cpupll";
+ reg = <0x206400 0x200>;
+ #clock-cells = <1>;
+ clocks = <&mpll MSTAR_MSC313_MPLL_DIV2>;
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH v4 0/8] ARM: mstar: cpupll
From: Romain Perier @ 2022-01-26 17:55 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, linux-clk, Arnd Bergmann,
Daniel Palmer, Romain Perier, Rob Herring
Cc: devicetree, linux-arm-kernel, linux-kernel
This series adds a basic driver for the PLL that generates
the cpu clock on MStar/SigmaStar ARMv7 SoCs.
Unfortunately there isn't much documentation for this thing
so there are few magic values and guesses.
This needs to come after the MPLL DT changes.
Changes since v3:
- Added Reviewed-by on Daniel's patches
- Removed "[PATCH v3 8/9] ARM: mstar: Add OPP table for mercury5"
Changes since v2:
- Re-ordered Kconfig by name
- Re-ordered includes alphabetically and removed useless ones
- Used timeout for cpu_relax
- Returned DIV_ROUND_DOWN_ULL() directly in
msc313_cpupll_frequencyforreg()
- Returned DIV_ROUND_DOWN_ULL() directly in
msc313_cpupll_regforfrequecy()
- Reduced the number of lines for msc313_cpupll_of_match
- Removed CLK_IS_CRITICAL
Changes since v1:
- Re-worked the series and ensure that 'make dt_binding_check' passes.
The required commit is merged now, so it is okay.
- Fixed coding style issues in the driver and makes check_patch.pl happy
- Added one more commit for extending the opp_table for infinity2m.
Daniel Palmer (7):
dt-bindings: clk: mstar msc313 cpupll binding description
clk: mstar: msc313 cpupll clk driver
ARM: mstar: Add cpupll to base dtsi
ARM: mstar: Link cpupll to cpu
ARM: mstar: Link cpupll to second core
ARM: mstar: Add OPP table for infinity
ARM: mstar: Add OPP table for infinity3
Romain Perier (1):
ARM: mstar: Extend opp_table for infinity2m
.../bindings/clock/mstar,msc313-cpupll.yaml | 45 ++++
arch/arm/boot/dts/mstar-infinity.dtsi | 34 +++
arch/arm/boot/dts/mstar-infinity2m.dtsi | 17 ++
arch/arm/boot/dts/mstar-infinity3.dtsi | 58 +++++
arch/arm/boot/dts/mstar-v7.dtsi | 9 +
drivers/clk/mstar/Kconfig | 8 +
drivers/clk/mstar/Makefile | 2 +-
drivers/clk/mstar/clk-msc313-cpupll.c | 221 ++++++++++++++++++
8 files changed, 393 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/clock/mstar,msc313-cpupll.yaml
create mode 100644 drivers/clk/mstar/clk-msc313-cpupll.c
--
2.34.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