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]
Date:   Mon, 12 Oct 2020 15:05:09 +0300
From:   Peter Ujfalusi <peter.ujfalusi@...com>
To:     Vinod Koul <vkoul@...nel.org>
CC:     <dmaengine@...r.kernel.org>, Rob Herring <robh+dt@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 2/3] dmaengine: add peripheral configuration



On 12/10/2020 9.09, Vinod Koul wrote:
> On 09-10-20, 14:29, Peter Ujfalusi wrote:
>>
>>
>> On 09/10/2020 14.15, Vinod Koul wrote:
>>>>> If for any any reason subsequent txn is for different direction, I would
>>>>> expect that parameters are set again before prep_ calls
>>>>
>>>> But in DEV_TO_DEV?
>>>
>>> Do we support that :D
>>>
>>>> If we have two peripherals, both needs config:
>>>> p1_config and p2_config
>>>>
>>>> What and how would one use the single peripheral_config?
>>>
>>> Since the config is implementation specific, I do not think it limits.
>>> You may create
>>>
>>> struct peter_config {
>>>         struct p1_config;
>>>         struct p2_config;
>>> };
>>
>> The use case is:
>> MEM -DMA-> P1 -DMA-> P2
>> or
>> P2 -DMA-> P1 -DMA-> MEM
>> or
>> MEM -DMA-> P2
>> or
>> P2 -DMA-> MEM
>> or
>> MEM -DMA-> P1 -DMA-> MEM
>>
>> How would the DMA guess what it should do? How would the independent P1
>> and P2 would know how to set up the config?
> 
> As I said, we do not support DEV_TO_DEV yet :)
> 
> Question is how would p1<-->p2 look, will p1 initiate a DMA txn or p2..?
> who will configure these..

That's a good question, I have not really thought about that.
If we have MEM in the picture, then it is a bit cleaner, but I would guess.

> Do you have a real world example in horizon...

In j721e we have AASRC module which needs special PDMA configuration to
match with it's setup, AASRC can be chained with McASP, which in turn
have different type of PDMA.

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Powered by blists - more mailing lists