On 15-01-20, 11:44, Peter Ujfalusi wrote: > > > On 14/01/2020 20.06, santosh.shilimkar@xxxxxxxxxx wrote: > >>>>> Can you please giver your Acked-by for the ringacc patches if they are > >>>>> still OK from your point of view as you had offered to take them > >>>>> before > >>>>> I got comments from Lokesh. > >>>>> > >>>> Sure. But you really need to split the series so that dma engine and > >>>> soc driver patches can be applied independently. > >>> > >>> The ringacc is a build and runtime dependency for the DMA. I have hoped > >>> that all of them can go via DMAengine (hence asking for your ACK on the > >>> drivers/soc/ti/ patches) for 5.6. > >>> > >>>> Can you please do that? > >>> > >>> This late in the merge window that would really mean that I will miss > >>> another release for the KS3 DMA... > >>> I can live with that if you can pick the ringacc for 5.6 and if Vinod > >>> takes the DMAengine core changes as well. > >>> > >>> That would leave only the DMA drivers for 5.7 and we can also queue up > >>> changes for 5.7 which depends on the DMAengine API (ASoC changes, UART, > >>> sa2ul, etc). > >>> > >>> If they go independently and nothing makes it to 5.6 then 5.8 is the > >>> realistic target for the DMA support for the KS3 family of devices... > >> > >> Thats too many kernel versions to get this important piece in. > >> > >> Santosh, if you do not have anything else queued up that clashes with > >> this, can the whole series be picked up by Vinod with your ack on the > >> drivers/soc/ti/ pieces? > >> > > I would prefer driver patches to go via driver tree. > > Not sure what you mean by 'driver patches'... > The series to enable DMA support on TI's K3 platform consists: > Patch 1-2: Ring Accelerator _driver_ (drivers/soc/ti/) > Patch 3-6: DMAengine core patches to add new features needed for k3-udma > Patch 7-11: DMA _driver_ patches for K3 (drivers/dma/ti/) > > Patch 10 depends on the ringacc and the DMAengine core patches > Patch 11 depends on patch 10 > > I kept it as a single series in hope that they will go via one subsystem > tree to avoid build dependency issues and will have a good amount of > time in linux-next for testing. > > >> Vinod could also perhaps setup an immutable branch based on v5.5-rc1 > >> with just the drivers/soc/ti parts applied so you can merge that branch > >> in case you end up having to send up anything that conflicts. > >> > > As suggested on other email to Peter, these DMA engine related patches > > should be queued up since they don't have any dependency. Based on > > the status of that patchset, will take care of pulling in the driver > > patches either for this merge window or early part of next merge window. > > OK, I'll send the two patch for ringacc as a separate series. > > Vinod: Would it be possible for you to pick up the DMAengine core > patches (patch 3-6)? > The UDMA driver patches have hard dependency on DMAengine core and > ringacc, not sure how they are going to go in... Since they have build dependency, the usual method for this is: 1. Santosh acks the dependent patches and I will apply the rest (nice and simple) 2. Santosh picks up ring driver patches, provides a signed immutable tag which I will pull in and apply the rest, i.e., dmaengine updates and new dmaengine driver That way we are all okay and changes get merged now.. there is a 3rd option 3. Santosh picks ring driver patches, and Vinod picks rest after next rc1 (provided they make to linus in merge window) I would love to see either 1 or 2 whichever way folks are comfortable to deal with :) -- ~Vinod
