Re: [PATCH v2 4/4] dmaengine: xilinx: xdma: Add terminate_all/synchronize callbacks

[Lizhi Hou <lizhi.hou@amd.com>]

On 12/4/23 06:36, Miquel Raynal wrote:
> Hi Jan,
>
> jankul@alatek.krakow.pl wrote on Mon, 4 Dec 2023 14:13:13 +0100:
>
>> Hi Miquel,
>>
>> On 4.12.2023 12:02, Miquel Raynal wrote:
>>> Hi Jan,
>>>    
>>>>>>>> +    vchan_synchronize(&xdma_chan->vchan); +} + /** *
>>>>>>>> xdma_prep_device_sg - prepare a descriptor for a DMA
>>>> tr
>>>>>> ansaction
>>>>>>>> * @chan: DMA channel pointer @@ -1088,6 +1154,8 @@ static
>>>>>>>> int xdma_probe(struct platform_device *
>>>> pd
>>>>>> ev)
>>>>>>>> xdev->dma_dev.device_prep_slave_sg =
>>>> xdma_prep_device_sg;
>>>>>>>> xdev->dma_dev.device_config = xdma
>>>> _de
>>>>>> vice_config;
>>>>>>>> xdev->dma_dev.device_issue_pending =
>>>> xdma_issue_pending;
>>>>>>>> +    xdev->dma_dev.device_terminate_all = xdma_term
>>>> in
>>>>>> ate_all;
>>>>>>>> +    xdev->dma_dev.device_synchronize = xdma_synchr
>>>> on
>>>>>> ize;
>>>>>>>> xdev->dma_dev.filter.map = pdata->
>>>> dev
>>>>>> ice_map;
>>>>>>>> xdev->dma_dev.filter.mapcnt = pdat
>>>> a->
>>>>>> device_map_cnt;
>>>>>>>> xdev->dma_dev.filter.fn = xdma_fil
>>>> ter
>>>>>> _fn;
>>> Not related, but if you could fix your mailer, it is a bit hard to
>>> track your answers.
>>>    
>> Thanks for pointing this out, I didn't notice it. From now on it should be okay.
>>
>>>>>> I have already prepared a patch with an appropriate fix, which
>>>>>> I'm goi
>>>> ng to submit with the whole patch series, once I have interleaved
>>>> DMA transfers properly sorted out (hopefully soon). Or maybe should
>>>> I post this patch with fix, immediately as a reply to the already
>>>> sent one? What do y ou prefer?
>>>>> I see. Well in the case of cyclic transfers it looks like this
>>>>> is enoug
>>>> h
>>>>> (I don't have any way to test interleaved/SG transfers) so maybe
>>>>>   maintainers can take this now as it is ready and fixes cyclic
>>>>> transfers, so when the interleaved transfers are ready you can
>>>>> improve these functions with a series on top of it?
>>>>>    
>>>> So I decided to base my new patchset on my previous one, as I
>>>> haven't seen any ack from any maintainer yet on both mine and your
>>>> patchset. I'm going to submit it this week.
>>> Well, the difference between the two approaches is that I am fixing
>>> something upstream, and you're adding a new feature, which is not
>>> ready yet. I don't mind about using your patch though, I just want
>>> upstream to be fixed.
>>>    
>>>> This specific commit of yours (PATCH 4/4) basically does the same
>>>> thing as mine patch, so there will be no difference in its
>>>> functionality, i.e. it will also fix cyclic transfers.
>>>    
>> Okay, so as far as I understand, you'd like me to submit my patchset based on the top of yours.
> That would be ideal, unless my series get postponed for any reason.
> I believe the maintainers will soon give their feedback, we'll do what
> they prefer.
>
> I believe Lizhi will also give a Tested-by -or not-.

Yes, I verified this patch set for sg list test and it passed.

Tested-by: Lizhi Hou <lizhi.hou@amd.com>

>
>> I guess maintainers will be fine with that (so do I). If so, what is the proper way to post my next
>> patch series? Should I post it as a reply to your patchset, or as a completely new thread
>> with a information that it is based on this patchset?
> You can definitely send an individual patchset and just point out that
> it applies on top of the few fixes I sent.
>
>> I don't want to wait with submission
>> without getting any feedback until your patches are going to be upstreamed.
> Of course.
>
> Thanks,
> Miquèl