[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190123125533.GP4635@vkoul-mobl>
Date: Wed, 23 Jan 2019 18:25:33 +0530
From: Vinod Koul <vkoul@...nel.org>
To: John Stultz <john.stultz@...aro.org>
Cc: lkml <linux-kernel@...r.kernel.org>,
Youlin Wang <wwx575822@...esmail.huawei.com>,
Dan Williams <dan.j.williams@...el.com>,
Zhuangluan Su <suzhuangluan@...ilicon.com>,
Ryan Grachek <ryan@...ted.us>,
Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
"open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM"
<dmaengine@...r.kernel.org>, Tanglei Han <hantanglei@...wei.com>
Subject: Re: [PATCH 3/8 v4] dma: k3dma: Upgrade k3dma driver to support
hisi_asp_dma hardware
On 22-01-19, 15:48, John Stultz wrote:
> On Sun, Jan 20, 2019 at 3:12 AM Vinod Koul <vkoul@...nel.org> wrote:
> >
> > On 16-01-19, 09:10, John Stultz wrote:
> > > From: Youlin Wang <wwx575822@...esmail.huawei.com>
> > >
> > > On the hi3660 hardware there are two (at least) DMA controllers,
> > > the DMA-P (Peripherial DMA) and the DMA-A (Audio DMA). The
> > ^^^
> > typo
>
> Thanks so much for the review!
>
> Fixed!
>
> > > +
> > > +#define K3_FLAG_NOCLK (1<<0)
> >
> > why not use BIT()
> >
> > space between two please
>
> Fixed.
>
> > > +static const struct k3dma_soc_data k3_v1_dma_data = {
> > > + .flags = 0,
> > > +};
> >
> > So basically this is default right, do we need to set dma_data and not
> > assume default..
>
> I'm not sure I fully understand you here. Basically I'm just creating
> a per-variant data structure. The k3_v1_dma_data isn't really the
> default, but is the first variant supported. There may be future
> variants that cause some new flag that the k3_v3_dma_data may need to
> set. But for now that variant doesn't have any flags set.
So my point was we can skip this and treat driver data NULL as default
i.e. no flags, no big deal though, saves you dummy k3_v1_dma_data.
>
>
> > > +
> > > +static const struct k3dma_soc_data asp_v1_dma_data = {
> > > + .flags = K3_FLAG_NOCLK,
> > > +};
> > > +
> > > static const struct of_device_id k3_pdma_dt_ids[] = {
> > > - { .compatible = "hisilicon,k3-dma-1.0", },
> > > + { .compatible = "hisilicon,k3-dma-1.0",
> > > + .data = &k3_v1_dma_data
> > > + },
> > > + { .compatible = "hisilicon,hisi-pcm-asp-dma-1.0",
> > > + .data = &asp_v1_dma_data
> > > + },
> > > {}
> > > };
> > > MODULE_DEVICE_TABLE(of, k3_pdma_dt_ids);
> > > @@ -810,6 +830,7 @@ static struct dma_chan *k3_of_dma_simple_xlate(struct of_phandle_args *dma_spec,
> > >
> > > static int k3_dma_probe(struct platform_device *op)
> > > {
> > > + const struct k3dma_soc_data *soc_data;
> > > struct k3_dma_dev *d;
> > > const struct of_device_id *of_id;
> > > struct resource *iores;
> > > @@ -823,6 +844,10 @@ static int k3_dma_probe(struct platform_device *op)
> > > if (!d)
> > > return -ENOMEM;
> > >
> > > + soc_data = device_get_match_data(&op->dev);
> > > + if (!soc_data)
> > > + return -EINVAL;
> >
> > So this is not optional, either ways fine by me :)
>
> I think this way makes sense, but maybe I'm missing a better alternative?
>
> Do let me know if there's an example you'd rather I follow.
To elaborate I was thinking of alternate scheme with:
compatible = "hisilicon,k3-dma-1.0", NULL
compatible = "hisilicon,hisi-pcm-asp-dma-1.0", .data = &asp_v1_dma_data
and
soc_data = device_get_match_data(&op->dev);
if (!soc_data) {
/* no data so flags are null */
dev_warn(... "no driver data specified, assuming no flags\n"
k3_dma->flags = 0;
}
--
~Vinod
Powered by blists - more mailing lists