Re: [PATCH v4 5/5] spi: spi-qcom-qspi: Add DMA mode support

[Vijaya Krishna Nivarthi]

Hi,

Thank you very much for the review and all the inputs...


On 4/22/2023 1:28 AM, Doug Anderson wrote:
> On Fri, Apr 21, 2023 at 11:21 AM Vijaya Krishna Nivarthi
> <quic_vnivarth@xxxxxxxxxxx> wrote:
> > > > If we were to have a linked list of descriptors that we can parse and
> > > > free, it would require 2 more fields
> > > >
> > > > this_descriptor_dma - dma address of the current descriptor
> > > Isn't that exactly the same value as "data_address"? Sure,
> > > "data_address" is a u32 and the DMA address is 64-bits, but elsewhere
> > > in the code you already rely on the fact that the upper bits of the
> > > DMA address are 0 when you do:
> >
> > No; data_address is the dma_address mapped to the xfer buffer.
> >
> > This is provided by spi framework and retrieved from sgl.
> >
> > "this_descriptor" would be the dma_address of the current cmd_descriptor.
> >
> > this is returned from dma_pool_alloc()
> >
> > this would be required for freeing.
> Oh! Of course, that's right. So you are correct, you'd need to add
> "this_descriptor_dma", but not the virtual address since that would be
> the same as the address of the structure via the list_node_t. I guess
> I won't insist on using a linked list even though it seems more
> elegant to me. In the very least it should fall back to PIO if the
> array isn't enough and if we need to change it later we always can.
>
> -Doug


Retained the array, addressed all other comments and uploaded v5.

Conditional can_dma() and clearing interrupts in handle_err(), I thought 
were particularly helpful as they were potential problems later.

test script was very useful too.

Thank you.