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... > Regards, > Santosh - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
