* Re: [PATCH v14 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings
From: Krzysztof Kozlowski @ 2024-04-09 7:29 UTC (permalink / raw)
To: Tanmay Shah, andersson, mathieu.poirier, robh,
krzysztof.kozlowski+dt, conor+dt, michal.simek, ben.levinsky
Cc: linux-remoteproc, devicetree, linux-arm-kernel, linux-kernel,
Radhey Shyam Pandey
In-Reply-To: <20240408205313.3552165-3-tanmay.shah@amd.com>
On 08/04/2024 22:53, Tanmay Shah wrote:
> From: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
>
> Introduce bindings for TCM memory address space on AMD-xilinx Zynq
> UltraScale+ platform. It will help in defining TCM in device-tree
> and make it's access platform agnostic and data-driven.
>
> Tightly-coupled memories(TCMs) are low-latency memory that provides
> predictable instruction execution and predictable data load/store
> timing. Each Cortex-R5F processor contains two 64-bit wide 64 KB memory
> banks on the ATCM and BTCM ports, for a total of 128 KB of memory.
>
> The TCM resources(reg, reg-names and power-domain) are documented for
> each TCM in the R5 node. The reg and reg-names are made as required
> properties as we don't want to hardcode TCM addresses for future
> platforms and for zu+ legacy implementation will ensure that the
> old dts w/o reg/reg-names works and stable ABI is maintained.
>
> It also extends the examples for TCM split and lockstep modes.
>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: rtc: orion-rtc: move to trivial-rtc
From: Krzysztof Kozlowski @ 2024-04-09 7:31 UTC (permalink / raw)
To: Javier Carrasco, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jiaxun Yang,
Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery, Maxime Coquelin,
Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32
In-Reply-To: <20240408-rtc_dtschema-v1-1-c447542fc362@gmail.com>
On 08/04/2024 17:53, Javier Carrasco wrote:
> This RTC requires a compatible, a reg and a single interrupt,
> which makes it suitable for a direct conversion into trivial-rtc.
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> ---
> Documentation/devicetree/bindings/rtc/orion-rtc.txt | 18 ------------------
> Documentation/devicetree/bindings/rtc/trivial-rtc.yaml | 2 ++
> 2 files changed, 2 insertions(+), 18 deletions(-)
I assume you checked if any entry in MAINTAINERS needs updating.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/9] dt-bindings: rtc: google,goldfish-rtc: move to trivial-rtc
From: Krzysztof Kozlowski @ 2024-04-09 7:32 UTC (permalink / raw)
To: Javier Carrasco, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jiaxun Yang,
Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery, Maxime Coquelin,
Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32
In-Reply-To: <20240408-rtc_dtschema-v1-2-c447542fc362@gmail.com>
On 08/04/2024 17:53, Javier Carrasco wrote:
> This RTC requires a compatible, a reg and a single interrupt,
> which makes it suitable for a direct conversion into trivial-rtc.
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/9] dt-bindings: rtc: lpc32xx-rtc: move to trivial-rtc
From: Krzysztof Kozlowski @ 2024-04-09 7:34 UTC (permalink / raw)
To: Javier Carrasco, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jiaxun Yang,
Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery, Maxime Coquelin,
Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32
In-Reply-To: <20240408-rtc_dtschema-v1-3-c447542fc362@gmail.com>
On 08/04/2024 17:53, Javier Carrasco wrote:
> This RTC requires a compatible, a reg and a single interrupt,
> which makes it suitable for a direct conversion into trivial-rtc.
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> ---
> Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt | 15 ---------------
> Documentation/devicetree/bindings/rtc/trivial-rtc.yaml | 2 ++
> 2 files changed, 2 insertions(+), 15 deletions(-)
This one no... and if you tested DTS you would see errors, although you
need to test specific lpc config, not multi_v7.
It does not look like you tested the DTS against bindings. Please run
`make dtbs_check W=1` (see
Documentation/devicetree/bindings/writing-schema.rst or
https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
for instructions).
Anyway, you *must* check all DTS before moving anything to trivial.
Does it mean all other bindings were not checked against DTS at all?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 4/9] dt-bindings: rtc: maxim,ds1742: move to trivial-rtc
From: Krzysztof Kozlowski @ 2024-04-09 7:35 UTC (permalink / raw)
To: Javier Carrasco, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jiaxun Yang,
Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery, Maxime Coquelin,
Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32
In-Reply-To: <20240408-rtc_dtschema-v1-4-c447542fc362@gmail.com>
On 08/04/2024 17:53, Javier Carrasco wrote:
> This RTC only requires the compatible a reg and properties,
> which makes it suitable for a direct conversion into trivial-rtc.
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 5/9] dt-bindings: rtc: rtc-aspeed: move to trivial-rtc
From: Krzysztof Kozlowski @ 2024-04-09 7:36 UTC (permalink / raw)
To: Javier Carrasco, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jiaxun Yang,
Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery, Maxime Coquelin,
Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32
In-Reply-To: <20240408-rtc_dtschema-v1-5-c447542fc362@gmail.com>
On 08/04/2024 17:53, Javier Carrasco wrote:
> The RTCs documented in this binding require a compatible, a reg
> and a single interrupt, which make them suitable for a direct
> conversion into trivial-rtc.
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 6/9] dt-bindings: rtc: pxa-rtc: convert to dtschema
From: Krzysztof Kozlowski @ 2024-04-09 7:37 UTC (permalink / raw)
To: Javier Carrasco, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jiaxun Yang,
Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery, Maxime Coquelin,
Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32
In-Reply-To: <20240408-rtc_dtschema-v1-6-c447542fc362@gmail.com>
On 08/04/2024 17:53, Javier Carrasco wrote:
> Convert existing binding to dtschema to support validation.
>
> The missing 'reg' and 'interrupts' properties have been added, taking
> the 2 supported interrupts into account to fix the example.
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 7/9] dt-bindings: rtc: spear-rtc: move to trivial-rtc
From: Krzysztof Kozlowski @ 2024-04-09 7:37 UTC (permalink / raw)
To: Javier Carrasco, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jiaxun Yang,
Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery, Maxime Coquelin,
Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32
In-Reply-To: <20240408-rtc_dtschema-v1-7-c447542fc362@gmail.com>
On 08/04/2024 17:53, Javier Carrasco wrote:
> The RTC documented in this binding requires a compatible, a reg
> and a single interrupt, which makes it suitable for a direct
> conversion into trivial-rtc.
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> ---
> Documentation/devicetree/bindings/rtc/spear-rtc.txt | 15 ---------------
> Documentation/devicetree/bindings/rtc/trivial-rtc.yaml | 2 ++
> 2 files changed, 2 insertions(+), 15 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 8/9] dt-bindings: rtc: stmp3xxx-rtc: convert to dtschema
From: Krzysztof Kozlowski @ 2024-04-09 7:40 UTC (permalink / raw)
To: Javier Carrasco, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jiaxun Yang,
Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery, Maxime Coquelin,
Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32
In-Reply-To: <20240408-rtc_dtschema-v1-8-c447542fc362@gmail.com>
On 08/04/2024 17:53, Javier Carrasco wrote:
> Convert existing binding to dtschema to support validation.
>
> The 'fsl,imx28-rtc' compatible is currently not supported, and it is
> only referenced in this binding and in nxp/mxs/imx28.dtsi. Therefore,
> that compatible has been dropped, which triggers a warning when testing
> the DT against the new binding.
Instead document missing compatibles and mention this in commit msg.
>
> There is another reference to fsl,stmp3xxx-rtc in nxp/mxs/imx23.dtsi,
> where another unsupported compatible 'fsl,imx23-rtc' is used, and the
> same problem would arise when testing the file against the new binding.
Please write concise messages... you have to paragraphs about the same?
What is the difference here?
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> ---
> .../devicetree/bindings/rtc/fsl,stmp3xxx-rtc.yaml | 45 ++++++++++++++++++++++
> .../devicetree/bindings/rtc/stmp3xxx-rtc.txt | 21 ----------
> 2 files changed, 45 insertions(+), 21 deletions(-)
>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 9/9] dt-bindings: rtc: via,vt8500-rtc: move to trivial-rtc
From: Krzysztof Kozlowski @ 2024-04-09 7:40 UTC (permalink / raw)
To: Javier Carrasco, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jiaxun Yang,
Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery, Maxime Coquelin,
Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32
In-Reply-To: <20240408-rtc_dtschema-v1-9-c447542fc362@gmail.com>
On 08/04/2024 17:53, Javier Carrasco wrote:
> The RTC documented in this binding requires a compatible, a reg
> and a single interrupt, which makes it suitable for a direct
> conversion into trivial-rtc.
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v7 1/5] dt-bindings: interconnect: Add Qualcomm IPQ9574 support
From: Varadarajan Narayanan @ 2024-04-09 7:41 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: andersson, konrad.dybcio, mturquette, sboyd, robh, krzk+dt,
conor+dt, djakov, dmitry.baryshkov, quic_anusha, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-pm
In-Reply-To: <Zg5q6mnWtK6hmPBT@hu-varada-blr.qualcomm.com>
On Thu, Apr 04, 2024 at 02:25:06PM +0530, Varadarajan Narayanan wrote:
> On Wed, Apr 03, 2024 at 04:59:40PM +0200, Krzysztof Kozlowski wrote:
> > On 03/04/2024 12:42, Varadarajan Narayanan wrote:
> > > Add interconnect-cells to clock provider so that it can be
> > > used as icc provider.
> > >
> > > Add master/slave ids for Qualcomm IPQ9574 Network-On-Chip
> > > interfaces. This will be used by the gcc-ipq9574 driver
> > > that will for providing interconnect services using the
> > > icc-clk framework.
> > >
> > > Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
> > > ---
> > > v7:
> > > Fix macro names to be consistent with other bindings
> > > v6:
> > > Removed Reviewed-by: Krzysztof Kozlowski
> > > Redefine the bindings such that driver and DT can share them
> > >
> > > v3:
> > > Squash Documentation/ and include/ changes into same patch
> > >
> > > qcom,ipq9574.h
> > > Move 'first id' to clock driver
> > >
> > > ---
> > > .../bindings/clock/qcom,ipq9574-gcc.yaml | 3 +
> > > .../dt-bindings/interconnect/qcom,ipq9574.h | 87 +++++++++++++++++++
> > > 2 files changed, 90 insertions(+)
> > > create mode 100644 include/dt-bindings/interconnect/qcom,ipq9574.h
> > >
> > > diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
> > > index 944a0ea79cd6..824781cbdf34 100644
> > > --- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
> > > +++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
> > > @@ -33,6 +33,9 @@ properties:
> > > - description: PCIE30 PHY3 pipe clock source
> > > - description: USB3 PHY pipe clock source
> > >
> > > + '#interconnect-cells':
> > > + const: 1
> > > +
> > > required:
> > > - compatible
> > > - clocks
> > > diff --git a/include/dt-bindings/interconnect/qcom,ipq9574.h b/include/dt-bindings/interconnect/qcom,ipq9574.h
> > > new file mode 100644
> > > index 000000000000..0b076b0cf880
> > > --- /dev/null
> > > +++ b/include/dt-bindings/interconnect/qcom,ipq9574.h
> > > @@ -0,0 +1,87 @@
> > > +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> > > +#ifndef INTERCONNECT_QCOM_IPQ9574_H
> > > +#define INTERCONNECT_QCOM_IPQ9574_H
> > > +
> > > +#define ICC_ANOC_PCIE0 0
> > > +#define ICC_SNOC_PCIE0 1
> > > +#define ICC_ANOC_PCIE1 2
> > > +#define ICC_SNOC_PCIE1 3
> > > +#define ICC_ANOC_PCIE2 4
> > > +#define ICC_SNOC_PCIE2 5
> > > +#define ICC_ANOC_PCIE3 6
> > > +#define ICC_SNOC_PCIE3 7
> > > +#define ICC_SNOC_USB 8
> > > +#define ICC_ANOC_USB_AXI 9
> > > +#define ICC_NSSNOC_NSSCC 10
> > > +#define ICC_NSSNOC_SNOC_0 11
> > > +#define ICC_NSSNOC_SNOC_1 12
> > > +#define ICC_NSSNOC_PCNOC_1 13
> > > +#define ICC_NSSNOC_QOSGEN_REF 14
> > > +#define ICC_NSSNOC_TIMEOUT_REF 15
> > > +#define ICC_NSSNOC_XO_DCD 16
> > > +#define ICC_NSSNOC_ATB 17
> > > +#define ICC_MEM_NOC_NSSNOC 18
> > > +#define ICC_NSSNOC_MEMNOC 19
> > > +#define ICC_NSSNOC_MEM_NOC_1 20
> > > +
> > > +#define ICC_NSSNOC_PPE 0
> > > +#define ICC_NSSNOC_PPE_CFG 1
> > > +#define ICC_NSSNOC_NSS_CSR 2
> > > +#define ICC_NSSNOC_IMEM_QSB 3
> > > +#define ICC_NSSNOC_IMEM_AHB 4
> > > +
> > > +#define MASTER_ANOC_PCIE0 (ICC_ANOC_PCIE0 * 2)
> > > +#define SLAVE_ANOC_PCIE0 ((ICC_ANOC_PCIE0 * 2) + 1)
> >
> > Which existing Qualcomm platform has such code?
>
> Existing Qualcomm platforms don't use icc-clk. They use icc-rpm
> or icc-rpmh. clk-cbf-msm8996.c is the only driver that uses icc-clk.
>
> The icc_clk_register automatically creates master & slave nodes
> for each clk entry provided as input with the node-ids 'n' and
> 'n+1'. Since clk-cbf-msm8996.c has only one entry, it could just
> define MASTER_CBF_M4M and SLAVE_CBF_M4M with 0 and 1 and avoid these
> calculations.
>
> However, ipq9574 gives an array of clock entries as input to
> icc_clk_register. To tie the order/sequence of these clock
> entries correctly with the node-ids, this calculation is needed.
>
> > This is the third time I am asking for consistent headers. Open
> > existing, recently added headers and look how it is done there. Why?
> > Because I am against such calculations and see no reason for them.
>
> Apologies. Regret that I have to trouble you.
>
> In this ipq9574 case, have to reconcile between the following
> feedbacks.
>
> 1. https://lore.kernel.org/linux-arm-msm/fe40b307-26d0-4b2a-869b-5d093415b9d1@linaro.org/
> We could probably use indexed identifiers here to avoid confusion:
> [ICC_BINDING_NAME] = CLK_BINDING_NAME
>
> 2. https://lore.kernel.org/linux-arm-msm/95f4e99a60cc97770fc3cee850b62faf.sboyd@kernel.org/
> Are these supposed to be in a dt-binding header?
>
> 3. https://lore.kernel.org/linux-arm-msm/031d0a35-b192-4161-beef-97b89d5d1da6@linaro.org/
> Do you use them as well in the DTS?
>
> Having the defines (with the calculations) seemed to to comply
> with the above three feedbacks.
>
> Please let me know if this can be handled in a different way that
> would be consistent with other Qualcomm platforms.
Krzysztof,
Is this ok? Can I post a new version addressing other review comments?
Thanks
Varada
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: mailbox: arm,mhuv3: Add bindings
From: Krzysztof Kozlowski @ 2024-04-09 7:44 UTC (permalink / raw)
To: Cristian Marussi, linux-kernel, linux-arm-kernel, devicetree
Cc: sudeep.holla, jassisinghbrar, robh+dt, krzysztof.kozlowski+dt,
conor+dt
In-Reply-To: <20240404062347.3219795-2-cristian.marussi@arm.com>
On 04/04/2024 08:23, Cristian Marussi wrote:
> Add bindings for the ARM MHUv3 Mailbox controller.
>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
...
> + mailbox@2aaa0000 {
> + compatible = "arm,mhuv3";
> + #mbox-cells = <3>;
> + reg = <0 0x2aaa0000 0 0x10000>;
> + clocks = <&clock 0>;
> + interrupt-names = "combined", "pbx-dbch-xfer-ack-1",
> + "ffch-high-tide-0";
> + interrupts = <0 36 4>, <0 37 4>;
> + };
> +
> + mailbox@2ab00000 {
> + compatible = "arm,mhuv3";
> + #mbox-cells = <3>;
> + reg = <0 0x2aab0000 0 0x10000>;
> + clocks = <&clock 0>;
> + interrupt-names = "combined", "mbx-dbch-xfer-1", "ffch-low-tide-0";
> + interrupts = <0 35 4>, <0 38 4>, <0 39 4>;
Use defines for GIC and level flags.
With this fixed:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] riscv: dts: sophgo: add initial Milk-V Duo S board device tree
From: Michael Opdenacker @ 2024-04-09 7:52 UTC (permalink / raw)
To: Inochi Amaoto, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen Wang, Paul Walmsley, Palmer Dabbelt, Albert Ou
Cc: michael.opdenacker, devicetree, linux-riscv, linux-kernel
In-Reply-To: <IA1PR20MB49532A8D4294ADCE0C33A654BB072@IA1PR20MB4953.namprd20.prod.outlook.com>
Hi Inochi
Thanks for the review and tips!
On 4/9/24 at 09:17, Inochi Amaoto wrote:
> On Tue, Apr 09, 2024 at 08:45:04AM +0200, michael.opdenacker@bootlin.com wrote:
>> From: Michael Opdenacker <michael.opdenacker@bootlin.com>
>>
>> This adds initial support for the Milk-V Duo S board
>> (https://milkv.io/duo-s), enabling the serial port and
>> read-only SD card support, allowing to boot Linux to the
>> command line.
>>
> Hi Michael,
>
> I think your patch losts the board binding and have wrong compatiable.
> Also, the SD can have rw support with proper property. See link [1]
> (need 'disable-wp').
Right, ""sophgo,sg2000" doesn't exist yet, so it will be indeed cleaner
to use "sophgo,cv1812h" instead.
>
> I suggest you resubmitting this patch after applying clk patchs.
> This could reduce some unnecessary change. For now, you can just
> use the dts for huashan-pi (with changed memory size).
>
> [1]: https://lore.kernel.org/linux-riscv/IA1PR20MB4953B158F6F575840F3D4267BB7D2@IA1PR20MB4953.namprd20.prod.outlook.com/
Good to know. That was next on my list.
I'll submit a V2 in the next days.
Thanks again
Cheers
Michael.
--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: adc: ad7173: add support for ad411x
From: Ceclan, Dumitru @ 2024-04-09 8:08 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner
Cc: dumitru.ceclan, Lars-Peter Clausen, Michael Hennerich,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20240406155328.447b594f@jic23-huawei>
On 06/04/2024 17:53, Jonathan Cameron wrote:
> On Wed, 3 Apr 2024 10:40:39 -0500
> David Lechner <dlechner@baylibre.com> wrote:
>
>> On Wed, Apr 3, 2024 at 2:43 AM Ceclan, Dumitru <mitrutzceclan@gmail.com> wrote:
>>>
>>> On 01/04/2024 22:37, David Lechner wrote:
>>>> On Mon, Apr 1, 2024 at 10:10 AM Dumitru Ceclan via B4 Relay
>>>> <devnull+dumitru.ceclan.analog.com@kernel.org> wrote:
>>>>>
>>>>> From: Dumitru Ceclan <dumitru.ceclan@analog.com>
>>>
>>> ...
>>>
>>>>> properties:
>>>>> reg:
>>>>> + description:
>>>>> + Reg values 16-19 are only permitted for ad4111/ad4112 current channels.
>>>>> minimum: 0
>>>>> - maximum: 15
>>>>> + maximum: 19
>>>>
>>>> This looks wrong. Isn't reg describing the number of logical channels
>>>> (# of channel config registers)?
>>>>
>>>> After reviewing the driver, I see that > 16 is used as a way of
>>>> flagging current inputs, but still seems like the wrong way to do it.
>>>> See suggestion below.
>>>>
>>>
>>> This was a suggestion from Jonathan, maybe I implemented it wrong.
>
> Maybe Jonathan was wrong! I was younger then than now :)
>
> However, reg values for child nodes are unique so can't just use a flag these
> need to be different values.
>
I do not see where the restriction appears when using just the flag, when defining
the channels you would still define unique reg values.
>>> Other alternative that came to my mind: attribute "adi,current-channel".
>>
>> Having a boolean flag like this would make more sense to me if we
>> don't agree that the suggestion below is simpler.
>>
>>>>>
>>>>> diff-channels:
>>>>> + description:
>>>>> + For using current channels specify only the positive channel.
>>>>> + (IIN2+, IIN2−) -> diff-channels = <2 0>
>>>>
>>>> I find this a bit confusing since 2 is already VIN2 and 0 is already
>>>> VIN0. I think it would make more sense to assign unique channel
>>>> numbers individually to the negative and positive current inputs.
>>>> Also, I think it makes sense to use the same numbers that the
>>>> registers in the datasheet use (8 - 11 for negative and 12 to 15 for
>>>> positive).
>>>>
>>>> So: (IIN2+, IIN2−) -> diff-channels = <13 10>
>>>>
>>>>
>>> It would mean for the user to look in the datasheet at the possible
>>> channel INPUT configurations values, decode the bit field into two
>>> integer values and place it here (0110101010) -> 13 10. This is
>>> cumbersome for just choosing current input 2.
>>
>> It could be documented in the devicetree bindings, just as it is done
>> in adi,ad4130.yaml so that users of the bindings don't have to
>> decipher the datasheet.
>
> The <13 10> option makes sense to me and avoids suggesting a common negative
> input.
>
> The 'fun' bit here is that diff-channels doesn't actually tell us anything.
> So we could just not provide it and rely on documentation of reg = 16-19 meaning
> the current channels?
>
So a channel without diff-channels defined and reg=16 means IN0+ IN0-?
>>
>>>
>>>>> +
>>>>> + Family AD411x supports a dedicated VCOM voltage input.
>>>>> + To select it set the second channel to 16.
>>>>> + (VIN2, VCOM) -> diff-channels = <2 16>
>>>>
>>>> The 411x datasheets call this pin VINCOM so calling it VCOM here is a
>>>> bit confusing.
>>>>
>>>
>>> Sure, I'll rename to VINCOM.
>>>
>>>> Also, do we need to add a vincom-supply to get this voltage? Or is it
>>>> safe to assume it is always connected to AVSS? The datasheet seems to
>>>> indicate that the latter is the case. But then it also has this
>>>> special case (at least for AD4116, didn't check all datasheets)
>>>> "VIN10, VINCOM (single-ended or differential pair)". If it can be used
>>>> as part of a fully differential input, we probably need some extra
>>>> flag to indicate that case.
>>>>
>>>
>>> I cannot see any configuration options for these use cases. All inputs
>>> are routed to the same mux and routed to the differential positive and
>>> negative ADC inputs.
>>>
>>> "VIN10, VINCOM (single-ended or differential pair)" the only difference
>>> between these two use cases is if you connected VINCOM to AVSS (with
>>> unipolar coding) or not with bipolar encoding. The channel is still
>>> measuring the difference between the two selected inputs and comparing
>>> to the selected reference.
>>>
>>>> Similarly, do we need special handling for ADCIN15 on AD4116? It has a
>>>> "(pseudo differential or differential pair)" notation that other
>>>> inputs don't. In other words, it is more like VINCOM than it is to the
>>>> other ADCINxx pins. So we probably need an adcin15-supply for this pin
>>>> to properly get the right channel configuration. I.e. the logic in the
>>>> IIO driver would be if adcin15-supply is present, any channels that
>>>> use this input are pseudo-differential, otherwise any channels that
>>>> use it are fully differential.
>>>>
>>>
>>> I cannot seem to understand what would a adcin15-supply be needed for.
>>> This input, the same as all others, enters the mux and is routed to
>>> either positive or negative input of the ADC.
>>>
>>> The voltage on the ADCIN15 pin is not important to the user, just the
>>> difference in voltage between that pin and the other one selected.
>>>
>>
>> These suggestions come from some recent discussion about
>> pseudo-differential vs. fully differential inputs (e.g. search the IIO
>> mailing list for AD7380).
>>
>> So what I suggested here might be more technically correct according
>> to what I got out of that discussion. But for this specific case, I
>> agree it is good enough to just treat all inputs as always
>> fully-differential to keep things from getting too unwieldy.
>
> Hmm. That whole approach to pseudo differential does get messy if
> we have the common line routed through the main MUX rather than an opt
> in only on the negative side.
>
> If I read this right, its almost a trick to support a pseudo differential
> wiring with simple registers (I guess reflecting MUX limitations).
>
> So what could we do?
>
> We could assume that VINCOM is used like a conventional pseudo
> differential negative signal and have supply-vincom + non diffferential
> channels if that's the configuration wanted.
>
> Then for differential channels can support all the VINX VINX+1
> and swapped options.
> For VIN10 it gets fun as non differential and differential options
> I think map to same actual config. Don't see reason we need to express
> that in the binding though so let that have VIN10 VINCOM (probably using
> a magic channel number) and VIN10 pseudo differential.
>
> Similar setup for ADCIN15 equivalent usage
>
> Code wise this probably won't be particular hard to support in the driver
> (obviously I haven't tried though :) is it worth the effort to keep
> it inline with other devices that support pseudo differential channesl.
Then this would need to be done to any fully differential ADC as support
for pseudo differential channels is present (connect a fixed non 0 voltage
to the negative input).
The AD717x family supports pseudo differential channels as well... should
this change be applied to them too? It is just the case that the documentation
does not mentions this use case.
I think that a distinction needs to be made here:
- When a device is only pseudo differential, sure, it is in a different category
- When a device is fully differential and you are using it as pseudo-differential
you are having two inputs compared to one another
I would need more clarification is why would supply-vincom be a requirement.
The voltage supplied to VINCOM will not be used in any computation within
the driver. From the perspective of getting the data it doesn't matter if
you are using the channel in a pseudo-differential, single ended or fully
differential manner.
Regarding VINX VINX+1, it is not mandatory to respect those, from AD4111 page27:
"Due to the matching resistors on the analog front end, the
differential inputs must be paired together in the following
pairs: VIN0 and VIN1, VIN2 and VIN3, VIN4 and VIN5, and
VIN6 and VIN7. If any two voltage inputs are paired in a
configuration other than what is described in this data sheet,
the accuracy of the device cannot be guaranteed."
Tried the device and it works as fully differential when pairing any
VINx with VINCOM. Still works when selecting VINCOM as the positive
input of the ADC.
I really see this as overly complicated and unnecessary. These families
of ADCs are fully differential. If you are using it to measure a single ended
(Be it compared to 0V or pseudo differential where you are comparing to Vref/2
and obtaining results [Vref/2 , -Vref/2]) the final result will not require knowing
the common voltage.
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: adc: ad7173: add support for ad411x
From: Ceclan, Dumitru @ 2024-04-09 8:10 UTC (permalink / raw)
To: Jonathan Cameron
Cc: David Lechner, dumitru.ceclan, Lars-Peter Clausen,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-iio, devicetree, linux-kernel
In-Reply-To: <20240406152637.5d53c34f@jic23-huawei>
On 06/04/2024 17:26, Jonathan Cameron wrote:
> On Thu, 4 Apr 2024 16:08:56 +0300
> "Ceclan, Dumitru" <mitrutzceclan@gmail.com> wrote:
>
>> On 03/04/2024 18:22, David Lechner wrote:
>>> On Wed, Apr 3, 2024 at 2:50 AM Ceclan, Dumitru <mitrutzceclan@gmail.com> wrote:
>>>> On 02/04/2024 00:16, David Lechner wrote:
>>>>> On Mon, Apr 1, 2024 at 2:37 PM David Lechner <dlechner@baylibre.com> wrote:
>>>>>> On Mon, Apr 1, 2024 at 10:10 AM Dumitru Ceclan via B4 Relay
>>>>>> <devnull+dumitru.ceclan.analog.com@kernel.org> wrote:
>>>>>>> From: Dumitru Ceclan <dumitru.ceclan@analog.com>
>>>>>>>
>>>> ...
>>>>
>>>>>>> properties:
>>>>>>> reg:
>>>>>>> + description:
>>>>>>> + Reg values 16-19 are only permitted for ad4111/ad4112 current channels.
>>>>>>> minimum: 0
>>>>>>> - maximum: 15
>>>>>>> + maximum: 19
>>>>>> This looks wrong. Isn't reg describing the number of logical channels
>>>>>> (# of channel config registers)?
>>>>>>
>>>>>> After reviewing the driver, I see that > 16 is used as a way of
>>>>>> flagging current inputs, but still seems like the wrong way to do it.
>>>>>> See suggestion below.
>>>>>>
>>>>>>> diff-channels:
>>>>>>> + description:
>>>>>>> + For using current channels specify only the positive channel.
>>>>>>> + (IIN2+, IIN2−) -> diff-channels = <2 0>
>>>>>> I find this a bit confusing since 2 is already VIN2 and 0 is already
>>>>>> VIN0. I think it would make more sense to assign unique channel
>>>>>> numbers individually to the negative and positive current inputs.
>>>>>> Also, I think it makes sense to use the same numbers that the
>>>>>> registers in the datasheet use (8 - 11 for negative and 12 to 15 for
>>>>>> positive).
>>>>>>
>>>>>> So: (IIN2+, IIN2−) -> diff-channels = <13 10>
>>>>> Thinking about this a bit more...
>>>>>
>>>>> Since the current inputs have dedicated pins and aren't mix-and-match
>>>>> with multiple valid wiring configurations like the voltage inputs, do
>>>>> we even need to describe them in the devicetree?
>>>>>
>>>>> In the driver, the current channels would just be hard-coded like the
>>>>> temperature channel since there isn't any application-specific
>>>>> variation.
>>>> Sure, but we still need to offer the user a way to configure which
>>>> current inputs he wants and if they should use bipolar or unipolar coding.
>>> From the datasheet, it looks like only positive current input is
>>> allowed so I'm not sure bipolar applies here. But, yes, if there is
>>> some other variation in wiring or electrical signal that needs to be
>>> describe here, then it makes sense to allow a channel configuration
>>> node for it.
>>
>> AD4111 datasheet pg.29:
>> When the ADC is configured for bipolar operation, the output
>> code is offset binary with a negative full-scale voltage resulting
>> in a code of 000 … 000, a zero differential input voltage resulting in
>> a code of 100 … 000, and a positive full-scale input voltage
>> resulting in a code of 111 … 111. The output code for any
>> analog input voltage can be represented as
>> Code = 2^(N – 1) × ((V_IN × 0.1/V REF) + 1)
>> The output code for any input current is represented as
>> Code = 2^(N − 1) × ((I_IN × 50 Ω/V REF) + 1)
>>
>> I would say bipolar applies here, not a great idea because of the limitation on
>> the negative side (Input Current Range min:−0.5 max:+24 mA) so still, the option
>> is available.
> Just to check I am correct in thinking you 'might' use bipolar if you want
> to be able to measure small negative currents, but the range is much larger
> in the positive direction?
>
> J
Yes, exactly
^ permalink raw reply
* Re: [PATCH] arm64: dts: meson: fix S4 power-controller node
From: Xianwei Zhao @ 2024-04-09 8:15 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, devicetree, linux-arm-kernel,
linux-amlogic, linux-kernel
In-Reply-To: <CAFBinCD=xWuhoX9cWcKU3bSGcsDShKbxnMVTdyfD84AFZQn8aw@mail.gmail.com>
Hi Martin,
Thanks for your review.
On 2024/4/9 01:27, Martin Blumenstingl wrote:
> [ EXTERNAL EMAIL ]
>
> On Mon, Apr 8, 2024 at 5:26 AM Xianwei Zhao via B4 Relay
> <devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
>>
>> From: Xianwei Zhao <xianwei.zhao@amlogic.com>
>>
>> The power-controller module works well by adding its parent
>> node secure-monitor.
>>
>
> Please add a Fixes tag here with the original commit where the
> incorrectly placed node was added.
Will add Fixes tag.
>> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
>> ---
>> arch/arm64/boot/dts/amlogic/meson-s4.dtsi | 11 +++++++----
>> 1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-s4.dtsi b/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
>> index ce90b35686a2..24d00dce4969 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
>> @@ -65,10 +65,13 @@ xtal: xtal-clk {
>> #clock-cells = <0>;
>> };
>>
>> - pwrc: power-controller {
>> - compatible = "amlogic,meson-s4-pwrc";
>> - #power-domain-cells = <1>;
>> - status = "okay";
>> + sm: secure-monitor {
>> + compatible = "amlogic,meson-gxbb-sm";
>> +
>> + pwrc: power-controller {
>> + compatible = "amlogic,meson-s4-pwrc";
>> + #power-domain-cells = <1>;
>> + };
> In Documentation/devicetree/bindings/firmware/amlogic,meson-gxbb-sm.yaml
> the hierarchy is:
> firmware {
> secure-monitor {
> power-controller {
> ...
> }
> }
> }
>
> Is this patch correct (and the documentation needs to be adapted) or
> is the documentation correct (and this patch has to be adapted)?
Will add firmware node to adapt documentation.
^ permalink raw reply
* [PATCH] dt-bindings: host1x: Add missing 'dma-coherent'
From: Jon Hunter @ 2024-04-09 8:23 UTC (permalink / raw)
To: Thierry Reding, Mikko Perttunen, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-tegra, devicetree, Jon Hunter
The dtbs_check reports that the 'dma-coherent' property is "unevaluated
and invalid" for the host1x@13e00000 device on Tegra194 and Tegra234
platforms. Fix this by updating the dt-binding document for host1x to
add the 'dma-coherent' property for these devices.
Fixes: 361238cdc525 ("arm64: tegra: Mark host1x as dma-coherent on Tegra194/234")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
---
.../bindings/display/tegra/nvidia,tegra20-host1x.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
index 94c5242c03b2..3563378a01af 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
@@ -177,6 +177,15 @@ allOf:
required:
- reg-names
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra194-host1x
+ then:
+ properties:
+ dma-coherent: true
- if:
properties:
compatible:
@@ -226,6 +235,8 @@ allOf:
use. Should be a mapping of IDs 0..n to IOMMU entries corresponding to
usable stream IDs.
+ dma-coherent: true
+
required:
- reg-names
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: panel-simple-dsi: add New Khadas TS050 panel bindings
From: Jacobe Zang @ 2024-04-09 8:26 UTC (permalink / raw)
To: neil.armstrong, narmstrong, airlied, daniel, maarten.lankhorst,
mripard, tzimmermann, robh, krzysztof.kozlowski+dt, conor+dt
Cc: quic_jesszhan, sam, nick, thierry.reding, dri-devel, devicetree,
linux-kernel, linux-amlogic, Jacobe Zang
This add the bindings for the New Khadas TS050 1080x1920 5" LCD DSI panel
designed to work with the Khadas VIM3 and VIM3L Single Board Computers.
Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com>
---
.../devicetree/bindings/display/panel/panel-simple-dsi.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
index f9160d7bac3ca..e194309f31b72 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
@@ -36,6 +36,8 @@ properties:
- jdi,fhd-r63452
# Khadas TS050 5" 1080x1920 LCD panel
- khadas,ts050
+ # Khadas NEW TS050 5" 1080x1920 LCD panel
+ - khadas,newts050
# Kingdisplay KD097D04 9.7" 1536x2048 TFT LCD panel
- kingdisplay,kd097d04
# LG ACX467AKM-7 4.95" 1080×1920 LCD Panel
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: power: supply: ltc3350-charger: Add bindings
From: Krzysztof Kozlowski @ 2024-04-09 8:27 UTC (permalink / raw)
To: Mike Looijmans, linux-pm
Cc: Conor Dooley, Krzysztof Kozlowski, Rob Herring, Sebastian Reichel,
devicetree, linux-kernel
In-Reply-To: <20240408064905.20298-1-mike.looijmans@topic.nl>
On 08/04/2024 08:49, 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>
> ---
>
> .../bindings/power/supply/ltc3350.yaml | 55 +++++++++++++++++++
Missing vendor prefix, use compatible as filename.
> 1 file changed, 55 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/supply/ltc3350.yaml
>
> diff --git a/Documentation/devicetree/bindings/power/supply/ltc3350.yaml b/Documentation/devicetree/bindings/power/supply/ltc3350.yaml
> new file mode 100644
> index 000000000000..607a62fd25ba
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/supply/ltc3350.yaml
> @@ -0,0 +1,55 @@
> +# 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/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
Just one space after 'a'.
> + 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
> + description: I2C address of the charger.
Drop description, it is obvious.
> +
> + 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
Looks like it is shunt-resistor-micro-ohms. Unless it is something
different?
> +
> +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";
Messed indentation. Keep it consistent.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: arm: qcom: Add msm8916 based Motorola devices
From: Krzysztof Kozlowski @ 2024-04-09 8:29 UTC (permalink / raw)
To: Nikita Travkin, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20240405-msm8916-moto-init-v1-1-502b58176d34@trvn.ru>
On 05/04/2024 16:06, Nikita Travkin wrote:
> Add compatible values for the msm8916 based Motorola smartphones.
>
> Signed-off-by: Nikita Travkin <nikita@trvn.ru>
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net-next v6 00/10] Support ICSSG-based Ethernet on AM65x SR1.0 devices
From: patchwork-bot+netdevbpf @ 2024-04-09 8:50 UTC (permalink / raw)
To: Diogo Ivo
Cc: danishanwar, rogerq, davem, edumazet, kuba, pabeni, andrew,
dan.carpenter, jacob.e.keller, robh, robh+dt,
krzysztof.kozlowski+dt, conor+dt, vigneshr, wsa+renesas,
hkallweit1, arnd, vladimir.oltean, linux-arm-kernel, netdev,
devicetree, jan.kiszka
In-Reply-To: <20240403104821.283832-1-diogo.ivo@siemens.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Wed, 3 Apr 2024 11:48:10 +0100 you wrote:
> Hello,
>
> This series extends the current ICSSG-based Ethernet driver to support
> AM65x Silicon Revision 1.0 devices.
>
> Notable differences between the Silicon Revisions are that there is
> no TX core in SR1.0 with this being handled by the firmware, requiring
> extra DMA channels to manage communication with the firmware (with the
> firmware being different as well) and in the packet classifier.
>
> [...]
Here is the summary with links:
- [net-next,v6,01/10] dt-bindings: net: Add support for AM65x SR1.0 in ICSSG
https://git.kernel.org/netdev/net-next/c/dc073430db8d
- [net-next,v6,02/10] eth: Move IPv4/IPv6 multicast address bases to their own symbols
https://git.kernel.org/netdev/net-next/c/e1900d7ba9c9
- [net-next,v6,03/10] net: ti: icssg-prueth: Move common functions into a separate file
https://git.kernel.org/netdev/net-next/c/e2dc7bfd677f
- [net-next,v6,04/10] net: ti: icssg-prueth: Add SR1.0-specific configuration bits
https://git.kernel.org/netdev/net-next/c/6d6a5751cd8e
- [net-next,v6,05/10] net: ti: icssg-prueth: Add SR1.0-specific description bits
https://git.kernel.org/netdev/net-next/c/8623dea207a7
- [net-next,v6,06/10] net: ti: icssg-prueth: Adjust IPG configuration for SR1.0
https://git.kernel.org/netdev/net-next/c/95c2e689331e
- [net-next,v6,07/10] net: ti: icssg-prueth: Adjust the number of TX channels for SR1.0
https://git.kernel.org/netdev/net-next/c/604e603d73ec
- [net-next,v6,08/10] net: ti: icssg-prueth: Add functions to configure SR1.0 packet classifier
https://git.kernel.org/netdev/net-next/c/0a74a9de79c1
- [net-next,v6,09/10] net: ti: icssg-prueth: Modify common functions for SR1.0
https://git.kernel.org/netdev/net-next/c/ce95cb4c8d26
- [net-next,v6,10/10] net: ti: icssg-prueth: Add ICSSG Ethernet driver for AM65x SR1.0 platforms
https://git.kernel.org/netdev/net-next/c/e654b85a693e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 3/9] dt-bindings: rtc: lpc32xx-rtc: move to trivial-rtc
From: Javier Carrasco @ 2024-04-09 8:52 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jiaxun Yang,
Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery, Maxime Coquelin,
Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32
In-Reply-To: <dd5e9837-0dcf-4b0e-8d11-f8bed868cdf2@linaro.org>
On 4/9/24 09:34, Krzysztof Kozlowski wrote:
> On 08/04/2024 17:53, Javier Carrasco wrote:
>> This RTC requires a compatible, a reg and a single interrupt,
>> which makes it suitable for a direct conversion into trivial-rtc.
>>
>> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
>> ---
>> Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt | 15 ---------------
>> Documentation/devicetree/bindings/rtc/trivial-rtc.yaml | 2 ++
>> 2 files changed, 2 insertions(+), 15 deletions(-)
>
> This one no... and if you tested DTS you would see errors, although you
> need to test specific lpc config, not multi_v7.
>
> It does not look like you tested the DTS against bindings. Please run
> `make dtbs_check W=1` (see
> Documentation/devicetree/bindings/writing-schema.rst or
> https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
> for instructions).
>
> Anyway, you *must* check all DTS before moving anything to trivial.
>
> Does it mean all other bindings were not checked against DTS at all?
>
> Best regards,
> Krzysztof
>
Hi,
I did check the conversion against nxp/lpc/lpc3250-phy3250.dts, which
throws a message about the 'clocks' property.
That property is not documented in the original binding, and even though
it could be missing, I could not find any function to get a clock (i.e.
any form of clk_get()) in rtc-lpc32xx.c, which is the only file where
the compatible can be found.
Is therefore the property not useless in the dts? My apologies if I am
missing something here.
Thanks and best regards,
Javier Carrasco
^ permalink raw reply
* [PATCH v1] arm64: dts: imx8mm: fix missing pgc_vpu_* power domain parent
From: Vitor Soares @ 2024-04-09 8:58 UTC (permalink / raw)
To: 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,
Lucas Stach, stable
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.
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 {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 3/6] firmware: arm_scmi: add initial support for i.MX BBM protocol
From: Sudeep Holla @ 2024-04-09 8:59 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Cristian Marussi, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Peng Fan, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <ZhQxu8LVNKf5QDLm@pluto>
On Mon, Apr 08, 2024 at 07:04:43PM +0100, Cristian Marussi wrote:
> On Fri, Apr 05, 2024 at 08:39:25PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > The i.MX BBM protocol is for managing i.MX BBM module which provides
> > RTC and BUTTON feature.
> >
>
> I appreciate that you added versioning but I think a bit of documentation
> about what the protocol and its comamnds purpose is still lacking, as asked
> by Sudeep previously
>
> https://lore.kernel.org/linux-arm-kernel/ZeGtoJ7ztSe8Kg8R@bogus/#t
>
I have decided to ignore all these vendor protocol patches until they have
some documentation to understand what these protocol are for, what are
the commands, their input/output parameter details, any conditions are the
caller and callee,..etc very similar to SCMI spec.
To start with can you please expand what is BBM or MISC protocol is ?
Don't expect me to respond if the requested details are still missing in
the future versions, I am going to ignore it silently.
I have asked for these in atleast 2 different threads may be not just NXP
patches but in one instance Qcom patches, but they apply equally here.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v3 0/2] convert imx-audio-spdif.txt to YAML
From: Shengjiu Wang @ 2024-04-09 8:50 UTC (permalink / raw)
To: lgirdwood, broonie, robh+dt, krzysztof.kozlowski+dt, conor+dt,
shengjiu.wang, linux-sound, devicetree, linux-kernel, shawnguo,
s.hauer, kernel, festevam, imx, linux-arm-kernel
convert imx-audio-spdif.txt to YAML
changes in v3:
- change file name to fsl,imx-audio-spdif.yaml
- change example name back to sound-spdif
- exchange the fallback and specific compatible string
- update anyOf content
changes in v2:
- change file name to imx-spdif.yaml
- remove |
- add anyof for spdif-in and spdif-out requirement
- change example name to sound
Shengjiu Wang (2):
ASoC: dt-bindings: imx-audio-spdif: convert to YAML
ARM: dts: imx6: exchange fallback and specific compatible string
.../bindings/sound/fsl,imx-audio-spdif.yaml | 67 +++++++++++++++++++
.../bindings/sound/imx-audio-spdif.txt | 36 ----------
.../boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi | 4 +-
arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi | 4 +-
4 files changed, 71 insertions(+), 40 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/fsl,imx-audio-spdif.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
--
2.34.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox