All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eugeniy.Paltsev@synopsys.com (Eugeniy Paltsev)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH v3 0/3] dmaengine: DW DMAC: split pdata to hardware properties
Date: Tue, 8 Nov 2016 12:22:51 +0000	[thread overview]
Message-ID: <1478607771.2603.31.camel@synopsys.com> (raw)
In-Reply-To: <1478526908.5295.67.camel@linux.intel.com>

On Mon, 2016-11-07@15:55 +0200, Andy Shevchenko wrote:
>?
> Thanks for an update, but, please, answer to all my comments to your
> patch v2. Either you are okay with them, then you didn't address few,
> or
> you are not okay, I didn't get why. Deffer newer version until we get
> an
> agreement on the implementation.
>?

Thanks for response.
My comments are given inline?below.


---
> > Changes for v2:
> >????- use separate bool values for quirks in "dw_dma_platform_data"
> > instead of
> >??????common bit field.
> >?
> >????- convert device tree properties reading to unified device
> > property
> > API.
> This should be a separate patch.
>?
Agree. Implemented as?separate patch in?PATCH v3 series.

> >?
> >?
> > I was wrong about DW_DMA_IS_SOFT_LLP flag - it is used to check
> > about
> > ongoing soft llp transfer. So DW_DMA_IS_SOFT_LLP flag and "dwc-
> > >?
> > > nollp"?
> > variable have different functions and I couldn't just get rid of
> > "dwc-
> > >?
> > > nollp"
> > and use DW_DMA_IS_SOFT_LLP flag instead. So I left "dwc->nollp"
> > untouched.
> So, then perhaps we may convert it to another flag let's say
> DW_DMA_IS_LLP_SUPPORTED.
>?
> But this is other story independent of the subject.

Implemented in?PATCH v3 series.?
"dwc->nollp" was converted to "DW_DMA_IS_LLP_SUPPORTED" flag.

