[QUERY]: RZ/Five (AX45MP) non-coherent DMA
Lad, Prabhakar
prabhakar.csengg at gmail.com
Sat Nov 5 15:41:24 PDT 2022
Hi Heiko,
On Fri, Nov 4, 2022 at 11:07 PM Heiko Stübner <heiko at sntech.de> wrote:
>
> 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.
>
Great!. I'll go through the series and take some inspiration from it.
> 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.
>
Agreed, thanks for the suggestion. I'll continue my investigation in
this direction.
Cheers,
Prabhakar
More information about the linux-riscv
mailing list