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