Messages in this thread | | | Date | Mon, 24 Apr 2023 15:00:49 +0530 | Subject | Re: [PATCH v4 5/5] spi: spi-qcom-qspi: Add DMA mode support | From | 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@quicinc.com> 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.
| |