From: Lizhi Hou <lizhi.hou@amd.com>
To: Vinod Koul <vkoul@kernel.org>
Cc: <dmaengine@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<trix@redhat.com>, <tumic@gpxsee.org>, <max.zhen@amd.com>,
<sonal.santan@amd.com>, <larry.liu@amd.com>, <brian.xu@amd.com>
Subject: Re: [PATCH V9 XDMA 1/2] dmaengine: xilinx: xdma: Add xilinx xdma driver
Date: Tue, 8 Nov 2022 09:55:48 -0800 [thread overview]
Message-ID: <7600d6a0-79ab-143d-28c8-77320d7ba12c@amd.com> (raw)
In-Reply-To: <Y2YOHx3RBJxdx9xz@matsya>
On 11/5/22 00:17, Vinod Koul wrote:
> On 04-11-22, 11:17, Lizhi Hou wrote:
>> On 11/4/22 10:57, Vinod Koul wrote:
>>> On 04-11-22, 09:57, Lizhi Hou wrote:
>>>> On 11/4/22 07:32, Vinod Koul wrote:
>>>>> On 25-10-22, 10:57, Lizhi Hou wrote:
>>>>>> +static inline int xdma_write_reg(struct xdma_device *xdev, u32 base, u32 reg,
>>>>>> + u32 val)
>>>>>> +{
>>>>>> + return regmap_write(xdev->regmap, base + reg, val);
>>>>>> +}
>>>>> Do you really need one more level indirection?
>>>> Do you mean using readl / writel instead of regmap_* here?
>>> Nope, I refer to using regmap_write() intead of xdma_write_reg()
>> Ok. As you mentioned below,
>>
>> why not move err into xdma_write_reg(), rather than adding in each
>> helper!
>>
>> If I use regmap_write() directly, I will not be able to move err into
>> xdma_write_reg(). Having a inline function might be useful to add debug
>> code. May I keep xdma_write_reg()?
> Okay, either way if xdma_write_reg() is doing only regmap_write() then
> no, if it has extra logic like logging on error etc then it makes sense
Got it. Thanks. :)
>
>>>>>> +failed:
>>>>>> + xdma_free_desc(&sw_desc->vdesc);
>>>>> who will free sw_desc here?
>>>> sw_desc is freed by xdma_free_desc(). xdma_free_desc() is virt-dma callback
>>>> it converts struct virt_dma_desc pointer to driver sw_desc pointer and free
>>>> the whole thing.
>>> IN case of error, you are returning NULL, so allocated descriptor leaks
>> I meant the descriptor is freed inside xdma_free_desc() which is called
>> before 'return NULL'.
>>
>> xdma_free_desc(struct virt_dma_desc *vdesc)
>>
>> {
>>
>> sw_desc = to_xdma_desc(vdesc);
>>
>> .....
>>
>> kfree(sw_desc);
>>
>> }
> ok
>
>>>>>> +#ifndef _PLATDATA_AMD_XDMA_H
>>>>>> +#define _PLATDATA_AMD_XDMA_H
>>>>>> +
>>>>>> +#include <linux/dmaengine.h>
>>>>>> +
>>>>>> +/**
>>>>>> + * struct xdma_chan_info - DMA channel information
>>>>>> + * This information is used to match channel when request dma channel
>>>>>> + * @dir: Channel transfer direction
>>>>>> + */
>>>>>> +struct xdma_chan_info {
>>>>>> + enum dma_transfer_direction dir;
>>>>>> +};
>>>>>> +
>>>>>> +#define XDMA_FILTER_PARAM(chan_info) ((void *)(chan_info))
>>>>>> +
>>>>>> +struct dma_slave_map;
>>>>>> +
>>>>>> +/**
>>>>>> + * struct xdma_platdata - platform specific data for XDMA engine
>>>>>> + * @max_dma_channels: Maximum dma channels in each direction
>>>>>> + */
>>>>>> +struct xdma_platdata {
>>>>>> + u32 max_dma_channels;
>>>>>> + u32 device_map_cnt;
>>>>>> + struct dma_slave_map *device_map;
>>>>>> +};
>>>>> why do you need this plat data
>>>> max_dma_channels is used to specify the maximum dma channels will be used.
>>> What is the device mode, who creates this dma device, devicetree or
>>> something else?
>> This dma engine is on PCI device (exposed on PCI BAR). Thus, the pci device
>> driver creates this dma device.
> So it is a platform_device type? Why not make it something like auxdev?
With our FPGA device, the XDMA IP is populated by flattened device tree.
Using platform device will support both device tree and non-dt case.
Thanks,
Lizhi
>
next prev parent reply other threads:[~2022-11-08 17:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-25 17:57 [PATCH V9 XDMA 0/2] xilinx XDMA driver Lizhi Hou
2022-10-25 17:57 ` [PATCH V9 XDMA 1/2] dmaengine: xilinx: xdma: Add xilinx xdma driver Lizhi Hou
2022-11-04 14:32 ` Vinod Koul
2022-11-04 16:57 ` Lizhi Hou
2022-11-04 17:57 ` Vinod Koul
2022-11-04 18:17 ` Lizhi Hou
2022-11-05 7:17 ` Vinod Koul
2022-11-08 17:55 ` Lizhi Hou [this message]
2022-11-14 16:55 ` Lizhi Hou
2022-10-25 17:57 ` [PATCH V9 XDMA 2/2] dmaengine: xilinx: xdma: Add user logic interrupt support Lizhi Hou
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=7600d6a0-79ab-143d-28c8-77320d7ba12c@amd.com \
--to=lizhi.hou@amd.com \
--cc=brian.xu@amd.com \
--cc=dmaengine@vger.kernel.org \
--cc=larry.liu@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=max.zhen@amd.com \
--cc=sonal.santan@amd.com \
--cc=trix@redhat.com \
--cc=tumic@gpxsee.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