On 15-01-20, 11:44, Peter Ujfalusi wrote:
[...]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-rc1As suggested on other email to Peter, these DMA engine related patches
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.
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:
I have pushed the ring driver changes with an immutable tag and also pushed out to next. I will know if it breaks anything in a day.
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