> >?
> > --- a/drivers/dma/dw/core.c
> > +++ b/drivers/dma/dw/core.c
> > @@ -1452,9 +1452,24 @@ int dw_dma_probe(struct dw_dma_chip *chip)
> >??	dw->regs = chip->regs;
> >??	chip->dw = dw;
> >??
> > +	/* Reassign the platform data pointer */
> > +	pdata = dw->pdata;
> > +
> >??	pm_runtime_get_sync(chip->dev);
> >??
> > -	if (!chip->pdata) {
> > +	if ((!chip->pdata) || (chip->pdata && chip->pdata-
> > >?
> > > only_quirks_used)) {
> It's simple as
> if (!chip->pdata || chip->pdata->only_quirks_used)
>?
> > ?[--sources--]
> >?
> Would we leave the first part in the place it is now and add new
> piece
> after?
>?
> > [--sources--]
> >?
> ...like
>?
> /* Apply platform defined quirks */
> if (chip->data && chip->data->only_quirks_used) {
>??...
> }
Agree. That looks better.

>?
> >?
> > -	if (of_property_read_u32(np, "dma-channels",
> > &nr_channels))
> > -		return NULL;
> > +	if (device_property_read_bool(dev, "is-private"))
> As I mentioned above, please do a separate patch for this.
Implemented as?separate patch in?PATCH v3 series.?

>?
> >?
> > @@ -183,7 +186,7 @@ static int dw_probe(struct platform_device
> > *pdev)
> >??
> >??	pdata = dev_get_platdata(dev);
> >??	if (!pdata)
> > -		pdata = dw_dma_parse_dt(pdev);
> > +		pdata = dw_dma_parse_dt(dev);
> Perhaps you might rename the function to something like
>?
> dw_dma_parse_properties(dev);
Implemented in?PATCH v3 series.

>?
> >?
> > + * @only_quirks_used: Only read quirks (like "is_private" or
> > "is_memcpy") from
> > + *	platform data structure. Read other parameters from
> > device
> > tree
> > + *	node (if exists) or from hardware autoconfig registers.
> Can you somehow be more clear that all listed quirks will be copied
> from
> platform data.
See?comment below.

>?
> >?
> >???* @is_nollp: The device channels does not support multi block
> > transfers.
> >???* @chan_allocation_order: Allocate channels starting from 0 or 7
> >???* @chan_priority: Set channel priority increasing from 0 to 7 or
> > 7
> > to 0.
> > @@ -52,6 +55,7 @@ struct dw_dma_platform_data {
> >??	unsigned int	nr_channels;
> >??	bool		is_private;
> >??	bool		is_memcpy;
> >?
> > +	bool		only_quirks_used;
> Perhaps add if at the end of quirk list and name just?
>?
> >?
> >??	bool		is_nollp;
> ...here
>?
> bool use_quirks;
>?

I don't treat "is_nollp" as quirks like "is_private" or "is_memcpy".
It is like general pdata field: we can easily?read it from autoconfig
registers (and we don't have any problem with that) in case of
pdata/device-tree absence (as opposed to quirks like "is_private" or
"is_memcpy")

So, in PATCH v3 series "is_nollp" used as regular pdata field.

--?
?Paltsev Eugeniy

WARNING: multiple messages have this Message-ID (diff)
From: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
To: "andriy.shevchenko@linux.intel.com"  <andriy.shevchenko@linux.intel.com>
Cc: "dan.j.williams@intel.com" <dan.j.williams@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Eugeniy.Paltsev@synopsys.com" <Eugeniy.Paltsev@synopsys.com>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	"vinod.koul@intel.com" <vinod.koul@intel.com>,
	"vireshk@kernel.org" <vireshk@kernel.org>,
	"linux-snps-arc@lists.infradead.org" 
	<linux-snps-arc@lists.infradead.org>
Subject: Re: [PATCH v3 0/3] dmaengine: DW DMAC: split pdata to hardware properties
Date: Tue, 8 Nov 2016 12:22:51 +0000	[thread overview]
Message-ID: <1478607771.2603.31.camel@synopsys.com> (raw)
In-Reply-To: <1478526908.5295.67.camel@linux.intel.com>

On Mon, 2016-11-07 at 15:55 +0200, Andy Shevchenko wrote:
> 
> Thanks for an update, but, please, answer to all my comments to your
> patch v2. Either you are okay with them, then you didn't address few,
> or
> you are not okay, I didn't get why. Deffer newer version until we get
> an
> agreement on the implementation.
> 

Thanks for response.
My comments are given inline below.


---
> > Changes for v2:
> >    - use separate bool values for quirks in "dw_dma_platform_data"
> > instead of
> >      common bit field.
> > 
> >    - convert device tree properties reading to unified device
> > property
> > API.
> This should be a separate patch.
> 
Agree. Implemented as separate patch in PATCH v3 series.

> > 
> > 
> > I was wrong about DW_DMA_IS_SOFT_LLP flag - it is used to check
> > about
> > ongoing soft llp transfer. So DW_DMA_IS_SOFT_LLP flag and "dwc-
> > > 
> > > nollp" 
> > variable have different functions and I couldn't just get rid of
> > "dwc-
> > > 
> > > nollp"
> > and use DW_DMA_IS_SOFT_LLP flag instead. So I left "dwc->nollp"
> > untouched.
> So, then perhaps we may convert it to another flag let's say
> DW_DMA_IS_LLP_SUPPORTED.
> 
> But this is other story independent of the subject.

Implemented in PATCH v3 series. 
"dwc->nollp" was converted to "DW_DMA_IS_LLP_SUPPORTED" flag.

> > 
> > --- a/drivers/dma/dw/core.c
> > +++ b/drivers/dma/dw/core.c
> > @@ -1452,9 +1452,24 @@ int dw_dma_probe(struct dw_dma_chip *chip)
> >  	dw->regs = chip->regs;
> >  	chip->dw = dw;
> >  
> > +	/* Reassign the platform data pointer */
> > +	pdata = dw->pdata;
> > +
> >  	pm_runtime_get_sync(chip->dev);
> >  
> > -	if (!chip->pdata) {
> > +	if ((!chip->pdata) || (chip->pdata && chip->pdata-
> > > 
> > > only_quirks_used)) {
> It's simple as
> if (!chip->pdata || chip->pdata->only_quirks_used)
> 
> >  [--sources--]
> > 
> Would we leave the first part in the place it is now and add new
> piece
> after?
> 
> > [--sources--]
> > 
> ...like
> 
> /* Apply platform defined quirks */
> if (chip->data && chip->data->only_quirks_used) {
>  ...
> }
Agree. That looks better.

> 
> > 
> > -	if (of_property_read_u32(np, "dma-channels",
> > &nr_channels))
> > -		return NULL;
> > +	if (device_property_read_bool(dev, "is-private"))
> As I mentioned above, please do a separate patch for this.
Implemented as separate patch in PATCH v3 series. 

> 
> > 
> > @@ -183,7 +186,7 @@ static int dw_probe(struct platform_device
> > *pdev)
> >  
> >  	pdata = dev_get_platdata(dev);
> >  	if (!pdata)
> > -		pdata = dw_dma_parse_dt(pdev);
> > +		pdata = dw_dma_parse_dt(dev);
> Perhaps you might rename the function to something like
> 
> dw_dma_parse_properties(dev);
Implemented in PATCH v3 series.

> 
> > 
> > + * @only_quirks_used: Only read quirks (like "is_private" or
> > "is_memcpy") from
> > + *	platform data structure. Read other parameters from
> > device
> > tree
> > + *	node (if exists) or from hardware autoconfig registers.
> Can you somehow be more clear that all listed quirks will be copied
> from
> platform data.
See comment below.

> 
> > 
> >   * @is_nollp: The device channels does not support multi block
> > transfers.
> >   * @chan_allocation_order: Allocate channels starting from 0 or 7
> >   * @chan_priority: Set channel priority increasing from 0 to 7 or
> > 7
> > to 0.
> > @@ -52,6 +55,7 @@ struct dw_dma_platform_data {
> >  	unsigned int	nr_channels;
> >  	bool		is_private;
> >  	bool		is_memcpy;
> > 
> > +	bool		only_quirks_used;
> Perhaps add if at the end of quirk list and name just 
> 
> > 
> >  	bool		is_nollp;
> ...here
> 
> bool use_quirks;
> 

I don't treat "is_nollp" as quirks like "is_private" or "is_memcpy".
It is like general pdata field: we can easily read it from autoconfig
registers (and we don't have any problem with that) in case of
pdata/device-tree absence (as opposed to quirks like "is_private" or
"is_memcpy")

So, in PATCH v3 series "is_nollp" used as regular pdata field.

-- 
 Paltsev Eugeniy

  reply	other threads:[~2016-11-08 12:22 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-28 15:59 [PATCH v3 0/3] dmaengine: DW DMAC: split pdata to hardware properties Eugeniy Paltsev
2016-10-28 15:59 ` Eugeniy Paltsev
2016-10-28 16:00 ` [PATCH v3 1/3] dmaengine: DW DMAC: split pdata to hardware properties and platform quirks Eugeniy Paltsev
2016-10-28 16:00   ` Eugeniy Paltsev
2016-10-28 16:00 ` [PATCH v3 2/3] dmaengine: DW DMAC: convert to unified device property API Eugeniy Paltsev
2016-10-28 16:00   ` Eugeniy Paltsev
2016-10-28 16:00 ` [PATCH v3 3/3] dmaengine: DW DMAC: move "nollp" to "dwc->flags" Eugeniy Paltsev
2016-10-28 16:00   ` Eugeniy Paltsev
2016-10-28 16:15 ` [PATCH v3 0/3] dmaengine: DW DMAC: split pdata to hardware properties Andy Shevchenko
2016-10-28 16:15   ` Andy Shevchenko
2016-11-02 11:55 ` Eugeniy Paltsev
2016-11-02 11:55   ` Eugeniy Paltsev
2016-11-07 13:55   ` Andy Shevchenko
2016-11-07 13:55     ` Andy Shevchenko
2016-11-08 12:22     ` Eugeniy Paltsev [this message]
2016-11-08 12:22       ` Eugeniy Paltsev
2016-11-08 13:36       ` Andy Shevchenko
2016-11-08 13:36         ` Andy Shevchenko
2016-11-10 16:28         ` Eugeniy Paltsev
2016-11-10 16:28           ` Eugeniy Paltsev
2016-11-11 11:05           ` Andy Shevchenko
2016-11-11 11:05             ` Andy Shevchenko

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=1478607771.2603.31.camel@synopsys.com \
    --to=eugeniy.paltsev@synopsys.com \
    --cc=linux-snps-arc@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.