linux-kernel - Re: [PATCH v5 2/2] Add Intel LGM soc DMA support.

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: <831fadff-8127-7634-32be-0000e69e0d94@ti.com>
Date:   Fri, 28 Aug 2020 14:17:06 +0300
From:   Peter Ujfalusi <peter.ujfalusi@...com>
To:     "Reddy, MallikarjunaX" <mallikarjunax.reddy@...ux.intel.com>,
        <dmaengine@...r.kernel.org>, <vkoul@...nel.org>,
        <devicetree@...r.kernel.org>, <robh+dt@...nel.org>
CC:     <linux-kernel@...r.kernel.org>, <andriy.shevchenko@...el.com>,
        <cheol.yong.kim@...el.com>, <qi-ming.wu@...el.com>,
        <chuanhua.lei@...ux.intel.com>, <malliamireddy009@...il.com>
Subject: Re: [PATCH v5 2/2] Add Intel LGM soc DMA support.

Hi,

On 27/08/2020 17.41, Reddy, MallikarjunaX wrote:
>>>>> +
>>>>> +    dma_dev->device_alloc_chan_resources =
>>>>> +        d->inst->ops->device_alloc_chan_resources;
>>>>> +    dma_dev->device_free_chan_resources =
>>>>> +        d->inst->ops->device_free_chan_resources;
>>>>> +    dma_dev->device_terminate_all =
>>>>> d->inst->ops->device_terminate_all;
>>>>> +    dma_dev->device_issue_pending =
>>>>> d->inst->ops->device_issue_pending;
>>>>> +    dma_dev->device_tx_status = d->inst->ops->device_tx_status;
>>>>> +    dma_dev->device_resume = d->inst->ops->device_resume;
>>>>> +    dma_dev->device_pause = d->inst->ops->device_pause;
>>>>> +    dma_dev->device_config = d->inst->ops->device_config;
>>>>> +    dma_dev->device_prep_slave_sg =
>>>>> d->inst->ops->device_prep_slave_sg;
>>>>> +    dma_dev->device_synchronize = d->inst->ops->device_synchronize;
>>>>> +
>>>>> +    if (d->ver == DMA_VER22) {
>>>>> +        dma_dev->src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
>>>>> +        dma_dev->dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
>>>>> +        dma_dev->directions = BIT(DMA_MEM_TO_DEV) |
>>>>> +                      BIT(DMA_DEV_TO_MEM);
>>>>> +        dma_dev->residue_granularity =
>>>>> +                    DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
>>>>> +    }
>>>> So, if version is != DMA_VER22, then you don't support any direction?
>>>> Why register the DMA device if it can not do any transfer?
>>> Only dma0 instance (intel,lgm-cdma) is used as a general purpose slave
>>> DMA. we set both control and datapath here.
>>> Other instances we set only control path. data path is taken care by dma
>>> client(GSWIP).
>> How the client (GSWIP) can request a channel from intel,lgm-* ? Don't
>> you need some capabilities for the DMA device so core can sort out the
>> request?
> client request channel by name, dma_request_slave_channel(dev, name);

clients should use dma_request_chan(dev, name);

If the channel can be requested via DT or ACPI then we don't check the
capabilities at all, so yes, that could work.

>>> Only thing needs to do is get the channel, set the descriptor and just
>>> on the channel.
>> How do you 'on' the channel?
> we on the channel in issue_pending.

Right.
Basically you only prep_slave_sg/single for the DMA_VER22? Or do you
that for the others w/o direction support?

For the intel,lgm-* DMAs you only call issue_pending() and probably
terminate_all?

Interesting setup ;)

- Péter

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