date:20160816

[PATCH] ARC: Support syscall ABI v4

2016-08-16 Thread Vineet Gupta

The syscall ABI includes the gcc functional calling ABI since a syscall
implies userland caller and kernel callee.

The current gcc ABI (v3) for ARCv2 ISA required 64-bit data be passed in
even-odd register pairs, (potentially punching reg holes when passing such
values as args). This was partly driven by the fact that the double-word
LDD/STD instructions in ARCv2 expect the register alignment and thus gcc
forcing this avoids extra MOV at the cost of a few unused register (which we
have plenty anyways).

This however was rejected as part of upstreaming gcc port to HS. So the new
ABI v4 doesn't enforce the even-odd reg restriction.

Do note that for ARCompact ISA builds v3 and v4 are practically the same in
terms of gcc code generation.

In terms of change management, we infer the new ABI if gcc 6.x onwards
is used for building the kernel.

Signed-off-by: Vineet Gupta 
---
 arch/arc/include/uapi/asm/elf.h | 11 +--
 arch/arc/kernel/process.c   |  2 +-
 arch/arc/kernel/setup.c |  6 --
 3 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/arch/arc/include/uapi/asm/elf.h b/arch/arc/include/uapi/asm/elf.h
index 0f99ac8fcbb2..0037a587320d 100644
--- a/arch/arc/include/uapi/asm/elf.h
+++ b/arch/arc/include/uapi/asm/elf.h
@@ -13,8 +13,15 @@
 
 /* Machine specific ELF Hdr flags */
 #define EF_ARC_OSABI_MSK   0x0f00
-#define EF_ARC_OSABI_ORIG  0x   /* MUST be zero for back-compat */
-#define EF_ARC_OSABI_CURRENT   0x0300   /* v3 (no legacy syscalls) */
+
+#define EF_ARC_OSABI_V30x0300   /* v3 (no legacy syscalls) 
*/
+#define EF_ARC_OSABI_V40x0400   /* v4 (64bit data any reg 
align) */
+
+#if __GNUC__ < 6
+#define EF_ARC_OSABI_CURRENT   EF_ARC_OSABI_V3
+#else
+#define EF_ARC_OSABI_CURRENT   EF_ARC_OSABI_V4
+#endif
 
 typedef unsigned long elf_greg_t;
 typedef unsigned long elf_fpregset_t;
diff --git a/arch/arc/kernel/process.c b/arch/arc/kernel/process.c
index b5db9e7fd649..be1972bd2729 100644
--- a/arch/arc/kernel/process.c
+++ b/arch/arc/kernel/process.c
@@ -199,7 +199,7 @@ int elf_check_arch(const struct elf32_hdr *x)
}
 
eflags = x->e_flags;
-   if ((eflags & EF_ARC_OSABI_MSK) < EF_ARC_OSABI_CURRENT) {
+   if ((eflags & EF_ARC_OSABI_MSK) != EF_ARC_OSABI_CURRENT) {
pr_err("ABI mismatch - you need newer toolchain\n");
force_sigsegv(SIGSEGV, current);
return 0;
diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
index a946400a86d0..f52a0d0dc462 100644
--- a/arch/arc/kernel/setup.c
+++ b/arch/arc/kernel/setup.c
@@ -291,8 +291,10 @@ static char *arc_extn_mumbojumbo(int cpu_id, char *buf, 
int len)
   cpu->dccm.base_addr, TO_KB(cpu->dccm.sz),
   cpu->iccm.base_addr, TO_KB(cpu->iccm.sz));
 
-   n += scnprintf(buf + n, len - n,
-  "OS ABI [v3]\t: no-legacy-syscalls\n");
+   n += scnprintf(buf + n, len - n, "OS ABI [v%d]\t: %s\n",
+   EF_ARC_OSABI_CURRENT >> 8,
+   EF_ARC_OSABI_CURRENT == EF_ARC_OSABI_V3 ?
+   "no-legacy-syscalls" : "64-bit data any register 
aligned");
 
return buf;
 }
-- 
2.7.4


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v2] arc: Add "model" properly in device tree description of all boards

