Wrong "nollp" DW DMAC parameter value on ARC SDP.
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(0x)); 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). 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? 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) -- Paltsev Eugeniy ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Wrong "nollp" DW DMAC parameter value on ARC SDP.
On Fri, 2016-08-12 at 08:03 +, 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(0x)); > 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? > > 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), ..." > 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 -- Andy Shevchenko Intel Finland Oy ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Wrong "nollp" DW DMAC parameter value on ARC SDP.
On Fri, 2016-08-12 at 13:59 +0300, Andy Shevchenko wrote: > On Fri, 2016-08-12 at 08:03 +, 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(0x)); > > 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 0xfffc > > 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), ..." > > > > > > 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? -- Paltsev Eugeniy ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Wrong "nollp" DW DMAC parameter value on ARC SDP.
On Fri, 2016-08-12 at 13:36 +, Eugeniy Paltsev wrote: > On Fri, 2016-08-12 at 13:59 +0300, Andy Shevchenko wrote: > > > > On Fri, 2016-08-12 at 08:03 +, 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(0x)); > > > 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 0xfffc Nice. Oh, forgot to ask, what are the DW_PARAMS and DWC_PARAMS[x] are on the same hardware? I assume we are talking about that one which has no hardware LLP support. > > > 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. > > > 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. -- Andy Shevchenko Intel Finland Oy ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: Problems with support of file locks for ARC (maybe for other targets too)
> -Original Message- > From: Vineet Gupta > Sent: Friday, August 12, 2016 2:39 AM > To: Yuriy Kolerov ; ucl...@uclibc.org > Cc: Waldemar Brodkorb ; Alexey Brodkin > ; Anton Kolesov ; > arcml > Subject: Re: Problems with support of file locks for ARC (maybe for other > targets too) > > On 08/11/2016 09:12 AM, Yuriy Kolerov wrote: > > > >>> Moreover the whole uClibc and every application must be compiled > >>> with > >> those macros. Here is my question. Is it acceptable just to compile > >> toolchain itself using CFLAGS_FOR_TARGET with those macros and don’t > >> define them manually in each application? > >> > >> If you enable LFS support in build system (uClibc or buildroot) these > >> macros will be automatically defined - no point or need to pass them > >> as CFLAGS etc - infact that would be wrong IMO. > > If you enable __UCLIBC_HAS_LFS__ while configuring uClibc then > _LARGEFILE64_SOURCE and _FILE_OFFSET_BITS=64 will not be defined > automatically. > > What was I smoking when replying ? You are correct - these macros have to > be added to each application's makefile or at top level as target C flags. > > > E.g. Buildroot has this generic line in Makefile for packages: > > > > TARGET_CPPFLAGS += -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE > > -D_FILE_OFFSET_BITS=64 > > Actually BR dropped support for disabling LFS in 2015 - before that the line > above used to be guarded by BR2_LARGEFILE. > > > These defines are not placed to config.h or somewhere else. They must be > defined each time you compile anything. uClibc may be built by Buildroot > with these flags by default (actually it is not true at least for ARC - > Buildroot > must be fixed but it is not a subject of this discussion). However you must > define these macros manually when building every application later. > > Right, I stand corrected. > > > I don’t understand this thing - is it possible to compile uClibc with full > support of LFS (see macros above) and don’t use this feature in applications > and everything will be ok? > > Indeed this is the case - if you don't build with LFS, xxx64 won't even be > available to begin with. > > > And is it possible to compile uClibc without _LARGEFILE64_SOURCE and > _FILE_OFFSET_BITS=64 and compile applications with them and everything > will be ok? > > This mostly likely won't work as those defines will not be present in headers > to use in application. But actually it works... As for now uClibc in Buildroot is built without -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 because uClibc does not use global TARGET_CFLAGS. And all other applications (e.g. BusyBox) use those flags. Again - all those defines are presented in features.h and must be activating just by passing those -D options. I'll try to push a patch to Buildroot to force using LFS flags but what frustrates me is that everything works somehow together. > > Right now when we build toolchain for ARC using Buildroot uClibc is > compiled without them and e.g. BusyBox is compiled with - > D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 > ... > > Buildroot now assumes LFS to be default (and you can't switch it off) so > everything including uClibc / Busybox has LFS enabled already. > > > > >> So you really don't need LFS to be able to use locks - but need to > >> make sure that for common generic ABI - user struct flock pairs > >> correctly with kernel struct > >> flock64 with or w/o LFS. > > But this point remains valid - for our ABI - kernel uses struct flock64 and > this > needs to be binary compatible with uClibc struct flock and struct flock64 (LFS > only) > > Read the comment in libc/sysdeps/linux/common-generic/bits/stat.h > > -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
