* Re: [PATCH net-next v6 14/17] dt-bindings: net: pse-pd: Add bindings for PD692x0 PSE controller
From: Kory Maincent @ 2024-04-09 13:43 UTC (permalink / raw)
To: Rob Herring
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Krzysztof Kozlowski,
Conor Dooley, Oleksij Rempel, Mark Brown, Frank Rowand,
Andrew Lunn, Heiner Kallweit, Russell King, Thomas Petazzoni,
netdev, linux-kernel, linux-doc, devicetree, Dent Project
In-Reply-To: <20240402132834.GB3744978-robh@kernel.org>
On Tue, 2 Apr 2024 08:28:34 -0500
Rob Herring <robh@kernel.org> wrote:
> > + patternProperties:
> > + "^manager@0[0-9]|1[0-2]$":
>
> Unit-addresses are typically in hex.
>
> Is 'manager' something specific to this device or should be common?
Specific to this device.
> > + $ref: /schemas/graph.yaml#/properties/ports
>
> This is not using the graph binding. Furthermore, I don't want to see
> new cases of 'port' node names which are not graph nodes. We have it
> already with ethernet switches, but 'ethernet-port' is preferred over
> 'port'.
Ok I will remove the ref then.
> Why is this one 'managers' and the other device binding 'channels'?
Here each manager can have up to 8 ports.
The ports in tps23881 are called channels in the datasheet but I can use the
port naming for both if you prefer.
> > + description:
> > + PD69208T4/PD69204T4/PD69208M PSE manager exposing 4 or 8 physical
> > + ports.
> > +
> > + properties:
> > + reg:
> > + description:
> > + Incremental index of the PSE manager starting from 0, ranging
> > + from lowest to highest chip select, up to 12.
> > + maxItems: 1
> > +
> > + patternProperties:
> > + '^port@[0-7]$':
> > + type: object
> > + required:
> > + - reg
>
> Any property you want is allowed in this node. You are missing
> 'additionalProperties'.
Indeed.
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: mtd: amlogic,meson-nand: support fields for boot ROM code
From: Rob Herring @ 2024-04-09 13:47 UTC (permalink / raw)
To: Arseniy Krasnov
Cc: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, linux-mtd, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel, oxffffaa, kernel
In-Reply-To: <20240408085931.456337-2-avkrasnov@salutedevices.com>
On Mon, Apr 08, 2024 at 11:59:30AM +0300, Arseniy Krasnov wrote:
> Boot ROM code on Meson requires that some pages on NAND must be written
> in special mode: "short" ECC mode where each block is 384 bytes and
> scrambling mode is on. Such pages located with the specified interval
> within specified offset. Both interval and offset are located in the
> device tree and used by driver if 'nand-is-boot-medium' is set for
> NAND chip.
>
> Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
> ---
> .../bindings/mtd/amlogic,meson-nand.yaml | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
> index 57b6957c8415..80ba5003ca70 100644
> --- a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
> +++ b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
> @@ -64,11 +64,25 @@ patternProperties:
> items:
> maximum: 0
>
> + amlogic,boot-page-last:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + The NFC driver needs this information to select ECC
> + algorithms supported by the boot ROM.
> +
> + amlogic,boot-page-step:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + The NFC driver needs this information to select ECC
> + algorithms supported by the boot ROM (in pages).
> +
> unevaluatedProperties: false
>
> dependencies:
> nand-ecc-strength: [nand-ecc-step-size]
> nand-ecc-step-size: [nand-ecc-strength]
> + amlogic,boot-page-last: [nand-is-boot-medium, amlogic,boot-page-step]
> + amlogic,boot-page-step: [nand-is-boot-medium, amlogic,boot-page-last]
You need quotes if using the inline syntax.
Rob
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: power: supply: ltc3350-charger: Add bindings
From: Mike Looijmans @ 2024-04-09 13:50 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, Sebastian Reichel, linux-pm, devicetree,
Conor Dooley, linux-kernel
In-Reply-To: <171266946179.1029796.4237832991239731761.robh@kernel.org>
On 09-04-2024 15:31, Rob Herring wrote:
> On Tue, 09 Apr 2024 14:35:54 +0200, Mike Looijmans wrote:
>> The LTC3350 is a backup power controller that can charge and monitor
>> a series stack of one to four supercapacitors.
>>
>> Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
>>
>> ---
>>
>> Changes in v2:
>> Rename to lltc,ltc3350.yaml
>> Fix spaces and indentation
>>
>> .../bindings/power/supply/lltc,ltc3350.yaml | 54 +++++++++++++++++++
>> 1 file changed, 54 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/power/supply/lltc,ltc3350.yaml
>>
> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> on your patch (DT_CHECKER_FLAGS is new in v5.13):
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/supply/lltc,ltc3350.yaml: $id: Cannot determine base path from $id, relative path/filename doesn't match actual path or filename
> $id: http://devicetree.org/schemas/power/supply/ltc3350.yaml
> file: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/supply/lltc,ltc3350.yaml
Ah, should have run the test AFTER renaming...
Need a v3 then.
--
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijmans@topic.nl
W: www.topic.nl
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: power: supply: ltc3350-charger: Add bindings
From: Mike Looijmans @ 2024-04-09 13:54 UTC (permalink / raw)
To: linux-pm
Cc: Mike Looijmans, Krzysztof Kozlowski, Conor Dooley,
Krzysztof Kozlowski, Rob Herring, Sebastian Reichel, devicetree,
linux-kernel
In-Reply-To: <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.949ef384-8293-46b8-903f-40a477c056ae.66250b05-de15-4489-babe-49dcb09de02a@emailsignatures365.codetwo.com>
The LTC3350 is a backup power controller that can charge and monitor
a series stack of one to four supercapacitors.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Changes in v3:
Fix $id after rename to lltc,ltc3350.yaml
Changes in v2:
Rename to lltc,ltc3350.yaml
Fix spaces and indentation
.../bindings/power/supply/lltc,ltc3350.yaml | 54 +++++++++++++++++++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/supply/lltc,ltc3350.yaml
diff --git a/Documentation/devicetree/bindings/power/supply/lltc,ltc3350.yaml b/Documentation/devicetree/bindings/power/supply/lltc,ltc3350.yaml
new file mode 100644
index 000000000000..dca7fe0f0d8f
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/lltc,ltc3350.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (C) 2024 Topic Embedded Products
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/lltc,ltc3350.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Linear Technology (Analog Devices) LTC3350 Supercap Charger
+
+maintainers:
+ - Mike Looijmans <mike.looijmans@topic.nl>
+
+description: |
+ The LTC3350 is a High Current Supercapacitor Backup Controller and System
+ Monitor.
+ Specifications about the charger can be found at:
+ https://www.analog.com/en/products/ltc3350.html
+
+properties:
+ compatible:
+ enum:
+ - lltc,ltc3350
+
+ reg:
+ maxItems: 1
+
+ lltc,rsnsc-micro-ohms:
+ description: Capacitor charger sense resistor in microohm.
+ minimum: 1000
+
+ lltc,rsnsi-micro-ohms:
+ description: Input current sense resistor in microohm.
+ minimum: 1000
+
+required:
+ - compatible
+ - reg
+ - lltc,rsnsc-micro-ohms
+ - lltc,rsnsi-micro-ohms
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ charger: battery-charger@9 {
+ compatible = "lltc,ltc3350";
+ reg = <0x9>;
+ lltc,rsnsc-micro-ohms = <10000>;
+ lltc,rsnsi-micro-ohms = <10000>;
+ };
+ };
--
2.34.1
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijmans@topic.nl
W: www.topic.nl
Please consider the environment before printing this e-mail
^ permalink raw reply related
* Re: [RESEND v7 08/37] clocksource: sh_tmu: CLOCKSOURCE support.
From: Geert Uytterhoeven @ 2024-04-09 13:56 UTC (permalink / raw)
To: Yoshinori Sato
Cc: linux-sh, Damien Le Moal, Niklas Cassel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Michael Turquette, Stephen Boyd, David Airlie, Daniel Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Thomas Gleixner, Bjorn Helgaas, Lorenzo Pieralisi,
Krzysztof Wilczyński, Greg Kroah-Hartman, Jiri Slaby,
Magnus Damm, Daniel Lezcano, Rich Felker,
John Paul Adrian Glaubitz, Lee Jones, Helge Deller,
Heiko Stuebner, Shawn Guo, Sebastian Reichel, Chris Morgan,
Linus Walleij, Arnd Bergmann, David Rientjes, Hyeonggon Yoo,
Vlastimil Babka, Baoquan He, Andrew Morton, Guenter Roeck,
Kefeng Wang, Stephen Rothwell, Javier Martinez Canillas, Guo Ren,
Azeem Shaikh, Max Filippov, Jonathan Corbet, Jacky Huang,
Herve Codina, Manikanta Guntupalli, Anup Patel, Biju Das,
Uwe Kleine-König, Sam Ravnborg, Sergey Shtylyov,
Laurent Pinchart, linux-ide, devicetree, linux-kernel,
linux-renesas-soc, linux-clk, dri-devel, linux-pci, linux-serial,
linux-fbdev
In-Reply-To: <4a9b59733c7a8e7d042f3987ca6bf601eea5b30d.1712207606.git.ysato@users.sourceforge.jp>
Hi Sato-san,
On Thu, Apr 4, 2024 at 7:15 AM Yoshinori Sato
<ysato@users.sourceforge.jp> wrote:
> Allows initialization as CLOCKSOURCE.
>
> Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
Thanks for your patch!
> --- a/drivers/clocksource/sh_tmu.c
> +++ b/drivers/clocksource/sh_tmu.c
> @@ -495,7 +514,12 @@ static int sh_tmu_map_memory(struct sh_tmu_device *tmu)
>
> static int sh_tmu_parse_dt(struct sh_tmu_device *tmu)
> {
> - struct device_node *np = tmu->pdev->dev.of_node;
> + struct device_node *np;
Technically, np might be used uninitialized.
> +
> + if (tmu->pdev)
> + np = tmu->pdev->dev.of_node;
If you would set up tmu->np in sh_tmu_setup_pdev()...
> + if (tmu->np)
> + np = tmu->np;
... you could just assign np = tmu->np unconditionally.
>
> tmu->model = SH_TMU;
> tmu->num_channels = 3;
> @@ -665,6 +734,7 @@ static void __exit sh_tmu_exit(void)
> platform_driver_unregister(&sh_tmu_device_driver);
> }
>
> +TIMER_OF_DECLARE(sh_tmu, "renesas,tmu", sh_tmu_of_register);
As there are now two entry points, the device is actually probed twice:
once from TIMER_OF_DECLARE/sh_tmu_of_register(), and a second
time from platform_driver/sh_tmu_probe().
E.g. on Armadillo-800-EVA with R-Mobile A1 (booting Linux on ARM
(not SH), and using TMU as the main clock source):
timer@fff80000 ch0: used for clock events
timer@fff80000 ch0: used for periodic clock events
timer@fff80000 ch1: used as clock source
clocksource: timer@fff80000: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 154445288668 ns
...
fff80000.timer ch0: used for clock events
genirq: Flags mismatch irq 16. 00015a04 (fff80000.timer) vs.
00015a04 (timer@fff80000)
fff80000.timer ch0: failed to request irq 16
fff80000.timer ch1: used as clock source
clocksource: fff80000.timer: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 154445288668 ns
After this, the timer seems to be stuck, and the boot is blocked.
On Marzen with R-Car H1 (booting Linux on ARM (not SH), and using
arm_global_timer as the main clock source), I also see the double
timer probe, but no such lock-up. I expect you to see the double
timer probe on SH775x, too?
The double probe can be fixed by adding a call to
of_node_set_flag(np, OF_POPULATED) at the end of sh_tmu_of_register()
in case of success, cfr. [1].
I haven't found the cause of the stuck timer on R-Mobile A1 yet;
both the TMU clock and the A4R power domain seem to be activated...
> #ifdef CONFIG_SUPERH
> sh_early_platform_init("earlytimer", &sh_tmu_device_driver);
> #endif
[1] "[PATCH] clocksource/drivers/renesas-ostm: Avoid reprobe after
successful early probe"
https://lore.kernel.org/all/bd027379713cbaafa21ffe9e848ebb7f475ca0e7.1710930542.git.geert+renesas@glider.be/
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/5] ARM: dts: aspeed: greatlakes: correct Mellanox multi-host property
From: Krzysztof Kozlowski @ 2024-04-09 14:00 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, devicetree, Andrew Jeffery, Joel Stanley,
linux-arm-kernel, Conor Dooley, linux-kernel, linux-aspeed
In-Reply-To: <171266958251.1032405.3082451019333889181.robh@kernel.org>
On 09/04/2024 15:38, Rob Herring wrote:
>
> On Fri, 05 Apr 2024 08:46:20 +0200, Krzysztof Kozlowski wrote:
>> "mlx,multi-host" is using incorrect vendor prefix and is not documented.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>
>> ---
>>
>> Changes in v2:
>> 1. None
>> ---
>> arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-greatlakes.dts | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>
>
> My bot found new DTB warnings on the .dts files added or changed in this
> series.
>
> Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
> are fixed by another series. Ultimately, it is up to the platform
> maintainer whether these warnings are acceptable or not. No need to reply
> unless the platform maintainer has comments.
>
> If you already ran DT checks and didn't see these error(s), then
> make sure dt-schema is up to date:
>
> pip3 install dtschema --upgrade
>
>
> New warnings running 'make CHECK_DTBS=y aspeed/aspeed-bmc-ampere-mtmitchell.dtb aspeed/aspeed-bmc-facebook-greatlakes.dtb aspeed/aspeed-bmc-facebook-harma.dtb aspeed/aspeed-bmc-facebook-yosemite4.dtb aspeed/aspeed-bmc-facebook-yosemitev2.dtb' for 20240405064624.18997-1-krzysztof.kozlowski@linaro.org:
>
> arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dtb: ftgmac@1e690000: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'mellanox,multi-host' were unexpected)
> from schema $id: http://devicetree.org/schemas/net/faraday,ftgmac100.yaml#
>
Just FYI
These warnings are expected and not a result of my patches.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set additionalProperties to true
From: Rob Herring @ 2024-04-09 14:09 UTC (permalink / raw)
To: Cristian Marussi
Cc: Peng Fan, Krzysztof Kozlowski, Peng Fan (OSS),
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Sudeep Holla,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <ZhUuKajQbce2AI9f@pluto>
On Tue, Apr 9, 2024 at 7:01 AM Cristian Marussi
<cristian.marussi@arm.com> wrote:
>
> On Tue, Apr 09, 2024 at 09:25:10AM +0000, Peng Fan wrote:
> > Hi Krzysztof,
> >
> > > Subject: RE: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > additionalProperties to true
> > >
> > > > Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > > additionalProperties to true
> > > >
> > > > On 08/04/2024 08:08, Peng Fan wrote:
> > > > >> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > > >> additionalProperties to true
> > > > >>
> > > > >> On 08/04/2024 01:50, Peng Fan wrote:
> > > > >>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > > >>>> additionalProperties to true
> > > > >>>>
> > > > >>>> On 07/04/2024 12:04, Peng Fan wrote:
> > > > >>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > > > >>>>>> set additionalProperties to true
> > > > >>>>>>
> > > > >>>>>> On 07/04/2024 02:37, Peng Fan wrote:
> > > > >>>>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > > > >>>>>>>> set additionalProperties to true
> > > > >>>>>>>>
> > > > >>>>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> > > > >>>>>>>>> From: Peng Fan <peng.fan@nxp.com>
> > > > >>>>>>>>>
> > > > >>>>>>>>> When adding vendor extension protocols, there is dt-schema
> > > > >> warning:
> > > > >>>>>>>>> "
> > > > >>>>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do
> > > > >>>>>>>>> not match any of the regexes: 'pinctrl-[0-9]+'
> > > > >>>>>>>>> "
> > > > >>>>>>>>>
> > > > >>>>>>>>> Set additionalProperties to true to address the issue.
> > > > >>>>>>>>
> > > > >>>>>>>> I do not see anything addressed here, except making the
> > > > >>>>>>>> binding accepting anything anywhere...
> > > > >>>>>>>
> > > > >>>>>>> I not wanna add vendor protocols in arm,scmi.yaml, so will
> > > > >>>>>>> introduce a new yaml imx.scmi.yaml which add i.MX SCMI
> > > > >>>>>>> protocol
> > > > >> extension.
> > > > >>>>>>>
> > > > >>>>>>> With additionalProperties set to false, I not know how, please
> > > > suggest.
> > > > >>>>>>
> > > > >>>>>> First of all, you cannot affect negatively existing devices
> > > > >>>>>> (their
> > > > >>>>>> bindings) and your patch does exactly that. This should make
> > > > >>>>>> you thing what is the correct approach...
> > > > >>>>>>
> > > > >>>>>> Rob gave you the comment about missing compatible - you still
> > > > >>>>>> did not address that.
> > > > >>>>>
> > > > >>>>> I added the compatible in patch 2/6 in the examples "compatible
> > > > >>>>> =
> > > > >>>> "arm,scmi";"
> > > > >>>>
> > > > >>>> So you claim that your vendor extensions are the same or fully
> > > > >>>> compatible with arm,scmi and you add nothing... Are your
> > > > >>>> extensions/protocol valid for arm,scmi?
> > > > >>>
> > > > >>> Yes. They are valid for arm,scmi.
> > > > >>>
> > > > >>> If yes, why is this in separate binding. If no, why you use
> > > > >>> someone
> > > > >>>> else's compatible?
> > > > >>>
> > > > >>> Per SCMI Spec
> > > > >>> 0x80-0xFF: Reserved for vendor or platform-specific extensions to
> > > > >>> this interface
> > > > >>>
> > > > >>> i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use
> > > > >>> the id for their own protocol.
> > > > >>
> > > > >> So how are they valid for arm,scmi? I don't understand.
> > > > >
> > > > > arm,scmi is a firmware compatible string. The protocol node is a sub-node.
> > > > > I think the arm,scmi is that saying the firmware following SCMI spec
> > > > > to implement the protocols.
> > > > >
> > > > > For vendor reserved ID, firmware also follow the SCMI spec to
> > > > > implement their own usage, so from firmware level, it is ARM SCMI
> > > > > spec
> > > > compatible.
> > > >
> > > > That's not the point. It is obvious that your firmware is compatible
> > > > with arm,scmi, but what you try to say in this and revised patch is
> > > > that every arm,scmi is compatible with your implementation. What you
> > > > are saying is that 0x84 is MISC protocol for every firmware, Qualcomm,
> > > > NXP, Samsung, TI, Mediatek etc.
> > > >
> > > > I claim it is not true. 0x84 is not MISC for Qualcomm, for example.
> > >
> > > You are right. I am lost now on how to add vendor ID support, using
> > > arm,scmi.yaml or adding a new imx,scmi.yaml or else.
> >
>
> Hi Peng,
>
> I dont think in the following you will find the solution to the problem,
> it is just to recap the situation and constraints around vendor protocol
> bindings.
>
> Describing SCMI vendors protocols is tricky because while on one side
> the protocol node has to be rooted under the main scmi fw DT node (like
> all the standard protocols) and be 'derived' from the arm,scmi.yaml
> protocol-node definition, the optional additional properties of the a specific
> vendor protocol nodes can be customized by each single vendor, and since,
> as you said, you can have multiple protocols from different vendors sharing the
> same protocol number, you could have multiple disjoint sets of valid properties
> allowed under that same protocol node number; so on one side you have to stick
> to some basic protocol-node defs and be rooted under the SCMI node, while on
> the other side you will have multiple possibly allowed sets of additional
> properties to check against, so IOW you cannot anyway just set
> additionalProperties to false since that will result in no checks at all.
>
> As a consequence, at runtime, in the final DTB shipped with a specific
> platform you should have only one of the possible vendor nodes for each
> of these overlapping protocols, and the SCMI core at probe time will
> pick the proper protocol implementation based on the vendor/sub_vendor
> IDs gathered from the running SCMI fw platform at init: this way you
> can just build the usual "all-inclusive" defconfig without worrying
> about vendor protocol clashes since the SCMI core can pick the right
> protocol implementation, you should just had taken care to provide the
> proper DTB for your protocol; BUT this also means that it is not possible
> to add multiple DT bindings based on a 'if vendor' condition since the
> vendor itself is NOT defined and not needed in the bindings since it is
> discoverable at runtime.
>
> So, after all of this blabbing of mine about this, I am wondering if it
> is not possible that the solution is to handle each and every vendor
> protocol node that appears with a block of addtional properties that
> are picked via a oneOf statement from some external vendor specific
> yaml.
> (...in a similar way to how pinctrl additional properties are added...)
>
>
> NOTE THAT the following is just an example of what I mean, it is certainly
> wrong, incomplete annd maybe just not acceptable (and could cause DT
> maintainers eyes to bleed :P)...
>
> ...so it is just fr the sake of explaining what I mean...
>
> diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> index e9d3f043c4ed..3c38a1e3ffed 100644
> --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> @@ -278,6 +278,22 @@ properties:
> required:
> - reg
>
> + protocol@81:
> + $ref: '#/$defs/protocol-node'
> + unevaluatedProperties: false
> +
> + properties:
> + reg:
> + const: 0x81
> +
> + patternProperties:
> + '$':
> + type: object
Did you mean to have child nodes under the protocol node rather than in it?
> + oneOf:
> + - $ref: /schemas/vendor-A/scmi-protos.yaml#
> + - $ref: /schemas/vendor-B/protos.yaml#
Moved up one level, this would work, but it would have to be an
'anyOf' because it is possible that 2 vendors have the exact same set
of properties.
I can think of 2 other ways to structure this.
First, is a specific vendor protocol discoverable? Not that is 0x81
protocol present, but that 0x81 is vendor Foo's extra special
value-add protocol? If not, I think we should require a compatible
string on vendor protocols. Then the base SCMI schema can require just
that, and each vendor protocol defines its node with a $ref to
'#/$defs/protocol-node'.
The 2nd way is just a variation of the oneOf above, but do we do 1
file per vendor protocol or 1 file per vendor. Either should be
doable, just a matter of where 'protocol@81', etc. are defined.
Rob
^ permalink raw reply
* Re: [PATCH] dt-bindings: PCI: rockchip,rk3399-pcie: add missing maxItems to ep-gpios
From: Rob Herring @ 2024-04-09 14:10 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Shawn Lin, Conor Dooley, linux-rockchip, Krzysztof Kozlowski,
Krzysztof Wilczyński, linux-kernel, Bjorn Helgaas,
devicetree, linux-arm-kernel, Heiko Stuebner, Lorenzo Pieralisi,
linux-pci
In-Reply-To: <20240401100058.15749-1-krzysztof.kozlowski@linaro.org>
On Mon, 01 Apr 2024 12:00:58 +0200, Krzysztof Kozlowski wrote:
> Properties with GPIOs should define number of actual GPIOs, so add
> missing maxItems to ep-gpios. Otherwise multiple GPIOs could be
> provided which is not a true hardware description.
>
> Fixes: aa222f9311e1 ("dt-bindings: PCI: Convert Rockchip RK3399 PCIe to DT schema")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
> Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] dt-bindings: timer: renesas,cmt: Add R-Car V4M support
From: Rob Herring @ 2024-04-09 14:11 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Daniel Lezcano, Thomas Gleixner, Krzysztof Kozlowski,
Conor Dooley, Laurent Pinchart, devicetree, linux-renesas-soc,
linux-kernel
In-Reply-To: <3e8a7a93261d8ad264dec2fa2784fe1bbfc4a23c.1712068536.git.geert+renesas@glider.be>
On Tue, Apr 02, 2024 at 04:36:05PM +0200, Geert Uytterhoeven wrote:
> Document support for the Compare Match Timer Type0 (CMT0) and Type1
> (CMT1) in the Renesas R-Car V4M (R8A779H0) SoC.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Documentation/devicetree/bindings/timer/renesas,cmt.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Daniel, please apply this. The timer bindings seem to keep getting
missed.
>
> diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.yaml b/Documentation/devicetree/bindings/timer/renesas,cmt.yaml
> index a0be1755ea28b996..5e09c04da30e47d5 100644
> --- a/Documentation/devicetree/bindings/timer/renesas,cmt.yaml
> +++ b/Documentation/devicetree/bindings/timer/renesas,cmt.yaml
> @@ -103,6 +103,7 @@ properties:
> - renesas,r8a779a0-cmt0 # 32-bit CMT0 on R-Car V3U
> - renesas,r8a779f0-cmt0 # 32-bit CMT0 on R-Car S4-8
> - renesas,r8a779g0-cmt0 # 32-bit CMT0 on R-Car V4H
> + - renesas,r8a779h0-cmt0 # 32-bit CMT0 on R-Car V4M
> - const: renesas,rcar-gen4-cmt0 # 32-bit CMT0 on R-Car Gen4
>
> - items:
> @@ -110,6 +111,7 @@ properties:
> - renesas,r8a779a0-cmt1 # 48-bit CMT on R-Car V3U
> - renesas,r8a779f0-cmt1 # 48-bit CMT on R-Car S4-8
> - renesas,r8a779g0-cmt1 # 48-bit CMT on R-Car V4H
> + - renesas,r8a779h0-cmt1 # 48-bit CMT on R-Car V4M
> - const: renesas,rcar-gen4-cmt1 # 48-bit CMT on R-Car Gen4
>
> reg:
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v3 18/25] dt-bindings: media: imx258: Add alternate compatible strings
From: Rob Herring @ 2024-04-09 14:12 UTC (permalink / raw)
To: git
Cc: mchehab, devicetree, linux-media, shawnguo, jacopo.mondi,
phone-devel, linux-arm-kernel, krzysztof.kozlowski+dt, festevam,
sakari.ailus, conor+dt, imx, pavel, dave.stevenson, s.hauer,
linux-kernel, kernel
In-Reply-To: <20240403150355.189229-19-git@luigi311.com>
On Wed, 03 Apr 2024 09:03:47 -0600, git@luigi311.com wrote:
> From: Dave Stevenson <dave.stevenson@raspberrypi.com>
>
> There are a number of variants of the imx258 modules that can not
> be differentiated at runtime, so add compatible strings for the
> PDAF variant.
>
> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
> Signed-off-by: Luis Garcia <git@luigi311.com>
> ---
> .../devicetree/bindings/media/i2c/sony,imx258.yaml | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/5] arm64: dts: mediatek: mt8395-nio-12l: Fix MT6360 regulator nodes names
From: AngeloGioacchino Del Regno @ 2024-04-09 14:14 UTC (permalink / raw)
To: linux-mediatek
Cc: robh, krzk+dt, conor+dt, matthias.bgg, devicetree, linux-kernel,
linux-arm-kernel, kernel
In-Reply-To: <20240409114211.310462-2-angelogioacchino.delregno@collabora.com>
Il 09/04/24 13:42, AngeloGioacchino Del Regno ha scritto:
> The regulators' node names for mt6360-regulator are supposed to be
> uppercase. Also, drop "-regulator" from the usb-otg-vbus node name
> to make all vregs to probe correctly.
>
> The alternative would've been to use regulator-compatible, but that's
> a deprecated property.
> Now all regulators are probing fine.
>
> Fixes: 96564b1e2ea4 ("arm64: dts: mediatek: Introduce the MT8395 Radxa NIO 12L board")
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> .../boot/dts/mediatek/mt8395-radxa-nio-12l.dts | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
> index e5d9b671a405..18182cf073fb 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
> @@ -216,7 +216,7 @@ charger {
> compatible = "mediatek,mt6360-chg";
> richtek,vinovp-microvolt = <14500000>;
>
> - otg_vbus_regulator: usb-otg-vbus-regulator {
> + otg_vbus_regulator: usb-otg-vbus {
Reviewing and NACK'ing my own patch, I just noticed that everything apart the
usb-otg-vbus renaming is wrong.
The MT6360 regulator node names should not be capitalized as the bindings are
correct in this regard, and there already is one user (genio-1200-evk) apart
from NIO-12L declaring the wrong ones - so, the driver must be fixed, not the
other way around.
This patch will be cleaned up in v2.
Cheers
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: riscv: add Zimop ISA extension description
From: Conor Dooley @ 2024-04-09 14:15 UTC (permalink / raw)
To: Clément Léger
Cc: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Rob Herring, Krzysztof Kozlowski, Anup Patel, Shuah Khan,
Atish Patra, linux-doc, linux-riscv, linux-kernel, devicetree,
kvm, kvm-riscv, linux-kselftest
In-Reply-To: <20240404103254.1752834-2-cleger@rivosinc.com>
[-- Attachment #1: Type: text/plain, Size: 313 bytes --]
On Thu, Apr 04, 2024 at 12:32:47PM +0200, Clément Léger wrote:
> Add description for the Zimop (May-Be-Operations) ISA extension which
> was ratified in commit 58220614a5f of the riscv-isa-manual.
>
> Signed-off-by: Clément Léger <cleger@rivosinc.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: mtd: amlogic,meson-nand: support fields for boot ROM code
From: Arseniy Krasnov @ 2024-04-09 14:10 UTC (permalink / raw)
To: Rob Herring
Cc: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, linux-mtd, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel, oxffffaa, kernel
In-Reply-To: <20240409134718.GA1050037-robh@kernel.org>
On 09.04.2024 16:47, Rob Herring wrote:
> On Mon, Apr 08, 2024 at 11:59:30AM +0300, Arseniy Krasnov wrote:
>> Boot ROM code on Meson requires that some pages on NAND must be written
>> in special mode: "short" ECC mode where each block is 384 bytes and
>> scrambling mode is on. Such pages located with the specified interval
>> within specified offset. Both interval and offset are located in the
>> device tree and used by driver if 'nand-is-boot-medium' is set for
>> NAND chip.
>>
>> Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
>> ---
>> .../bindings/mtd/amlogic,meson-nand.yaml | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
>> index 57b6957c8415..80ba5003ca70 100644
>> --- a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
>> +++ b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
>> @@ -64,11 +64,25 @@ patternProperties:
>> items:
>> maximum: 0
>>
>> + amlogic,boot-page-last:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + description:
>> + The NFC driver needs this information to select ECC
>> + algorithms supported by the boot ROM.
>> +
>> + amlogic,boot-page-step:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + description:
>> + The NFC driver needs this information to select ECC
>> + algorithms supported by the boot ROM (in pages).
>> +
>> unevaluatedProperties: false
>>
>> dependencies:
>> nand-ecc-strength: [nand-ecc-step-size]
>> nand-ecc-step-size: [nand-ecc-strength]
>> + amlogic,boot-page-last: [nand-is-boot-medium, amlogic,boot-page-step]
>> + amlogic,boot-page-step: [nand-is-boot-medium, amlogic,boot-page-last]
>
> You need quotes if using the inline syntax.
IIUC it must look like this:
amlogic,boot-page-last: [nand-is-boot-medium, "amlogic,boot-page-step"]
etc.
>
> Rob
^ permalink raw reply
* [PATCH v2 0/5] arm64: dts: qcom: add USB-C orientation GPIOs
From: Dmitry Baryshkov @ 2024-04-09 14:28 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Dmitry Baryshkov
Populate orientation GPIOs for some of the PMIC-GLINK-based devices.
This leaves only FairPhone5, RB3Gen2, SC8180X Primus and SC8280XP CRD
without the orientation GPIOs declared.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
Changes in v2:
- Relax schema restriction for orientation-gpios property (Luca Weiss)
- Link to v1: https://lore.kernel.org/r/20240408-hdk-orientation-gpios-v1-0-8064ba43e52a@linaro.org
---
Dmitry Baryshkov (5):
dt-bindings: soc: qcom: pmic-glink: allow orientation-gpios
arm64: dts: qcom: sm8350-hdk: add USB-C orientation GPIO
arm64: dts: qcom: sm8450-hdk: add USB-C orientation GPIO
arm64: dts: qcom: sc8280xp-lenovo-thinkpad-x13s: add USB-C orientation GPIOs
arm64: dts: qcom: sc8180x-lenovo-flex-5g: add USB-C orientation GPIOs
.../devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml | 14 --------------
arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts | 2 ++
arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 2 ++
arch/arm64/boot/dts/qcom/sm8350-hdk.dts | 1 +
arch/arm64/boot/dts/qcom/sm8450-hdk.dts | 1 +
5 files changed, 6 insertions(+), 14 deletions(-)
---
base-commit: 8568bb2ccc278f344e6ac44af6ed010a90aa88dc
change-id: 20240408-hdk-orientation-gpios-141bc7fd247d
Best regards,
--
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
^ permalink raw reply
* [PATCH v2 1/5] dt-bindings: soc: qcom: pmic-glink: allow orientation-gpios
From: Dmitry Baryshkov @ 2024-04-09 14:28 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Dmitry Baryshkov
In-Reply-To: <20240409-hdk-orientation-gpios-v2-0-658efd993987@linaro.org>
The orientation GPIOs are not limited to sm8450/sm8550/x1e8000
platforms. Allow corresponding property to be used on all Qualcom
platforms.
Fixes: 65682407f8f4 ("dt-bindings: soc: qcom: qcom,pmic-glink: add a gpio used to determine the Type-C port plug orientation")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
.../devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml | 14 --------------
1 file changed, 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
index 4310bae6c58e..4512390f90f0 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
@@ -58,20 +58,6 @@ patternProperties:
required:
- compatible
-allOf:
- - if:
- not:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sm8450-pmic-glink
- - qcom,sm8550-pmic-glink
- - qcom,x1e80100-pmic-glink
- then:
- properties:
- orientation-gpios: false
-
additionalProperties: false
examples:
--
2.39.2
^ permalink raw reply related
* [PATCH v2 2/5] arm64: dts: qcom: sm8350-hdk: add USB-C orientation GPIO
From: Dmitry Baryshkov @ 2024-04-09 14:28 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Dmitry Baryshkov
In-Reply-To: <20240409-hdk-orientation-gpios-v2-0-658efd993987@linaro.org>
Define the USB-C orientation GPIO so that the USB-C port orientation is
known without having to resort to the altmode notifications.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8350-hdk.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
index b43d264ed42b..4c25ab2f5670 100644
--- a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
@@ -42,6 +42,7 @@ pmic-glink {
compatible = "qcom,sm8350-pmic-glink", "qcom,pmic-glink";
#address-cells = <1>;
#size-cells = <0>;
+ orientation-gpios = <&tlmm 81 GPIO_ACTIVE_HIGH>;
connector@0 {
compatible = "usb-c-connector";
--
2.39.2
^ permalink raw reply related
* [PATCH v2 3/5] arm64: dts: qcom: sm8450-hdk: add USB-C orientation GPIO
From: Dmitry Baryshkov @ 2024-04-09 14:28 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Dmitry Baryshkov
In-Reply-To: <20240409-hdk-orientation-gpios-v2-0-658efd993987@linaro.org>
Define the USB-C orientation GPIO so that the USB-C port orientation is
known without having to resort to the altmode notifications.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8450-hdk.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8450-hdk.dts b/arch/arm64/boot/dts/qcom/sm8450-hdk.dts
index 0786cff07b89..3be46b56c723 100644
--- a/arch/arm64/boot/dts/qcom/sm8450-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8450-hdk.dts
@@ -95,6 +95,7 @@ pmic-glink {
compatible = "qcom,sm8450-pmic-glink", "qcom,pmic-glink";
#address-cells = <1>;
#size-cells = <0>;
+ orientation-gpios = <&tlmm 91 GPIO_ACTIVE_HIGH>;
connector@0 {
compatible = "usb-c-connector";
--
2.39.2
^ permalink raw reply related
* [PATCH v2 4/5] arm64: dts: qcom: sc8280xp-lenovo-thinkpad-x13s: add USB-C orientation GPIOs
From: Dmitry Baryshkov @ 2024-04-09 14:28 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Dmitry Baryshkov
In-Reply-To: <20240409-hdk-orientation-gpios-v2-0-658efd993987@linaro.org>
Define the USB-C orientation GPIOs so that the USB-C ports orientation
is known without having to resort to the altmode notifications.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
index 15ae94c1602d..2806aa8ec497 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
@@ -100,6 +100,8 @@ pmic-glink {
#address-cells = <1>;
#size-cells = <0>;
+ orientation-gpios = <&tlmm 166 GPIO_ACTIVE_HIGH>,
+ <&tlmm 49 GPIO_ACTIVE_HIGH>;
connector@0 {
compatible = "usb-c-connector";
--
2.39.2
^ permalink raw reply related
* [PATCH v2 5/5] arm64: dts: qcom: sc8180x-lenovo-flex-5g: add USB-C orientation GPIOs
From: Dmitry Baryshkov @ 2024-04-09 14:28 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Dmitry Baryshkov
In-Reply-To: <20240409-hdk-orientation-gpios-v2-0-658efd993987@linaro.org>
Define the USB-C orientation GPIOs so that the USB-C ports orientation
is known without having to resort to the altmode notifications.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts b/arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts
index 6f2e1c732ed3..6af99116c715 100644
--- a/arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts
+++ b/arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts
@@ -51,6 +51,8 @@ pmic-glink {
#address-cells = <1>;
#size-cells = <0>;
+ orientation-gpios = <&tlmm 38 GPIO_ACTIVE_HIGH>,
+ <&tlmm 58 GPIO_ACTIVE_HIGH>;
connector@0 {
compatible = "usb-c-connector";
--
2.39.2
^ permalink raw reply related
* Re: [PATCH v1] arm64: dts: imx8mm: fix missing pgc_vpu_* power domain parent
From: Lucas Stach @ 2024-04-09 14:36 UTC (permalink / raw)
To: Vitor Soares, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Vitor Soares, devicetree, imx, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <e1552a3008a30ef7ed9097b4b80cda23ccb9e840.camel@gmail.com>
Am Dienstag, dem 09.04.2024 um 14:22 +0100 schrieb Vitor Soares:
> Hi Lucas,
>
> Thanks for your feedback.
>
> On Tue, 2024-04-09 at 11:13 +0200, Lucas Stach wrote:
> > Hi Vitor,
> >
> > Am Dienstag, dem 09.04.2024 um 09:58 +0100 schrieb Vitor Soares:
> > > From: Vitor Soares <vitor.soares@toradex.com>
> > >
> > > The pgc_vpu_* nodes miss the reference to the power domain parent,
> > > leading the system to hang during the resume.
> > >
> > This change is not correct. The vpumix domain is controlled through
> > the
> > imx8mm-vpu-blk-ctrl and must not be directly triggered by the child
> > domains in order to guarantee proper power sequencing.
> >
> > If the sequencing is incorrect for resume, it needs to be fixed in
> > the
> > blk-ctrl driver. I'll happily assist if you have any questions about
> > this intricate mix between GPC and blk-ctrl hardware/drivers.
>
> I'm new into the topic, so I tried to follow same approach as in imx8mp
> DT.
>
That's a good hint, the 8MP VPU GPC node additions missed my radar. The
direct dependency there between the GPC domains is equally wrong.
> I also checked the imx8mq DT and it only have one domain for the
> VPU in the GPC. It seem blk-ctrl also dependes on pgc_vpu_* to work
> properly.
>
> The blk-ctrl driver hangs on imx8m_blk_ctrl_power_on() when access the
> ip registers for the soft reset. I tried to power-up the before the
> soft reset, but it didn't work.
>
The runtime_pm_get_sync() at the start of that function should ensure
that bus GPC domain aka vpumix is powered up. Can you check if that is
happening?
Regards,
Lucas
> Do you have an idea how we can address this within blk-ctrl?
>
> Best regards,
> Vitor
>
> >
> > Regards,
> > Lucas
> >
> > > As these PU domains are nested inside the vpumix domain, let's
> > > reference
> > > it accordingly. After this change, the suspend/resume is working.
> > >
> > > Cc: Lucas Stach <l.stach@pengutronix.de>
> > > Cc: <stable@vger.kernel.org>
> > > Closes:
> > > https://lore.kernel.org/all/fccbb040330a706a4f7b34875db1d896a0bf81c8.camel@gmail.com/
> > > Fixes: d39d4bb15310 ("arm64: dts: imx8mm: add GPC node")
> > > Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
> > > ---
> > > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > > b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > > index 8a1b42b94dce..97d0c6d23ad8 100644
> > > --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > > @@ -739,16 +739,19 @@ pgc_vpumix: power-domain@6 {
> > > pgc_vpu_g1: power-domain@7
> > > {
> > > #power-domain-cells
> > > = <0>;
> > > reg =
> > > <IMX8MM_POWER_DOMAIN_VPUG1>;
> > > + power-domains =
> > > <&pgc_vpumix>;
> > > };
> > >
> > > pgc_vpu_g2: power-domain@8
> > > {
> > > #power-domain-cells
> > > = <0>;
> > > reg =
> > > <IMX8MM_POWER_DOMAIN_VPUG2>;
> > > + power-domains =
> > > <&pgc_vpumix>;
> > > };
> > >
> > > pgc_vpu_h1: power-domain@9
> > > {
> > > #power-domain-cells
> > > = <0>;
> > > reg =
> > > <IMX8MM_POWER_DOMAIN_VPUH1>;
> > > + power-domains =
> > > <&pgc_vpumix>;
> > > };
> > >
> > > pgc_dispmix:
> > > power-domain@10 {
> >
>
^ permalink raw reply
* Re: [PATCH v2 00/13] ASoC: ti: davinci-i2s: Add features to McBSP driver
From: Péter Ujfalusi @ 2024-04-09 14:39 UTC (permalink / raw)
To: Bastien Curutchet, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai
Cc: linux-sound, devicetree, linux-kernel, alsa-devel,
Thomas Petazzoni, herve.codina, christophercordahi
In-Reply-To: <20240402071213.11671-1-bastien.curutchet@bootlin.com>
Hi Bastien,
On 02/04/2024 10:12, Bastien Curutchet wrote:
> This series aims to add some features to McBSP driver.
>
> Convert bindings from .txt to .yaml.
> Add possibility to use an external clock as sample rate generator's
> input.
> Add handling of new formats (TDM, S24_LE, BP_FC).
> Enable the detection of unexpected frame pulses.
> Set the clock free-running mode according to SND_SOC_DAIFMT_[GATED/CONT]
> configuration in DAI format.
> Add ti,T1-framing[tx/rx] properties in DT. They allow to set the data
> delay to two bit-clock periods.
>
> This has been tested on a platform designed off of the DAVINCI/OMAP-L138
> connected to 3 daisy-chained AD7767. An external clock drives the
> sample rate generator through the CLKS pin.
> The hardware I have only allowed me to test acquisition side of McBSP.
> It is connected to a 6 channels TDM and acts as Bit clock provider and
> Frame clock consumer.
Nice and clean, thank you for the updates!
Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
PS: sorry for the delay.
>
> Change log v1 -> v2:
> PATCH 1 (bindings):
> * Drop power-domains property's description
> * Drop the unused label 'mcbsp0' in example
> * Add <> around each entry of the 'dmas' property
> * Add 'Reviewed-by: Rob Herring <robh@kernel.org>'
> PATCH 2 (bindings):
> * Drop the 'ti,enable-sync-err' flag
> * Drop the 'ti,disable-free-run' flag
> * Add 'Reviewed-by: Rob Herring <robh@kernel.org>'
> PATCH 4:
> * In probe() use dev_err for fixed error
> PATCH 7 (TDM):
> * set playback.max_channels to 128
> * Add a check on tx_mask as the one done for rx_mask
> * Allow TDM with BP_FP format
> PATCH 9:
> * Detection of unexpected frame pulses is enabled by default
> PATCH 10:
> * Free-running mode is selected by the DAI format through
> SND_SOC_DAIFMT_[CONT/GATED]
> PATCH 12:
> * drop the 'ti,drive-dx' property
> * add 'ti,T1-framing-[rx/tx]' properties
> PATCH 13:
> * Drop the drive_dx part
> * Add support for 'T1 framing' with data delay set to 2 bit-clock
> periods
> Bastien Curutchet (13):
> ASoC: dt-bindings: davinci-mcbsp: convert McBSP bindings to yaml
> schema
> ASoC: dt-bindings: davinci-mcbsp: Add optional clock
> ASoC: ti: davinci-i2s: Remove the unused clk_input_pin attribute
> ASoC: ti: davinci-i2s: Replace dev_err with dev_err_probe
> ASoC: ti: davinci-i2s: Use external clock to drive sample rate
> generator
> ASoC: ti: davinci-i2s: Delete unnecessary assignment
> ASoC: ti: davinci-i2s: Add TDM support
> ASoC: ti: davinci-i2s: Add handling of BP_FC format
> ASoC: ti: davinci-i2s: Enable unexpected frame pulses detection
> ASoC: ti: davinci-i2s: Link free-run mode to
> SND_SOC_DAIFMT_[GATED/CONT]
> ASoC: ti: davinci-i2s: Add S24_LE to supported formats
> ASoC: dt-bindings: davinci-mcbsp: Add the 'ti,T1-framing-{rx/tx}'
> flags
> ASoC: ti: davinci-i2s: Add T1 framing support
>
> .../bindings/sound/davinci-mcbsp.txt | 50 ----
> .../bindings/sound/davinci-mcbsp.yaml | 113 +++++++
> include/linux/platform_data/davinci_asp.h | 15 -
> sound/soc/ti/davinci-i2s.c | 278 ++++++++++++++----
> 4 files changed, 333 insertions(+), 123 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/sound/davinci-mcbsp.txt
> create mode 100644 Documentation/devicetree/bindings/sound/davinci-mcbsp.yaml
>
--
Péter
^ permalink raw reply
* Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set additionalProperties to true
From: Cristian Marussi @ 2024-04-09 14:56 UTC (permalink / raw)
To: Rob Herring
Cc: Peng Fan, Krzysztof Kozlowski, Peng Fan (OSS),
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Sudeep Holla,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAL_Jsq+aVEOPzqddu-X8GLJPex+J6V+_T1qaGHAXgp94+_-ptg@mail.gmail.com>
On Tue, Apr 09, 2024 at 09:09:46AM -0500, Rob Herring wrote:
> On Tue, Apr 9, 2024 at 7:01 AM Cristian Marussi
> <cristian.marussi@arm.com> wrote:
> >
> > On Tue, Apr 09, 2024 at 09:25:10AM +0000, Peng Fan wrote:
> > > Hi Krzysztof,
> > >
> > > > Subject: RE: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > > additionalProperties to true
> > > >
> > > > > Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > > > additionalProperties to true
> > > > >
> > > > > On 08/04/2024 08:08, Peng Fan wrote:
> > > > > >> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > > > >> additionalProperties to true
> > > > > >>
> > > > > >> On 08/04/2024 01:50, Peng Fan wrote:
> > > > > >>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > > > >>>> additionalProperties to true
> > > > > >>>>
> > > > > >>>> On 07/04/2024 12:04, Peng Fan wrote:
> > > > > >>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > > > > >>>>>> set additionalProperties to true
> > > > > >>>>>>
> > > > > >>>>>> On 07/04/2024 02:37, Peng Fan wrote:
> > > > > >>>>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > > > > >>>>>>>> set additionalProperties to true
> > > > > >>>>>>>>
> > > > > >>>>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> > > > > >>>>>>>>> From: Peng Fan <peng.fan@nxp.com>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> When adding vendor extension protocols, there is dt-schema
> > > > > >> warning:
> > > > > >>>>>>>>> "
> > > > > >>>>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do
> > > > > >>>>>>>>> not match any of the regexes: 'pinctrl-[0-9]+'
> > > > > >>>>>>>>> "
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Set additionalProperties to true to address the issue.
> > > > > >>>>>>>>
> > > > > >>>>>>>> I do not see anything addressed here, except making the
> > > > > >>>>>>>> binding accepting anything anywhere...
> > > > > >>>>>>>
> > > > > >>>>>>> I not wanna add vendor protocols in arm,scmi.yaml, so will
> > > > > >>>>>>> introduce a new yaml imx.scmi.yaml which add i.MX SCMI
> > > > > >>>>>>> protocol
> > > > > >> extension.
> > > > > >>>>>>>
> > > > > >>>>>>> With additionalProperties set to false, I not know how, please
> > > > > suggest.
> > > > > >>>>>>
> > > > > >>>>>> First of all, you cannot affect negatively existing devices
> > > > > >>>>>> (their
> > > > > >>>>>> bindings) and your patch does exactly that. This should make
> > > > > >>>>>> you thing what is the correct approach...
> > > > > >>>>>>
> > > > > >>>>>> Rob gave you the comment about missing compatible - you still
> > > > > >>>>>> did not address that.
> > > > > >>>>>
> > > > > >>>>> I added the compatible in patch 2/6 in the examples "compatible
> > > > > >>>>> =
> > > > > >>>> "arm,scmi";"
> > > > > >>>>
> > > > > >>>> So you claim that your vendor extensions are the same or fully
> > > > > >>>> compatible with arm,scmi and you add nothing... Are your
> > > > > >>>> extensions/protocol valid for arm,scmi?
> > > > > >>>
> > > > > >>> Yes. They are valid for arm,scmi.
> > > > > >>>
> > > > > >>> If yes, why is this in separate binding. If no, why you use
> > > > > >>> someone
> > > > > >>>> else's compatible?
> > > > > >>>
> > > > > >>> Per SCMI Spec
> > > > > >>> 0x80-0xFF: Reserved for vendor or platform-specific extensions to
> > > > > >>> this interface
> > > > > >>>
> > > > > >>> i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use
> > > > > >>> the id for their own protocol.
> > > > > >>
> > > > > >> So how are they valid for arm,scmi? I don't understand.
> > > > > >
> > > > > > arm,scmi is a firmware compatible string. The protocol node is a sub-node.
> > > > > > I think the arm,scmi is that saying the firmware following SCMI spec
> > > > > > to implement the protocols.
> > > > > >
> > > > > > For vendor reserved ID, firmware also follow the SCMI spec to
> > > > > > implement their own usage, so from firmware level, it is ARM SCMI
> > > > > > spec
> > > > > compatible.
> > > > >
> > > > > That's not the point. It is obvious that your firmware is compatible
> > > > > with arm,scmi, but what you try to say in this and revised patch is
> > > > > that every arm,scmi is compatible with your implementation. What you
> > > > > are saying is that 0x84 is MISC protocol for every firmware, Qualcomm,
> > > > > NXP, Samsung, TI, Mediatek etc.
> > > > >
> > > > > I claim it is not true. 0x84 is not MISC for Qualcomm, for example.
> > > >
> > > > You are right. I am lost now on how to add vendor ID support, using
> > > > arm,scmi.yaml or adding a new imx,scmi.yaml or else.
> > >
> >
> > Hi Peng,
> >
> > I dont think in the following you will find the solution to the problem,
> > it is just to recap the situation and constraints around vendor protocol
> > bindings.
> >
> > Describing SCMI vendors protocols is tricky because while on one side
> > the protocol node has to be rooted under the main scmi fw DT node (like
> > all the standard protocols) and be 'derived' from the arm,scmi.yaml
> > protocol-node definition, the optional additional properties of the a specific
> > vendor protocol nodes can be customized by each single vendor, and since,
> > as you said, you can have multiple protocols from different vendors sharing the
> > same protocol number, you could have multiple disjoint sets of valid properties
> > allowed under that same protocol node number; so on one side you have to stick
> > to some basic protocol-node defs and be rooted under the SCMI node, while on
> > the other side you will have multiple possibly allowed sets of additional
> > properties to check against, so IOW you cannot anyway just set
> > additionalProperties to false since that will result in no checks at all.
> >
> > As a consequence, at runtime, in the final DTB shipped with a specific
> > platform you should have only one of the possible vendor nodes for each
> > of these overlapping protocols, and the SCMI core at probe time will
> > pick the proper protocol implementation based on the vendor/sub_vendor
> > IDs gathered from the running SCMI fw platform at init: this way you
> > can just build the usual "all-inclusive" defconfig without worrying
> > about vendor protocol clashes since the SCMI core can pick the right
> > protocol implementation, you should just had taken care to provide the
> > proper DTB for your protocol; BUT this also means that it is not possible
> > to add multiple DT bindings based on a 'if vendor' condition since the
> > vendor itself is NOT defined and not needed in the bindings since it is
> > discoverable at runtime.
> >
> > So, after all of this blabbing of mine about this, I am wondering if it
> > is not possible that the solution is to handle each and every vendor
> > protocol node that appears with a block of addtional properties that
> > are picked via a oneOf statement from some external vendor specific
> > yaml.
> > (...in a similar way to how pinctrl additional properties are added...)
> >
> >
> > NOTE THAT the following is just an example of what I mean, it is certainly
> > wrong, incomplete annd maybe just not acceptable (and could cause DT
> > maintainers eyes to bleed :P)...
> >
> > ...so it is just fr the sake of explaining what I mean...
> >
> > diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > index e9d3f043c4ed..3c38a1e3ffed 100644
> > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > @@ -278,6 +278,22 @@ properties:
> > required:
> > - reg
> >
> > + protocol@81:
> > + $ref: '#/$defs/protocol-node'
> > + unevaluatedProperties: false
> > +
> > + properties:
> > + reg:
> > + const: 0x81
> > +
> > + patternProperties:
> > + '$':
> > + type: object
>
> Did you mean to have child nodes under the protocol node rather than in it?
... nope ... it is just as bad as my yaml-fu is :P ... but not sure if
vendors has also this needs or plain props will suffice...
>
> > + oneOf:
> > + - $ref: /schemas/vendor-A/scmi-protos.yaml#
> > + - $ref: /schemas/vendor-B/protos.yaml#
>
> Moved up one level, this would work, but it would have to be an
> 'anyOf' because it is possible that 2 vendors have the exact same set
> of properties.
>
ok
> I can think of 2 other ways to structure this.
>
> First, is a specific vendor protocol discoverable? Not that is 0x81
> protocol present, but that 0x81 is vendor Foo's extra special
> value-add protocol? If not, I think we should require a compatible
> string on vendor protocols. Then the base SCMI schema can require just
> that, and each vendor protocol defines its node with a $ref to
> '#/$defs/protocol-node'.
Basically yes it is discoverable, since at runtime the SCMI core, early on,
normally discovers the vendor_id/sub_vendor_id by querying the platform via
Base protocol and then later only loads/initializes (by closest match) the
vendor protocols that are present in the DT AND that has been 'tagged' at
compile time with the same vendor_id/sub_vendor_id tuple (in the vendor
module code, struct scmi_protocol)
Of course you should take care to put the proper protocol@81 node in your
vendor_A DTB for the vendor_A SCMI driver to make use of the additional
vendor_A properties that you have defined under your node as referred
in your vendor-protos.yaml...if you botch that up I will load a protocol
and call your vendor_A driver with a vendor_X DT node.
DT is currrently vendor-agnostic.
>
> The 2nd way is just a variation of the oneOf above, but do we do 1
> file per vendor protocol or 1 file per vendor. Either should be
> doable, just a matter of where 'protocol@81', etc. are defined.
>
Oh, yes mine was just an ill example...one file per vendor will do just
fine: the important thing is that the list and the yaml itself can be
extended as new vendors appears (in a backward compatble way of course)
Thanks,
Cristian
^ permalink raw reply
* Re: [PATCH v2 0/2] Add support for AD4000 series
From: Marcelo Schmitt @ 2024-04-09 14:59 UTC (permalink / raw)
To: David Lechner
Cc: Marcelo Schmitt, lars, Michael.Hennerich, jic23, robh+dt,
krzysztof.kozlowski+dt, conor+dt, linux-iio, devicetree,
linux-kernel
In-Reply-To: <CAMknhBFoX9mC3F43GSmYZyET9oQvHEB+AAsesZv-aEgFPZPA_w@mail.gmail.com>
On 04/08, David Lechner wrote:
> On Mon, Apr 8, 2024 at 9:31 AM Marcelo Schmitt
> <marcelo.schmitt@analog.com> wrote:
> >
> > This is more like an RFC patch set since configuration read/write is currently
> > buggy.
> >
> > Change log v1 -> v2:
> > - Took device tree provided by David.
> > - Dropped ABI additions in favor of device tree properties.
> > - Set differential IIO channel subtype for differential ADCs.
> > - Set scan_type shift bits to mask out correct real bits from buffer.
> > - Added __aligned(8) to buffer timestamp.
> > - Used union to reduce buffer memory usage for 16-bit devices.
> > - Used SPI transfer functions rather than SPI message.
> > - Used c99 style structure initialization.
> > - Used iio_device_claim_direct_scoped().
> > - Removed unneeded pointer casts.
> > - Added other power supplies (VDD and VIO).
> >
> > Link to v1: https://lore.kernel.org/linux-iio/cover.1711131830.git.marcelo.schmitt@analog.com/
> >
> > Additional topics:
> >
> > - Why there is no different handling for the different SPI wiring modes?
> > It looks like there is no need for different handling of "4-wire" and "3-wire"
> > modes.
> > If in "4-wire" (dt default mode), SDI is connected to SPI controller CS and
> > CNV is active high. We can activate the CNV GPIO then let the SPI controller
> > bring CS (connected to SDI) down when starting the transfer.
> > If in "3-wire" (dt single mode), if we have a CNV (active low) GPIO we activate
> > it and then proceed with with the transfer. If controller CS is connected to
> > CNV it works the same way.
> > I'm thinking it's better if we can support these devices in similar way
> > other SPI ADCs are supported. Does that make sense?
>
> In the AD7944 driver, I handled the "3-wire" mode separately because
> the sample conversion is triggered on the rising edge of the CNV line.
> In "4-wire" mode, since we have a GPIO connected to CNV, we can just
> toggle the GPIO from low to high, wait for the conversion time
> (t_CONV) and then read the sample (SPI xfer) then toggle the CNV line
> low again. In 3-wire mode, the CS line is connected to the CNV pin, so
> in order to get an up-to-date sample, we need to to toggle the CS line
> from low to high to trigger a conversion (spi xfer with no data, only
> delay), then wait for the conversion time, then read the sample (2nd
> spi xfer). So in "4-wire" mode, the CS line is getting toggled once
> per sample, but in "3-wire" mode, it is getting toggled twice per
> sample. I didn't add support for "3-wire" mode where CNV is connected
> to GPIO because we can't get max sample rate that way and it is
> unusual to not have CS connected to something. But if we do that here,
> the timing has to be different from 4-wire mode in order to not get
> stale data.
Yes, that's also the case for ad4000 series. The rising edge of CNV triggers
the conversion which causes a latency/delay of one read if CNV is connected
to a chip select.
I thought it was okay to just accept the latency since it's intrinsic to the
ADC start conversion on CNV rising edge and latency would be less noticeable
when doing continuous sampling.
Although, this indeed causes the timestamps to be disarranged, which is making me
rethink the implementation.
Yet, if we choose to have extra pulse of CNV for the sake of getting correct
timesamps, that might also impact performance for high sample rates (unless
split sample handling into different cases for single-shot and buffered readings).
I'll give it try and do it like ad7944.
>
> > To me, the "3-wire" mode with controller CS to ADC CNV is what most resembles
> > conventional SPI. The only important distinction is that the
> > controller must be able to keep ADC SDI line high during conversions.
> > Although, while the spi-engine implementation provided to me can keep SDI up
> > during conversions, I'm not sure its a thing all SPI controllers can do.
> > I tried a raspberry pi 4 some time ago and it was leaving the SDI line low if
> > no tx buffer was provided. Even with a tx full of 1s the controller would
> > bring SDI down between each 8 bits of transfer.
>
> This is a good point. It sounds like additional bindings are needed to
> describe the various wiring cases of the SDI line.
>
> It sounds like possibilities are:
>
> 1. SDI is hard-wired high -> can't write to registers, CNV is
> connected to SPI controller CS, chip is in "3-wire" mode. Currently
> adi,spi-mode="single"
> 2. SDI is connected to SDO of another chip, SDI of last chip is
> hard-wired low -> can't write to registers, CNV is connected to SPI
> controller CS, chips are in daisy chain mode. Currently
> adi,spi-mode="chain"
> 3. SDI is connected to SPI controller CS -> can't write registers,
> chip can operate in 4-wire mode with CNV connected to GPIO, Currently
> adi,spi-mode omitted.
> 4. SDI is connected to SPI controller SDO -> can write registers, and
> support all writing modes (3-wire, 4-wire, daisy chain) as long as SPI
> controller SDO line can be kept high or low at the appropriate time.
> Currently not handled.
> 5. There could be a pin mux that switches between the one of the first
> three and the 4th option (needed to avoid the issue with SPI
> controller not being able to place the SDI pin in the correct state
> during conversion trigger as described above).
>
> On AD7944, the proposed adi,spi-mode property was sufficient to
> describe what was wired to the SDI pin because we only had the first 3
> options (the AD7944 doesn't have SPI registers to write to).
>
> Also see related comments in my reply to the DT bindings patch.
>
> (From the complete bindings point of view, we should probably also
> consider the possibility of variations of 1. and 2. where CS of the
> SPI controller is not wired and CNV is connected to a GPIO - this can
> be determined by the combination of the adi,spi-mode property and the
> presence or absence of the cnv-gpios property.)
This sounds reasonable to me. I also think the comments on DT patch are good.
Will comment there too.
>
> > Anyway, single-shot and buffered reads work with the spi-engine controller
> > with ADC in "3-wire"/single mode with controller CS line connected to ADC CNV
> > pin which is how I've been testing it.
>
> Technically, yes data can be captured in "3-wire" mode with a single
> CS toggle, but then the data is stale and doesn't correspond to the
> soft timestamp because it is reading the data from the previous
> conversion triggered by the last SPI xfer, whenever that was. Since it
> is trivial to avoid this by adding the extra CS/CNV toggle I describe
> above, I don't see any reason not to.
Okay, will make it do the extra pulse to CNV for "3-wire" mode.
>
> But the way the driver is written now, it is actually only supporting
> the unnamed wiring option 4 from above, so now I understand the
> confusion about 3-wire vs. 4-wire mode in that context.
>
> >
> > - Why did not make vref regulator optional?
> > Other SAR ADCs I've seen needed a voltage reference otherwise they simply
> > could not provide any reasonable readings. Isn't it preferable to fail rather
> > than having a device that can't provide reliable data?
>
> In the device tree bindings, making vref-supply required makes sense
> since there is no internal reference. In the driver, as discussed in
> V1, it will fail if vref-supply in regulator_get_voltage() if
> vref-supply is missing and we use devm_regulator_get() instead of
> devm_regulator_get_optional(). So leaving it as-is is fine. We have a
> plan to clean this up later anyway.
>
Not sure I understand the idea here. Should the driver use
devm_regulator_get_optional() instead of devm_regulator_get() because
the optional call would fail immediately if no vref-supply while the regular
call would only fail at regulator_get_voltage()? Why? This looks very counter
intuitive to me.
> >
> > - Why did not split into AD and ADAQ patches?
> > The main difference between AD and ADAQ is the amplifier in front of the ADC.
> > If only supporting AD, we could probably avoid the scale table since it would
> > only have two possible values per ADC. But then the handling of span compression
> > scale would need refactoring to be in the scale table when adding ADAQ.
> > I'm not excited to implement something knowing it will need rework in the
> > following patch. Will do if required.
>
> If it isn't that much work, it seems worth it to me. If the driver
> work is too much, maybe just split the DT patch?
>
> >
> > - Span compression and offset.
> > For non-differential ADCs, enabling the span compression requires an input offset.
> > Link: https://www.analog.com/media/en/technical-documentation/data-sheets/AD4000-4004-4008.pdf
> > page 18
> > and
> > Link: https://www.analog.com/media/en/technical-documentation/data-sheets/ad4002-4006-4010.pdf
> > page 19
> > I updated the _offset attribute for those ADCs according to span compression
> > being enabled or not. Is it okay to have an attribute update cause an update to
> > another one?
> > Maybe also make the span compression a dt property and have it fixed after probe?
>
> This doesn't sound like something that belongs in DT since it doesn't
> depend on the physical properties of what is wired to the input.
>
> But the fact that offset should not be read until after scale is set
> sounds like a quirk that would be worth documenting in some
> chip-specific docs.
>
> >
> > - Configuration register
> > Despite it doing single-shot and buffered captures, read and writes to the
> > configuration register are currently buggy. It is as if the register was
> > "floating". I tried setting up buffers like ad7768-1, adxl355_core, bma220_spi,
> > bma400_core, and mcp3911.
>
> If the ADC CNV pin is connected to a GPIO and the ADC SDI pin is
> connected to SDO of the SPI controller, then nothing is connected to
> CS of the SPI controller, so that might be the problem.
ADC CNV is connected to controller CS and ADC SDI to controller SDO.
Think it's something to do with buffer alignment.
Will try the changes suggested in reply to driver patch.
>
> >
> >
> > Thanks,
> > Marcelo
> >
> > Marcelo Schmitt (2):
> > dt-bindings: iio: adc: Add AD4000
> > iio: adc: Add support for AD4000
> >
> > .../bindings/iio/adc/adi,ad4000.yaml | 201 ++++++
> > MAINTAINERS | 8 +
> > drivers/iio/adc/Kconfig | 12 +
> > drivers/iio/adc/Makefile | 1 +
> > drivers/iio/adc/ad4000.c | 649 ++++++++++++++++++
> > 5 files changed, 871 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad4000.yaml
> > create mode 100644 drivers/iio/adc/ad4000.c
> >
> > --
> > 2.43.0
> >
> >
^ permalink raw reply
* Re: [PATCH v2 2/5] arm64: dts: qcom: sm8350-hdk: add USB-C orientation GPIO
From: Konrad Dybcio @ 2024-04-09 15:00 UTC (permalink / raw)
To: Dmitry Baryshkov, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20240409-hdk-orientation-gpios-v2-2-658efd993987@linaro.org>
On 4/9/24 16:28, Dmitry Baryshkov wrote:
> Define the USB-C orientation GPIO so that the USB-C port orientation is
> known without having to resort to the altmode notifications.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Konrad
^ permalink raw reply
* Re: [PATCH v2 3/5] arm64: dts: qcom: sm8450-hdk: add USB-C orientation GPIO
From: Konrad Dybcio @ 2024-04-09 15:00 UTC (permalink / raw)
To: Dmitry Baryshkov, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20240409-hdk-orientation-gpios-v2-3-658efd993987@linaro.org>
On 4/9/24 16:28, Dmitry Baryshkov wrote:
> Define the USB-C orientation GPIO so that the USB-C port orientation is
> known without having to resort to the altmode notifications.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Konrad
^ 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