linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Thu, 10 Nov 2016 16:28:29 +0000	[thread overview]
Message-ID: <1478795309.2603.55.camel@synopsys.com> (raw)
In-Reply-To: <1478612190.5295.92.camel@linux.intel.com>

On Tue, 2016-11-08 at 15:36 +0200, Andy Shevchenko wrote:
> On Tue, 2016-11-08 at 12:22 +0000, Eugeniy Paltsev wrote:
> > 
> > On Mon, 2016-11-07 at 15:55 +0200, Andy Shevchenko wrote:
>  
> > 
> > > 
> > > > 
> > > > + * @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;
> What do think about shorten name?
> 
I don't know better short and understandable name for "use_quirks"
variable. You can suggest your ideas if you want.

> > 
> > 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.
> I still would consider is_nollp as a quirk since nothing prevents to
> override the hardware value (see Intel Quark case).
> 
Do you mean this issue:
http://www.spinics.net/lists/linux-serial/msg22948.html
?

As I remember, we had problems with next code:
---------------------------->8--------------------------
channel_writel(dwc, LLP, DWC_LLP_LOC(0xffffffff));
dwc->nollp = DWC_LLP_LOC(channel_readl(dwc, LLP)) == 0;
channel_writel(dwc, LLP, 0);
---------------------------->8--------------------------
which was executed if we didn't use autoconfig registers.
This code doesn't used anymore.

And we don't have any problems with autoconfig registers!

So in case of Intel Quark we will read "nollp" parameter from pdata or
from autoconfig registers (in case of pdata absence). It should work
fine in both cases.
Please correct me if I'm wrong.

So, in my opinion, "is_nollp" should be used as regular pdata field.
-- 
 Paltsev Eugeniy

  reply	other threads:[~2016-11-10 16:28 UTC|newest]

Thread overview: 11+ 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 16:00 ` [PATCH v3 1/3] dmaengine: DW DMAC: split pdata to hardware properties and platform quirks 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 ` [PATCH v3 3/3] dmaengine: DW DMAC: move "nollp" to "dwc->flags" Eugeniy Paltsev
2016-10-28 16:15 ` [PATCH v3 0/3] dmaengine: DW DMAC: split pdata to hardware properties Andy Shevchenko
2016-11-02 11:55 ` Eugeniy Paltsev
2016-11-07 13:55   ` Andy Shevchenko
2016-11-08 12:22     ` Eugeniy Paltsev
2016-11-08 13:36       ` Andy Shevchenko
2016-11-10 16:28         ` Eugeniy Paltsev [this message]
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=1478795309.2603.55.camel@synopsys.com \
    --to=eugeniy.paltsev@synopsys.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=vinod.koul@intel.com \
    --cc=vireshk@kernel.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;
as well as URLs for NNTP newsgroup(s).