2016-08-16 Thread Vineet Gupta

Hi Arnd,

On 08/15/2016 09:28 PM, Alexey Brodkin wrote:
> As it was discussed quite some time ago (see
> https://lkml.org/lkml/2015/11/5/862) it's a good practice to add
> "model" property in .dts. Moreover as per ePAPR "model" property is
> required and should look like "manufacturer,model" so we do here.

I went back to the discussion above and you mentioned that "model" needs to be a
descriptive name.
However per Documentation/booting-without-of.txt "model" is type/model - more 
like
"compatible" which is what Alexey's patch does. I don't have a preference either
ways !

-Vineet

>
> Signed-off-by: Alexey Brodkin 
> Cc: Vineet Gupta 
> Cc: Jonas Gorski 
> Cc: Arnd Bergmann 
> Cc: Rob Herring 
> Cc: Christian Ruppert 
> ---
>
> Changes v1 -> v2:
>  * Added "hs" postfix for boards based on ARC HS core
>  * Added "archs" postfix in VDK's .dts to distinguish VDKs for
>ARC cores from those for ARM cores
>
>  arch/arc/boot/dts/abilis_tb100_dvk.dts | 1 +
>  arch/arc/boot/dts/abilis_tb101_dvk.dts | 1 +
>  arch/arc/boot/dts/axs101.dts   | 1 +
>  arch/arc/boot/dts/axs103.dts   | 1 +
>  arch/arc/boot/dts/axs103_idu.dts   | 1 +
>  arch/arc/boot/dts/nsim_700.dts | 1 +
>  arch/arc/boot/dts/nsim_hs.dts  | 1 +
>  arch/arc/boot/dts/nsim_hs_idu.dts  | 1 +
>  arch/arc/boot/dts/nsimosci.dts | 1 +
>  arch/arc/boot/dts/nsimosci_hs.dts  | 1 +
>  arch/arc/boot/dts/nsimosci_hs_idu.dts  | 1 +
>  arch/arc/boot/dts/vdk_hs38.dts | 1 +
>  arch/arc/boot/dts/vdk_hs38_smp.dts | 1 +
>  13 files changed, 13 insertions(+)
>
> diff --git a/arch/arc/boot/dts/abilis_tb100_dvk.dts 
> b/arch/arc/boot/dts/abilis_tb100_dvk.dts
> index 3dd6ed9..3acf04d 100644
> --- a/arch/arc/boot/dts/abilis_tb100_dvk.dts
> +++ b/arch/arc/boot/dts/abilis_tb100_dvk.dts
> @@ -24,6 +24,7 @@
>  /include/ "abilis_tb100.dtsi"
>  
>  / {
> + model = "abilis,tb100";
>   chosen {
>   bootargs = "earlycon=uart8250,mmio32,0xff10,9600n8 
> console=ttyS0,9600n8";
>   };
> diff --git a/arch/arc/boot/dts/abilis_tb101_dvk.dts 
> b/arch/arc/boot/dts/abilis_tb101_dvk.dts
> index 1cf51c2..37d88c5 100644
> --- a/arch/arc/boot/dts/abilis_tb101_dvk.dts
> +++ b/arch/arc/boot/dts/abilis_tb101_dvk.dts
> @@ -24,6 +24,7 @@
>  /include/ "abilis_tb101.dtsi"
>  
>  / {
> + model = "abilis,tb101";
>   chosen {
>   bootargs = "earlycon=uart8250,mmio32,0xff10,9600n8 
> console=ttyS0,9600n8";
>   };
> diff --git a/arch/arc/boot/dts/axs101.dts b/arch/arc/boot/dts/axs101.dts
> index 3f9b058..d9b9b9d 100644
> --- a/arch/arc/boot/dts/axs101.dts
> +++ b/arch/arc/boot/dts/axs101.dts
> @@ -13,6 +13,7 @@
>  /include/ "axs10x_mb.dtsi"
>  
>  / {
> + model = "snps,axs101";
>   compatible = "snps,axs101", "snps,arc-sdp";
>  
>   chosen {
> diff --git a/arch/arc/boot/dts/axs103.dts b/arch/arc/boot/dts/axs103.dts
> index e6d0e31..ec7fb27 100644
> --- a/arch/arc/boot/dts/axs103.dts
> +++ b/arch/arc/boot/dts/axs103.dts
> @@ -16,6 +16,7 @@
>  /include/ "axs10x_mb.dtsi"
>  
>  / {
> + model = "snps,axs103";
>   compatible = "snps,axs103", "snps,arc-sdp";
>  
>   chosen {
> diff --git a/arch/arc/boot/dts/axs103_idu.dts 
> b/arch/arc/boot/dts/axs103_idu.dts
> index f999fef..070c297 100644
> --- a/arch/arc/boot/dts/axs103_idu.dts
> +++ b/arch/arc/boot/dts/axs103_idu.dts
> @@ -16,6 +16,7 @@
>  /include/ "axs10x_mb.dtsi"
>  
>  / {
> + model = "snps,axs103-smp";
>   compatible = "snps,axs103", "snps,arc-sdp";
>  
>   chosen {
> diff --git a/arch/arc/boot/dts/nsim_700.dts b/arch/arc/boot/dts/nsim_700.dts
> index 6397051..ce0ccd20 100644
> --- a/arch/arc/boot/dts/nsim_700.dts
> +++ b/arch/arc/boot/dts/nsim_700.dts
> @@ -10,6 +10,7 @@
>  /include/ "skeleton.dtsi"
>  
>  / {
> + model = "snps,nsim";
>   compatible = "snps,nsim";
>   #address-cells = <1>;
>   #size-cells = <1>;
> diff --git a/arch/arc/boot/dts/nsim_hs.dts b/arch/arc/boot/dts/nsim_hs.dts
> index bf05fe5..3772c40 100644
> --- a/arch/arc/boot/dts/nsim_hs.dts
> +++ b/arch/arc/boot/dts/nsim_hs.dts
> @@ -10,6 +10,7 @@
>  /include/ "skeleton_hs.dtsi"
>  
>  / {
> + model = "snps,nsim_hs";
>   compatible = "snps,nsim_hs";
>   #address-cells = <2>;
>   #size-cells = <2>;
> diff --git a/arch/arc/boot/dts/nsim_hs_idu.dts 
> b/arch/arc/boot/dts/nsim_hs_idu.dts
> index 99eabe1..48434d7c 100644
> --- a/arch/arc/boot/dts/nsim_hs_idu.dts
> +++ b/arch/arc/boot/dts/nsim_hs_idu.dts
> @@ -10,6 +10,7 @@
>  /include/ "skeleton_hs_idu.dtsi"
>  
>  / {
> + model = "snps,nsim_hs-smp";
>   compatible = "snps,nsim_hs";
>   interrupt-parent = <_intc>;
>  
> diff --git a/arch/arc/boot/dts/nsimosci.dts b/arch/arc/boot/dts/nsimosci.dts
> index e659a34..bcf6031 100644
> --- a/arch/arc/boot/dts/nsimosci.dts
> +++ b/arch/arc/boot/dts/nsimosci.dts
> @@ -10,6

[LTP] [PATCH v2] syscalls/fcntl34: Use flock64 instead of flock

2016-08-16 Thread Yuriy Kolerov


This test uses OFD locks which are supported only by 64-bit ABI.
Thus OFD locks must be used with flock64 structure for sure in this
test. It is necessary because on some 32-bit targets (e.g. 32-bit
uClibc) flock is not mapped to flock64 when _FILE_OFFSET_BITS is not
set to 64.

Signed-off-by: Yuriy Kolerov 
---
 testcases/kernel/syscalls/fcntl/fcntl34.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/testcases/kernel/syscalls/fcntl/fcntl34.c b/testcases/kernel/syscalls/fcntl/fcntl34.c
index c72951e..2f89dea 100644
--- a/testcases/kernel/syscalls/fcntl/fcntl34.c
+++ b/testcases/kernel/syscalls/fcntl/fcntl34.c
@@ -66,7 +66,7 @@ void *thread_fn_01(void *arg)
 
 	memset(buf, (intptr_t)arg, write_size);
 
-	struct flock lck = {
+	struct flock64 lck = {
 		.l_whence = SEEK_SET,
 		.l_start  = 0,
 		.l_len= 1,
___
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.

2016-08-16 Thread Andy Shevchenko

On Tue, 2016-08-16 at 11:32 +, Eugeniy Paltsev wrote:
> On Mon, 2016-08-15 at 15:41 +0300, Andy Shevchenko wrote:
> > On Mon, 2016-08-15 at 11:10 +, Eugeniy Paltsev wrote:

> > Consider to review 
> > http://www.spinics.net/lists/dmaengine/msg10682.html
> Looks good to me.

> Reviewed-by: Eugeniy Platsev 

I assume that was related to my patch. Please, send this as an answer to
that thread.

-- 
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.

2016-08-16 Thread Eugeniy Paltsev

On Mon, 2016-08-15 at 15:41 +0300, Andy Shevchenko wrote:
> On Mon, 2016-08-15 at 11:10 +, Eugeniy Paltsev wrote:
> > 
> > On Fri, 2016-08-12 at 17:08 +0300, Andy Shevchenko wrote:
> > > 
> > >  
> > > > 
> > > > > 
> > > > > > 
> > > > > > "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?
> > DW_PARAMS: 0x38280b0c
> Wow, you have two masters with number 3 and 4? (Just out of
> curiosity)
> 
> > 
> > DWC_PARAMS[0]: 0x4926d300
> > DWC_PARAMS[1]: 0x4926d300
> > DWC_PARAMS[2]: 0x4926d300
> > DWC_PARAMS[3]: 0x4926d300
> A-ha, seems you have CHx_HC_LLP == 0. That may explain.
>  
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > 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.
> Yep.
> 
> Consider to review 
> http://www.spinics.net/lists/dmaengine/msg10682.html
Looks good to me.
>
> > 
> > > 
> > >  
> > 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",
> > ))
> > pdata->chan_allocation_order = (unsigned char)tmp;
> Please, make this as a patch and submit either separately, or with
> your
> series mentioning that it has a dependency to my 8250 LPSS series.
> 
Reviewed-by: Eugeniy Platsev 
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH] DW: Read "is_memcpy" and "is_nollp" property from device tree.

2016-08-16 Thread Eugeniy Paltsev

DW DMAC on ARC SDP became broken after df5c7386 ("dmaengine: dw: some Intel
devices has no memcpy support") and 30cb2639 ("dmaengine: dw: don't override
platform data with autocfg") commits.

* After df5c7386 commit "DMA_MEMCPY" capability option doesn't get set
correctly in platform driver version.
* After 30cb2639 commit "nollp" parameters don't get set correctly in
platform driver version.

This happens because in old driver version there are three sources of
parameters: pdata, device tree and autoconfig hardware registers. Some
parameters were read from pdata and others from autoconfig hardware
registers. If pdata was absent some pdata structure fields were filled
with parameters from device tree.
But 30cb2639 commit disabled overriding pdata with autocfg, so if we
use platform driver version without pdata some parameters will not be set.
This leads to inoperability of DW DMAC.

This patch adds reading missed parameters from device tree.

Note there's a prerequisite http://www.spinics.net/lists/dmaengine/msg10682.html

Signed-off-by: Eugeniy Paltsev 
---
 drivers/dma/dw/platform.c | 6 ++
 1 file changed, 6 insertions(+)

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", ))
pdata->chan_allocation_order = (unsigned char)tmp;
 
-- 
2.5.5


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH] ARC: Support syscall ABI v4

Re: [PATCH v2] arc: Add "model" properly in device tree description of all boards

[LTP] [PATCH v2] syscalls/fcntl34: Use flock64 instead of flock

Re: Wrong "nollp" DW DMAC parameter value on ARC SDP.

Re: Wrong "nollp" DW DMAC parameter value on ARC SDP.

[PATCH] DW: Read "is_memcpy" and "is_nollp" property from device tree.

6 matches

Site Navigation

Mail list logo

Footer information