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

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

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

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