[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<NT0PR01MB11826C9F142FCD1A1199A11B8AC02@NT0PR01MB1182.CHNPR01.prod.partner.outlook.cn>
Date: Wed, 12 Jun 2024 10:13:30 +0000
From: JiaJie Ho <jiajie.ho@...rfivetech.com>
To: Vinod Koul <vkoul@...nel.org>
CC: Herbert Xu <herbert@...dor.apana.org.au>, "David S . Miller"
<davem@...emloft.net>, Eugeniy Paltsev <Eugeniy.Paltsev@...opsys.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
"dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>
Subject: RE: [PATCH v5 1/3] dmaengine: dw-axi-dmac: Support hardware quirks
> On 30-05-24, 11:11, Jia Jie Ho wrote:
>
> > +
> > +struct dw_axi_peripheral_config {
> > +#define DWAXIDMAC_STARFIVE_SM_ALGO BIT(0)
>
> what does this quirk mean?
>
> > + u32 quirks;
>
> Can you explain why you need this to be exposed. I would prefer we use
> existing interfaces and not define a new one...
>
Hi Vinod,
Thanks for reviewing this.
This is a dedicated dma controller for the crypto engine.
I am adding this quirk to:
1. Select the src and dest AXI master for transfers between mem and dev.
Driver currently only uses AXI0 for both.
2. Workaround a hardware limitation on the crypto engine to
transfer data > 256B by incrementing the peripheral FIFO offset.
What is the recommended way to handle such cases besides using
peripheral_config in dma_slave_config?
Best regards,
Jia Jie
Powered by blists - more mailing lists