On Tue, Oct 15, 2019 at 12:29 PM Peter Ujfalusi [off-list ref] wrote:

Rob,

On 10/11/19 10:30 AM, Peter Ujfalusi wrote:

quoted

I have already moved the TR vs Packet mode channel selection, which does
make sense as it was Linux's choice to use TR for certain cases.

If I move these to code then we need to have big tables
struct psil_config am654_psil[32767] = {};
struct psil_config j721e_psil[32767] = {};

After thinking about this a bit more, I think we can move all the PSI-L
endpoint configuration to the kernel as not all the 32767 threads are
actually in use. Sure it is going to be some amount of static data in
the kernel, but it is an acceptable compromise.

The DMA binding can look like this:

dmas = <&main_udmap 0xc400>,
       <&main_udmap 0x4400>;
dma-names = "tx", "rx";

or
dmas = <&main_udmap 0x4400 UDMA_DIR_TX>,
       <&main_udmap 0x4400 UDMA_DIR_RX>;
dma-names = "tx", "rx";

If I keep the direction.
0xc400 is destination ID, which is 0x4400 | 0x8000 as per PSI-L
specification.
In the TRM only the source threads can be found as a map (thread IDs <
0x7fff), but the binding document can cover this.

This way we don't need another dtsi file and I can create the map in the
kernel.

This will hide some details of the HW from DT, but since the PSI-L
thread configuration is static in hardware I believe it is acceptable.

However we still have uncovered features in the binding or in code, like
a case when the RX does not have access to the DMA channel, only flows.
Not sure if I should reserve the direction parameter as an indication to
this or find other way.
Basically we communicate on the given PSI-L thread without having a DMA
channel as other core is owning the channel.

What do you think?

Seems like a reasonable solution though I don't really follow the last issue.

Rob

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