Hi, Here [1] you can find my new patchset, based on Miquel's one, as we agreed earlier this week. As my patches touch some common driver code, I'd appreciate if you could run them against your testcases and leave some feedback. Thanks, Jan [1] https://lore.kernel.org/dmaengine/20231208134838.49500-1-jankul@xxxxxxxxxxxxxxxx/T/#t On 4.12.2023 17:41, Lizhi Hou wrote: > > On 12/4/23 06:36, Miquel Raynal wrote: >> Hi Jan, >> >> jankul@xxxxxxxxxxxxxxxx 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@xxxxxxx> > >> >>> 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
