[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aFEFBss3RT7NbQkV@vaman>
Date: Tue, 17 Jun 2025 11:32:46 +0530
From: Vinod Koul <vkoul@...nel.org>
To: Guodong Xu <guodong@...cstar.com>
Cc: robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
dlan@...too.org, paul.walmsley@...ive.com, palmer@...belt.com,
aou@...s.berkeley.edu, alex@...ti.fr, p.zabel@...gutronix.de,
drew@...7.com, emil.renner.berthing@...onical.com,
inochiama@...il.com, geert+renesas@...der.be, tglx@...utronix.de,
hal.feng@...rfivetech.com, joel@....id.au, duje.mihanovic@...le.hr,
elder@...cstar.com, dmaengine@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-riscv@...ts.infradead.org, spacemit@...ts.linux.dev
Subject: Re: [PATCH 4/8] dma: mmp_pdma: Add SpacemiT PDMA support with 64-bit
addressing
On 11-06-25, 20:57, Guodong Xu wrote:
> Extend the MMP PDMA driver to support SpacemiT PDMA controllers with
> 64-bit physical addressing capabilities, as used in the K1 SoC. This
> change introduces a flexible architecture that maintains compatibility
> with existing 32-bit Marvell platforms while adding 64-bit support.
>
> Key changes:
> - Add struct mmp_pdma_config to abstract platform-specific behaviors
> - Implement 64-bit address support through:
> * New high address registers (DDADRH, DSADRH, DTADRH)
> * DCSR_LPAEEN bit for Long Physical Address Extension mode
> * Helper functions for 32/64-bit address handling
> - Add "spacemit,pdma-1.0" compatible string with associated config
> - Extend descriptor structure to support 64-bit addresses
> - Refactor address handling code to be platform-agnostic
> - Add proper DMA mask configuration for both 32-bit and 64-bit modes
>
> The implementation uses a configuration-based approach to keeps all
> platform-specific code isolated in config structures. It maintains clean
> separation between 32-bit and 64-bit code paths, provides consistent
> API for both addressing modes and preserves backward compatibility.
I would ask for this to be split, first to to driver changes for adding
new ops and then adding new soc support. This way the two changes are
independent
--
~Vinod
Powered by blists - more mailing lists