From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: "Reddy, MallikarjunaX" <mallikarjunax.reddy@linux.intel.com>,
<dmaengine@vger.kernel.org>, <vkoul@kernel.org>,
<devicetree@vger.kernel.org>, <robh+dt@kernel.org>
Cc: <linux-kernel@vger.kernel.org>, <andriy.shevchenko@intel.com>,
<cheol.yong.kim@intel.com>, <qi-ming.wu@intel.com>,
<chuanhua.lei@linux.intel.com>, <malliamireddy009@gmail.com>
Subject: Re: [PATCH v5 2/2] Add Intel LGM soc DMA support.
Date: Fri, 28 Aug 2020 14:17:06 +0300 [thread overview]
Message-ID: <831fadff-8127-7634-32be-0000e69e0d94@ti.com> (raw)
In-Reply-To: <51ed096a-d211-9bab-bf1e-44f912b2a20e@linux.intel.com>
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
next prev parent reply other threads:[~2020-08-28 14:06 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-14 5:26 [PATCH v5 0/2] Add Intel LGM soc DMA support Amireddy Mallikarjuna reddy
2020-08-14 5:26 ` [PATCH v5 1/2] dt-bindings: dma: Add bindings for intel LGM SOC Amireddy Mallikarjuna reddy
2020-08-14 20:32 ` Rob Herring
2020-08-18 7:00 ` Reddy, MallikarjunaX
2020-08-25 11:21 ` Vinod Koul
2020-08-27 9:54 ` Reddy, MallikarjunaX
2020-08-28 10:45 ` Vinod Koul
2020-08-31 8:06 ` Reddy, MallikarjunaX
2020-08-31 11:00 ` Vinod Koul
2020-09-01 15:03 ` Reddy, MallikarjunaX
2020-09-04 6:31 ` Peter Ujfalusi
2020-09-07 7:25 ` Reddy, MallikarjunaX
2020-08-14 5:26 ` [PATCH v5 2/2] Add Intel LGM soc DMA support Amireddy Mallikarjuna reddy
2020-08-14 8:47 ` kernel test robot
2020-08-18 10:16 ` Peter Ujfalusi
2020-08-18 10:29 ` Peter Ujfalusi
2020-08-24 2:30 ` Reddy, MallikarjunaX
2020-08-24 11:24 ` Peter Ujfalusi
2020-08-27 14:41 ` Reddy, MallikarjunaX
2020-08-28 11:17 ` Peter Ujfalusi [this message]
2020-08-31 8:07 ` Reddy, MallikarjunaX
2020-09-04 6:31 ` Peter Ujfalusi
2020-09-07 7:32 ` Reddy, MallikarjunaX
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=831fadff-8127-7634-32be-0000e69e0d94@ti.com \
--to=peter.ujfalusi@ti.com \
--cc=andriy.shevchenko@intel.com \
--cc=cheol.yong.kim@intel.com \
--cc=chuanhua.lei@linux.intel.com \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=malliamireddy009@gmail.com \
--cc=mallikarjunax.reddy@linux.intel.com \
--cc=qi-ming.wu@intel.com \
--cc=robh+dt@kernel.org \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).