lkml.org 
[lkml]   [2018]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v5 2/3] dmaengine: mediatek: Add MediaTek High-Speed DMA controller for MT7622 and MT7623 SoC
From
Date
Hi, Vinod

On Thu, 2018-03-01 at 18:26 +0530, Vinod Koul wrote:
> On Thu, Mar 01, 2018 at 06:27:01PM +0800, Sean Wang wrote:
> > On Thu, 2018-03-01 at 13:53 +0530, Vinod Koul wrote:
> > > On Sun, Feb 18, 2018 at 03:08:30AM +0800, sean.wang@mediatek.com wrote:
> > >
> > > > @@ -0,0 +1,1054 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > // Copyright ...
> > >
> > > The copyright line needs to follow SPDX tag line
> > >
> >
> > okay, I will make it reorder and be something like that
> >
> > // SPDX-License-Identifier: GPL-2.0
> > /*
> > * Copyright (c) 2017-2018 MediaTek Inc.
> > * Author: Sean Wang <sean.wang@mediatek.com>
> > *
> > * Driver for MediaTek High-Speed DMA Controller
> > *
> > */
>
> It needs to be:
>
> // SPDX-License-Identifier: GPL-2.0
> // Copyright (c) 2017-2018 MediaTek Inc.
>
> /*
> * whatever else you want
> */
>
> The first two lines are in C99 style comment and need to have SPDX tag and
> Copyright info

Sure, I can do it using C99 style comments at the first two lines.

In addition, I'm really curious where we can find a reference to the
rule and if it 's a strict rule for all the drivers.

Because I'm considering whether I should turn other driver into using
the same rule.

> > the point is I learned from other subsystem makes the driver name be
> > same with the module name with KBUILD_MODNAME.
> >
> > If you really don't like it, I can just change it into
> >
> > #define MTK_DMA_DEV "mtk-hsdma"
>
> It is used only once, why not use KBUILD_MODNAME directly?
>

Yup, it can use KBUILD_MODNAME directly.

> >
> > > > +
> > > > +#define MTK_HSDMA_USEC_POLL 20
> > > > +#define MTK_HSDMA_TIMEOUT_POLL 200000
> > > > +#define MTK_HSDMA_DMA_BUSWIDTHS BIT(DMA_SLAVE_BUSWIDTH_UNDEFINED)
> > >
> > > Undefined buswidth??
>
> ??

Sorry for I didn't answer the question in the short time.

After spending some time on a confirmation with design, it is
DMA_SLAVE_BUSWIDTH_4_BYTES and not be configurable.

>
> > > > +/**
> > > > + * struct mtk_hsdma_pdesc - This is the struct holding info describing physical
> > > > + * descriptor (PD) and its placement must be kept at
> > > > + * 4-bytes alignment in little endian order.
> > > > + * @desc[1-4]: The control pad used to indicate hardware how to
> > >
> > > pls align to 80char or lesser
> > >
> >
> > weird, it seems the line is already with 80 char and pass the
> > checkpatch.pl. or do I misunderstand something ?
>
> Okay please check. With text it helps to wrap before that
>

After check again, these lines are all already aligned to 80 chars

> > > > + /*
> > > > + * Updating into hardware the pointer of TX ring lets HSDMA to take
> > > > + * action for those pending PDs.
> > > > + */
> > > > + mtk_dma_write(hsdma, MTK_HSDMA_TX_CPU, ring->cur_tptr);
> > > > +
> > > > + spin_unlock_irqrestore(&hsdma->lock, flags);
> > > > +
> > > > + return !hvd->len ? 0 : -ENOSPC;
> > >
> > > you already wrote and started txn, so why this?
> > >
> >
> > it's possible just partial virtual descriptor fits into hardware and
> > then return -ENOSPC. And it will start it to complete the remaining part
> > as soon as possible when some rooms is being freed.
>
> Either ways you have issued the descriptor, so you succeed right?
>

I think I should get your points.

I guessed what you meant is that it should be returning 0 instead of
-ENOSPC for all successful descriptor issuing either in part or in full

I will refine this flow based on the thought.

> > > shouldn't we check if next is in range, we can crash if we get bad value
> > > from hardware..
> >
> > okay, there are checks for next with ddone bit check and null check in
> > the corresponding descriptor as the following.
>
> what if you get bad next value
>

next is not hardware value. it's maintained by software which is always
between 0 to MTK_DMA_SIZE - 1, and definitely doesn't get a bad value.

> >
> > > > + rxd = &pc->ring.rxd[next];
>
> resulting in bad ref here

rxd is also definitely a good ref


>


\
 
 \ /
  Last update: 2018-03-02 07:48    [W:0.074 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site