From: Eugeniy.Paltsev@synopsys.com (Eugeniy Paltsev)
To: linux-snps-arc@lists.infradead.org
Subject: Wrong "nollp" DW DMAC parameter value on ARC SDP.
Date: Mon, 15 Aug 2016 11:10:34 +0000 [thread overview]
Message-ID: <1471259434.21247.47.camel@synopsys.com> (raw)
In-Reply-To: <1471010908.4887.100.camel@linux.intel.com>
On Fri, 2016-08-12@17:08 +0300, Andy Shevchenko wrote:
> On Fri, 2016-08-12@13:36 +0000, Eugeniy Paltsev wrote:
> >?
> > On Fri, 2016-08-12@13:59 +0300, Andy Shevchenko wrote:
> > >?
> > >?
> > > On Fri, 2016-08-12@08:03 +0000, Eugeniy Paltsev wrote:
> > > >?
> > > >?
> > > >?
> > > > Hi,
> > > >?
> > > > "nollp" parameter defines if DW DMAC channel supports multi
> > > > block
> > > > transfer or not.
> > > >?
> > > > It is calculated in runtime, but differently depending on on
> > > > availability of pdata. If pdata is absent "nollp" is calculated
> > > > using
> > > > autoconfig hardware registers. Otherwise "nollp" is calculated
> > > > using
> > > > the next code construction:
> > > > channel_writel(dwc, LLP, DWC_LLP_LOC(0xffffffff));
> > > > dwc->nollp = DWC_LLP_LOC(channel_readl(dwc, LLP)) == 0;
> > > > channel_writel(dwc, LLP, 0);
> > > >?
> > > > I realized that these methods give different results.
> > > > For example on ARC AXS101 SDP in case of using autoconfig
> > > > "nollp"
> > > > was
> > > > calculated as "true" (and DMAC works fine),?
> > > > otherwise "nollp" was calculated as "false" (and DMAC doesn't
> > > > work).
> > > Can you show out what the value you read back?
> > channel_readl(dwc, LLP) return 0xfffffffc
> Nice.
>?
> Oh, forgot to ask, what are the DW_PARAMS and DWC_PARAMS[x] are on
> the same hardware?
DW_PARAMS: 0x38280b0c
DWC_PARAMS[0]: 0x4926d300
DWC_PARAMS[1]: 0x4926d300
DWC_PARAMS[2]: 0x4926d300
DWC_PARAMS[3]: 0x4926d300
> I assume we are talking about that one which has no hardware LLP
> support.
Yep.
> >?
> > >?
> > > >?
> > > > So I'm wondering how the code in question really works?
> > > > From DW AHB DMAC databook I wasn't able to find anything
> > > > relevant
> > > > to
> > > > this tricky implementation. Could you please clarify a little
> > > > but
> > > > what
> > > > happens here?
> > > "Table 4-1:
> > > ...
> > > Hardcode Channel x LLP register to 0?
> > > ...
> > > Description: If set to 1, hardcodes channel x Linked List Pointer
> > > register to 0 (LLPx.LOC == 0), ..."
> So, any comment on this one? I suppose you may have an access to some
> internal Synopsys documentation which might shed a light. Or maybe I
> missed something else which should be considered.
Looks like this code based on idea, what if DMA ip-core doesn't have?
LLP support it will not have LLP registers. It is not necessarily true.
>
> >?
> > >?
> > > >?
> > > > Maybe we should add "nollp" field in pdata structure and
> > > > receive
> > > > it
> > > > from pdata/device tree (like we use "is_private" or "is_memcpu"
> > > > fields)
> > > Yeah, perhaps we can remove that trick since we need this flag to
> > > be
> > > set
> > > on Intel Quark which might have the same issue as your case [1].
> > >?
> > > [1] http://www.spinics.net/lists/linux-serial/msg22948.html
> > >?
> > In which tree I can find this patch applied, so I may base my work
> > on
> > it?
> The series is under review. I'm preparing v10, so, I would like to
> re-
> make this patch with regarding to your input.
>?
> For now I would prefer just to remove the trick, but I still wonder
> what
> the circumstances are to bring it not working.
>?
Please add this code to read "is_memcpy" and "is_nollp" property?
from device tree.
----------------------------->8------------------------------
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index 5bda0eb..2712602 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -129,6 +129,12 @@ dw_dma_parse_dt(struct platform_device *pdev)
????????if (of_property_read_bool(np, "is_private"))
????????????????pdata->is_private = true;
?
+???????if (of_property_read_bool(np, "is_memcpy"))
+???????????????pdata->is_memcpy = true;
+
+???????if (of_property_read_bool(np, "is_nollp"))
+???????????????pdata->is_nollp = true;
+
????????if (!of_property_read_u32(np, "chan_allocation_order", &tmp))
????????????????pdata->chan_allocation_order = (unsigned char)tmp;
?
----------------------------->8------------------------------
--?
?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: "dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"viresh.kumar@linaro.org" <viresh.kumar@linaro.org>,
"Nelson.Pereira@synopsys.com" <Nelson.Pereira@synopsys.com>,
"vinod.koul@intel.com" <vinod.koul@intel.com>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>
Subject: Re: Wrong "nollp" DW DMAC parameter value on ARC SDP.
Date: Mon, 15 Aug 2016 11:10:34 +0000 [thread overview]
Message-ID: <1471259434.21247.47.camel@synopsys.com> (raw)
In-Reply-To: <1471010908.4887.100.camel@linux.intel.com>
On Fri, 2016-08-12 at 17:08 +0300, Andy Shevchenko wrote:
> On Fri, 2016-08-12 at 13:36 +0000, Eugeniy Paltsev wrote:
> >
> > On Fri, 2016-08-12 at 13:59 +0300, Andy Shevchenko wrote:
> > >
> > >
> > > On Fri, 2016-08-12 at 08:03 +0000, Eugeniy Paltsev wrote:
> > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > "nollp" parameter defines if DW DMAC channel supports multi
> > > > block
> > > > transfer or not.
> > > >
> > > > It is calculated in runtime, but differently depending on on
> > > > availability of pdata. If pdata is absent "nollp" is calculated
> > > > using
> > > > autoconfig hardware registers. Otherwise "nollp" is calculated
> > > > using
> > > > the next code construction:
> > > > channel_writel(dwc, LLP, DWC_LLP_LOC(0xffffffff));
> > > > dwc->nollp = DWC_LLP_LOC(channel_readl(dwc, LLP)) == 0;
> > > > channel_writel(dwc, LLP, 0);
> > > >
> > > > I realized that these methods give different results.
> > > > For example on ARC AXS101 SDP in case of using autoconfig
> > > > "nollp"
> > > > was
> > > > calculated as "true" (and DMAC works fine),
> > > > otherwise "nollp" was calculated as "false" (and DMAC doesn't
> > > > work).
> > > Can you show out what the value you read back?
> > channel_readl(dwc, LLP) return 0xfffffffc
> Nice.
>
> Oh, forgot to ask, what are the DW_PARAMS and DWC_PARAMS[x] are on
> the same hardware?
DW_PARAMS: 0x38280b0c
DWC_PARAMS[0]: 0x4926d300
DWC_PARAMS[1]: 0x4926d300
DWC_PARAMS[2]: 0x4926d300
DWC_PARAMS[3]: 0x4926d300
> I assume we are talking about that one which has no hardware LLP
> support.
Yep.
> >
> > >
> > > >
> > > > So I'm wondering how the code in question really works?
> > > > From DW AHB DMAC databook I wasn't able to find anything
> > > > relevant
> > > > to
> > > > this tricky implementation. Could you please clarify a little
> > > > but
> > > > what
> > > > happens here?
> > > "Table 4-1:
> > > ...
> > > Hardcode Channel x LLP register to 0?
> > > ...
> > > Description: If set to 1, hardcodes channel x Linked List Pointer
> > > register to 0 (LLPx.LOC == 0), ..."
> So, any comment on this one? I suppose you may have an access to some
> internal Synopsys documentation which might shed a light. Or maybe I
> missed something else which should be considered.
Looks like this code based on idea, what if DMA ip-core doesn't have
LLP support it will not have LLP registers. It is not necessarily true.
>
> >
> > >
> > > >
> > > > Maybe we should add "nollp" field in pdata structure and
> > > > receive
> > > > it
> > > > from pdata/device tree (like we use "is_private" or "is_memcpu"
> > > > fields)
> > > Yeah, perhaps we can remove that trick since we need this flag to
> > > be
> > > set
> > > on Intel Quark which might have the same issue as your case [1].
> > >
> > > [1] http://www.spinics.net/lists/linux-serial/msg22948.html
> > >
> > In which tree I can find this patch applied, so I may base my work
> > on
> > it?
> The series is under review. I'm preparing v10, so, I would like to
> re-
> make this patch with regarding to your input.
>
> For now I would prefer just to remove the trick, but I still wonder
> what
> the circumstances are to bring it not working.
>
Please add this code to read "is_memcpy" and "is_nollp" property
from device tree.
----------------------------->8------------------------------
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index 5bda0eb..2712602 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -129,6 +129,12 @@ dw_dma_parse_dt(struct platform_device *pdev)
if (of_property_read_bool(np, "is_private"))
pdata->is_private = true;
+ if (of_property_read_bool(np, "is_memcpy"))
+ pdata->is_memcpy = true;
+
+ if (of_property_read_bool(np, "is_nollp"))
+ pdata->is_nollp = true;
+
if (!of_property_read_u32(np, "chan_allocation_order", &tmp))
pdata->chan_allocation_order = (unsigned char)tmp;
----------------------------->8------------------------------
--
Paltsev Eugeniy
next prev parent reply other threads:[~2016-08-15 11:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-12 8:03 Wrong "nollp" DW DMAC parameter value on ARC SDP Eugeniy Paltsev
2016-08-12 8:03 ` Eugeniy Paltsev
2016-08-12 10:59 ` Andy Shevchenko
2016-08-12 10:59 ` Andy Shevchenko
2016-08-12 13:36 ` Eugeniy Paltsev
2016-08-12 13:36 ` Eugeniy Paltsev
2016-08-12 14:08 ` Andy Shevchenko
2016-08-12 14:08 ` Andy Shevchenko
2016-08-15 11:10 ` Eugeniy Paltsev [this message]
2016-08-15 11:10 ` Eugeniy Paltsev
2016-08-15 12:41 ` Andy Shevchenko
2016-08-15 12:41 ` Andy Shevchenko
2016-08-16 11:32 ` Eugeniy Paltsev
2016-08-16 11:32 ` Eugeniy Paltsev
2016-08-16 11:46 ` Andy Shevchenko
2016-08-16 11:46 ` 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=1471259434.21247.47.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.