[QUERY]: RZ/Five (AX45MP) non-coherent DMA

Heiko Stübner heiko at sntech.de
Fri Nov 4 16:07:00 PDT 2022


Hi Prabhakar,

Am Freitag, 4. November 2022, 23:09:15 CET schrieb Lad, Prabhakar:
> When trying to add non coherent DMA support for the RZ/Five SoC, I was
> suggested to use the ALTERNATIVE() macro [0].
> 
> My initial intention was to implement the alternative_call_x()
> something like what x86 has and from there call the C function, So
> while doing some experiments I realized that using the asm "call
> <func>" would cause adding the whole lot of registers in the clobbers
> list.
> 
> As per my understanding the only correct approach to
> alternative_call_x() is if the function itself is inline assembly then
> we know the exact registers being used and then we could add them
> appropriately in the clobbers list.

I'm working in a quite similar area right now and I've Cc'ed you on a
RFC series when I'm also worked on makeing call work in alternatives.

As you noted, using assembler for the call'ed function makes things
way easier to handle.

> The problem with the above approach being we have quite a lot of C
> code [1] for the CMO and it also requires some register writes of the
> l2 cache controller, converting this to assembly would be a pain.
> 
> * Is my understanding correct?
> * Is there any other approach I am missing?
> * Is there no way out apart from implementing inline asm?

In the inline-asm part that will form the alternative, can you
not just save and restore the registers manually around the
actual call?

ALTERNATIVE(
[1] ... nops ...,
[2] ... CMO ...,
[3] ... THEAD ...,
[4] save registers to stack
    call ax45mp dma-func
    restore registers from stack

That way you would no incur many penalties to the other alternatives
I think.


Heiko

> [0] https://patchwork.kernel.org/project/linux-riscv/cover/20221019220242.4746-1-prabhakar.mahadev-lad.rj@bp.renesas.com/
> [1] https://patchwork.kernel.org/project/linux-riscv/patch/20221019220242.4746-3-prabhakar.mahadev-lad.rj@bp.renesas.com/
> 
> Cheers,
> Prabhakar







More information about the linux-riscv mailing list