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

[Miquel Raynal <miquel.raynal@bootlin.com>]

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-.

> 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