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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <f7ddd927-5db3-e1b1-b7f1-94050b508298@st.com>
Date:   Mon, 21 Aug 2017 11:34:15 +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/04/2017 04:21 PM, Peter Ujfalusi wrote:
> On 08/04/2017 03:50 PM, Pierre Yves MORDRET wrote:
>> Our DMAMUX can manage up to 255 request lines (only 128 is eventually assigned
>> though) onto 16 events: 8 events mapped on 1 DMA and the 8 others onto the
>> second DMA. Request line numbering is fixed (a peripheral DMA request is
>> assigned to one MUX input) and but can be routed randomly onto the any 16
>> channels. We use chanID to mux input on event.
>> chanID given by dma_get_any_slave_channe is enough in our case.
> 
> I would think that if you have in the router node:
> dma-masters = <&dma1>, <&dma2>;
> 
> and request a DMA via the router:
> dmas = <&dma_router req_in param1 param2>;
> 
> then the router driver would decide which dma-master it is going to assign the
> given request line and craft the dma-spec based on this decision. This
> requires no callback to the router from the DMA master driver at all.
> 
> The idea of the dma event router is to be transparent for the DMA clients
> (peripherals needing DMA channel) and for the DMA drivers as well. Neither
> should know that the events are muxed as it does not really matter for them.
>

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.

Regards
PY