From: Vinod Koul <vkoul@kernel.org>
To: Lizhi Hou <lizhi.hou@amd.com>
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: Sat, 5 Nov 2022 12:47:51 +0530 [thread overview]
Message-ID: <Y2YOHx3RBJxdx9xz@matsya> (raw)
In-Reply-To: <e1244ca1-18bd-d6c9-6101-9b20940fda72@amd.com>
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
> > > > > +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?
--
~Vinod
next prev parent reply other threads:[~2022-11-05 7:18 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 [this message]
2022-11-08 17:55 ` Lizhi Hou
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=Y2YOHx3RBJxdx9xz@matsya \
--to=vkoul@kernel.org \
--cc=brian.xu@amd.com \
--cc=dmaengine@vger.kernel.org \
--cc=larry.liu@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizhi.hou@amd.com \
--cc=max.zhen@amd.com \
--cc=sonal.santan@amd.com \
--cc=trix@redhat.com \
--cc=tumic@gpxsee.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