On 15-01-20, 11:44, Peter Ujfalusi wrote:

On 14/01/2020 20.06, santosh.shilimkar@oracle.com wrote:

quoted

quoted

quoted

quoted

quoted

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.

quoted

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.

quoted

quoted

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel