* Re: [PATCH v1 1/2] dt-bindings: thermal: amlogic: add support for A1 thermal sensor
From: Dmitry Rokosov @ 2024-03-28 14:29 UTC (permalink / raw)
To: neil.armstrong
Cc: jbrunet, mturquette, khilman, martin.blumenstingl, glaroque,
rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt, kernel, rockosov, linux-amlogic,
linux-pm, linux-kernel, devicetree, linux-arm-kernel
In-Reply-To: <19897482-2fa1-4688-aeec-855123558374@linaro.org>
Hello Neil,
Thank you for quick feedback.
On Thu, Mar 28, 2024 at 03:07:52PM +0100, neil.armstrong@linaro.org wrote:
> Hi,
>
> On 28/03/2024 14:37, Dmitry Rokosov wrote:
> > Provide right compatible properties for Amlogic A1 Thermal Sensor
> > controller. A1 family supports only one thermal node - CPU thermal
> > sensor.
> >
> > Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
> > ---
> > .../bindings/thermal/amlogic,thermal.yaml | 14 +++++++++-----
> > 1 file changed, 9 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
> > index 20f8f9b3b971..0e7f6568d385 100644
> > --- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
> > +++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
> > @@ -13,11 +13,15 @@ description: Binding for Amlogic Thermal
> > properties:
> > compatible:
> > - items:
> > - - enum:
> > - - amlogic,g12a-cpu-thermal
> > - - amlogic,g12a-ddr-thermal
> > - - const: amlogic,g12a-thermal
> > + oneOf:
> > + - items:
> > + - enum:
> > + - amlogic,g12a-cpu-thermal
> > + - amlogic,g12a-ddr-thermal
> > + - const: amlogic,g12a-thermal
> > + - items:
> > + - const: amlogic,a1-cpu-thermal
> > + - const: amlogic,a1-thermal
>
> In this case you can just use "amlogic,a1-cpu-thermal" or "amlogic,a1-thermal", no need for a fallback.
Okay, I will send v2 with only one compatible w/o fallback.
--
Thank you,
Dmitry
^ permalink raw reply
* Re: [PATCH net-next v6 11/17] dt-bindings: net: pse-pd: Add another way of describing several PSE PIs
From: Kory Maincent @ 2024-03-28 14:23 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Oleksij Rempel, Mark Brown,
Frank Rowand, Heiner Kallweit, Russell King, Thomas Petazzoni,
netdev, linux-kernel, linux-doc, devicetree, Dent Project
In-Reply-To: <2d325acb-fc35-4ca3-80f2-ac88359578fd@lunn.ch>
On Thu, 28 Mar 2024 13:31:06 +0100
Andrew Lunn <andrew@lunn.ch> wrote:
> > + pairsets:
> > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > + description:
> > + List of phandles, each pointing to the power supply for the
> > + corresponding pairset named in 'pairset-names'. This property
> > + aligns with IEEE 802.3-2022, Section 33.2.3 and 145.2.4.
> > + PSE Pinout Alternatives (as per IEEE 802.3-2022 Table
> > 145\u20133)
> > +
> > |-----------|---------------|---------------|---------------|---------------|
> > + | Conductor | Alternative A | Alternative A | Alternative B
> > | Alternative B |
> > + | | (MDI-X) | (MDI) | (X)
> > | (S) |
> > +
> > |-----------|---------------|---------------|---------------|---------------|
> > + | 1 | Negative VPSE | Positive VPSE | \u2014
> > | \u2014 |
> > + | 2 | Negative VPSE | Positive VPSE | \u2014
> > | \u2014 |
> > + | 3 | Positive VPSE | Negative VPSE | \u2014
> > | \u2014 |
> > + | 4 | \u2014 | \u2014 |
> > Negative VPSE | Positive VPSE |
> > + | 5 | \u2014 | \u2014 |
> > Negative VPSE | Positive VPSE |
> > + | 6 | Positive VPSE | Negative VPSE | \u2014
> > | \u2014 |
> > + | 7 | \u2014 | \u2014 |
> > Positive VPSE | Negative VPSE |
> > + | 8 | \u2014 | \u2014 |
> > Positive VPSE | Negative VPSE |
>
> Is it possible to avoid \u encoding? Ideally this documentation should
> be understandable without having to render it using a toolset. I just
> want to use less(1).
>
> Or is this a email problem? Has something converted your UTF-8 file to
> this \u notation?
It seems to come from the documentation I copied pasted from Oleksij mail.
Will fix it.
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next v6 11/17] dt-bindings: net: pse-pd: Add another way of describing several PSE PIs
From: Kory Maincent @ 2024-03-28 14:20 UTC (permalink / raw)
To: Andrew Lunn
Cc: Rob Herring, devicetree, Thomas Petazzoni, Dent Project,
Rafael J. Wysocki, Jonathan Corbet, Rob Herring, Russell King,
Conor Dooley, Jakub Kicinski, Frank Rowand, Krzysztof Kozlowski,
Heiner Kallweit, Russ Weight, David S. Miller, Greg Kroah-Hartman,
Oleksij Rempel, Paolo Abeni, Mark Brown, netdev, linux-doc,
Eric Dumazet, Luis Chamberlain, linux-kernel
In-Reply-To: <5230d786-44a8-45a0-ab0d-e1aa4ab6a836@lunn.ch>
On Thu, 28 Mar 2024 13:32:09 +0100
Andrew Lunn <andrew@lunn.ch> wrote:
> On Tue, Mar 26, 2024 at 10:39:28AM -0500, Rob Herring wrote:
> >
> > On Tue, 26 Mar 2024 15:04:48 +0100, Kory Maincent wrote:
> > > From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com>
> > >
> > > PSE PI setup may encompass multiple PSE controllers or auxiliary circuits
> > > that collectively manage power delivery to one Ethernet port.
> > > Such configurations might support a range of PoE standards and require
> > > the capability to dynamically configure power delivery based on the
> > > operational mode (e.g., PoE2 versus PoE4) or specific requirements of
> > > connected devices. In these instances, a dedicated PSE PI node becomes
> > > essential for accurately documenting the system architecture. This node
> > > would serve to detail the interactions between different PSE controllers,
> > > the support for various PoE modes, and any additional logic required to
> > > coordinate power delivery across the network infrastructure.
> > >
> > > The old usage of "#pse-cells" is unsuficient as it carries only the PSE PI
> > > index information.
> > >
> > > Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
> > > ---
> > 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:
> >
> >
> > doc reference errors (make refcheckdocs):
> > Warning: Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml
> > references a file that doesn't exist:
> > Documentation/networking/pse-pd/pse-pi.rst
> > Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml:
> > Documentation/networking/pse-pd/pse-pi.rst
>
> Is this a false positive?
I suppose so as the file is added in the patch 10.
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v5 1/1] dt-bindings: net: dwmac: Document STM32 property st,ext-phyclk
From: Marek Vasut @ 2024-03-28 14:19 UTC (permalink / raw)
To: Christophe Roullier, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Maxime Coquelin, Alexandre Torgue, Richard Cochran,
Jose Abreu, Liam Girdwood, Mark Brown
Cc: netdev, devicetree, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20240328140803.324141-2-christophe.roullier@foss.st.com>
On 3/28/24 3:08 PM, Christophe Roullier wrote:
[...]
> | RMII | - | eth-ck | eth-ck | n/a |
> | | | st,ext-phyclk | st,eth-ref-clk-sel | |
> | | | | or st,ext-phyclk | |
>
> ---------------------------------------------------------------------------
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com>
> ---
> Documentation/devicetree/bindings/net/stm32-dwmac.yaml | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
> index fc8c96b08d7dc..b35eae80ed6ac 100644
> --- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
> @@ -82,6 +82,13 @@ properties:
> Should be phandle/offset pair. The phandle to the syscon node which
> encompases the glue register, and the offset of the control register
>
> +st,ext-phyclk:
Don't you need two spaces in front of the 'st,' here ?
> + description:
> + set this property in RMII mode when you have PHY without crystal 50MHz and want to
> + select RCC clock instead of ETH_REF_CLK. OR in RGMII mode when you want to select
> + RCC clock instead of ETH_CLK125.
> + type: boolean
> +
With that fixed:
Reviewed-by: Marek Vasut <marex@denx.de>
^ permalink raw reply
* Re: [RFC PATCH 06/13] pinctrl: renesas: pinctrl-rzg2l: Make cfg to u64 in struct rzg2l_variable_pin_cfg
From: Geert Uytterhoeven @ 2024-03-28 14:13 UTC (permalink / raw)
To: Prabhakar
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, linux-renesas-soc, linux-gpio, devicetree,
linux-kernel, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20240326222844.1422948-7-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Prabhakar,
On Tue, Mar 26, 2024 at 11:30 PM Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Now that we have updated the macro PIN_CFG_MASK to allow for the maximum
> configuration bits, update the size of 'cfg' to 'u64' in the
> 'struct rzg2l_variable_pin_cfg'.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Thanks for your patch!
> --- a/drivers/pinctrl/renesas/pinctrl-rzg2l.c
> +++ b/drivers/pinctrl/renesas/pinctrl-rzg2l.c
> @@ -241,7 +241,7 @@ struct rzg2l_dedicated_configs {
> * @pin: port pin
> */
> struct rzg2l_variable_pin_cfg {
> - u32 cfg:20;
> + u64 cfg:46;
> u32 port:5;
> u32 pin:3;
Doesn't this store the 46 cfg bits in a 64-bit word, and the 8 port
and pin bits in a different 32-bit word? Worse, you'll get 4 bytes
of padding at the end of the structure.
Changing the port and pin to u64 should make sure everything is
stored together in a single 64-bit word.
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 net-next v6 10/17] net: pse-pd: Add support for PSE PIs
From: Kory Maincent @ 2024-03-28 14:12 UTC (permalink / raw)
To: Simon Horman
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring,
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: <20240328104011.GY403975@kernel.org>
On Thu, 28 Mar 2024 10:40:11 +0000
Simon Horman <horms@kernel.org> wrote:
> On Thu, Mar 28, 2024 at 10:33:22AM +0000, Simon Horman wrote:
> > On Tue, Mar 26, 2024 at 03:04:47PM +0100, Kory Maincent wrote:
> > > From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com>
>
> ...
>
> > > diff --git a/include/linux/pse-pd/pse.h b/include/linux/pse-pd/pse.h
> >
> > ...
> >
> > > @@ -73,11 +103,11 @@ struct pse_control;
> > > * @pse_control_head: head of internal list of requested PSE controls
> > > * @dev: corresponding driver model device struct
> > > * @of_pse_n_cells: number of cells in PSE line specifiers
> > > - * @of_xlate: translation function to translate from specifier as found
> > > in the
> > > - * device tree to id as given to the PSE control ops
> > > * @nr_lines: number of PSE controls in this controller device
> > > * @lock: Mutex for serialization access to the PSE controller
> > > * @types: types of the PSE controller
> > > + * @pi: table of PSE PIs described in this controller device
> > > + * @of_legacy: flag set if the pse_pis devicetree node is not used
> >
> > nit: it looks line the documentation didn't keep up with the
> > structure during development: @no_of_pse_pi should be
> > documented instead of @of_legacy.
>
> There seem to be some similar minor problems in
> [PATCH net-next v6 13/17] net: pse-pd: Use regulator framework within PSE
> framework
>
> ./scripts/kernel-doc -none is your friend here.
Oh didn't know about it, thanks!
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 1/1] arm64: dts: imx8qxp: add asrc[0,1], esai0, spdif[0,1] and sai[4,5]
From: Shawn Guo @ 2024-03-28 14:10 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
In-Reply-To: <20240226192130.259288-1-Frank.Li@nxp.com>
On Mon, Feb 26, 2024 at 02:21:29PM -0500, Frank Li wrote:
> Add asrc[0,1], esai0, spdif[0,1], sai[4,5] and related lpcg node for
> imx8 audio subsystem.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> .../boot/dts/freescale/imx8-ss-audio.dtsi | 306 ++++++++++++++++++
> 1 file changed, 306 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi b/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
> index 07afeb78ed564..6d78d6c0d9002 100644
> --- a/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
> @@ -6,6 +6,7 @@
>
> #include <dt-bindings/clock/imx8-clock.h>
> #include <dt-bindings/clock/imx8-lpcg.h>
> +#include <dt-bindings/dma/fsl-edma.h>
> #include <dt-bindings/firmware/imx/rsrc.h>
>
> audio_ipg_clk: clock-audio-ipg {
> @@ -481,4 +482,309 @@ acm: acm@59e00000 {
> "sai3_rx_bclk",
> "sai4_rx_bclk";
> };
> +
> + asrc0: asrc@59000000 {
We want to sort nodes in unit-address, right?
> + compatible = "fsl,imx8qm-asrc";
> + reg = <0x59000000 0x10000>;
> + interrupts = <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&asrc0_lpcg 0>,
> + <&asrc0_lpcg 0>,
> + <&aud_pll_div0_lpcg 0>,
> + <&aud_pll_div1_lpcg 0>,
> + <&acm IMX_ADMA_ACM_AUD_CLK0_SEL>,
> + <&acm IMX_ADMA_ACM_AUD_CLK1_SEL>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>;
> + clock-names = "ipg", "mem",
> + "asrck_0", "asrck_1", "asrck_2", "asrck_3",
> + "asrck_4", "asrck_5", "asrck_6", "asrck_7",
> + "asrck_8", "asrck_9", "asrck_a", "asrck_b",
> + "asrck_c", "asrck_d", "asrck_e", "asrck_f",
> + "spba";
> + dmas = <&edma0 0 0 0>,
> + <&edma0 1 0 0>,
> + <&edma0 2 0 0>,
> + <&edma0 3 0 FSL_EDMA_RX>,
> + <&edma0 4 0 FSL_EDMA_RX>,
> + <&edma0 5 0 FSL_EDMA_RX>;
> + /* tx* is output channel of asrc, it is rx channel for eDMA */
> + dma-names = "rxa", "rxb", "rxc", "txa", "txb", "txc";
> + fsl,asrc-rate = <8000>;
One space around =
> + fsl,asrc-width = <16>;
> + fsl,asrc-clk-map = <0>;
> + power-domains = <&pd IMX_SC_R_ASRC_0>;
> + status = "disabled";
> + };
> +
> + esai0: esai@59010000 {
> + compatible = "fsl,imx8qm-esai", "fsl,imx6ull-esai";
> + reg = <0x59010000 0x10000>;
> + interrupts = <GIC_SPI 409 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&esai0_lpcg 1>, <&esai0_lpcg 0>, <&esai0_lpcg 1>, <&clk_dummy>;
> + clock-names = "core", "extal", "fsys", "spba";
> + dmas = <&edma0 6 0 FSL_EDMA_RX>, <&edma0 7 0 0>;
> + dma-names = "rx", "tx";
> + power-domains = <&pd IMX_SC_R_ESAI_0>;
> + status = "disabled";
> + };
> +
> + spdif0: spdif@59020000 {
> + compatible = "fsl,imx8qm-spdif";
> + reg = <0x59020000 0x10000>;
> + interrupts = <GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>, /* rx */
Ditto
> + <GIC_SPI 458 IRQ_TYPE_LEVEL_HIGH>; /* tx */
> + clocks = <&spdif0_lpcg 1>, /* core */
> + <&clk_dummy>, /* rxtx0 */
> + <&spdif0_lpcg 0>, /* rxtx1 */
> + <&clk_dummy>, /* rxtx2 */
> + <&clk_dummy>, /* rxtx3 */
> + <&clk_dummy>, /* rxtx4 */
> + <&audio_ipg_clk>, /* rxtx5 */
> + <&clk_dummy>, /* rxtx6 */
> + <&clk_dummy>, /* rxtx7 */
> + <&clk_dummy>; /* spba */
> + clock-names = "core", "rxtx0", "rxtx1", "rxtx2", "rxtx3", "rxtx4",
> + "rxtx5", "rxtx6", "rxtx7", "spba";
> + dmas = <&edma0 8 0 (FSL_EDMA_MULTI_FIFO | FSL_EDMA_RX)>,
> + <&edma0 9 0 FSL_EDMA_MULTI_FIFO>;
> + dma-names = "rx", "tx";
> + power-domains = <&pd IMX_SC_R_SPDIF_0>;
> + status = "disabled";
> + };
> +
> + spdif1: spdif@59030000 {
> + compatible = "fsl,imx8qm-spdif";
> + reg = <0x59030000 0x10000>;
> + interrupts = <GIC_SPI 460 IRQ_TYPE_LEVEL_HIGH>, /* rx */
Ditto
Shawn
> + <GIC_SPI 462 IRQ_TYPE_LEVEL_HIGH>; /* tx */
> + clocks = <&spdif1_lpcg 1>, /* core */
> + <&clk_dummy>, /* rxtx0 */
> + <&spdif1_lpcg 0>, /* rxtx1 */
> + <&clk_dummy>, /* rxtx2 */
> + <&clk_dummy>, /* rxtx3 */
> + <&clk_dummy>, /* rxtx4 */
> + <&audio_ipg_clk>, /* rxtx5 */
> + <&clk_dummy>, /* rxtx6 */
> + <&clk_dummy>, /* rxtx7 */
> + <&clk_dummy>; /* spba */
> + clock-names = "core", "rxtx0", "rxtx1", "rxtx2", "rxtx3", "rxtx4",
> + "rxtx5", "rxtx6", "rxtx7", "spba";
> + dmas = <&edma0 10 0 (FSL_EDMA_MULTI_FIFO | FSL_EDMA_RX)>,
> + <&edma0 11 0 FSL_EDMA_MULTI_FIFO>;
> + dma-names = "rx", "tx";
> + power-domains = <&pd IMX_SC_R_SPDIF_1>;
> + status = "disabled";
> + };
> +
> + asrc1: asrc@59800000 {
> + compatible = "fsl,imx8qm-asrc";
> + reg = <0x59800000 0x10000>;
> + interrupts = <GIC_SPI 380 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 381 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&asrc1_lpcg 0>,
> + <&asrc1_lpcg 0>,
> + <&aud_pll_div0_lpcg 0>,
> + <&aud_pll_div1_lpcg 0>,
> + <&acm IMX_ADMA_ACM_AUD_CLK0_SEL>,
> + <&acm IMX_ADMA_ACM_AUD_CLK1_SEL>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>;
> + clock-names = "ipg", "mem",
> + "asrck_0", "asrck_1", "asrck_2", "asrck_3",
> + "asrck_4", "asrck_5", "asrck_6", "asrck_7",
> + "asrck_8", "asrck_9", "asrck_a", "asrck_b",
> + "asrck_c", "asrck_d", "asrck_e", "asrck_f",
> + "spba";
> + dmas = <&edma1 0 0 0>,
> + <&edma1 1 0 0>,
> + <&edma1 2 0 0>,
> + <&edma1 3 0 FSL_EDMA_RX>,
> + <&edma1 4 0 FSL_EDMA_RX>,
> + <&edma1 5 0 FSL_EDMA_RX>;
> + /* tx* is output channel of asrc, it is rx channel for eDMA */
> + dma-names = "txa", "txb", "txc", "rxa", "rxb", "rxc";
> + fsl,asrc-rate = <8000>;
> + fsl,asrc-width = <16>;
> + fsl,asrc-clk-map = <1>;
> + power-domains = <&pd IMX_SC_R_ASRC_1>;
> + status = "disabled";
> + };
> +
> + sai4: sai@59820000 {
> + compatible = "fsl,imx8qm-sai";
> + reg = <0x59820000 0x10000>;
> + interrupts = <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&sai4_lpcg 1>,
> + <&clk_dummy>,
> + <&sai4_lpcg 0>,
> + <&clk_dummy>,
> + <&clk_dummy>;
> + clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3";
> + dmas = <&edma1 8 0 FSL_EDMA_RX>, <&edma1 9 0 0>;
> + dma-names = "rx", "tx";
> + power-domains = <&pd IMX_SC_R_SAI_4>;
> + status = "disabled";
> + };
> +
> + sai5: sai@59830000 {
> + compatible = "fsl,imx8qm-sai";
> + reg = <0x59830000 0x10000>;
> + interrupts = <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&sai5_lpcg 1>,
> + <&clk_dummy>,
> + <&sai5_lpcg 0>,
> + <&clk_dummy>,
> + <&clk_dummy>;
> + clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3";
> + dmas = <&edma1 10 0 0>;
> + dma-names = "tx";
> + power-domains = <&pd IMX_SC_R_SAI_5>;
> + status = "disabled";
> + };
> +
> + amix: amix@59840000 {
> + compatible = "fsl,imx8qm-audmix";
> + reg = <0x59840000 0x10000>;
> + clocks = <&amix_lpcg 0>;
> + clock-names = "ipg";
> + power-domains = <&pd IMX_SC_R_AMIX>;
> + dais = <&sai4>, <&sai5>;
> + status = "disabled";
> + };
> +
> + mqs: mqs@59850000 {
> + compatible = "fsl,imx8qm-mqs";
> + reg = <0x59850000 0x10000>;
> + clocks = <&mqs0_lpcg 1>,
> + <&mqs0_lpcg 0>;
> + clock-names = "core", "mclk";
> + power-domains = <&pd IMX_SC_R_MQS_0>;
> + status = "disabled";
> + };
> +
> + asrc0_lpcg: clock-controller@59400000 {
> + compatible = "fsl,imx8qxp-lpcg";
> + reg = <0x59400000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&audio_ipg_clk>;
> + clock-indices = <IMX_LPCG_CLK_4>;
> + clock-output-names = "asrc0_lpcg_ipg_clk";
> + power-domains = <&pd IMX_SC_R_ASRC_0>;
> + };
> +
> + esai0_lpcg: clock-controller@59410000 {
> + compatible = "fsl,imx8qxp-lpcg";
> + reg = <0x59410000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&acm IMX_ADMA_ACM_ESAI0_MCLK_SEL>,
> + <&audio_ipg_clk>;
> + clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
> + clock-output-names = "esai0_lpcg_extal_clk",
> + "esai0_lpcg_ipg_clk";
> + power-domains = <&pd IMX_SC_R_ESAI_0>;
> + };
> +
> + spdif0_lpcg: clock-controller@59420000 {
> + compatible = "fsl,imx8qxp-lpcg";
> + reg = <0x59420000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&acm IMX_ADMA_ACM_SPDIF0_TX_CLK_SEL>,
> + <&audio_ipg_clk>;
> + clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
> + clock-output-names = "spdif0_lpcg_tx_clk",
> + "spdif0_lpcg_gclkw";
> + power-domains = <&pd IMX_SC_R_SPDIF_0>;
> + };
> +
> + spdif1_lpcg: clock-controller@59430000 {
> + compatible = "fsl,imx8qxp-lpcg";
> + reg = <0x59430000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&acm IMX_ADMA_ACM_SPDIF1_TX_CLK_SEL>,
> + <&audio_ipg_clk>;
> + clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
> + clock-output-names = "spdif1_lpcg_tx_clk",
> + "spdif1_lpcg_gclkw";
> + power-domains = <&pd IMX_SC_R_SPDIF_1>;
> + status = "disabled";
> + };
> +
> + asrc1_lpcg: clock-controller@59c00000 {
> + compatible = "fsl,imx8qxp-lpcg";
> + reg = <0x59c00000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&audio_ipg_clk>;
> + clock-indices = <IMX_LPCG_CLK_4>;
> + clock-output-names = "asrc1_lpcg_ipg_clk";
> + power-domains = <&pd IMX_SC_R_ASRC_1>;
> + };
> +
> + sai4_lpcg: clock-controller@59c20000 {
> + compatible = "fsl,imx8qxp-lpcg";
> + reg = <0x59c20000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&acm IMX_ADMA_ACM_SAI4_MCLK_SEL>,
> + <&audio_ipg_clk>;
> + clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
> + clock-output-names = "sai4_lpcg_mclk",
> + "sai4_lpcg_ipg_clk";
> + power-domains = <&pd IMX_SC_R_SAI_4>;
> + };
> +
> + sai5_lpcg: clock-controller@59c30000 {
> + compatible = "fsl,imx8qxp-lpcg";
> + reg = <0x59c30000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&acm IMX_ADMA_ACM_SAI5_MCLK_SEL>,
> + <&audio_ipg_clk>;
> + clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
> + clock-output-names = "sai5_lpcg_mclk",
> + "sai5_lpcg_ipg_clk";
> + power-domains = <&pd IMX_SC_R_SAI_5>;
> + };
> +
> + amix_lpcg: clock-controller@59c40000 {
> + compatible = "fsl,imx8qxp-lpcg";
> + reg = <0x59c40000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&audio_ipg_clk>;
> + clock-indices = <IMX_LPCG_CLK_0>;
> + clock-output-names = "amix_lpcg_ipg_clk";
> + power-domains = <&pd IMX_SC_R_AMIX>;
> + };
> +
> + mqs0_lpcg: clock-controller@59c50000 {
> + compatible = "fsl,imx8qxp-lpcg";
> + reg = <0x59c50000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&acm IMX_ADMA_ACM_MQS_TX_CLK_SEL>,
> + <&audio_ipg_clk>;
> + clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
> + clock-output-names = "mqs0_lpcg_mclk",
> + "mqs0_lpcg_ipg_clk";
> + power-domains = <&pd IMX_SC_R_MQS_0>;
> + };
> };
> --
> 2.34.1
>
^ permalink raw reply
* [PATCH v5 0/1] Add property in dwmac-stm32 documentation
From: Christophe Roullier @ 2024-03-28 14:08 UTC (permalink / raw)
To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue, Richard Cochran, Jose Abreu, Liam Girdwood,
Mark Brown, Christophe Roullier, Marek Vasut
Cc: netdev, devicetree, linux-stm32, linux-arm-kernel, linux-kernel
Introduce property in dwmac-stm32 documentation
- st,ext-phyclk: is present since 2020 in driver so need to explain
it and avoid dtbs check issue : views/kernel/upstream/net-next/arch/arm/boot/dts/st/stm32mp157c-dk2.dtb:
ethernet@5800a000: Unevaluated properties are not allowed
('st,ext-phyclk' was unexpected)
Furthermore this property will be use in upstream of MP13 dwmac glue. (next step)
V2: - Drop deprecated: property for st,eth-clk-sel and st,eth-ref-clk-sel
V3: - Rework commit message
V4: - Fix syntax issue in commit message
V5: - Remark from Andrew Lunn (remove documentation of PHY regulator, it will come in next step (with
implementation))
Christophe Roullier (1):
dt-bindings: net: dwmac: Document STM32 property st,ext-phyclk
Documentation/devicetree/bindings/net/stm32-dwmac.yaml | 7 +++++++
1 file changed, 7 insertions(+)
--
2.25.1
^ permalink raw reply
* [PATCH v5 1/1] dt-bindings: net: dwmac: Document STM32 property st,ext-phyclk
From: Christophe Roullier @ 2024-03-28 14:08 UTC (permalink / raw)
To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue, Richard Cochran, Jose Abreu, Liam Girdwood,
Mark Brown, Christophe Roullier, Marek Vasut
Cc: netdev, devicetree, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20240328140803.324141-1-christophe.roullier@foss.st.com>
The Linux kernel dwmac-stm32 driver currently supports three DT
properties used to configure whether PHY clock are generated by
the MAC or supplied to the MAC from the PHY.
Originally there were two properties, st,eth-clk-sel and
st,eth-ref-clk-sel, each used to configure MAC clocking in
different bus mode and for different MAC clock frequency.
Since it is possible to determine the MAC 'eth-ck' clock
frequency from the clock subsystem and PHY bus mode from
the 'phy-mode' property, two disparate DT properties are
no longer required to configure MAC clocking.
Linux kernel commit 1bb694e20839 ("net: ethernet: stmmac: simplify phy modes management for stm32")
introduced a third, unified, property st,ext-phyclk. This property
covers both use cases of st,eth-clk-sel and st,eth-ref-clk-sel DT
properties, as well as a new use case for 25 MHz clock generated
by the MAC.
The third property st,ext-phyclk is so far undocumented,
document it.
Below table summarizes the clock requirement and clock sources for
supported PHY interface modes.
__________________________________________________________________________
|PHY_MODE | Normal | PHY wo crystal| PHY wo crystal |No 125Mhz from PHY|
| | | 25MHz | 50MHz | |
---------------------------------------------------------------------------
| MII | - | eth-ck | n/a | n/a |
| | | st,ext-phyclk | | |
---------------------------------------------------------------------------
| GMII | - | eth-ck | n/a | n/a |
| | | st,ext-phyclk | | |
---------------------------------------------------------------------------
| RGMII | - | eth-ck | n/a | eth-ck |
| | | st,ext-phyclk | | st,eth-clk-sel or|
| | | | | st,ext-phyclk |
---------------------------------------------------------------------------
| RMII | - | eth-ck | eth-ck | n/a |
| | | st,ext-phyclk | st,eth-ref-clk-sel | |
| | | | or st,ext-phyclk | |
---------------------------------------------------------------------------
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com>
---
Documentation/devicetree/bindings/net/stm32-dwmac.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
index fc8c96b08d7dc..b35eae80ed6ac 100644
--- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
@@ -82,6 +82,13 @@ properties:
Should be phandle/offset pair. The phandle to the syscon node which
encompases the glue register, and the offset of the control register
+st,ext-phyclk:
+ description:
+ set this property in RMII mode when you have PHY without crystal 50MHz and want to
+ select RCC clock instead of ETH_REF_CLK. OR in RGMII mode when you want to select
+ RCC clock instead of ETH_CLK125.
+ type: boolean
+
st,eth-clk-sel:
description:
set this property in RGMII PHY when you want to select RCC clock instead of ETH_CLK125.
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v1 1/3] arm64: dts: amlogic: a1: add cooling-cells for DVFS feature
From: neil.armstrong @ 2024-03-28 14:08 UTC (permalink / raw)
To: Dmitry Rokosov, jbrunet, mturquette, khilman, martin.blumenstingl,
glaroque, rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: kernel, rockosov, linux-amlogic, linux-pm, linux-kernel,
devicetree, linux-arm-kernel
In-Reply-To: <20240328134459.18446-2-ddrokosov@salutedevices.com>
On 28/03/2024 14:44, Dmitry Rokosov wrote:
> It's used for CPU with DVFS feature to specify minimum and maximum
> cooling state used in the reference.
> Without these values DVFS will not work and dtbs_check will raise the
> error.
>
> Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
> index fbee986421f1..f65d4a77ee52 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
> @@ -32,6 +32,7 @@ cpu0: cpu@0 {
> reg = <0x0 0x0>;
> enable-method = "psci";
> next-level-cache = <&l2>;
> + #cooling-cells = <2>;
> };
>
> cpu1: cpu@1 {
> @@ -40,6 +41,7 @@ cpu1: cpu@1 {
> reg = <0x0 0x1>;
> enable-method = "psci";
> next-level-cache = <&l2>;
> + #cooling-cells = <2>;
> };
>
> l2: l2-cache0 {
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
^ permalink raw reply
* Re: [PATCH v1 2/2] thermal: amlogic: support A1 SoC family Thermal Sensor controller
From: neil.armstrong @ 2024-03-28 14:08 UTC (permalink / raw)
To: Dmitry Rokosov, jbrunet, mturquette, khilman, martin.blumenstingl,
glaroque, rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: kernel, rockosov, linux-amlogic, linux-pm, linux-kernel,
devicetree, linux-arm-kernel
In-Reply-To: <20240328133802.15651-3-ddrokosov@salutedevices.com>
On 28/03/2024 14:37, Dmitry Rokosov wrote:
> In comparison to other Amlogic chips, there is one key difference.
> The offset for the sec_ao base, also known as u_efuse_off, is special,
> while other aspects remain the same.
>
> Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
> ---
> drivers/thermal/amlogic_thermal.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/thermal/amlogic_thermal.c b/drivers/thermal/amlogic_thermal.c
> index 5877cde25b79..1d23afd32013 100644
> --- a/drivers/thermal/amlogic_thermal.c
> +++ b/drivers/thermal/amlogic_thermal.c
> @@ -222,6 +222,12 @@ static const struct amlogic_thermal_data amlogic_thermal_g12a_ddr_param = {
> .regmap_config = &amlogic_thermal_regmap_config_g12a,
> };
>
> +static const struct amlogic_thermal_data amlogic_thermal_a1_cpu_param = {
> + .u_efuse_off = 0x114,
> + .calibration_parameters = &amlogic_thermal_g12a,
> + .regmap_config = &amlogic_thermal_regmap_config_g12a,
> +};
> +
> static const struct of_device_id of_amlogic_thermal_match[] = {
> {
> .compatible = "amlogic,g12a-ddr-thermal",
> @@ -231,6 +237,10 @@ static const struct of_device_id of_amlogic_thermal_match[] = {
> .compatible = "amlogic,g12a-cpu-thermal",
> .data = &amlogic_thermal_g12a_cpu_param,
> },
> + {
> + .compatible = "amlogic,a1-cpu-thermal",
> + .data = &amlogic_thermal_a1_cpu_param,
> + },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, of_amlogic_thermal_match);
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Keep it even it you change the compatible,
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: thermal: amlogic: add support for A1 thermal sensor
From: neil.armstrong @ 2024-03-28 14:07 UTC (permalink / raw)
To: Dmitry Rokosov, jbrunet, mturquette, khilman, martin.blumenstingl,
glaroque, rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: kernel, rockosov, linux-amlogic, linux-pm, linux-kernel,
devicetree, linux-arm-kernel
In-Reply-To: <20240328133802.15651-2-ddrokosov@salutedevices.com>
Hi,
On 28/03/2024 14:37, Dmitry Rokosov wrote:
> Provide right compatible properties for Amlogic A1 Thermal Sensor
> controller. A1 family supports only one thermal node - CPU thermal
> sensor.
>
> Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
> ---
> .../bindings/thermal/amlogic,thermal.yaml | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
> index 20f8f9b3b971..0e7f6568d385 100644
> --- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
> +++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
> @@ -13,11 +13,15 @@ description: Binding for Amlogic Thermal
>
> properties:
> compatible:
> - items:
> - - enum:
> - - amlogic,g12a-cpu-thermal
> - - amlogic,g12a-ddr-thermal
> - - const: amlogic,g12a-thermal
> + oneOf:
> + - items:
> + - enum:
> + - amlogic,g12a-cpu-thermal
> + - amlogic,g12a-ddr-thermal
> + - const: amlogic,g12a-thermal
> + - items:
> + - const: amlogic,a1-cpu-thermal
> + - const: amlogic,a1-thermal
In this case you can just use "amlogic,a1-cpu-thermal" or "amlogic,a1-thermal", no need for a fallback.
Thanks,
Neil
>
> reg:
> maxItems: 1
^ permalink raw reply
* Re: [PATCH v5 6/6] ARM: dts: imx: Add UNI-T UTi260B thermal camera board
From: Shawn Guo @ 2024-03-28 13:54 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Shawn Guo, Sascha Hauer, Fabio Estevam, imx, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Pengutronix Kernel Team,
Dong Aisheng, Linus Walleij, Dmitry Torokhov, linux-arm-kernel,
devicetree, linux-kernel, Stefan Wahren
In-Reply-To: <20240226212740.2019837-7-sre@kernel.org>
On Mon, Feb 26, 2024 at 10:26:28PM +0100, Sebastian Reichel wrote:
> Add DT for the UNI-T UTi260B handheld thermal camera.
>
> Reviewed-by: Stefan Wahren <wahrenst@gmx.net>
> Signed-off-by: Sebastian Reichel <sre@kernel.org>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 7/7] regulator: mcp16502: Update the names from buck regulators
From: Mark Brown @ 2024-03-28 13:45 UTC (permalink / raw)
To: Conor Dooley
Cc: Mihai Sain, robh, krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
alexandre.belloni, claudiu.beznea, lgirdwood, andrei.simion,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20240327-agreed-routine-0cc60186876b@spud>
[-- Attachment #1: Type: text/plain, Size: 911 bytes --]
On Wed, Mar 27, 2024 at 04:28:49PM +0000, Conor Dooley wrote:
> On Wed, Mar 27, 2024 at 12:17:24PM +0200, Mihai Sain wrote:
> > Use generic names for buck regulators to avoid any confusion.
> > Update the names from buck regulators in order to match
> > the datasheet block diagram for the buck regulators.
> I know the regulator core will create dummy regulators when they are not
> provided in the devicetree, so I am not 100% on how backwards
> compatibility works here.
> You'll end up with a bunch of dummies and therefore the regulator-names
> and constraints on the regulator will be lost, no?
> Can you explain how is this backwards compatible with the old
> devicetrees?
It quite simply isn't backwards compatible. The original driver looks
to be pretty broken but this breaks compatibility, we'd need a
transition plan of some kind which probably needs some core work to cope
with fallback names.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v1 1/3] arm64: dts: amlogic: a1: add cooling-cells for DVFS feature
From: Dmitry Rokosov @ 2024-03-28 13:44 UTC (permalink / raw)
To: neil.armstrong, jbrunet, mturquette, khilman, martin.blumenstingl,
glaroque, rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: kernel, rockosov, linux-amlogic, linux-pm, linux-kernel,
devicetree, linux-arm-kernel, Dmitry Rokosov
In-Reply-To: <20240328134459.18446-1-ddrokosov@salutedevices.com>
It's used for CPU with DVFS feature to specify minimum and maximum
cooling state used in the reference.
Without these values DVFS will not work and dtbs_check will raise the
error.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
---
arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
index fbee986421f1..f65d4a77ee52 100644
--- a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
@@ -32,6 +32,7 @@ cpu0: cpu@0 {
reg = <0x0 0x0>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
cpu1: cpu@1 {
@@ -40,6 +41,7 @@ cpu1: cpu@1 {
reg = <0x0 0x1>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
l2: l2-cache0 {
--
2.43.0
^ permalink raw reply related
* [PATCH v1 3/3] arm64: dts: amlogic: ad402: setup thermal-zones
From: Dmitry Rokosov @ 2024-03-28 13:44 UTC (permalink / raw)
To: neil.armstrong, jbrunet, mturquette, khilman, martin.blumenstingl,
glaroque, rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: kernel, rockosov, linux-amlogic, linux-pm, linux-kernel,
devicetree, linux-arm-kernel, Dmitry Rokosov
In-Reply-To: <20240328134459.18446-1-ddrokosov@salutedevices.com>
There is one thermal zone with 3 trip points: soc_passive, soc_hot, and
soc_critical, as well as two cooling maps.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
---
.../arm64/boot/dts/amlogic/meson-a1-ad402.dts | 45 +++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-a1-ad402.dts b/arch/arm64/boot/dts/amlogic/meson-a1-ad402.dts
index 6c02301840ff..2d22e8b45c6d 100644
--- a/arch/arm64/boot/dts/amlogic/meson-a1-ad402.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-a1-ad402.dts
@@ -7,6 +7,7 @@
/dts-v1/;
#include "meson-a1.dtsi"
+#include <dt-bindings/thermal/thermal.h>
#include <dt-bindings/gpio/gpio.h>
@@ -177,6 +178,50 @@ codec {
};
};
};
+
+ thermal-zones {
+ soc_thermal: soc_thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ sustainable-power = <130>;
+
+ thermal-sensors = <&cpu_temp>;
+
+ trips {
+ soc_passive: soc-passive {
+ temperature = <70000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ soc_hot: soc-hot {
+ temperature = <85000>;
+ hysteresis = <5000>;
+ type = "hot";
+ };
+
+ soc_critical: soc-critical {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+
+ soc_cooling_maps: cooling-maps {
+ map0 {
+ trip = <&soc_passive>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+
+ map1 {
+ trip = <&soc_hot>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+ };
};
/* Bluetooth HCI H4 */
--
2.43.0
^ permalink raw reply related
* [PATCH v1 2/3] arm64: dts: amlogic: a1: introduce cpu temperature sensor
From: Dmitry Rokosov @ 2024-03-28 13:44 UTC (permalink / raw)
To: neil.armstrong, jbrunet, mturquette, khilman, martin.blumenstingl,
glaroque, rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: kernel, rockosov, linux-amlogic, linux-pm, linux-kernel,
devicetree, linux-arm-kernel, Dmitry Rokosov
In-Reply-To: <20240328134459.18446-1-ddrokosov@salutedevices.com>
The A1 SoC family has only one thermal sensor for CPU temperature
measurement. It is required to set the TS clock rate to 500kHz to make
it workable.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
---
arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
index f65d4a77ee52..6f0d0e07e037 100644
--- a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
@@ -854,6 +854,18 @@ usb2_phy1: phy@4000 {
power-domains = <&pwrc PWRC_USB_ID>;
};
+ cpu_temp: temperature-sensor@4c00 {
+ compatible = "amlogic,a1-cpu-thermal",
+ "amlogic,a1-thermal";
+ reg = <0x0 0x4c00 0x0 0x50>;
+ interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ assigned-clocks = <&clkc_periphs CLKID_TS>;
+ assigned-clock-rates = <500000>;
+ #thermal-sensor-cells = <0>;
+ amlogic,ao-secure = <&sec_AO>;
+ };
+
hwrng: rng@5118 {
compatible = "amlogic,meson-rng";
reg = <0x0 0x5118 0x0 0x4>;
--
2.43.0
^ permalink raw reply related
* [PATCH v1 0/3] arm64: dts: amlogic: a1: introduce thermal setup
From: Dmitry Rokosov @ 2024-03-28 13:44 UTC (permalink / raw)
To: neil.armstrong, jbrunet, mturquette, khilman, martin.blumenstingl,
glaroque, rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: kernel, rockosov, linux-amlogic, linux-pm, linux-kernel,
devicetree, linux-arm-kernel, Dmitry Rokosov
This patch series introduces thermal sensor declaration to the Meson A1
common dtsi file. It also sets up thermal zones for the AD402 reference
board. It depends on the series with A1 thermal support at [1].
Links:
[1] - https://lore.kernel.org/all/20240328133802.15651-1-ddrokosov@salutedevices.com/
Dmitry Rokosov (3):
arm64: dts: amlogic: a1: add cooling-cells for DVFS feature
arm64: dts: amlogic: a1: introduce cpu temperature sensor
arm64: dts: amlogic: ad402: setup thermal-zones
.../arm64/boot/dts/amlogic/meson-a1-ad402.dts | 45 +++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 14 ++++++
2 files changed, 59 insertions(+)
--
2.43.0
^ permalink raw reply
* Re: [PATCH net-next v6 10/17] net: pse-pd: Add support for PSE PIs
From: Kory Maincent @ 2024-03-28 13:43 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Oleksij Rempel, Mark Brown,
Frank Rowand, Heiner Kallweit, Russell King, Thomas Petazzoni,
netdev, linux-kernel, linux-doc, devicetree, Dent Project
In-Reply-To: <f3bafb50-406b-444a-8411-5ddae8d84c31@lunn.ch>
On Thu, 28 Mar 2024 13:24:00 +0100
Andrew Lunn <andrew@lunn.ch> wrote:
> > +.. code-block::
> > +
> > + +-------------+
> > + | PSE PI |
> > + 8 -----+ +-------------+
> > + 7 -----+ Rail 1 |
> > + 6 -----+------+----------------------+
> > + 5 -----+ | |
> > + 4 -----+ / Rail 2 | PSE 1
> > + 3 -----+----? +-------------+
> > + 2 -----+----+---------? |
> > + 1 -----+---? +-------------+
> > + |
> > + +-------------+
>
> Is ? a standard markup character? I don't remember seeing it used like
> this before.
It seems the Documentation copy-pasted from Oleksij mail bring me few weird
characters.
I will fix it.
> > +static int of_load_single_pse_pi_pairset(struct device_node *node,
> > + struct pse_pi *pi,
> > + int pairset_num)
> > +{
> > + struct device_node *pairset_np;
> > + const char *name;
> > + int ret;
> > +
> > + ret = of_property_read_string_index(node, "pairset-names",
> > + pairset_num, &name);
> > + if (ret)
> > + return ret;
> > +
> > + if (!strcmp(name, "alternative-a")) {
> > + pi->pairset[pairset_num].pinout = ALTERNATIVE_A;
> > + } else if (!strcmp(name, "alternative-b")) {
> > + pi->pairset[pairset_num].pinout = ALTERNATIVE_B;
> > + } else {
> > + pr_err("pse: wrong pairset-names value %s\n", name);
> > + return -EINVAL;
>
> Maybe include the node path in the error message? For a 24 port
> switch, it will help find a typo in one of the ports. I would do this
> for all error messages in this code.
Ok, I will.
Thanks for your review!
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v5 7/7] iio: accel: adxl345: Add spi-3wire option
From: Jonathan Cameron @ 2024-03-28 13:39 UTC (permalink / raw)
To: Lothar Rubusch
Cc: lars, Michael.Hennerich, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-iio, devicetree, linux-kernel, eraretuya
In-Reply-To: <20240327220320.15509-8-l.rubusch@gmail.com>
On Wed, 27 Mar 2024 22:03:20 +0000
Lothar Rubusch <l.rubusch@gmail.com> wrote:
> Add a setup function implementation to the spi module to enable spi-3wire
> as option when specified in the device-tree.
>
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
> drivers/iio/accel/adxl345.h | 2 ++
> drivers/iio/accel/adxl345_spi.c | 12 +++++++++++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/accel/adxl345.h b/drivers/iio/accel/adxl345.h
> index 4ea9341d4..e6bc3591c 100644
> --- a/drivers/iio/accel/adxl345.h
> +++ b/drivers/iio/accel/adxl345.h
> @@ -30,6 +30,8 @@
> #define ADXL345_POWER_CTL_MEASURE BIT(3)
> #define ADXL345_POWER_CTL_STANDBY 0x00
>
> +#define ADXL345_DATA_FORMAT_SPI_3WIRE BIT(6) /* 3-wire SPI mode */
> +
> #define ADXL345_DATA_FORMAT_RANGE GENMASK(1, 0) /* Set the g range */
> #define ADXL345_DATA_FORMAT_JUSTIFY BIT(2) /* Left-justified (MSB) mode */
> #define ADXL345_DATA_FORMAT_FULL_RES BIT(3) /* Up to 13-bits resolution */
> diff --git a/drivers/iio/accel/adxl345_spi.c b/drivers/iio/accel/adxl345_spi.c
> index 1c0513bd3..f145d5c1d 100644
> --- a/drivers/iio/accel/adxl345_spi.c
> +++ b/drivers/iio/accel/adxl345_spi.c
> @@ -20,6 +20,16 @@ static const struct regmap_config adxl345_spi_regmap_config = {
> .read_flag_mask = BIT(7) | BIT(6),
> };
>
> +static int adxl345_spi_setup(struct device *dev, struct regmap *regmap)
> +{
> + struct spi_device *spi = container_of(dev, struct spi_device, dev);
> +
> + if (spi->mode & SPI_3WIRE)
> + return regmap_write(regmap, ADXL345_REG_DATA_FORMAT,
> + ADXL345_DATA_FORMAT_SPI_3WIRE);
Your earlier patch carefully (I think) left one or two fields alone, then
this write just comes in and changes them. In particular INT_INVERT.
If it doesn't makes sense to write it there, either write that bit
every time here, or leave it alone every time. Not decide on whether
to write the bit based on SPI_3WIRE or not. As far as I know they
are unconnected features.
> + return 0;
> +}
> +
> static int adxl345_spi_probe(struct spi_device *spi)
> {
> struct regmap *regmap;
> @@ -33,7 +43,7 @@ static int adxl345_spi_probe(struct spi_device *spi)
> if (IS_ERR(regmap))
> return dev_err_probe(&spi->dev, PTR_ERR(regmap), "Error initializing regmap\n");
>
> - return adxl345_core_probe(&spi->dev, regmap, NULL);
> + return adxl345_core_probe(&spi->dev, regmap, adxl345_spi_setup);
> }
>
> static const struct adxl345_chip_info adxl345_spi_info = {
^ permalink raw reply
* [PATCH v1 2/2] thermal: amlogic: support A1 SoC family Thermal Sensor controller
From: Dmitry Rokosov @ 2024-03-28 13:37 UTC (permalink / raw)
To: neil.armstrong, jbrunet, mturquette, khilman, martin.blumenstingl,
glaroque, rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: kernel, rockosov, linux-amlogic, linux-pm, linux-kernel,
devicetree, linux-arm-kernel, Dmitry Rokosov
In-Reply-To: <20240328133802.15651-1-ddrokosov@salutedevices.com>
In comparison to other Amlogic chips, there is one key difference.
The offset for the sec_ao base, also known as u_efuse_off, is special,
while other aspects remain the same.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
---
drivers/thermal/amlogic_thermal.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/thermal/amlogic_thermal.c b/drivers/thermal/amlogic_thermal.c
index 5877cde25b79..1d23afd32013 100644
--- a/drivers/thermal/amlogic_thermal.c
+++ b/drivers/thermal/amlogic_thermal.c
@@ -222,6 +222,12 @@ static const struct amlogic_thermal_data amlogic_thermal_g12a_ddr_param = {
.regmap_config = &amlogic_thermal_regmap_config_g12a,
};
+static const struct amlogic_thermal_data amlogic_thermal_a1_cpu_param = {
+ .u_efuse_off = 0x114,
+ .calibration_parameters = &amlogic_thermal_g12a,
+ .regmap_config = &amlogic_thermal_regmap_config_g12a,
+};
+
static const struct of_device_id of_amlogic_thermal_match[] = {
{
.compatible = "amlogic,g12a-ddr-thermal",
@@ -231,6 +237,10 @@ static const struct of_device_id of_amlogic_thermal_match[] = {
.compatible = "amlogic,g12a-cpu-thermal",
.data = &amlogic_thermal_g12a_cpu_param,
},
+ {
+ .compatible = "amlogic,a1-cpu-thermal",
+ .data = &amlogic_thermal_a1_cpu_param,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, of_amlogic_thermal_match);
--
2.43.0
^ permalink raw reply related
* [PATCH v1 1/2] dt-bindings: thermal: amlogic: add support for A1 thermal sensor
From: Dmitry Rokosov @ 2024-03-28 13:37 UTC (permalink / raw)
To: neil.armstrong, jbrunet, mturquette, khilman, martin.blumenstingl,
glaroque, rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: kernel, rockosov, linux-amlogic, linux-pm, linux-kernel,
devicetree, linux-arm-kernel, Dmitry Rokosov
In-Reply-To: <20240328133802.15651-1-ddrokosov@salutedevices.com>
Provide right compatible properties for Amlogic A1 Thermal Sensor
controller. A1 family supports only one thermal node - CPU thermal
sensor.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
---
.../bindings/thermal/amlogic,thermal.yaml | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
index 20f8f9b3b971..0e7f6568d385 100644
--- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
@@ -13,11 +13,15 @@ description: Binding for Amlogic Thermal
properties:
compatible:
- items:
- - enum:
- - amlogic,g12a-cpu-thermal
- - amlogic,g12a-ddr-thermal
- - const: amlogic,g12a-thermal
+ oneOf:
+ - items:
+ - enum:
+ - amlogic,g12a-cpu-thermal
+ - amlogic,g12a-ddr-thermal
+ - const: amlogic,g12a-thermal
+ - items:
+ - const: amlogic,a1-cpu-thermal
+ - const: amlogic,a1-thermal
reg:
maxItems: 1
--
2.43.0
^ permalink raw reply related
* [PATCH v1 0/2] thermal: amlogic: introduce A1 SoC family Thermal Sensor controller
From: Dmitry Rokosov @ 2024-03-28 13:37 UTC (permalink / raw)
To: neil.armstrong, jbrunet, mturquette, khilman, martin.blumenstingl,
glaroque, rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: kernel, rockosov, linux-amlogic, linux-pm, linux-kernel,
devicetree, linux-arm-kernel, Dmitry Rokosov
It is primarily based on the G12A thermal controller, with only a slight
variation in the offset value of the efuse parameters. Therefore, this
patch series provides appropriate platform data and dt-bindings to
ensure proper support.
Dmitry Rokosov (2):
dt-bindings: thermal: amlogic: add support for A1 thermal sensor
thermal: amlogic: support A1 SoC family Thermal Sensor controller
.../bindings/thermal/amlogic,thermal.yaml | 14 +++++++++-----
drivers/thermal/amlogic_thermal.c | 10 ++++++++++
2 files changed, 19 insertions(+), 5 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v5 1/7] iio: accel: adxl345: Make data_range obsolete
From: Jonathan Cameron @ 2024-03-28 13:37 UTC (permalink / raw)
To: Lothar Rubusch
Cc: lars, Michael.Hennerich, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-iio, devicetree, linux-kernel, eraretuya
In-Reply-To: <20240327220320.15509-2-l.rubusch@gmail.com>
On Wed, 27 Mar 2024 22:03:14 +0000
Lothar Rubusch <l.rubusch@gmail.com> wrote:
> Replace write() data_format by regmap_update_bits(), because bus specific
> pre-configuration may have happened before on the same register. For
> further updates to the data_format register then bus pre-configuration
> needs to be masked out.
>
> Remove the data_range field from the struct adxl345_data, because it is
> not used anymore.
>
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
> drivers/iio/accel/adxl345_core.c | 18 ++++++++++++------
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iio/accel/adxl345_core.c b/drivers/iio/accel/adxl345_core.c
> index 8bd30a23e..35df5e372 100644
> --- a/drivers/iio/accel/adxl345_core.c
> +++ b/drivers/iio/accel/adxl345_core.c
> @@ -37,7 +37,15 @@
> #define ADXL345_POWER_CTL_MEASURE BIT(3)
> #define ADXL345_POWER_CTL_STANDBY 0x00
>
> +#define ADXL345_DATA_FORMAT_RANGE GENMASK(1, 0) /* Set the g range */
> +#define ADXL345_DATA_FORMAT_JUSTIFY BIT(2) /* Left-justified (MSB) mode */
> #define ADXL345_DATA_FORMAT_FULL_RES BIT(3) /* Up to 13-bits resolution */
> +#define ADXL345_DATA_FORMAT_SELF_TEST BIT(7) /* Enable a self test */
> +#define ADXL345_DATA_FORMAT_MSK (ADXL345_DATA_FORMAT_RANGE | \
> + ADXL345_DATA_FORMAT_JUSTIFY | \
> + ADXL345_DATA_FORMAT_FULL_RES | \
> + ADXL345_DATA_FORMAT_SELF_TEST)
This needs renaming. It's not a mask of everything in the register, or
even just of everything related to format.
Actually I'd just not have this definition. Use the build up value
from all the submasks at the call site. Then we are just making it clear
only a subset of fields are being cleared.
Jonathan
> +
> #define ADXL345_DATA_FORMAT_2G 0
> #define ADXL345_DATA_FORMAT_4G 1
> #define ADXL345_DATA_FORMAT_8G 2
> @@ -48,7 +56,6 @@
> struct adxl345_data {
> const struct adxl345_chip_info *info;
> struct regmap *regmap;
> - u8 data_range;
> };
>
> #define ADXL345_CHANNEL(index, axis) { \
> @@ -218,15 +225,14 @@ int adxl345_core_probe(struct device *dev, struct regmap *regmap)
>
> data = iio_priv(indio_dev);
> data->regmap = regmap;
> - /* Enable full-resolution mode */
> - data->data_range = ADXL345_DATA_FORMAT_FULL_RES;
> data->info = device_get_match_data(dev);
> if (!data->info)
> return -ENODEV;
>
> - ret = regmap_write(data->regmap, ADXL345_REG_DATA_FORMAT,
> - data->data_range);
> - if (ret < 0)
> + /* Enable full-resolution mode */
> + ret = regmap_update_bits(regmap, ADXL345_REG_DATA_FORMAT,
> + ADXL345_DATA_FORMAT_MSK, ADXL345_DATA_FORMAT_FULL_RES);
> + if (ret)
> return dev_err_probe(dev, ret, "Failed to set data range\n");
>
> indio_dev->name = data->info->name;
^ permalink raw reply
* [PATCH 09/10] iio: dac: add support for AXI DAC IP core
From: Nuno Sa via B4 Relay @ 2024-03-28 13:22 UTC (permalink / raw)
To: linux-iio, devicetree
Cc: Dragos Bogdan, Jonathan Cameron, Lars-Peter Clausen,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Olivier Moysan, Nuno Sa
In-Reply-To: <20240328-iio-backend-axi-dac-v1-0-afc808b3fde3@analog.com>
From: Nuno Sa <nuno.sa@analog.com>
Support the Analog Devices Generic AXI DAC IP core. The IP core is used
for interfacing with digital-to-analog (DAC) converters that require either
a high-speed serial interface (JESD204B/C) or a source synchronous parallel
interface (LVDS/CMOS). Typically (for such devices) SPI will be used for
configuration only, while this IP core handles the streaming of data into
memory via DMA.
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
---
MAINTAINERS | 1 +
drivers/iio/dac/Kconfig | 21 ++
drivers/iio/dac/Makefile | 1 +
drivers/iio/dac/adi-axi-dac.c | 644 ++++++++++++++++++++++++++++++++++++++++++
4 files changed, 667 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 76e872e320d7..505f28dc6da6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1413,6 +1413,7 @@ L: linux-iio@vger.kernel.org
S: Supported
W: https://ez.analog.com/linux-software-drivers
F: Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
+F: drivers/iio/dac/adi-axi-dac.c
ANALOG DEVICES INC DMA DRIVERS
M: Lars-Peter Clausen <lars@metafoo.de>
diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index 34eb40bb9529..7c0a8caa9a34 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -131,6 +131,27 @@ config AD5624R_SPI
Say yes here to build support for Analog Devices AD5624R, AD5644R and
AD5664R converters (DAC). This driver uses the common SPI interface.
+config ADI_AXI_DAC
+ tristate "Analog Devices Generic AXI DAC IP core driver"
+ select IIO_BUFFER
+ select IIO_BUFFER_DMAENGINE
+ select REGMAP_MMIO
+ select IIO_BACKEND
+ help
+ Say yes here to build support for Analog Devices Generic
+ AXI DAC IP core. The IP core is used for interfacing with
+ digital-to-analog (DAC) converters that require either a high-speed
+ serial interface (JESD204B/C) or a source synchronous parallel
+ interface (LVDS/CMOS).
+ Typically (for such devices) SPI will be used for configuration only,
+ while this IP core handles the streaming of data into memory via DMA.
+
+ Link: https://wiki.analog.com/resources/fpga/docs/axi_dac_ip
+ If unsure, say N (but it's safe to say "Y").
+
+ To compile this driver as a module, choose M here: the
+ module will be called adi-axi-dac.
+
config LTC2688
tristate "Analog Devices LTC2688 DAC spi driver"
depends on SPI
diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
index 55bf89739d14..6bcaa65434b2 100644
--- a/drivers/iio/dac/Makefile
+++ b/drivers/iio/dac/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_AD5696_I2C) += ad5696-i2c.o
obj-$(CONFIG_AD7293) += ad7293.o
obj-$(CONFIG_AD7303) += ad7303.o
obj-$(CONFIG_AD8801) += ad8801.o
+obj-$(CONFIG_ADI_AXI_DAC) += adi-axi-dac.o
obj-$(CONFIG_CIO_DAC) += cio-dac.o
obj-$(CONFIG_DPOT_DAC) += dpot-dac.o
obj-$(CONFIG_DS4424) += ds4424.o
diff --git a/drivers/iio/dac/adi-axi-dac.c b/drivers/iio/dac/adi-axi-dac.c
new file mode 100644
index 000000000000..0022ecb4e4bb
--- /dev/null
+++ b/drivers/iio/dac/adi-axi-dac.c
@@ -0,0 +1,644 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Analog Devices Generic AXI DAC IP core
+ * Link: https://wiki.analog.com/resources/fpga/docs/axi_dac_ip
+ *
+ * Copyright 2016-2024 Analog Devices Inc.
+ */
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/cleanup.h>
+#include <linux/clk.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/limits.h>
+#include <linux/kstrtox.h>
+#include <linux/math.h>
+#include <linux/math64.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/mutex.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/regmap.h>
+#include <linux/units.h>
+
+#include <linux/fpga/adi-axi-common.h>
+#include <linux/iio/backend.h>
+#include <linux/iio/buffer-dmaengine.h>
+#include <linux/iio/buffer.h>
+#include <linux/iio/iio.h>
+
+/*
+ * Register definitions:
+ * https://wiki.analog.com/resources/fpga/docs/axi_dac_ip#register_map
+ */
+
+/* Base controls */
+#define AXI_DAC_REG_CONFIG 0x0c
+#define AXI_DDS_DISABLE BIT(6)
+
+ /* DAC controls */
+#define AXI_DAC_REG_RSTN 0x0040
+#define AXI_DAC_RSTN_CE_N BIT(2)
+#define AXI_DAC_RSTN_MMCM_RSTN BIT(1)
+#define AXI_DAC_RSTN_RSTN BIT(0)
+#define AXI_DAC_REG_CNTRL_1 0x0044
+#define AXI_DAC_SYNC BIT(0)
+#define AXI_DAC_REG_CNTRL_2 0x0048
+#define ADI_DAC_R1_MODE BIT(4)
+#define AXI_DAC_DRP_STATUS 0x0074
+#define AXI_DAC_DRP_LOCKED BIT(17)
+/* DAC Channel controls */
+#define AXI_DAC_REG_CHAN_CNTRL_1(c) (0x0400 + (c) * 0x40)
+#define AXI_DAC_REG_CHAN_CNTRL_3(c) (0x0408 + (c) * 0x40)
+#define AXI_DAC_SCALE_SIGN BIT(15)
+#define AXI_DAC_SCALE_INT BIT(14)
+#define AXI_DAC_SCALE GENMASK(14, 0)
+#define AXI_DAC_REG_CHAN_CNTRL_2(c) (0x0404 + (c) * 0x40)
+#define AXI_DAC_REG_CHAN_CNTRL_4(c) (0x040c + (c) * 0x40)
+#define AXI_DAC_PHASE GENMASK(31, 16)
+#define AXI_DAC_FREQUENCY GENMASK(15, 0)
+#define AXI_DAC_REG_CHAN_CNTRL_7(c) (0x0418 + (c) * 0x40)
+#define AXI_DAC_DATA_SEL GENMASK(3, 0)
+
+/* 360 degrees in rad */
+#define AXI_DAC_2_PI_MEGA 6283190
+enum {
+ AXI_DAC_DATA_INTERNAL_TONE,
+ AXI_DAC_DATA_DMA = 2,
+};
+
+struct axi_dac_state {
+ struct regmap *regmap;
+ struct device *dev;
+ /*
+ * lock to protect multiple accesses to the device registers and global
+ * data/variables.
+ */
+ struct mutex lock;
+ u64 dac_clk;
+ u32 reg_config;
+ bool int_tone;
+};
+
+static int axi_dac_enable(struct iio_backend *back)
+{
+ struct axi_dac_state *st = iio_backend_get_priv(back);
+ unsigned int __val;
+ int ret;
+
+ guard(mutex)(&st->lock);
+ ret = regmap_set_bits(st->regmap, AXI_DAC_REG_RSTN,
+ AXI_DAC_RSTN_MMCM_RSTN);
+ if (ret)
+ return ret;
+ /*
+ * Make sure the DRP (Dynamic Reconfiguration Port) is locked. Not all
+ * designs really use it but if they don't we still get the lock bit
+ * set. So let's do it all the time so the code is generic.
+ */
+ ret = regmap_read_poll_timeout(st->regmap, AXI_DAC_DRP_STATUS, __val,
+ __val & AXI_DAC_DRP_LOCKED, 100, 1000);
+ if (ret)
+ return ret;
+
+ return regmap_set_bits(st->regmap, AXI_DAC_REG_RSTN,
+ AXI_DAC_RSTN_RSTN | AXI_DAC_RSTN_MMCM_RSTN);
+}
+
+static void axi_dac_disable(struct iio_backend *back)
+{
+ struct axi_dac_state *st = iio_backend_get_priv(back);
+
+ guard(mutex)(&st->lock);
+ regmap_write(st->regmap, AXI_DAC_REG_RSTN, 0);
+}
+
+static struct iio_buffer *axi_dac_request_buffer(struct iio_backend *back,
+ struct iio_dev *indio_dev)
+{
+ struct axi_dac_state *st = iio_backend_get_priv(back);
+ struct iio_buffer *buffer;
+ const char *dma_name;
+ int ret;
+
+ if (device_property_read_string(st->dev, "dma-names", &dma_name))
+ dma_name = "tx";
+
+ buffer = iio_dmaengine_buffer_alloc(st->dev, dma_name);
+ if (IS_ERR(buffer)) {
+ dev_err(st->dev, "Could not get DMA buffer, %ld\n",
+ PTR_ERR(buffer));
+ return ERR_CAST(buffer);
+ }
+
+ indio_dev->modes |= INDIO_BUFFER_HARDWARE;
+ iio_buffer_set_dir(buffer, IIO_BUFFER_DIRECTION_OUT);
+
+ ret = iio_device_attach_buffer(indio_dev, buffer);
+ if (ret)
+ return ERR_PTR(ret);
+
+ return buffer;
+}
+
+static void axi_dac_free_buffer(struct iio_backend *back,
+ struct iio_buffer *buffer)
+{
+ iio_dmaengine_buffer_free(buffer);
+}
+
+enum {
+ AXI_DAC_FREQ_TONE_1,
+ AXI_DAC_FREQ_TONE_2,
+ AXI_DAC_SCALE_TONE_1,
+ AXI_DAC_SCALE_TONE_2,
+ AXI_DAC_PHASE_TONE_1,
+ AXI_DAC_PHASE_TONE_2,
+};
+
+static int __axi_dac_frequency_get(struct axi_dac_state *st, unsigned int chan,
+ unsigned int tone, unsigned int *freq)
+{
+ u32 reg, raw;
+ int ret;
+
+ if (!st->dac_clk) {
+ dev_err(st->dev, "Sampling rate is 0...\n");
+ return -EINVAL;
+ }
+
+ if (tone == AXI_DAC_FREQ_TONE_1)
+ reg = AXI_DAC_REG_CHAN_CNTRL_2(chan);
+ else
+ reg = AXI_DAC_REG_CHAN_CNTRL_4(chan);
+
+ ret = regmap_read(st->regmap, reg, &raw);
+ if (ret)
+ return ret;
+
+ raw = FIELD_GET(AXI_DAC_FREQUENCY, raw);
+ *freq = DIV_ROUND_CLOSEST_ULL(raw * st->dac_clk, BIT(16));
+
+ return 0;
+}
+
+static int axi_dac_frequency_get(struct axi_dac_state *st,
+ const struct iio_chan_spec *chan, char *buf,
+ unsigned int tone)
+{
+ unsigned int freq;
+ int ret;
+
+ scoped_guard(mutex, &st->lock) {
+ ret = __axi_dac_frequency_get(st, chan->channel, tone, &freq);
+ if (ret)
+ return ret;
+ }
+
+ return sysfs_emit(buf, "%u\n", freq);
+}
+
+static int axi_dac_scale_get(struct axi_dac_state *st,
+ const struct iio_chan_spec *chan, char *buf,
+ unsigned int tone)
+{
+ unsigned int scale, sign;
+ int ret, vals[2];
+ u32 reg, raw;
+
+ if (tone == AXI_DAC_SCALE_TONE_1)
+ reg = AXI_DAC_REG_CHAN_CNTRL_1(chan->channel);
+ else
+ reg = AXI_DAC_REG_CHAN_CNTRL_3(chan->channel);
+
+ ret = regmap_read(st->regmap, reg, &raw);
+ if (ret)
+ return ret;
+
+ sign = FIELD_GET(AXI_DAC_SCALE_SIGN, raw);
+ raw = FIELD_GET(AXI_DAC_SCALE, raw);
+ scale = DIV_ROUND_CLOSEST_ULL((u64)raw * MEGA, AXI_DAC_SCALE_INT);
+
+ vals[0] = scale / MEGA;
+ vals[1] = scale % MEGA;
+
+ if (sign) {
+ vals[0] *= -1;
+ if (!vals[0])
+ vals[1] *= -1;
+ }
+
+ return iio_format_value(buf, IIO_VAL_INT_PLUS_MICRO, ARRAY_SIZE(vals),
+ vals);
+}
+
+static int axi_dac_phase_get(struct axi_dac_state *st,
+ const struct iio_chan_spec *chan, char *buf,
+ unsigned int tone)
+{
+ u32 reg, raw, phase;
+ int ret, vals[2];
+
+ if (tone == AXI_DAC_PHASE_TONE_1)
+ reg = AXI_DAC_REG_CHAN_CNTRL_2(chan->channel);
+ else
+ reg = AXI_DAC_REG_CHAN_CNTRL_4(chan->channel);
+
+ ret = regmap_read(st->regmap, reg, &raw);
+ if (ret)
+ return ret;
+
+ raw = FIELD_GET(AXI_DAC_PHASE, raw);
+ phase = DIV_ROUND_CLOSEST_ULL((u64)raw * AXI_DAC_2_PI_MEGA, U16_MAX);
+
+ vals[0] = phase / MEGA;
+ vals[1] = phase % MEGA;
+
+ return iio_format_value(buf, IIO_VAL_INT_PLUS_MICRO, ARRAY_SIZE(vals),
+ vals);
+}
+
+static int __axi_dac_frequency_set(struct axi_dac_state *st, unsigned int chan,
+ u64 sample_rate, unsigned int freq,
+ unsigned int tone)
+{
+ u32 reg;
+ u16 raw;
+ int ret;
+
+ if (!sample_rate || freq > sample_rate / 2) {
+ dev_err(st->dev, "Invalid frequency(%u) dac_clk(%llu)\n",
+ freq, sample_rate);
+ return -EINVAL;
+ }
+
+ if (tone == AXI_DAC_FREQ_TONE_1)
+ reg = AXI_DAC_REG_CHAN_CNTRL_2(chan);
+ else
+ reg = AXI_DAC_REG_CHAN_CNTRL_4(chan);
+
+ raw = DIV64_U64_ROUND_CLOSEST((u64)freq * BIT(16), sample_rate);
+
+ ret = regmap_update_bits(st->regmap, reg, AXI_DAC_FREQUENCY, raw);
+ if (ret)
+ return ret;
+
+ /* synchronize channels */
+ return regmap_set_bits(st->regmap, AXI_DAC_REG_CNTRL_1, AXI_DAC_SYNC);
+}
+
+static int axi_dac_frequency_set(struct axi_dac_state *st,
+ const struct iio_chan_spec *chan,
+ const char *buf, size_t len, unsigned int tone)
+{
+ unsigned int freq;
+ int ret;
+
+ ret = kstrtou32(buf, 10, &freq);
+ if (ret)
+ return ret;
+
+ guard(mutex)(&st->lock);
+ ret = __axi_dac_frequency_set(st, chan->channel, st->dac_clk, freq,
+ tone);
+ if (ret)
+ return ret;
+
+ return len;
+}
+
+static int axi_dac_scale_set(struct axi_dac_state *st,
+ const struct iio_chan_spec *chan,
+ const char *buf, size_t len, unsigned int tone)
+{
+ int integer, frac, scale;
+ u32 raw = 0, reg;
+ int ret;
+
+ ret = iio_str_to_fixpoint(buf, 100000, &integer, &frac);
+ if (ret)
+ return ret;
+
+ scale = integer * MEGA + frac;
+ if (scale <= -2 * (int)MEGA || scale >= 2 * (int)MEGA)
+ return -EINVAL;
+
+ /* format is 1.1.14 (sign, integer and fractional bits) */
+ if (scale < 0) {
+ raw = FIELD_PREP(AXI_DAC_SCALE_SIGN, 1);
+ scale *= -1;
+ }
+
+ raw |= div_u64((u64)scale * AXI_DAC_SCALE_INT, MEGA);
+
+ if (tone == AXI_DAC_SCALE_TONE_1)
+ reg = AXI_DAC_REG_CHAN_CNTRL_1(chan->channel);
+ else
+ reg = AXI_DAC_REG_CHAN_CNTRL_3(chan->channel);
+
+ guard(mutex)(&st->lock);
+ ret = regmap_write(st->regmap, reg, raw);
+ if (ret)
+ return ret;
+
+ /* synchronize channels */
+ ret = regmap_set_bits(st->regmap, AXI_DAC_REG_CNTRL_1, AXI_DAC_SYNC);
+ if (ret)
+ return ret;
+
+ return len;
+}
+
+static int axi_dac_phase_set(struct axi_dac_state *st,
+ const struct iio_chan_spec *chan,
+ const char *buf, size_t len, unsigned int tone)
+{
+ int integer, frac, phase;
+ u32 raw, reg;
+ int ret;
+
+ ret = iio_str_to_fixpoint(buf, 100000, &integer, &frac);
+ if (ret)
+ return ret;
+
+ phase = integer * MEGA + frac;
+ if (phase < 0 || phase > AXI_DAC_2_PI_MEGA)
+ return -EINVAL;
+
+ raw = DIV_ROUND_CLOSEST_ULL((u64)phase * U16_MAX, AXI_DAC_2_PI_MEGA);
+
+ if (tone == AXI_DAC_PHASE_TONE_1)
+ reg = AXI_DAC_REG_CHAN_CNTRL_2(chan->channel);
+ else
+ reg = AXI_DAC_REG_CHAN_CNTRL_4(chan->channel);
+
+ guard(mutex)(&st->lock);
+ ret = regmap_update_bits(st->regmap, reg, AXI_DAC_PHASE,
+ FIELD_PREP(AXI_DAC_PHASE, raw));
+ if (ret)
+ return ret;
+
+ /* synchronize channels */
+ ret = regmap_set_bits(st->regmap, AXI_DAC_REG_CNTRL_1, AXI_DAC_SYNC);
+ if (ret)
+ return ret;
+
+ return len;
+}
+
+static int axi_dac_ext_info_set(struct iio_backend *back, uintptr_t private,
+ const struct iio_chan_spec *chan,
+ const char *buf, size_t len)
+{
+ struct axi_dac_state *st = iio_backend_get_priv(back);
+
+ switch (private) {
+ case AXI_DAC_FREQ_TONE_1:
+ case AXI_DAC_FREQ_TONE_2:
+ return axi_dac_frequency_set(st, chan, buf, len, private);
+ case AXI_DAC_SCALE_TONE_1:
+ case AXI_DAC_SCALE_TONE_2:
+ return axi_dac_scale_set(st, chan, buf, len, private);
+ case AXI_DAC_PHASE_TONE_1:
+ case AXI_DAC_PHASE_TONE_2:
+ return axi_dac_phase_set(st, chan, buf, len, private);
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static int axi_dac_ext_info_get(struct iio_backend *back, uintptr_t private,
+ const struct iio_chan_spec *chan, char *buf)
+{
+ struct axi_dac_state *st = iio_backend_get_priv(back);
+
+ switch (private) {
+ case AXI_DAC_FREQ_TONE_1:
+ case AXI_DAC_FREQ_TONE_2:
+ return axi_dac_frequency_get(st, chan, buf, private);
+ case AXI_DAC_SCALE_TONE_1:
+ case AXI_DAC_SCALE_TONE_2:
+ return axi_dac_scale_get(st, chan, buf, private);
+ case AXI_DAC_PHASE_TONE_1:
+ case AXI_DAC_PHASE_TONE_2:
+ return axi_dac_phase_get(st, chan, buf, private);
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static const struct iio_chan_spec_ext_info axi_dac_ext_info[] = {
+ IIO_BACKEND_EX_INFO("frequency0", IIO_SEPARATE, AXI_DAC_FREQ_TONE_1),
+ IIO_BACKEND_EX_INFO("frequency1", IIO_SEPARATE, AXI_DAC_FREQ_TONE_2),
+ IIO_BACKEND_EX_INFO("scale0", IIO_SEPARATE, AXI_DAC_SCALE_TONE_1),
+ IIO_BACKEND_EX_INFO("scale1", IIO_SEPARATE, AXI_DAC_SCALE_TONE_2),
+ IIO_BACKEND_EX_INFO("phase0", IIO_SEPARATE, AXI_DAC_PHASE_TONE_1),
+ IIO_BACKEND_EX_INFO("phase1", IIO_SEPARATE, AXI_DAC_PHASE_TONE_2),
+ {}
+};
+
+static int axi_dac_extend_chan(struct iio_backend *back,
+ struct iio_chan_spec *chan)
+{
+ struct axi_dac_state *st = iio_backend_get_priv(back);
+
+ if (chan->type != IIO_ALTVOLTAGE)
+ return -EINVAL;
+ if (st->reg_config & AXI_DDS_DISABLE)
+ /* nothing to extend */
+ return 0;
+
+ chan->ext_info = axi_dac_ext_info;
+
+ return 0;
+}
+
+static int axi_dac_data_source_set(struct iio_backend *back, unsigned int chan,
+ enum iio_backend_data_source data)
+{
+ struct axi_dac_state *st = iio_backend_get_priv(back);
+
+ switch (data) {
+ case IIO_BACKEND_INTERNAL_CW:
+ return regmap_update_bits(st->regmap,
+ AXI_DAC_REG_CHAN_CNTRL_7(chan),
+ AXI_DAC_DATA_SEL,
+ AXI_DAC_DATA_INTERNAL_TONE);
+ case IIO_BACKEND_EXTERNAL:
+ return regmap_update_bits(st->regmap,
+ AXI_DAC_REG_CHAN_CNTRL_7(chan),
+ AXI_DAC_DATA_SEL, AXI_DAC_DATA_DMA);
+ default:
+ return -EINVAL;
+ }
+}
+
+static int axi_dac_set_sample_rate(struct iio_backend *back, unsigned int chan,
+ u64 sample_rate)
+{
+ struct axi_dac_state *st = iio_backend_get_priv(back);
+ unsigned int freq;
+ int ret, tone;
+
+ if (!sample_rate)
+ return -EINVAL;
+ if (st->reg_config & AXI_DDS_DISABLE)
+ /* nothing to care if DDS is disabled */
+ return 0;
+
+ guard(mutex)(&st->lock);
+ /*
+ * If dac_clk is 0 then this must be the first time we're being notified
+ * about the interface sample rate. Hence, just update our internal
+ * variable and bail... If it's not 0, then we get the current DDS
+ * frequency (for the old rate) and update the registers for the new
+ * sample rate.
+ */
+ if (!st->dac_clk) {
+ st->dac_clk = sample_rate;
+ return 0;
+ }
+
+ for (tone = 0; tone <= AXI_DAC_FREQ_TONE_2; tone++) {
+ ret = __axi_dac_frequency_get(st, chan, tone, &freq);
+ if (ret)
+ return ret;
+
+ ret = __axi_dac_frequency_set(st, chan, sample_rate, tone, freq);
+ if (ret)
+ return ret;
+ }
+
+ st->dac_clk = sample_rate;
+
+ return 0;
+}
+
+static const struct iio_backend_ops axi_dac_generic = {
+ .enable = axi_dac_enable,
+ .disable = axi_dac_disable,
+ .request_buffer = axi_dac_request_buffer,
+ .free_buffer = axi_dac_free_buffer,
+ .extend_chan_spec = axi_dac_extend_chan,
+ .ext_info_set = axi_dac_ext_info_set,
+ .ext_info_get = axi_dac_ext_info_get,
+ .data_source_set = axi_dac_data_source_set,
+ .set_sample_rate = axi_dac_set_sample_rate,
+};
+
+static const struct regmap_config axi_dac_regmap_config = {
+ .val_bits = 32,
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .max_register = 0x0800,
+};
+
+static int axi_dac_probe(struct platform_device *pdev)
+{
+ const unsigned int *expected_ver;
+ struct axi_dac_state *st;
+ void __iomem *base;
+ unsigned int ver;
+ struct clk *clk;
+ int ret;
+
+ st = devm_kzalloc(&pdev->dev, sizeof(*st), GFP_KERNEL);
+ if (!st)
+ return -ENOMEM;
+
+ expected_ver = device_get_match_data(&pdev->dev);
+ if (!expected_ver)
+ return -ENODEV;
+
+ clk = devm_clk_get_enabled(&pdev->dev, NULL);
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+
+ base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ st->dev = &pdev->dev;
+ st->regmap = devm_regmap_init_mmio(&pdev->dev, base,
+ &axi_dac_regmap_config);
+ if (IS_ERR(st->regmap))
+ return PTR_ERR(st->regmap);
+
+ /*
+ * Force disable the core. Up to the frontend to enable us. And we can
+ * still read/write registers...
+ */
+ ret = regmap_write(st->regmap, AXI_DAC_REG_RSTN, 0);
+ if (ret)
+ return ret;
+
+ ret = regmap_read(st->regmap, ADI_AXI_REG_VERSION, &ver);
+ if (ret)
+ return ret;
+
+ if (ADI_AXI_PCORE_VER_MAJOR(ver) != ADI_AXI_PCORE_VER_MAJOR(*expected_ver)) {
+ dev_err(&pdev->dev,
+ "Major version mismatch. Expected %d.%.2d.%c, Reported %d.%.2d.%c\n",
+ ADI_AXI_PCORE_VER_MAJOR(*expected_ver),
+ ADI_AXI_PCORE_VER_MINOR(*expected_ver),
+ ADI_AXI_PCORE_VER_PATCH(*expected_ver),
+ ADI_AXI_PCORE_VER_MAJOR(ver),
+ ADI_AXI_PCORE_VER_MINOR(ver),
+ ADI_AXI_PCORE_VER_PATCH(ver));
+ return -ENODEV;
+ }
+
+ /* Let's get the core read only configuration */
+ ret = regmap_read(st->regmap, AXI_DAC_REG_CONFIG, &st->reg_config);
+ if (ret)
+ return ret;
+
+ /*
+ * In some designs, setting the R1_MODE bit to 0 (which is the default
+ * value) causes all channels of the frontend to be routed to the same
+ * DMA (so they are sampled together). This is for things like
+ * Multiple-Input and Multiple-Output (MIMO). As most of the times we
+ * want independent channels let's override the core's default value and
+ * set the R1_MODE bit.
+ */
+ ret = regmap_set_bits(st->regmap, AXI_DAC_REG_CNTRL_2, ADI_DAC_R1_MODE);
+ if (ret)
+ return ret;
+
+ mutex_init(&st->lock);
+ ret = devm_iio_backend_register(&pdev->dev, &axi_dac_generic, st);
+ if (ret)
+ return ret;
+
+ dev_info(&pdev->dev, "AXI DAC IP core (%d.%.2d.%c) probed\n",
+ ADI_AXI_PCORE_VER_MAJOR(ver),
+ ADI_AXI_PCORE_VER_MINOR(ver),
+ ADI_AXI_PCORE_VER_PATCH(ver));
+
+ return 0;
+}
+
+static unsigned int axi_dac_9_1_b_info = ADI_AXI_PCORE_VER(9, 1, 'b');
+
+static const struct of_device_id axi_dac_of_match[] = {
+ { .compatible = "adi,axi-dac-9.1.b", .data = &axi_dac_9_1_b_info },
+ {}
+};
+MODULE_DEVICE_TABLE(of, axi_dac_of_match);
+
+static struct platform_driver axi_dac_driver = {
+ .driver = {
+ .name = "adi-axi-dac",
+ .of_match_table = axi_dac_of_match,
+ },
+ .probe = axi_dac_probe,
+};
+module_platform_driver(axi_dac_driver);
+
+MODULE_AUTHOR("Nuno Sa <nuno.sa@analog.com>");
+MODULE_DESCRIPTION("Analog Devices Generic AXI DAC IP core driver");
+MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS(IIO_DMAENGINE_BUFFER);
+MODULE_IMPORT_NS(IIO_BACKEND);
--
2.44.0
^ permalink raw reply related
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