[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALAqxLV35NGGR4xZ-yvqLDuEqzhKTBvjAjBU+xBnyiGSAycW7Q@mail.gmail.com>
Date: Fri, 4 Jan 2019 21:44:17 -0800
From: John Stultz <john.stultz@...aro.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc: lkml <linux-kernel@...r.kernel.org>,
Youlin Wang <wwx575822@...esmail.huawei.com>,
Dan Williams <dan.j.williams@...el.com>,
Vinod Koul <vkoul@...nel.org>,
Zhuangluan Su <suzhuangluan@...ilicon.com>,
Ryan Grachek <ryan@...ted.us>, dmaengine@...r.kernel.org,
Tanglei Han <hantanglei@...wei.com>
Subject: Re: [PATCH 3/8 v2] dma: k3dma: Upgrade k3dma driver to support
hisi_asp_dma hardware
On Fri, Jan 4, 2019 at 9:39 PM Manivannan Sadhasivam
<manivannan.sadhasivam@...aro.org> wrote:
>
> On Fri, Jan 04, 2019 at 09:22:46PM -0800, John Stultz wrote:
> > On Fri, Jan 4, 2019 at 7:42 PM Manivannan Sadhasivam
> > <manivannan.sadhasivam@...aro.org> wrote:
> > > On Fri, Jan 04, 2019 at 12:56:23PM -0800, John Stultz wrote:
> > > > From: Youlin Wang <wwx575822@...esmail.huawei.com>
> > > >
> > > > There is an new "hisi-pcm-asp-dma-1.0" device added in
> > > > "arch/arm64/boot/dts/hisilicon/hi3660.dtsi".
> > > > So we have to add a matching id in the driver file:
> > > > .compatible = "hisilicon,hisi-pcm-asp-dma-1.0"
> > > >
> > > > And also hisi-pcm-asp dma device needs no setting to the clock.
> > > > So we skip this by adding and using soc data flags.
> > > >
> > > > After above this driver will support both k3 and hisi_asp dma hardware.
> > > >
> > >
> > > Small description about the hardware (ASP DMAC) would be really helpful.
> >
> > I've taken a shot at this (along with integrating your other feedback
> > - thanks again for the review!), though as I don't have direct
> > documentation, my knowledge is a bit second hand.
> >
> > See here:
> > https://git.linaro.org/people/john.stultz/android-dev.git/commit/?h=dev/hikey960-mainline-WIP&id=754a79facf1af0b59a7f8fd63050da12ebf5521e
> >
> > Let me know if you have suggestions for more specific changes!
>
> Description looks good to me. But looks like you are not protecting the
> other clk APIs like clk_prepare_enable and clk_disable_unprepare. Don't
> they fail when the relevant clk is not found?
No, those calls just return 0 if null clock is passed
int clk_prepare(struct clk *clk)
{
if (!clk)
return 0;
...
thanks
-john
Powered by blists - more mailing lists