[PATCH v2 2/2] dmaengine: apple-admac: Add M3 generation ADMACs

[Sasha Finkelstein]

On Aug 2, 2026, at 10:54, Janne Grunau <j at jannau.net> wrote:
> 
> On Wed, Jul 29, 2026 at 01:46:35PM +0200, Sasha Finkelstein wrote:
>> The admacs present on t8122 and t603x SoCs need additional writes in
>> order to operate correctly. The exact purpose of this register
>> is unknown
>> 
>> Signed-off-by: Sasha Finkelstein <k at chaosmail.tech>
>> ---
>> drivers/dma/apple-admac.c | 32 ++++++++++++++++++++++++++++++--
>> 1 file changed, 30 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/dma/apple-admac.c b/drivers/dma/apple-admac.c
>> index 14a5ee14a481..72ff677c8ce5 100644
>> --- a/drivers/dma/apple-admac.c
>> +++ b/drivers/dma/apple-admac.c
>> @@ -39,10 +39,14 @@
>> 
>> #define FLAG_DESC_NOTIFY BIT(16)
>> 
>> +#define T8122_UNK_28_VAL 0x200000
> 
> maybe BIT(21)

Probably not, this is not in any way related to channel 21. I suspect
but can't confirm that this is rather an address.

> 
>> #define REG_TX_START 0x0000
>> #define REG_TX_STOP 0x0004
>> #define REG_RX_START 0x0008
>> #define REG_RX_STOP 0x000c
>> +#define REG_UNK_28 0x0028
>> +#define REG_UNK_2C 0x002c
>> #define REG_IMPRINT 0x0090
>> #define REG_TX_SRAM_SIZE 0x0094
>> #define REG_RX_SRAM_SIZE 0x0098
>> @@ -127,6 +131,7 @@ struct admac_data {
>> struct mutex cache_alloc_lock;
>> struct admac_sram txcache, rxcache;
>> 
>> + bool set_unk28;
>> int irq;
>> int irq_index;
>> int nchannels;
>> @@ -147,6 +152,10 @@ struct admac_tx {
>> struct list_head node;
>> };
>> 
>> +struct admac_hw {
>> + bool set_unk28;
>> +};
>> +
>> static int admac_alloc_sram_carveout(struct admac_data *ad,
>>      enum dma_transfer_direction dir,
>>      u32 *out)
>> @@ -747,6 +756,11 @@ static int admac_device_config(struct dma_chan *chan,
>> u32 bus_width = readl_relaxed(ad->base + REG_BUS_WIDTH(adchan->no)) &
>> ~(BUS_WIDTH_WORD_SIZE | BUS_WIDTH_FRAME_SIZE);
>> 
>> + if (ad->set_unk28) {
>> + writel_relaxed(T8122_UNK_28_VAL, ad->base + REG_UNK_28);
>> + writel_relaxed(T8122_UNK_28_VAL, ad->base + REG_UNK_2C);
>> + }
> 
> can this be done in probe? This writes the same value for every channel
> without obvious way how the bit in those two registers can reset? If it
> needs to be done here a comment explaining why would be useful.

Those are getting reset. The AOP-attached ADMAC has it's power
controlled by the AOP firmware, so I can't even touch any registers
in probe, as the hw is off at that point and will SError at us.
device_config is the earliest point when the ADMAC is powered on. There
is an explanation of this setup in the commit history for this file.
(8d55e8a16f019211163f1180fd9f9fbe05901900)