linux-kernel - Re: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ea66ba14-fe18-cb83-5989-8ae7b3ab50c6@st.com>
Date:   Thu, 24 Aug 2017 15:03:30 +0200
From:   Pierre Yves MORDRET <pierre-yves.mordret@...com>
To:     Peter Ujfalusi <peter.ujfalusi@...com>,
        Vinod Koul <vinod.koul@...el.com>
CC:     Mark Rutland <mark.rutland@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Amelie DELAUNAY <amelie.delaunay@...com>,
        Alexandre TORGUE <alexandre.torgue@...com>,
        Russell King <linux@...linux.org.uk>,
        Fabien DESSENNE <fabien.dessenne@...com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        "M'boumba Cedric Madianga" <cedric.madianga@...il.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Fabrice GASNIER <fabrice.gasnier@...com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver

On 08/24/2017 07:47 AM, Peter Ujfalusi wrote:
> 
> 
> On 2017-08-21 12:34, Pierre Yves MORDRET wrote:
>> OK. I will redesign my driver to take into account this idea.
>>
>> I believe I should get rid of my custom API in DMA for channelID as well. Please
>> confirm. Not very clear for me whether I can keep it or not.
> 
> Yes, you should be able to get rid of any custom API.
> The DMA event router should be 'invisible' to both the DMA driver itself
> and for the DMA users as well. If you end up still needing custom API
> (which I doubt) then it is better to extend the core support to cover
> that in a generic way since it is likely that other might have similar
> needs.
> 

Will see that later on :)

> You need to identify what you need to manage with the DMA router, again
> in my cases:
> am335x/am437x: The DMA channel is fixed, but the DMA event to be handled
> by the channel (DMA event muxer) is selected by the router.
> dra7x: The DMA event is the fixed part and I needed to translate that to
> local eDMA/sDMA events and in eDMA I needed to pick a channel based on
> the translated event.
> 
> The same router code works for eDMA and sDMA in dra7, while the two DMA
> engines are different in their internal works.
> 
> At the end of the day I only needed to plug the DMA event routers and
> there is no change in the DMA drivers at all.
> 

Please tell me whether I'm wrong but for am335x/am437x both DMA Channels and
events are given by DT. I believe IP Spec provides the mapping for the channel
(this is what you call fixed channel) and DMA router event is selected randomly
within the DT.
As for dra7 events comes from DT but channel is selected though out local
algorithm. IP Spec defines DMA event muxer mapping.

At my opinion my router is more closed to dra7. IP Spec defines event mapping.
Nonetheless the DMA has a fixed allocated mapping. Using DMA alone DT has to
provide channel number. In router mode this number doesn't matter since router
makes the routing from fixed event to channel. However router needs to know
which channel will be assign to event: any random channel is allowed.

I'm pretty sure I can mimic what has been for DRA7 related to DMA Channel
allocation however it seems to be this is aside DMA engine. This kind of
implementation forbid the use of DMA and DMA router at the same time : I
remember you already raise the point. If a DMA channel is requested DMA router
is not aware of this allocation. This is the idea of my custom API which relies
on get_any_slave_channel().
Using DT to assign channel seems not a good idea either as I lost router's benefice.

BTW I need the channel ID within router.
Looking at core or of_dma_router_xlate() I don't really know how to do it a
generic manner.

Ideas are welcomed

> I'm happy to answer any questions you might have, if I can.
> 

You will be happy then.

> - Péter
> 

Thanks
Py