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]

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



On 08/02/2017 11:19 AM, Peter Ujfalusi wrote:
> 
> 
> On 2017-08-02 07:55, Vinod Koul wrote:
>> On Tue, Aug 01, 2017 at 09:32:50AM +0000, Pierre Yves MORDRET wrote:
>>>
>>>
>>> On 07/31/2017 02:31 PM, Vinod Koul wrote:
>>>> On Wed, Jul 26, 2017 at 07:38:02AM +0000, Pierre Yves MORDRET wrote:
>>>>>>>>> +
>>>>>>>>> +#ifndef __DMA_STM32_DMAMUX_H
>>>>>>>>> +#define __DMA_STM32_DMAMUX_H
>>>>>>>>> +
>>>>>>>>> +#if defined(CONFIG_STM32_DMAMUX)
>>>>>>>>> +int stm32_dmamux_set_config(struct device *dev, void *route_data, u32 chan_id);
>>>>>>>>
>>>>>>>> Why do we need a custom API in this case?
>>>>>>>>
>>>>>>>
>>>>>>> This API is called by DMA when a slave is requested by client. DMA can work
>>>>>>> without DMAMUX this API has been put in place to configure DMAMUX whether client
>>>>>>> is requesting a DMAMUX Channel instead of a DMA one.
>>>>>>
>>>>>> You mean the dmaengine driver right?
>>>>>>
>>>>>
>>>>> Yes. The API is mainly called by "device_config" through out STM32 DMA Driver
>>>>> when a router is in place for client.
>>>>> Please refer to Patch 4/5 on this set.
>>>>
>>>> Okay am thinking on why this can't be generic..? An optional router config
>>>> callback?
>>>>
>>>
>>> I would have liked to answer there is a callback within engine but unfortunately
>>> I didn't figure out one when I did my router's development. I've looked once
>>> more but again I can't find how to map chanID and request line without custom API.
>>
>> Yes there is no callback for routers but we can add a generic callback
>> here to be used. I added Peter for his comments, isn't that something they
>> need too?
> 
> The event router via of_dma_router_register() should be capable of 
> handling different type of muxers, like the ti-dma-crossbar.c is doing 
> for two different type of event crossbars.
> 
> Basically with the of_dma_route_allocate you craft a dma_spec which can 
> be understood by the dma-master pointed form the router's node.
> You do the configuration of the mux in this function, craft the dma_spec 
> and that's it. In DT the peripherals are using the router's node for DMA 
> binding and everything is transparent for them.
> 
> Note: The use of am335x xbar in the ti-dma-crossbar is optional and only 
> needed when we need to have different event than the default for a 
> specific dma request line.
> 
> If you normally use the DMA like this:
> dmas = <&edma 129 1>, <&ddma_xbar 128 1>;
> dma-names = "tx", "rx";
> 
> If you have DMA event router/mux, then depending on how it works you 
> might have different number of parameters. In my case the DRA7 crossbar 
> does not need extra parameter, so to get it in use:
> dmas = <&edma_xbar 129 1>, <&edma_xbar 128 1>;
> dma-names = "tx", "rx";
> 
> The router driver will rewrite the dma_spec and replace the 129/128 and 
> pass something different to the dma-master (dynamic event mapping).
> 
> On am335x we have different xbar type so there:
> 
> dmas = <&edma_xbar 12 0 1>, <&edma_xbar 13 0 2>;
> 
> Out from this the router driver will create a spec equivalent to
> dmas = <&edma_xbar 12 0>, <&edma_xbar 13 0>;
> 
> But it will change the xbar that DMA request 12/13 will not have the 
> default event routed to.
> 
> I believe that the dma_router infra we have in dmaengine can cover most 
> if not all use cases...
> 
> - Péter
> 

Our SoC works with or without DMAMUX. Both binding is allowed. Using only DMA a
ChannelId and request line is part of the binding. Using DMAMUx now the request
line is coming from dma_spec forwards to dma-master as well explained by Peter.
However ChannelID is now given by dma_get_any_slave_channel instead of bindings.
DMAMUX driver has to be aware of this ID to route request line to out DMA
channel. This channel id information is carried on until DMAMUX through
dmaengine_slave_config with a custom API.
Hope it clarifies the need.