From: Chunyan Zhang <[email protected]>
Add bindings for Unisoc system global register which provide register map
for clocks.
Signed-off-by: Chunyan Zhang <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
---
.../bindings/mfd/sprd,ums512-glbreg.yaml | 68 +++++++++++++++++++
1 file changed, 68 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
diff --git a/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml b/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
new file mode 100644
index 000000000000..3522f3d2d8de
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/sprd,ums512-glbreg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc System Global Register Device Tree Bindings
+
+maintainers:
+ - Orson Zhai <[email protected]>
+ - Baolin Wang <[email protected]>
+ - Chunyan Zhang <[email protected]>
+
+description:
+ Unisoc system global registers provide register map
+ for clocks and some multimedia modules of the SoC.
+
+properties:
+ "#address-cells": true
+ "#size-cells": true
+
+ compatible:
+ items:
+ - const: sprd,ums512-glbregs
+ - const: syscon
+ - const: simple-mfd
+
+ ranges:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ "^.*@[0-9a-f]+$":
+ # Child node
+ type: object
+ $ref: "../clock/sprd,ums512-clk.yaml"
+ description:
+ Clock controller for the SoC clocks.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ ap_apb_regs: syscon@71000000 {
+ compatible = "sprd,ums512-glbregs", "syscon", "simple-mfd";
+ reg = <0x71000000 0x3000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x71000000 0x3000>;
+
+ clock-controller@0 {
+ compatible = "sprd,ums512-apahb-gate";
+ reg = <0x0 0x2000>;
+ #clock-cells = <1>;
+ };
+ };
+
+ - |
+ ap_intc5_regs: syscon@32360000 {
+ compatible = "sprd,ums512-glbregs", "syscon", "simple-mfd";
+ reg = <0x32360000 0x1000>;
+ };
--
2.25.1
On Thu, 23 Sep 2021, Chunyan Zhang wrote:
> From: Chunyan Zhang <[email protected]>
>
> Add bindings for Unisoc system global register which provide register map
> for clocks.
>
> Signed-off-by: Chunyan Zhang <[email protected]>
> Reviewed-by: Rob Herring <[email protected]>
> ---
> .../bindings/mfd/sprd,ums512-glbreg.yaml | 68 +++++++++++++++++++
> 1 file changed, 68 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
Unapplied v3 and applied this (v4) instead, thanks.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
On Wed, Oct 6, 2021 at 3:00 AM Lee Jones <[email protected]> wrote:
>
> On Thu, 23 Sep 2021, Chunyan Zhang wrote:
>
> > From: Chunyan Zhang <[email protected]>
> >
> > Add bindings for Unisoc system global register which provide register map
> > for clocks.
> >
> > Signed-off-by: Chunyan Zhang <[email protected]>
> > Reviewed-by: Rob Herring <[email protected]>
> > ---
> > .../bindings/mfd/sprd,ums512-glbreg.yaml | 68 +++++++++++++++++++
> > 1 file changed, 68 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
>
> Unapplied v3 and applied this (v4) instead, thanks.
What about the clock binding this depends on:
Unknown file referenced: [Errno 2] No such file or directory:
'/usr/local/lib/python3.8/dist-packages/dtschema/schemas/clock/sprd,ums512-clk.yaml'
xargs: dt-doc-validate: exited with status 255; aborting
make[1]: *** Deleting file
'Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.example.dt.yaml'
Unknown file referenced: [Errno 2] No such file or directory:
'/usr/local/lib/python3.8/dist-packages/dtschema/schemas/clock/sprd,ums512-clk.yaml'
make[1]: *** [scripts/Makefile.lib:385:
Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.example.dt.yaml]
Error 255
Once again, all the components of MFD bindings need to be applied together.
Rob
On Mon, 11 Oct 2021, Rob Herring wrote:
> On Wed, Oct 6, 2021 at 3:00 AM Lee Jones <[email protected]> wrote:
> >
> > On Thu, 23 Sep 2021, Chunyan Zhang wrote:
> >
> > > From: Chunyan Zhang <[email protected]>
> > >
> > > Add bindings for Unisoc system global register which provide register map
> > > for clocks.
> > >
> > > Signed-off-by: Chunyan Zhang <[email protected]>
> > > Reviewed-by: Rob Herring <[email protected]>
> > > ---
> > > .../bindings/mfd/sprd,ums512-glbreg.yaml | 68 +++++++++++++++++++
> > > 1 file changed, 68 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
> >
> > Unapplied v3 and applied this (v4) instead, thanks.
>
> What about the clock binding this depends on:
>
> Unknown file referenced: [Errno 2] No such file or directory:
> '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/clock/sprd,ums512-clk.yaml'
> xargs: dt-doc-validate: exited with status 255; aborting
> make[1]: *** Deleting file
> 'Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.example.dt.yaml'
> Unknown file referenced: [Errno 2] No such file or directory:
> '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/clock/sprd,ums512-clk.yaml'
> make[1]: *** [scripts/Makefile.lib:385:
> Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.example.dt.yaml]
> Error 255
>
>
> Once again, all the components of MFD bindings need to be applied together.
I can't apply what is not sent to me.
This patch came in on its own.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Hi Lee,
On Tue, Oct 12, 2021 at 10:15 AM Lee Jones <[email protected]> wrote:
> On Mon, 11 Oct 2021, Rob Herring wrote:
> > On Wed, Oct 6, 2021 at 3:00 AM Lee Jones <[email protected]> wrote:
> > > On Thu, 23 Sep 2021, Chunyan Zhang wrote:
> > >
> > > > From: Chunyan Zhang <[email protected]>
> > > >
> > > > Add bindings for Unisoc system global register which provide register map
> > > > for clocks.
> > > >
> > > > Signed-off-by: Chunyan Zhang <[email protected]>
> > > > Reviewed-by: Rob Herring <[email protected]>
> > > > ---
> > > > .../bindings/mfd/sprd,ums512-glbreg.yaml | 68 +++++++++++++++++++
> > > > 1 file changed, 68 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
> > >
> > > Unapplied v3 and applied this (v4) instead, thanks.
> >
> > What about the clock binding this depends on:
> >
> > Unknown file referenced: [Errno 2] No such file or directory:
> > '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/clock/sprd,ums512-clk.yaml'
> > xargs: dt-doc-validate: exited with status 255; aborting
> > make[1]: *** Deleting file
> > 'Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.example.dt.yaml'
> > Unknown file referenced: [Errno 2] No such file or directory:
> > '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/clock/sprd,ums512-clk.yaml'
> > make[1]: *** [scripts/Makefile.lib:385:
> > Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.example.dt.yaml]
> > Error 255
> >
> >
> > Once again, all the components of MFD bindings need to be applied together.
Just ran into this, too...
> I can't apply what is not sent to me.
>
> This patch came in on its own.
Then please reject/postpone patches that don't build (yet) ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
Quoting Chunyan Zhang (2021-09-22 23:41:35)
> diff --git a/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml b/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
> new file mode 100644
> index 000000000000..3522f3d2d8de
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
> @@ -0,0 +1,68 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/sprd,ums512-glbreg.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Unisoc System Global Register Device Tree Bindings
> +
> +maintainers:
> + - Orson Zhai <[email protected]>
> + - Baolin Wang <[email protected]>
> + - Chunyan Zhang <[email protected]>
> +
> +description:
> + Unisoc system global registers provide register map
> + for clocks and some multimedia modules of the SoC.
> +
> +properties:
> + "#address-cells": true
> + "#size-cells": true
> +
> + compatible:
> + items:
> + - const: sprd,ums512-glbregs
> + - const: syscon
> + - const: simple-mfd
> +
> + ranges:
> + maxItems: 1
> +
> + reg:
> + maxItems: 1
> +
> +patternProperties:
> + "^.*@[0-9a-f]+$":
> + # Child node
> + type: object
> + $ref: "../clock/sprd,ums512-clk.yaml"
> + description:
> + Clock controller for the SoC clocks.
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + ap_apb_regs: syscon@71000000 {
> + compatible = "sprd,ums512-glbregs", "syscon", "simple-mfd";
> + reg = <0x71000000 0x3000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x71000000 0x3000>;
> +
> + clock-controller@0 {
> + compatible = "sprd,ums512-apahb-gate";
Why is this a subnode of a syscon and simple-mfd? Why not put the
clock-controller@71000000 directly onto the bus? Does making it a child
node help somehow?
> + reg = <0x0 0x2000>;
> + #clock-cells = <1>;
> + };
> + };
Hi Stephen,
Thanks for the review.
At 2021-10-14 06:04:32, "Stephen Boyd" <[email protected]> wrote:
>Quoting Chunyan Zhang (2021-09-22 23:41:35)
>> diff --git a/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml b/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
>> new file mode 100644
>> index 000000000000..3522f3d2d8de
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
>> @@ -0,0 +1,68 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/mfd/sprd,ums512-glbreg.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Unisoc System Global Register Device Tree Bindings
>> +
>> +maintainers:
>> + - Orson Zhai <[email protected]>
>> + - Baolin Wang <[email protected]>
>> + - Chunyan Zhang <[email protected]>
>> +
>> +description:
>> + Unisoc system global registers provide register map
>> + for clocks and some multimedia modules of the SoC.
>> +
>> +properties:
>> + "#address-cells": true
>> + "#size-cells": true
>> +
>> + compatible:
>> + items:
>> + - const: sprd,ums512-glbregs
>> + - const: syscon
>> + - const: simple-mfd
>> +
>> + ranges:
>> + maxItems: 1
>> +
>> + reg:
>> + maxItems: 1
>> +
>> +patternProperties:
>> + "^.*@[0-9a-f]+$":
>> + # Child node
>> + type: object
>> + $ref: "../clock/sprd,ums512-clk.yaml"
>> + description:
>> + Clock controller for the SoC clocks.
>> +
>> +required:
>> + - compatible
>> + - reg
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + ap_apb_regs: syscon@71000000 {
>> + compatible = "sprd,ums512-glbregs", "syscon", "simple-mfd";
>> + reg = <0x71000000 0x3000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0 0x71000000 0x3000>;
>> +
>> + clock-controller@0 {
>> + compatible = "sprd,ums512-apahb-gate";
>
>Why is this a subnode of a syscon and simple-mfd? Why not put the>clock-controller@71000000 directly onto the bus? Does making it a child
>node help somehow?
These clocks are at the same register range with global registers. I originally put them directly onto the bus indeed when submitting the patches for SC9863A clocks last year, and it had a private property named 'sprd,syscon' which could provide regmap for these clocks.
Rob suggested [1] us to make them a child of the syscon, and would not need the private property 'sprd, syscon' then.
Thanks,
Chunyan
[1] https://lkml.org/lkml/2019/12/26/212
>
>> + reg = <0x0 0x2000>;
>> + #clock-cells = <1>;
>> + };
>> + };
Quoting ChunyanZhang (2021-10-13 16:49:40)
> At 2021-10-14 06:04:32, "Stephen Boyd" <[email protected]> wrote:
> >Quoting Chunyan Zhang (2021-09-22 23:41:35)
> >> diff --git a/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml b/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
> >> +
> >> +examples:
> >> + - |
> >> + ap_apb_regs: syscon@71000000 {
> >> + compatible = "sprd,ums512-glbregs", "syscon", "simple-mfd";
> >> + reg = <0x71000000 0x3000>;
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> + ranges = <0 0x71000000 0x3000>;
> >> +
> >> + clock-controller@0 {
> >> + compatible = "sprd,ums512-apahb-gate";
> >
> >Why is this a subnode of a syscon and simple-mfd? Why not put the>clock-controller@71000000 directly onto the bus? Does making it a child
> >node help somehow?
>
> These clocks are at the same register range with global registers. I originally put them directly onto the bus indeed when submitting the patches for SC9863A clocks last year, and it had a private property named 'sprd,syscon' which could provide regmap for these clocks.
>
> Rob suggested [1] us to make them a child of the syscon, and would not need the private property 'sprd, syscon' then.
Why do you need to use a syscon? Are the registers shared with some
other driver?
2019 was two years ago...
At 2021-10-14 09:51:25, "Stephen Boyd" <[email protected]> wrote:
>Quoting ChunyanZhang (2021-10-13 16:49:40)
>> At 2021-10-14 06:04:32, "Stephen Boyd" <[email protected]> wrote:
>> >Quoting Chunyan Zhang (2021-09-22 23:41:35)
>> >> diff --git a/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml b/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
>> >> +
>> >> +examples:
>> >> + - |
>> >> + ap_apb_regs: syscon@71000000 {
>> >> + compatible = "sprd,ums512-glbregs", "syscon", "simple-mfd";
>> >> + reg = <0x71000000 0x3000>;
>> >> + #address-cells = <1>;
>> >> + #size-cells = <1>;
>> >> + ranges = <0 0x71000000 0x3000>;
>> >> +
>> >> + clock-controller@0 {
>> >> + compatible = "sprd,ums512-apahb-gate";
>> >
>> >Why is this a subnode of a syscon and simple-mfd? Why not put the>clock-controller@71000000 directly onto the bus? Does making it a child
>> >node help somehow?
>>
>> These clocks are at the same register range with global registers. I originally put them directly onto the bus indeed when submitting the patches for SC9863A clocks last year, and it had a private property named 'sprd,syscon' which could provide regmap for these clocks.
>>
>> Rob suggested [1] us to make them a child of the syscon, and would not need the private property 'sprd, syscon' then.
>
>Why do you need to use a syscon? Are the registers shared with some
>other driver?
Yes, shared with more than one devices which basically are multimedia devices. You may noticed that these are all gate clocks which are in the global registers ranges and are used to controll the enable status of some devices or some part of devices.
>
>2019 was two years ago...
Humm... yes, submitted that patch set from 2019 to 2020 :)
Quoting ChunyanZhang (2021-10-13 19:02:44)
> At 2021-10-14 09:51:25, "Stephen Boyd" <[email protected]> wrote:
> >Quoting ChunyanZhang (2021-10-13 16:49:40)
> >> At 2021-10-14 06:04:32, "Stephen Boyd" <[email protected]> wrote:
> >> >Quoting Chunyan Zhang (2021-09-22 23:41:35)
> >> >> diff --git a/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml b/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
> >> >> +
> >> >> +examples:
> >> >> + - |
> >> >> + ap_apb_regs: syscon@71000000 {
> >> >> + compatible = "sprd,ums512-glbregs", "syscon", "simple-mfd";
> >> >> + reg = <0x71000000 0x3000>;
> >> >> + #address-cells = <1>;
> >> >> + #size-cells = <1>;
> >> >> + ranges = <0 0x71000000 0x3000>;
> >> >> +
> >> >> + clock-controller@0 {
> >> >> + compatible = "sprd,ums512-apahb-gate";
> >> >
> >> >Why is this a subnode of a syscon and simple-mfd? Why not put the>clock-controller@71000000 directly onto the bus? Does making it a child
> >> >node help somehow?
> >>
> >> These clocks are at the same register range with global registers. I originally put them directly onto the bus indeed when submitting the patches for SC9863A clocks last year, and it had a private property named 'sprd,syscon' which could provide regmap for these clocks.
> >>
> >> Rob suggested [1] us to make them a child of the syscon, and would not need the private property 'sprd, syscon' then.
> >
> >Why do you need to use a syscon? Are the registers shared with some
> >other driver?
>
> Yes, shared with more than one devices which basically are multimedia devices. You may noticed that these are all gate clocks which are in the global registers ranges and are used to controll the enable status of some devices or some part of devices.
>
Where does the multimedia device address space start? I see 0x71000000
to 0x71002000 is for the clock-controller. Is the multimedia device at
0x71002000 to 0x71003000? If so they're next to each other but not
sharing the same register space. Is ap_apb_regs more like a soft macro
that combines a few clks with some multimedia device?
On Wed, 13 Oct 2021, Geert Uytterhoeven wrote:
> Hi Lee,
>
> On Tue, Oct 12, 2021 at 10:15 AM Lee Jones <[email protected]> wrote:
> > On Mon, 11 Oct 2021, Rob Herring wrote:
> > > On Wed, Oct 6, 2021 at 3:00 AM Lee Jones <[email protected]> wrote:
> > > > On Thu, 23 Sep 2021, Chunyan Zhang wrote:
> > > >
> > > > > From: Chunyan Zhang <[email protected]>
> > > > >
> > > > > Add bindings for Unisoc system global register which provide register map
> > > > > for clocks.
> > > > >
> > > > > Signed-off-by: Chunyan Zhang <[email protected]>
> > > > > Reviewed-by: Rob Herring <[email protected]>
> > > > > ---
> > > > > .../bindings/mfd/sprd,ums512-glbreg.yaml | 68 +++++++++++++++++++
> > > > > 1 file changed, 68 insertions(+)
> > > > > create mode 100644 Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
> > > >
> > > > Unapplied v3 and applied this (v4) instead, thanks.
> > >
> > > What about the clock binding this depends on:
> > >
> > > Unknown file referenced: [Errno 2] No such file or directory:
> > > '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/clock/sprd,ums512-clk.yaml'
> > > xargs: dt-doc-validate: exited with status 255; aborting
> > > make[1]: *** Deleting file
> > > 'Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.example.dt.yaml'
> > > Unknown file referenced: [Errno 2] No such file or directory:
> > > '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/clock/sprd,ums512-clk.yaml'
> > > make[1]: *** [scripts/Makefile.lib:385:
> > > Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.example.dt.yaml]
> > > Error 255
> > >
> > >
> > > Once again, all the components of MFD bindings need to be applied together.
>
> Just ran into this, too...
>
> > I can't apply what is not sent to me.
> >
> > This patch came in on its own.
>
> Then please reject/postpone patches that don't build (yet) ;-)
I don't explicitly build DT documentation.
Since I use the build bots to let me know if there are strange !(C,
ASM, arm, aarch64, mips, ppc, x86) build issues or ones with odd
configuration possibilities (randconfig) in the repos I maintain, you
might have to convince them that this is important too.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Resend this since I forgot to switch to plain text mode :(
At 2021-10-14 14:38:42, "Stephen Boyd" <[email protected]> wrote:
>Quoting ChunyanZhang (2021-10-13 19:02:44)
>> At 2021-10-14 09:51:25, "Stephen Boyd" <[email protected]> wrote:
>> >Quoting ChunyanZhang (2021-10-13 16:49:40)
>> >> At 2021-10-14 06:04:32, "Stephen Boyd" <[email protected]> wrote:
>> >> >Quoting Chunyan Zhang (2021-09-22 23:41:35)
>> >> >> diff --git a/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml b/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
>> >> >> +
>> >> >> +examples:
>> >> >> + - |
>> >> >> + ap_apb_regs: syscon@71000000 {
>> >> >> + compatible = "sprd,ums512-glbregs", "syscon", "simple-mfd";
>> >> >> + reg = <0x71000000 0x3000>;
>> >> >> + #address-cells = <1>;
>> >> >> + #size-cells = <1>;
>> >> >> + ranges = <0 0x71000000 0x3000>;
>> >> >> +
>> >> >> + clock-controller@0 {
>> >> >> + compatible = "sprd,ums512-apahb-gate";
>> >> >
>> >> >Why is this a subnode of a syscon and simple-mfd? Why not put the>clock-controller@71000000 directly onto the bus? Does making it a child
>> >> >node help somehow?
>> >>
>> >> These clocks are at the same register range with global registers. I originally put them directly onto the bus indeed when submitting the patches for SC9863A clocks last year, and it had a private property named 'sprd,syscon' which could provide regmap for these clocks.
>> >>
>> >> Rob suggested [1] us to make them a child of the syscon, and would not need the private property 'sprd, syscon' then.
>> >
>> >Why do you need to use a syscon? Are the registers shared with some
>> >other driver?
>>
>> Yes, shared with more than one devices which basically are multimedia devices. You may noticed that these are all gate clocks which are in the global registers ranges and are used to controll the enable status of some devices or some part of devices.
>>
>
>Where does the multimedia device address space start? I see 0x71000000
It doesn't mean that multimedia device address is in this space, multidedia devices have their own address space actually.
All the registers in this space (started from 0x71000000) are more like controll registers for device power, and they were designed as "global registers".
Some gate clocks are also in global register space, so we make this kind of clocks a subnode of syscon, and clock driver can use regmap which mapped by syscon to avoid remapping the same address space to more than one virtual addresses.
Hope I've made that clear, I'd like to give you an example, but I'm on a long leave and cannot look up the specification right now :(
This is not a new issue, we discussed this when the first time I submitted the patches for sprd clocks IIRC.
>to 0x71002000 is for the clock-controller. Is the multimedia device at
>0x71002000 to 0x71003000? If so they're next to each other but not
>sharing the same register space. Is ap_apb_regs more like a soft macro
>that combines a few clks with some multimedia device?
On Thu, Oct 14, 2021 at 1:48 AM Lee Jones <[email protected]> wrote:
>
> On Wed, 13 Oct 2021, Geert Uytterhoeven wrote:
>
> > Hi Lee,
> >
> > On Tue, Oct 12, 2021 at 10:15 AM Lee Jones <[email protected]> wrote:
> > > On Mon, 11 Oct 2021, Rob Herring wrote:
> > > > On Wed, Oct 6, 2021 at 3:00 AM Lee Jones <[email protected]> wrote:
> > > > > On Thu, 23 Sep 2021, Chunyan Zhang wrote:
> > > > >
> > > > > > From: Chunyan Zhang <[email protected]>
> > > > > >
> > > > > > Add bindings for Unisoc system global register which provide register map
> > > > > > for clocks.
> > > > > >
> > > > > > Signed-off-by: Chunyan Zhang <[email protected]>
> > > > > > Reviewed-by: Rob Herring <[email protected]>
> > > > > > ---
> > > > > > .../bindings/mfd/sprd,ums512-glbreg.yaml | 68 +++++++++++++++++++
> > > > > > 1 file changed, 68 insertions(+)
> > > > > > create mode 100644 Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
> > > > >
> > > > > Unapplied v3 and applied this (v4) instead, thanks.
> > > >
> > > > What about the clock binding this depends on:
> > > >
> > > > Unknown file referenced: [Errno 2] No such file or directory:
> > > > '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/clock/sprd,ums512-clk.yaml'
> > > > xargs: dt-doc-validate: exited with status 255; aborting
> > > > make[1]: *** Deleting file
> > > > 'Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.example.dt.yaml'
> > > > Unknown file referenced: [Errno 2] No such file or directory:
> > > > '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/clock/sprd,ums512-clk.yaml'
> > > > make[1]: *** [scripts/Makefile.lib:385:
> > > > Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.example.dt.yaml]
> > > > Error 255
> > > >
> > > >
> > > > Once again, all the components of MFD bindings need to be applied together.
> >
> > Just ran into this, too...
> >
> > > I can't apply what is not sent to me.
> > >
> > > This patch came in on its own.
> >
> > Then please reject/postpone patches that don't build (yet) ;-)
>
> I don't explicitly build DT documentation.
>
> Since I use the build bots to let me know if there are strange !(C,
> ASM, arm, aarch64, mips, ppc, x86) build issues or ones with odd
> configuration possibilities (randconfig) in the repos I maintain, you
> might have to convince them that this is important too.
It's really just a matter of turning on the build in
allyesconfig/allmodconfig builds. I've not done that primarily because
there's one person I don't want to yell at me, but I could probably
make it arm and/or arm64 only. It's really arch and config
independent, so doing it multiple times is kind of pointless.
I assume for bots you mean kernel-ci mainly? Do you run that before
stuff gets into linux-next? IMO, that's too late. But still a slight
improvement if things go in via one tree. Otherwise, I see the
breakage twice, 1st linux-next then the merge window.
Rob
Quoting Rob Herring (2021-10-14 09:18:16)
> On Thu, Oct 14, 2021 at 1:48 AM Lee Jones <[email protected]> wrote:
> >
> > I don't explicitly build DT documentation.
> >
> > Since I use the build bots to let me know if there are strange !(C,
> > ASM, arm, aarch64, mips, ppc, x86) build issues or ones with odd
> > configuration possibilities (randconfig) in the repos I maintain, you
> > might have to convince them that this is important too.
>
> It's really just a matter of turning on the build in
> allyesconfig/allmodconfig builds. I've not done that primarily because
> there's one person I don't want to yell at me, but I could probably
> make it arm and/or arm64 only. It's really arch and config
> independent, so doing it multiple times is kind of pointless.
>
> I assume for bots you mean kernel-ci mainly? Do you run that before
> stuff gets into linux-next? IMO, that's too late. But still a slight
> improvement if things go in via one tree. Otherwise, I see the
> breakage twice, 1st linux-next then the merge window.
>
I run `make dt_binding_check DT_SCHEMA_FILES="<path to yaml file>"` but
nowadays this seems to check all the bindings and not just the one
binding I care to check. Did something break?
Quoting ChunyanZhang (2021-10-14 01:18:15)
>
> Resend this since I forgot to switch to plain text mode :(
>
> At 2021-10-14 14:38:42, "Stephen Boyd" <[email protected]> wrote:
> >Quoting ChunyanZhang (2021-10-13 19:02:44)
> >> At 2021-10-14 09:51:25, "Stephen Boyd" <[email protected]> wrote:
> >> >Quoting ChunyanZhang (2021-10-13 16:49:40)
> >> >> At 2021-10-14 06:04:32, "Stephen Boyd" <[email protected]> wrote:
> >> >> >Quoting Chunyan Zhang (2021-09-22 23:41:35)
> >> >> >> diff --git a/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml b/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
> >> >> >> +
> >> >> >> +examples:
> >> >> >> + - |
> >> >> >> + ap_apb_regs: syscon@71000000 {
> >> >> >> + compatible = "sprd,ums512-glbregs", "syscon", "simple-mfd";
> >> >> >> + reg = <0x71000000 0x3000>;
> >> >> >> + #address-cells = <1>;
> >> >> >> + #size-cells = <1>;
> >> >> >> + ranges = <0 0x71000000 0x3000>;
> >> >> >> +
> >> >> >> + clock-controller@0 {
> >> >> >> + compatible = "sprd,ums512-apahb-gate";
> >> >> >
> >> >> >Why is this a subnode of a syscon and simple-mfd? Why not put the>clock-controller@71000000 directly onto the bus? Does making it a child
> >> >> >node help somehow?
> >> >>
> >> >> These clocks are at the same register range with global registers. I originally put them directly onto the bus indeed when submitting the patches for SC9863A clocks last year, and it had a private property named 'sprd,syscon' which could provide regmap for these clocks.
> >> >>
> >> >> Rob suggested [1] us to make them a child of the syscon, and would not need the private property 'sprd, syscon' then.
> >> >
> >> >Why do you need to use a syscon? Are the registers shared with some
> >> >other driver?
> >>
> >> Yes, shared with more than one devices which basically are multimedia devices. You may noticed that these are all gate clocks which are in the global registers ranges and are used to controll the enable status of some devices or some part of devices.
> >>
> >
>
> >Where does the multimedia device address space start? I see 0x71000000
>
> It doesn't mean that multimedia device address is in this space, multidedia devices have their own address space actually.
Ok got it.
> All the registers in this space (started from 0x71000000) are more like controll registers for device power, and they were designed as "global registers".
> Some gate clocks are also in global register space, so we make this kind of clocks a subnode of syscon, and clock driver can use regmap which mapped by syscon to avoid remapping the same address space to more than one virtual addresses.
So it looks like we're making the "power controller" device into a
syscon and then adding nodes in DT to describe the various pieces that
some registers inside that correspond to, like clks, power domains, etc.
I wonder why the ap_apb_regs device can't be a single node covering the
entire register space and then use the auxiliary bus in the kernel to
carve that device up into various kernel subsytems so that the
appropriate maintainers can review it.
>
> Hope I've made that clear, I'd like to give you an example, but I'm on a long leave and cannot look up the specification right now :(
> This is not a new issue, we discussed this when the first time I submitted the patches for sprd clocks IIRC.
Yes, I know it's not a new issue. Take care! We can pick this discussion
back up when you get back from leave.
On Thu, 14 Oct 2021, Rob Herring wrote:
> On Thu, Oct 14, 2021 at 1:48 AM Lee Jones <[email protected]> wrote:
> >
> > On Wed, 13 Oct 2021, Geert Uytterhoeven wrote:
> >
> > > Hi Lee,
> > >
> > > On Tue, Oct 12, 2021 at 10:15 AM Lee Jones <[email protected]> wrote:
> > > > On Mon, 11 Oct 2021, Rob Herring wrote:
> > > > > On Wed, Oct 6, 2021 at 3:00 AM Lee Jones <[email protected]> wrote:
> > > > > > On Thu, 23 Sep 2021, Chunyan Zhang wrote:
> > > > > >
> > > > > > > From: Chunyan Zhang <[email protected]>
> > > > > > >
> > > > > > > Add bindings for Unisoc system global register which provide register map
> > > > > > > for clocks.
> > > > > > >
> > > > > > > Signed-off-by: Chunyan Zhang <[email protected]>
> > > > > > > Reviewed-by: Rob Herring <[email protected]>
> > > > > > > ---
> > > > > > > .../bindings/mfd/sprd,ums512-glbreg.yaml | 68 +++++++++++++++++++
> > > > > > > 1 file changed, 68 insertions(+)
> > > > > > > create mode 100644 Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
> > > > > >
> > > > > > Unapplied v3 and applied this (v4) instead, thanks.
> > > > >
> > > > > What about the clock binding this depends on:
> > > > >
> > > > > Unknown file referenced: [Errno 2] No such file or directory:
> > > > > '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/clock/sprd,ums512-clk.yaml'
> > > > > xargs: dt-doc-validate: exited with status 255; aborting
> > > > > make[1]: *** Deleting file
> > > > > 'Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.example.dt.yaml'
> > > > > Unknown file referenced: [Errno 2] No such file or directory:
> > > > > '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/clock/sprd,ums512-clk.yaml'
> > > > > make[1]: *** [scripts/Makefile.lib:385:
> > > > > Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.example.dt.yaml]
> > > > > Error 255
> > > > >
> > > > >
> > > > > Once again, all the components of MFD bindings need to be applied together.
> > >
> > > Just ran into this, too...
> > >
> > > > I can't apply what is not sent to me.
> > > >
> > > > This patch came in on its own.
> > >
> > > Then please reject/postpone patches that don't build (yet) ;-)
> >
> > I don't explicitly build DT documentation.
> >
> > Since I use the build bots to let me know if there are strange !(C,
> > ASM, arm, aarch64, mips, ppc, x86) build issues or ones with odd
> > configuration possibilities (randconfig) in the repos I maintain, you
> > might have to convince them that this is important too.
>
> It's really just a matter of turning on the build in
> allyesconfig/allmodconfig builds. I've not done that primarily because
> there's one person I don't want to yell at me, but I could probably
> make it arm and/or arm64 only. It's really arch and config
> independent, so doing it multiple times is kind of pointless.
>
> I assume for bots you mean kernel-ci mainly? Do you run that before
> stuff gets into linux-next? IMO, that's too late. But still a slight
> improvement if things go in via one tree. Otherwise, I see the
> breakage twice, 1st linux-next then the merge window.
Kernel test robot <[email protected]> is the one that springs to mind.
Although, I'm sure there are other, less prolific implementations.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
On Thu, Oct 14, 2021 at 6:02 PM Stephen Boyd <[email protected]> wrote:
>
> Quoting Rob Herring (2021-10-14 09:18:16)
> > On Thu, Oct 14, 2021 at 1:48 AM Lee Jones <[email protected]> wrote:
> > >
> > > I don't explicitly build DT documentation.
> > >
> > > Since I use the build bots to let me know if there are strange !(C,
> > > ASM, arm, aarch64, mips, ppc, x86) build issues or ones with odd
> > > configuration possibilities (randconfig) in the repos I maintain, you
> > > might have to convince them that this is important too.
> >
> > It's really just a matter of turning on the build in
> > allyesconfig/allmodconfig builds. I've not done that primarily because
> > there's one person I don't want to yell at me, but I could probably
> > make it arm and/or arm64 only. It's really arch and config
> > independent, so doing it multiple times is kind of pointless.
> >
> > I assume for bots you mean kernel-ci mainly? Do you run that before
> > stuff gets into linux-next? IMO, that's too late. But still a slight
> > improvement if things go in via one tree. Otherwise, I see the
> > breakage twice, 1st linux-next then the merge window.
> >
>
> I run `make dt_binding_check DT_SCHEMA_FILES="<path to yaml file>"` but
> nowadays this seems to check all the bindings and not just the one
> binding I care to check. Did something break?
It should apply all the schemas to the example in DT_SCHEMA_FILES.
Originally, it only applied DT_SCHEMA_FILES schema to the example in
DT_SCHEMA_FILES.
Rob
Hi Rob, Stephen,
On Fri, Oct 15, 2021 at 3:59 PM Rob Herring <[email protected]> wrote:
> On Thu, Oct 14, 2021 at 6:02 PM Stephen Boyd <[email protected]> wrote:
> > Quoting Rob Herring (2021-10-14 09:18:16)
> > > On Thu, Oct 14, 2021 at 1:48 AM Lee Jones <[email protected]> wrote:
> > > >
> > > > I don't explicitly build DT documentation.
> > > >
> > > > Since I use the build bots to let me know if there are strange !(C,
> > > > ASM, arm, aarch64, mips, ppc, x86) build issues or ones with odd
> > > > configuration possibilities (randconfig) in the repos I maintain, you
> > > > might have to convince them that this is important too.
> > >
> > > It's really just a matter of turning on the build in
> > > allyesconfig/allmodconfig builds. I've not done that primarily because
> > > there's one person I don't want to yell at me, but I could probably
> > > make it arm and/or arm64 only. It's really arch and config
> > > independent, so doing it multiple times is kind of pointless.
> > >
> > > I assume for bots you mean kernel-ci mainly? Do you run that before
> > > stuff gets into linux-next? IMO, that's too late. But still a slight
> > > improvement if things go in via one tree. Otherwise, I see the
> > > breakage twice, 1st linux-next then the merge window.
> > >
> >
> > I run `make dt_binding_check DT_SCHEMA_FILES="<path to yaml file>"` but
> > nowadays this seems to check all the bindings and not just the one
> > binding I care to check. Did something break?
>
> It should apply all the schemas to the example in DT_SCHEMA_FILES.
> Originally, it only applied DT_SCHEMA_FILES schema to the example in
> DT_SCHEMA_FILES.
Probably Stephen means that yamllint is still run on all files, which
I tried to fix in [1]?
I've been running an improved version for months, but I haven't sent
it out yet.
[1] https://lore.kernel.org/linux-devicetree/[email protected]
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On Fri, Oct 15, 2021 at 7:45 AM Lee Jones <[email protected]> wrote:
>
> On Thu, 14 Oct 2021, Rob Herring wrote:
>
> > On Thu, Oct 14, 2021 at 1:48 AM Lee Jones <[email protected]> wrote:
> > >
> > > On Wed, 13 Oct 2021, Geert Uytterhoeven wrote:
> > >
> > > > Hi Lee,
> > > >
> > > > On Tue, Oct 12, 2021 at 10:15 AM Lee Jones <[email protected]> wrote:
> > > > > On Mon, 11 Oct 2021, Rob Herring wrote:
> > > > > > On Wed, Oct 6, 2021 at 3:00 AM Lee Jones <[email protected]> wrote:
> > > > > > > On Thu, 23 Sep 2021, Chunyan Zhang wrote:
> > > > > > >
> > > > > > > > From: Chunyan Zhang <[email protected]>
> > > > > > > >
> > > > > > > > Add bindings for Unisoc system global register which provide register map
> > > > > > > > for clocks.
> > > > > > > >
> > > > > > > > Signed-off-by: Chunyan Zhang <[email protected]>
> > > > > > > > Reviewed-by: Rob Herring <[email protected]>
> > > > > > > > ---
> > > > > > > > .../bindings/mfd/sprd,ums512-glbreg.yaml | 68 +++++++++++++++++++
> > > > > > > > 1 file changed, 68 insertions(+)
> > > > > > > > create mode 100644 Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
> > > > > > >
> > > > > > > Unapplied v3 and applied this (v4) instead, thanks.
> > > > > >
> > > > > > What about the clock binding this depends on:
> > > > > >
> > > > > > Unknown file referenced: [Errno 2] No such file or directory:
> > > > > > '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/clock/sprd,ums512-clk.yaml'
> > > > > > xargs: dt-doc-validate: exited with status 255; aborting
> > > > > > make[1]: *** Deleting file
> > > > > > 'Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.example.dt.yaml'
> > > > > > Unknown file referenced: [Errno 2] No such file or directory:
> > > > > > '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/clock/sprd,ums512-clk.yaml'
> > > > > > make[1]: *** [scripts/Makefile.lib:385:
> > > > > > Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.example.dt.yaml]
> > > > > > Error 255
> > > > > >
> > > > > >
> > > > > > Once again, all the components of MFD bindings need to be applied together.
> > > >
> > > > Just ran into this, too...
> > > >
> > > > > I can't apply what is not sent to me.
> > > > >
> > > > > This patch came in on its own.
> > > >
> > > > Then please reject/postpone patches that don't build (yet) ;-)
> > >
> > > I don't explicitly build DT documentation.
> > >
> > > Since I use the build bots to let me know if there are strange !(C,
> > > ASM, arm, aarch64, mips, ppc, x86) build issues or ones with odd
> > > configuration possibilities (randconfig) in the repos I maintain, you
> > > might have to convince them that this is important too.
> >
> > It's really just a matter of turning on the build in
> > allyesconfig/allmodconfig builds. I've not done that primarily because
> > there's one person I don't want to yell at me, but I could probably
> > make it arm and/or arm64 only. It's really arch and config
> > independent, so doing it multiple times is kind of pointless.
> >
> > I assume for bots you mean kernel-ci mainly? Do you run that before
> > stuff gets into linux-next? IMO, that's too late. But still a slight
> > improvement if things go in via one tree. Otherwise, I see the
> > breakage twice, 1st linux-next then the merge window.
>
> Kernel test robot <[email protected]> is the one that springs to mind.
It already does sometimes. I haven't figured out when, but I randomly
see some reports and doesn't report a lot of the cases.
> Although, I'm sure there are other, less prolific implementations.
Rob's bot, but that checks patches (not branches) and applies series
so you won't get errors unless the series is in the wrong patch order.
Rob
Quoting Geert Uytterhoeven (2021-10-15 10:09:10)
> Hi Rob, Stephen,
>
> On Fri, Oct 15, 2021 at 3:59 PM Rob Herring <[email protected]> wrote:
> > On Thu, Oct 14, 2021 at 6:02 PM Stephen Boyd <[email protected]> wrote:
> > > Quoting Rob Herring (2021-10-14 09:18:16)
> > > > On Thu, Oct 14, 2021 at 1:48 AM Lee Jones <[email protected]> wrote:
> > > > >
> > > > > I don't explicitly build DT documentation.
> > > > >
> > > > > Since I use the build bots to let me know if there are strange !(C,
> > > > > ASM, arm, aarch64, mips, ppc, x86) build issues or ones with odd
> > > > > configuration possibilities (randconfig) in the repos I maintain, you
> > > > > might have to convince them that this is important too.
> > > >
> > > > It's really just a matter of turning on the build in
> > > > allyesconfig/allmodconfig builds. I've not done that primarily because
> > > > there's one person I don't want to yell at me, but I could probably
> > > > make it arm and/or arm64 only. It's really arch and config
> > > > independent, so doing it multiple times is kind of pointless.
> > > >
> > > > I assume for bots you mean kernel-ci mainly? Do you run that before
> > > > stuff gets into linux-next? IMO, that's too late. But still a slight
> > > > improvement if things go in via one tree. Otherwise, I see the
> > > > breakage twice, 1st linux-next then the merge window.
> > > >
> > >
> > > I run `make dt_binding_check DT_SCHEMA_FILES="<path to yaml file>"` but
> > > nowadays this seems to check all the bindings and not just the one
> > > binding I care to check. Did something break?
> >
> > It should apply all the schemas to the example in DT_SCHEMA_FILES.
> > Originally, it only applied DT_SCHEMA_FILES schema to the example in
> > DT_SCHEMA_FILES.
>
> Probably Stephen means that yamllint is still run on all files, which
> I tried to fix in [1]?
>
> I've been running an improved version for months, but I haven't sent
> it out yet.
>
Oh yeah probably. Do I need to carry this patch locally until it is
fixed?
Hi Stephen,
On Sat, Oct 16, 2021 at 12:03 AM Stephen Boyd <[email protected]> wrote:
> Quoting Geert Uytterhoeven (2021-10-15 10:09:10)
> > On Fri, Oct 15, 2021 at 3:59 PM Rob Herring <[email protected]> wrote:
> > > On Thu, Oct 14, 2021 at 6:02 PM Stephen Boyd <[email protected]> wrote:
> > > > Quoting Rob Herring (2021-10-14 09:18:16)
> > > > > On Thu, Oct 14, 2021 at 1:48 AM Lee Jones <[email protected]> wrote:
> > > > > >
> > > > > > I don't explicitly build DT documentation.
> > > > > >
> > > > > > Since I use the build bots to let me know if there are strange !(C,
> > > > > > ASM, arm, aarch64, mips, ppc, x86) build issues or ones with odd
> > > > > > configuration possibilities (randconfig) in the repos I maintain, you
> > > > > > might have to convince them that this is important too.
> > > > >
> > > > > It's really just a matter of turning on the build in
> > > > > allyesconfig/allmodconfig builds. I've not done that primarily because
> > > > > there's one person I don't want to yell at me, but I could probably
> > > > > make it arm and/or arm64 only. It's really arch and config
> > > > > independent, so doing it multiple times is kind of pointless.
> > > > >
> > > > > I assume for bots you mean kernel-ci mainly? Do you run that before
> > > > > stuff gets into linux-next? IMO, that's too late. But still a slight
> > > > > improvement if things go in via one tree. Otherwise, I see the
> > > > > breakage twice, 1st linux-next then the merge window.
> > > > >
> > > >
> > > > I run `make dt_binding_check DT_SCHEMA_FILES="<path to yaml file>"` but
> > > > nowadays this seems to check all the bindings and not just the one
> > > > binding I care to check. Did something break?
> > >
> > > It should apply all the schemas to the example in DT_SCHEMA_FILES.
> > > Originally, it only applied DT_SCHEMA_FILES schema to the example in
> > > DT_SCHEMA_FILES.
> >
> > Probably Stephen means that yamllint is still run on all files, which
> > I tried to fix in [1]?
> >
> > I've been running an improved version for months, but I haven't sent
> > it out yet.
> >
>
> Oh yeah probably. Do I need to carry this patch locally until it is
> fixed?
Submitted the improved version:
https://lore.kernel.org/all/[email protected]
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On Fri, 15 Oct 2021, Rob Herring wrote:
> On Fri, Oct 15, 2021 at 7:45 AM Lee Jones <[email protected]> wrote:
> >
> > On Thu, 14 Oct 2021, Rob Herring wrote:
> >
> > > On Thu, Oct 14, 2021 at 1:48 AM Lee Jones <[email protected]> wrote:
> > > >
> > > > On Wed, 13 Oct 2021, Geert Uytterhoeven wrote:
> > > >
> > > > > Hi Lee,
> > > > >
> > > > > On Tue, Oct 12, 2021 at 10:15 AM Lee Jones <[email protected]> wrote:
> > > > > > On Mon, 11 Oct 2021, Rob Herring wrote:
> > > > > > > On Wed, Oct 6, 2021 at 3:00 AM Lee Jones <[email protected]> wrote:
> > > > > > > > On Thu, 23 Sep 2021, Chunyan Zhang wrote:
> > > > > > > >
> > > > > > > > > From: Chunyan Zhang <[email protected]>
> > > > > > > > >
> > > > > > > > > Add bindings for Unisoc system global register which provide register map
> > > > > > > > > for clocks.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Chunyan Zhang <[email protected]>
> > > > > > > > > Reviewed-by: Rob Herring <[email protected]>
> > > > > > > > > ---
> > > > > > > > > .../bindings/mfd/sprd,ums512-glbreg.yaml | 68 +++++++++++++++++++
> > > > > > > > > 1 file changed, 68 insertions(+)
> > > > > > > > > create mode 100644 Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
> > > > > > > >
> > > > > > > > Unapplied v3 and applied this (v4) instead, thanks.
> > > > > > >
> > > > > > > What about the clock binding this depends on:
> > > > > > >
> > > > > > > Unknown file referenced: [Errno 2] No such file or directory:
> > > > > > > '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/clock/sprd,ums512-clk.yaml'
> > > > > > > xargs: dt-doc-validate: exited with status 255; aborting
> > > > > > > make[1]: *** Deleting file
> > > > > > > 'Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.example.dt.yaml'
> > > > > > > Unknown file referenced: [Errno 2] No such file or directory:
> > > > > > > '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/clock/sprd,ums512-clk.yaml'
> > > > > > > make[1]: *** [scripts/Makefile.lib:385:
> > > > > > > Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.example.dt.yaml]
> > > > > > > Error 255
> > > > > > >
> > > > > > >
> > > > > > > Once again, all the components of MFD bindings need to be applied together.
> > > > >
> > > > > Just ran into this, too...
> > > > >
> > > > > > I can't apply what is not sent to me.
> > > > > >
> > > > > > This patch came in on its own.
> > > > >
> > > > > Then please reject/postpone patches that don't build (yet) ;-)
> > > >
> > > > I don't explicitly build DT documentation.
> > > >
> > > > Since I use the build bots to let me know if there are strange !(C,
> > > > ASM, arm, aarch64, mips, ppc, x86) build issues or ones with odd
> > > > configuration possibilities (randconfig) in the repos I maintain, you
> > > > might have to convince them that this is important too.
> > >
> > > It's really just a matter of turning on the build in
> > > allyesconfig/allmodconfig builds. I've not done that primarily because
> > > there's one person I don't want to yell at me, but I could probably
> > > make it arm and/or arm64 only. It's really arch and config
> > > independent, so doing it multiple times is kind of pointless.
> > >
> > > I assume for bots you mean kernel-ci mainly? Do you run that before
> > > stuff gets into linux-next? IMO, that's too late. But still a slight
> > > improvement if things go in via one tree. Otherwise, I see the
> > > breakage twice, 1st linux-next then the merge window.
> >
> > Kernel test robot <[email protected]> is the one that springs to mind.
>
> It already does sometimes. I haven't figured out when, but I randomly
> see some reports and doesn't report a lot of the cases.
It would be great if it can be figured it out.
Apart from my W=1 work, I seldom build/test/run obscure/specialist
compiler flags/options. If someone can convince the 0-day builder
bots that testing DT docs is a good idea when building for the
appropriate architectures, I'm all in.
> > Although, I'm sure there are other, less prolific implementations.
>
> Rob's bot, but that checks patches (not branches) and applies series
> so you won't get errors unless the series is in the wrong patch order.
Right. Good tool, but solves a different problem.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
On Mon, Oct 11, 2021 at 9:11 AM Rob Herring <[email protected]> wrote:
>
> On Wed, Oct 6, 2021 at 3:00 AM Lee Jones <[email protected]> wrote:
> >
> > On Thu, 23 Sep 2021, Chunyan Zhang wrote:
> >
> > > From: Chunyan Zhang <[email protected]>
> > >
> > > Add bindings for Unisoc system global register which provide register map
> > > for clocks.
> > >
> > > Signed-off-by: Chunyan Zhang <[email protected]>
> > > Reviewed-by: Rob Herring <[email protected]>
> > > ---
> > > .../bindings/mfd/sprd,ums512-glbreg.yaml | 68 +++++++++++++++++++
> > > 1 file changed, 68 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
> >
> > Unapplied v3 and applied this (v4) instead, thanks.
>
> What about the clock binding this depends on:
>
> Unknown file referenced: [Errno 2] No such file or directory:
> '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/clock/sprd,ums512-clk.yaml'
> xargs: dt-doc-validate: exited with status 255; aborting
> make[1]: *** Deleting file
> 'Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.example.dt.yaml'
> Unknown file referenced: [Errno 2] No such file or directory:
> '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/clock/sprd,ums512-clk.yaml'
> make[1]: *** [scripts/Makefile.lib:385:
> Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.example.dt.yaml]
> Error 255
>
>
> Once again, all the components of MFD bindings need to be applied together.
It seems that Stephen still has comments and there's a new check that
causes the clock schema to fail, so this should be dropped or
reverted.
Rob
On Wed, 20 Oct 2021, Rob Herring wrote:
> On Mon, Oct 11, 2021 at 9:11 AM Rob Herring <[email protected]> wrote:
> >
> > On Wed, Oct 6, 2021 at 3:00 AM Lee Jones <[email protected]> wrote:
> > >
> > > On Thu, 23 Sep 2021, Chunyan Zhang wrote:
> > >
> > > > From: Chunyan Zhang <[email protected]>
> > > >
> > > > Add bindings for Unisoc system global register which provide register map
> > > > for clocks.
> > > >
> > > > Signed-off-by: Chunyan Zhang <[email protected]>
> > > > Reviewed-by: Rob Herring <[email protected]>
> > > > ---
> > > > .../bindings/mfd/sprd,ums512-glbreg.yaml | 68 +++++++++++++++++++
> > > > 1 file changed, 68 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
> > >
> > > Unapplied v3 and applied this (v4) instead, thanks.
> >
> > What about the clock binding this depends on:
> >
> > Unknown file referenced: [Errno 2] No such file or directory:
> > '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/clock/sprd,ums512-clk.yaml'
> > xargs: dt-doc-validate: exited with status 255; aborting
> > make[1]: *** Deleting file
> > 'Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.example.dt.yaml'
> > Unknown file referenced: [Errno 2] No such file or directory:
> > '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/clock/sprd,ums512-clk.yaml'
> > make[1]: *** [scripts/Makefile.lib:385:
> > Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.example.dt.yaml]
> > Error 255
> >
> >
> > Once again, all the components of MFD bindings need to be applied together.
>
> It seems that Stephen still has comments and there's a new check that
> causes the clock schema to fail, so this should be dropped or
> reverted.
Dropped.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog