Re: Debian: openssl: Add ARC target

2021-08-30 Thread Alexey Brodkin
On Thu, 3 Jun 2021 19:14:24 + Vineet Gupta  
wrote: 
> Source: openssl 
> Severity: normal 
> Tags: patch 
> 
> Hi, 
> 
> This is needed to bootstrap arc port. 
> Patch attached. 

Ping!

-Alexey

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


Re: Debian: jemalloc: add arc support

2021-08-30 Thread Alexey Brodkin
On Thu, 3 Jun 2021 21:10:28 + Vineet Gupta  
wrote: 
> Update: upstream change has just now been merged. 

Ping!

-Alexey

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


Re: Debian: libffi: update symbols for ARC

2021-08-30 Thread Alexey Brodkin
On Thu, 3 Jun 2021 19:51:25 + Vineet Gupta  
wrote: 
> Source: libffi 
> Severity: normal 
> Tags: patch 
> 
> Hi, 
> 
> This is needed to bootstrap arc port. 
> Patch attached. 

Ping!

-Alexey

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


Re: python3.9: Add arc-linux-gnu triplet

2021-08-30 Thread Alexey Brodkin
On Wed, 11 Aug 2021 15:34:09 +0300 Alexey Brodkin  
wrote: 
> Source: python3.9 
> Severity: normal 
> Tags: patch upstream 
> 
> Dear Maintainer, 
> 
> There's a new triplet for ARCv2 processors "arc-linux-gnu" 
> defined here https://wiki.debian.org/Multiarch/Tuples. 
> 
> With addition of this triplet to Python3 it becomes buildable for ARC. 
> Attaching a simple diff that implements proposed change. 
> 
> -- System Information: 
> Debian Release: bullseye/sid 
>   APT prefers focal-updates 
>   APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 
>'focal-proposed'), (500, 'focal'), (100, 'focal-backports')
> Architecture: amd64 (x86_64) 
> 
> Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/12 CPU cores) 
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
> (charmap=UTF-8) 
> Shell: /bin/sh linked to /usr/bin/dash 
> Init: unable to detect 

Ping!

-Alexey

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


Re: Debian: gmp: add support for arc

2021-08-30 Thread Alexey Brodkin
On Thu, 3 Jun 2021 19:00:30 + Vineet Gupta  
wrote: 
> Source: gmp 
> Severity: normal 
> Tags: patch 
> 
> Hi, 
> 
> To bootstrap arc port we need symbols file update in gmp. 
> Patch attached. 

Ping!

-Alexey

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


[PATCH v2] dhcpcd: add ARC support

2021-07-04 Thread Alexey Brodkin
This retrofits ARC support from upstream [1].
Should be a part of the next release of "dhcpcd".

https://github.com/NetworkConfiguration/dhcpcd/commit/82386110e67cf75c224e9817fce55e6b0f143266

Signed-off-by: Alexey Brodkin 
Cc: Alexandre Belloni 
---

Changes in v2:

 * Added "Upstream-Status" tag in the patch
 * Added my SoB in the patch

 meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.0.bb   |  1 +
 ...rc-privsep-linux.c-add-support-for-arc-28.patch | 63 ++
 2 files changed, 64 insertions(+)
 create mode 100644 
meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch

diff --git a/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.0.bb 
b/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.0.bb
index 56fcf5cc0b..5be480eb03 100644
--- a/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.0.bb
+++ b/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.0.bb
@@ -13,6 +13,7 @@ UPSTREAM_CHECK_URI = 
"https://roy.marples.name/downloads/dhcpcd/;
 
 SRC_URI = "https://roy.marples.name/downloads/${BPN}/${BPN}-${PV}.tar.xz \
file://0001-remove-INCLUDEDIR-to-prevent-build-issues.patch \
+   file://0002-src-privsep-linux.c-add-support-for-arc-28.patch \
file://dhcpcd.service \
file://dhcpcd@.service \
"
diff --git 
a/meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch
 
b/meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch
new file mode 100644
index 00..045f06a9aa
--- /dev/null
+++ 
b/meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch
@@ -0,0 +1,63 @@
+From 82386110e67cf75c224e9817fce55e6b0f143266 Mon Sep 17 00:00:00 2001
+From: Fabrice Fontaine 
+Date: Mon, 8 Feb 2021 07:23:54 +0100
+Subject: [PATCH] src/privsep-linux.c: add support for arc (#28)
+
+Fix the following build failure:
+
+privsep-linux.c:206:4: error: #error "Platform does not support seccomp filter 
yet"
+ #  error "Platform does not support seccomp filter yet"
+^
+In file included from privsep-linux.c:36:
+privsep-linux.c:213:38: error: 'SECCOMP_AUDIT_ARCH' undeclared here (not in a 
function); did you mean 'SECCOMP_ALLOW_ARG'?
+  BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, SECCOMP_AUDIT_ARCH, 1, 0),
+  ^~
+
+It should be noted that AUDIT_ARCH_{ARCOMPACT,ARCV2} is only defined
+since kernel 5.2 and
+https://github.com/torvalds/linux/commit/67f2a8a29311841ba6ab9b0e2d1b8f1e9978cd84
+
+Detection of arc compact and arc v2 have been "copy/pasted" from
+https://github.com/wbx-github/uclibc-ng/commit/afab56958f1cbb47b831ee3ebff231dfbae74af2
+
+Fixes:
+ - 
http://autobuild.buildroot.org/results/d29083700a80dd647621eed06faeeae03f0587d3
+
+Upstream-Status: Backport 
[https://github.com/NetworkConfiguration/dhcpcd/commit/82386110e67cf75c224e9817fce55e6b0f143266]
+
+Signed-off-by: Fabrice Fontaine 
+Signed-off-by: Alexey Brodkin 
+---
+ src/privsep-linux.c | 16 
+ 1 file changed, 16 insertions(+)
+
+diff --git a/src/privsep-linux.c b/src/privsep-linux.c
+index 402667af..21d41a9a 100644
+--- a/src/privsep-linux.c
 b/src/privsep-linux.c
+@@ -149,6 +149,22 @@ ps_root_sendnetlink(struct dhcpcd_ctx *ctx, int protocol, 
struct msghdr *msg)
+ #  define SECCOMP_AUDIT_ARCH AUDIT_ARCH_I386
+ #elif defined(__x86_64__)
+ #  define SECCOMP_AUDIT_ARCH AUDIT_ARCH_X86_64
++#elif defined(__arc__)
++#  if defined(__A7__)
++#if (BYTE_ORDER == LITTLE_ENDIAN)
++#  define SECCOMP_AUDIT_ARCH AUDIT_ARCH_ARCOMPACT
++#else
++#  define SECCOMP_AUDIT_ARCH AUDIT_ARCH_ARCOMPACTBE
++#endif
++#  elif defined(__HS__)
++#if (BYTE_ORDER == LITTLE_ENDIAN)
++#  define SECCOMP_AUDIT_ARCH AUDIT_ARCH_ARCV2
++#else
++#  define SECCOMP_AUDIT_ARCH AUDIT_ARCH_ARCV2BE
++#endif
++#  else
++#error "Platform does not support seccomp filter yet"
++#  endif
+ #elif defined(__arm__)
+ #  ifndef EM_ARM
+ #define EM_ARM 40
+-- 
+2.16.2
+
-- 
2.16.2


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


Re: [OE-core] [PATCH] dhcpcd: add ARC support

2021-07-04 Thread Alexey Brodkin
Hi Alexandre,

> 
> I did run that through the autobuilders and it is working fine but this
> is missing an Upstream-Status tag.
>

I was a bit surprised by your response being under impression that I did
add "Upstream-Status" tag in the patch. So I went to check... and indeed,
I added it, but just locally, never "git add . && git commit --amend", thus
still have it as:
--->8--
$ git diff
diff --git 
a/meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch
 
b/meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch
index ec895143d8..045f06a9aa 100644
--- 
a/meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch
+++ 
b/meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch
@@ -23,7 +23,10 @@ 
https://github.com/wbx-github/uclibc-ng/commit/afab56958f1cbb47b831ee3ebff231dfb
 Fixes:
  - 
http://autobuild.buildroot.org/results/d29083700a80dd647621eed06faeeae03f0587d3

+Upstream-Status: Backport 
[https://github.com/NetworkConfiguration/dhcpcd/commit/82386110e67cf75c224e9817fce55e6b0f143266]
+
 Signed-off-by: Fabrice Fontaine 
+Signed-off-by: Alexey Brodkin 
--->8--

So thanks a lot for spotting that, will send a re-spin in a moment!

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


[PATCH] dhcpcd: add ARC support

2021-07-02 Thread Alexey Brodkin
This retrofits ARC support from upstream [1].
Should be a part of the next release of "dhcpcd".

https://github.com/NetworkConfiguration/dhcpcd/commit/82386110e67cf75c224e9817fce55e6b0f143266

Signed-off-by: Alexey Brodkin 
---
 meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.0.bb   |  1 +
 ...rc-privsep-linux.c-add-support-for-arc-28.patch | 60 ++
 2 files changed, 61 insertions(+)
 create mode 100644 
meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch

diff --git a/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.0.bb 
b/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.0.bb
index 56fcf5cc0b..5be480eb03 100644
--- a/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.0.bb
+++ b/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.0.bb
@@ -13,6 +13,7 @@ UPSTREAM_CHECK_URI = 
"https://roy.marples.name/downloads/dhcpcd/;
 
 SRC_URI = "https://roy.marples.name/downloads/${BPN}/${BPN}-${PV}.tar.xz \
file://0001-remove-INCLUDEDIR-to-prevent-build-issues.patch \
+   file://0002-src-privsep-linux.c-add-support-for-arc-28.patch \
file://dhcpcd.service \
file://dhcpcd@.service \
"
diff --git 
a/meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch
 
b/meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch
new file mode 100644
index 00..ec895143d8
--- /dev/null
+++ 
b/meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch
@@ -0,0 +1,60 @@
+From 82386110e67cf75c224e9817fce55e6b0f143266 Mon Sep 17 00:00:00 2001
+From: Fabrice Fontaine 
+Date: Mon, 8 Feb 2021 07:23:54 +0100
+Subject: [PATCH] src/privsep-linux.c: add support for arc (#28)
+
+Fix the following build failure:
+
+privsep-linux.c:206:4: error: #error "Platform does not support seccomp filter 
yet"
+ #  error "Platform does not support seccomp filter yet"
+^
+In file included from privsep-linux.c:36:
+privsep-linux.c:213:38: error: 'SECCOMP_AUDIT_ARCH' undeclared here (not in a 
function); did you mean 'SECCOMP_ALLOW_ARG'?
+  BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, SECCOMP_AUDIT_ARCH, 1, 0),
+  ^~
+
+It should be noted that AUDIT_ARCH_{ARCOMPACT,ARCV2} is only defined
+since kernel 5.2 and
+https://github.com/torvalds/linux/commit/67f2a8a29311841ba6ab9b0e2d1b8f1e9978cd84
+
+Detection of arc compact and arc v2 have been "copy/pasted" from
+https://github.com/wbx-github/uclibc-ng/commit/afab56958f1cbb47b831ee3ebff231dfbae74af2
+
+Fixes:
+ - 
http://autobuild.buildroot.org/results/d29083700a80dd647621eed06faeeae03f0587d3
+
+Signed-off-by: Fabrice Fontaine 
+---
+ src/privsep-linux.c | 16 
+ 1 file changed, 16 insertions(+)
+
+diff --git a/src/privsep-linux.c b/src/privsep-linux.c
+index 402667af..21d41a9a 100644
+--- a/src/privsep-linux.c
 b/src/privsep-linux.c
+@@ -149,6 +149,22 @@ ps_root_sendnetlink(struct dhcpcd_ctx *ctx, int protocol, 
struct msghdr *msg)
+ #  define SECCOMP_AUDIT_ARCH AUDIT_ARCH_I386
+ #elif defined(__x86_64__)
+ #  define SECCOMP_AUDIT_ARCH AUDIT_ARCH_X86_64
++#elif defined(__arc__)
++#  if defined(__A7__)
++#if (BYTE_ORDER == LITTLE_ENDIAN)
++#  define SECCOMP_AUDIT_ARCH AUDIT_ARCH_ARCOMPACT
++#else
++#  define SECCOMP_AUDIT_ARCH AUDIT_ARCH_ARCOMPACTBE
++#endif
++#  elif defined(__HS__)
++#if (BYTE_ORDER == LITTLE_ENDIAN)
++#  define SECCOMP_AUDIT_ARCH AUDIT_ARCH_ARCV2
++#else
++#  define SECCOMP_AUDIT_ARCH AUDIT_ARCH_ARCV2BE
++#endif
++#  else
++#error "Platform does not support seccomp filter yet"
++#  endif
+ #elif defined(__arm__)
+ #  ifndef EM_ARM
+ #define EM_ARM 40
+-- 
+2.16.2
+
-- 
2.16.2


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


[PATCH] dpkg: Add ARC support

2021-06-25 Thread Alexey Brodkin
This back-ports ARC support which was added after the most recent
tag 1.20.9 was cut. So on the next version bump this change to be
reverted.

Signed-off-by: Alexey Brodkin 
---
 .../dpkg/0014-arch-Add-support-for-ARCv2-CPU.patch | 68 ++
 meta/recipes-devtools/dpkg/dpkg_1.20.9.bb  |  1 +
 2 files changed, 69 insertions(+)
 create mode 100644 
meta/recipes-devtools/dpkg/dpkg/0014-arch-Add-support-for-ARCv2-CPU.patch

diff --git 
a/meta/recipes-devtools/dpkg/dpkg/0014-arch-Add-support-for-ARCv2-CPU.patch 
b/meta/recipes-devtools/dpkg/dpkg/0014-arch-Add-support-for-ARCv2-CPU.patch
new file mode 100644
index 00..ece18a33ac
--- /dev/null
+++ b/meta/recipes-devtools/dpkg/dpkg/0014-arch-Add-support-for-ARCv2-CPU.patch
@@ -0,0 +1,68 @@
+From c6acfba64b470c7e919fd5bd29124d7228492537 Mon Sep 17 00:00:00 2001
+From: Guillem Jover 
+Date: Fri, 28 May 2021 04:07:49 +0200
+Subject: [PATCH] arch: Add support for ARCv2 CPU
+
+This is based on the ARCv2 32-bit little-endian hard-float ISA.
+
+Closes: #980963
+
+Upstream-Status: Backport 
[https://salsa.debian.org/dpkg-team/dpkg/-/commit/0d134cdcb0dcc6b21fa7926964c1426a5821181d]
+
+Based-on-patch-by: Alexey Brodkin 
+Signed-off-by: Alexey Brodkin 
+---
+ data/cputable  | 1 +
+ scripts/Dpkg/Shlibs/Objdump.pm | 1 +
+ scripts/t/Dpkg_Arch.t  | 4 ++--
+ 3 files changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/data/cputable b/data/cputable
+index 9f2a8e0e4..277bed88f 100644
+--- a/data/cputable
 b/data/cputable
+@@ -20,6 +20,7 @@ i386 i686(i[34567]86|pentium)32  
little
+ ia64  ia64ia6464  little
+ alpha alpha   alpha.* 64  little
+ amd64 x86_64  (amd64|x86_64)  64  little
++arc   arc arc 32  little
+ armeb armeb   arm.*b  32  big
+ arm   arm arm.*   32  little
+ arm64 aarch64 aarch64 64  little
+diff --git a/scripts/Dpkg/Shlibs/Objdump.pm b/scripts/Dpkg/Shlibs/Objdump.pm
+index 4cee866e7..93319d1eb 100644
+--- a/scripts/Dpkg/Shlibs/Objdump.pm
 b/scripts/Dpkg/Shlibs/Objdump.pm
+@@ -100,6 +100,7 @@ use constant {
+ ELF_MACH_OR1K   => 92,
+ ELF_MACH_XTENSA => 94,
+ ELF_MACH_MICROBLAZE => 189,
++ELF_MACH_ARCV2  => 195,
+ ELF_MACH_AVR_OLD=> 0x1057,
+ ELF_MACH_OR1K_OLD   => 0x8472,
+ ELF_MACH_ALPHA  => 0x9026,
+diff --git a/scripts/t/Dpkg_Arch.t b/scripts/t/Dpkg_Arch.t
+index a3a9e6fee..f0bba272a 100644
+--- a/scripts/t/Dpkg_Arch.t
 b/scripts/t/Dpkg_Arch.t
+@@ -16,7 +16,7 @@
+ use strict;
+ use warnings;
+ 
+-use Test::More tests => 16836;
++use Test::More tests => 18407;
+ 
+ use_ok('Dpkg::Arch', qw(debarch_to_debtuple debarch_to_multiarch
+ debarch_eq debarch_is debarch_is_wildcard
+@@ -174,7 +174,7 @@ is(gnutriplet_to_debarch(undef), undef, 'undef 
gnutriplet');
+ is(gnutriplet_to_debarch('unknown-unknown-unknown'), undef, 'unknown 
gnutriplet');
+ is(gnutriplet_to_debarch('x86_64-linux-gnu'), 'amd64', 'known gnutriplet');
+ 
+-is(scalar get_valid_arches(), 539, 'expected amount of known architectures');
++is(scalar get_valid_arches(), 554, 'expected amount of known architectures');
+ 
+ {
+ local $ENV{CC} = 'false';
+-- 
+2.16.2
+
diff --git a/meta/recipes-devtools/dpkg/dpkg_1.20.9.bb 
b/meta/recipes-devtools/dpkg/dpkg_1.20.9.bb
index 60ae3ff736..18ca0e310b 100644
--- a/meta/recipes-devtools/dpkg/dpkg_1.20.9.bb
+++ b/meta/recipes-devtools/dpkg/dpkg_1.20.9.bb
@@ -15,6 +15,7 @@ SRC_URI = 
"git://salsa.debian.org/dpkg-team/dpkg.git;protocol=https;branch=1.20.
file://pager.patch \
file://0001-Add-support-for-riscv32-CPU.patch \
file://0013-scripts-dpkg-fsys-usrunmess.pl-correct-shebang.patch \
+   file://0014-arch-Add-support-for-ARCv2-CPU.patch \
"
 
 SRC_URI_append_class-native = " 
file://0001-build.c-ignore-return-of-1-from-tar-cf.patch"
-- 
2.16.2


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


[PATCH] default-distrovars.inc: Remove seccomp for ARC

2021-06-24 Thread Alexey Brodkin
libseccomp needs too be ported to ARC first

Signed-off-by: Alexey Brodkin 
Cc: Khem Raj 
---
 meta/conf/distro/include/default-distrovars.inc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/conf/distro/include/default-distrovars.inc 
b/meta/conf/distro/include/default-distrovars.inc
index ac10245767..e0726fa3bb 100644
--- a/meta/conf/distro/include/default-distrovars.inc
+++ b/meta/conf/distro/include/default-distrovars.inc
@@ -13,6 +13,9 @@ LOCALE_UTF8_IS_DEFAULT_class-nativesdk = "0"
 # seccomp is not yet ported to rv32
 DISTRO_FEATURES_DEFAULT_remove_riscv32 = "seccomp"
 
+# seccomp is not yet ported to ARC
+DISTRO_FEATURES_DEFAULT_remove_arc = "seccomp"
+
 DISTRO_FEATURES_DEFAULT ?= "acl alsa argp bluetooth debuginfod ext2 ipv4 ipv6 
largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11 vfat 
seccomp"
 DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT}"
 IMAGE_FEATURES ?= ""
-- 
2.16.2


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


[PATCH] gcc: Apply multilib fix to ARC as well

2021-06-20 Thread Alexey Brodkin
W/o that hack target GCC assume existence of per-mcpu folders,
which are missing.

In particular G++ failed to find "bits/c++config.h":
-->8--
 root@hsdk:~# cat test.cc
 #include 

 int myfunc(void)
 {
 }

 root@hsdk:~# g++ -c test.cc -v
 Using built-in specs.
 COLLECT_GCC=g++
 Target: arc-oe-linux
 Configured with: 
../../../../../../work-shared/gcc-11.1.0-r0/gcc-11.1.0/configure 
--build=x86_64-linux --host=arc-oe-linux --target=arc-oe-linux --prefix=/usr 
--exec_prefix=/usr -x
 Thread model: posix
 Supported LTO compression algorithms: zlib
 gcc version 11.1.1 20210523 (GCC)
 COLLECT_GCC_OPTIONS='-c' '-v' '-shared-libgcc' '-mcpu=hs38_linux'
  /usr/libexec/gcc/arc-oe-linux/11.1.1/cc1plus -quiet -v -imultilib hs38_linux 
-D_GNU_SOURCE test.cc -quiet -dumpbase test.cc -dumpbase-ext .cc 
-mcpu=hs38_linux -version -o /tmp/ccs
 GNU C++17 (GCC) version 11.1.1 20210523 (arc-oe-linux)
 compiled by GNU C version 11.1.1 20210523, GMP version 6.2.1, MPFR 
version 4.1.0, MPC version 1.2.1, isl version none
 GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129242
 ignoring nonexistent directory 
"/usr/lib/gcc/arc-oe-linux/11.1.1/../../../../include/c++/11.1.1/arc-oe-linux/hs38_linux"
 ignoring nonexistent directory "/usr/lib/arc-oe-linux/11.1.1/include"
 ignoring nonexistent directory "/usr/local/include"
 ignoring nonexistent directory 
"/usr/lib/gcc/arc-oe-linux/11.1.1/../../../../arc-oe-linux/include"
 #include "..." search starts here:
 #include <...> search starts here:
  /usr/lib/gcc/arc-oe-linux/11.1.1/../../../../include/c++/11.1.1
  /usr/lib/gcc/arc-oe-linux/11.1.1/../../../../include/c++/11.1.1/backward
  /usr/lib/gcc/arc-oe-linux/11.1.1/include
  /usr/lib/gcc/arc-oe-linux/11.1.1/include-fixed
  /usr/include
 End of search list.
 GNU C++17 (GCC) version 11.1.1 20210523 (arc-oe-linux)
 compiled by GNU C version 11.1.1 20210523, GMP version 6.2.1, MPFR 
version 4.1.0, MPC version 1.2.1, isl version none
 GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129242
 Compiler executable checksum: 6df2f07a822bfbbb80a61414b712b75d
 In file included from test.cc:1:
 /usr/include/c++/11.1.1/cstdlib:41:10: fatal error: bits/c++config.h: No such 
file or directory
41 | #include 
   |  ^~
 compilation terminated.
-->8--

Note "ignoring nonexistent directory 
"/usr/lib/gcc/arc-oe-linux/11.1.1/../../../../include/c++/11.1.1/arc-oe-linux/hs38_linux"
message which is being used by GCC due to the fact of implicit 
"-mcpu=hs38_linux".

In fact this header "bits/c++config.h" is located in 
"/usr/lib/gcc/arc-oe-linux/11.1.1/../../../../include/c++/11.1.1/arc-oe-linux"
on target.

Signed-off-by: Alexey Brodkin 
---
 .../gcc/gcc/0004-64-bit-multilib-hack.patch| 23 +++---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/gcc/gcc/0004-64-bit-multilib-hack.patch 
b/meta/recipes-devtools/gcc/gcc/0004-64-bit-multilib-hack.patch
index 789f57343b..8184e68743 100644
--- a/meta/recipes-devtools/gcc/gcc/0004-64-bit-multilib-hack.patch
+++ b/meta/recipes-devtools/gcc/gcc/0004-64-bit-multilib-hack.patch
@@ -1,4 +1,4 @@
-From 28e7c312b1292ca216d4b54ec9f6b7ac055907a8 Mon Sep 17 00:00:00 2001
+From 2fa5c93641b75a662839c1b6eee172b6c481c70e Mon Sep 17 00:00:00 2001
 From: Khem Raj 
 Date: Fri, 29 Mar 2013 09:10:06 +0400
 Subject: [PATCH] 64-bit multilib hack.
@@ -19,7 +19,7 @@ and be able to patch these entries with a complete set of 
correct paths but this
 don't have such code at this point. This is something the target gcc recipe 
should do
 and override these platform defaults in its build config.
 
-Do same for riscv64 and aarch64
+Do same for riscv64, aarch64 & arc
 
 RP 15/8/11
 
@@ -30,11 +30,12 @@ Signed-off-by: Elvis Dowson 
 Signed-off-by: Mark Hatle 
 ---
  gcc/config/aarch64/t-aarch64-linux |  8 
+ gcc/config/arc/t-multilib-linux|  4 ++--
  gcc/config/i386/t-linux64  |  6 ++
  gcc/config/mips/t-linux64  | 10 +++---
  gcc/config/riscv/t-linux   |  6 --
  gcc/config/rs6000/t-linux64|  5 ++---
- 5 files changed, 15 insertions(+), 20 deletions(-)
+ 6 files changed, 17 insertions(+), 22 deletions(-)
 
 diff --git a/gcc/config/aarch64/t-aarch64-linux 
b/gcc/config/aarch64/t-aarch64-linux
 index 241b0ef20b6..a7dadb2d64f 100644
@@ -53,6 +54,22 @@ index 241b0ef20b6..a7dadb2d64f 100644
  
 -MULTILIB_OSDIRNAMES += mabi.ilp32=../libilp32$(call 
if_multiarch,:aarch64$(AARCH_BE)-linux-gnu_ilp32)
 +#MULTILIB_OSDIRNAMES += mabi.ilp32=../libilp32$(call 
if_multiarch,:aarch64$(AARCH_BE)-linux-gnu_ilp32)
+diff --git a/gcc/config/arc/t-multilib-linux b/gcc/config/arc/t-multilib-linux
+index fc3fff640a2..d58e28f6df8 100644
+--- a/gcc/config/arc/t-multilib-linux
 b/gcc/conf

[PATCH] gdb: Add native GDB support for ARC

2021-06-15 Thread Alexey Brodkin
This adds support of so-called "native" GDB for ARC processors.
It was submitted upstream a bit late for inclusion in v10.x,
but already in the upstream "master" branch and will be an essential part
of v11.1 whenever it happens.

These are the changes from upstream "master":
 * 
https://sourceware.org/git?p=binutils-gdb.git;a=commit;h=b4e3cd0440109d0a5552d3313ccbd35c8103335b
 * 
https://sourceware.org/git?p=binutils-gdb.git;a=commit;h=d4af727286e3a9f177ba11677fbd3a012d36558a
 * 
https://sourceware.org/git?p=binutils-gdb.git;a=commit;h=46023bbe81355230b4e7b76d3084337823d02362
 * 
https://sourceware.org/git?p=binutils-gdb.git;a=commit;h=04c9f85efcd8df5fc482ce97c0104cc7dd5d19e6

Thanks a bunch to Anton & Shahab who made it possible!

Signed-off-by: Alexey Brodkin 
---
 meta/recipes-devtools/gdb/gdb-10.2.inc |   4 +
 .../0012-arc-Add-support-for-signal-handlers.patch | 218 +++
 ...pport-for-signal-frames-for-Linux-targets.patch | 232 
 ...to-account-the-REGNUM-in-supply-collect-g.patch | 104 ++
 ...b-Add-native-support-for-ARC-in-GNU-Linux.patch | 414 +
 5 files changed, 972 insertions(+)
 create mode 100644 
meta/recipes-devtools/gdb/gdb/0012-arc-Add-support-for-signal-handlers.patch
 create mode 100644 
meta/recipes-devtools/gdb/gdb/0013-arc-Add-support-for-signal-frames-for-Linux-targets.patch
 create mode 100644 
meta/recipes-devtools/gdb/gdb/0014-arc-Take-into-account-the-REGNUM-in-supply-collect-g.patch
 create mode 100644 
meta/recipes-devtools/gdb/gdb/0015-gdb-Add-native-support-for-ARC-in-GNU-Linux.patch

diff --git a/meta/recipes-devtools/gdb/gdb-10.2.inc 
b/meta/recipes-devtools/gdb/gdb-10.2.inc
index 0a7df54e9f..0d275075e6 100644
--- a/meta/recipes-devtools/gdb/gdb-10.2.inc
+++ b/meta/recipes-devtools/gdb/gdb-10.2.inc
@@ -15,5 +15,9 @@ SRC_URI = "${GNU_MIRROR}/gdb/gdb-${PV}.tar.xz \
file://0009-resolve-restrict-keyword-conflict.patch \
file://0010-Fix-invalid-sigprocmask-call.patch \
file://0011-gdbserver-ctrl-c-handling.patch \
+   file://0012-arc-Add-support-for-signal-handlers.patch \
+   
file://0013-arc-Add-support-for-signal-frames-for-Linux-targets.patch \
+   
file://0014-arc-Take-into-account-the-REGNUM-in-supply-collect-g.patch \
+   file://0015-gdb-Add-native-support-for-ARC-in-GNU-Linux.patch \
"
 SRC_URI[sha256sum] = 
"aaa1223d534c9b700a8bec952d9748ee1977513f178727e1bee520ee000b4f29"
diff --git 
a/meta/recipes-devtools/gdb/gdb/0012-arc-Add-support-for-signal-handlers.patch 
b/meta/recipes-devtools/gdb/gdb/0012-arc-Add-support-for-signal-handlers.patch
new file mode 100644
index 00..6a98b65766
--- /dev/null
+++ 
b/meta/recipes-devtools/gdb/gdb/0012-arc-Add-support-for-signal-handlers.patch
@@ -0,0 +1,218 @@
+From bfee93403b46ae4f050282b7721ba39073905c69 Mon Sep 17 00:00:00 2001
+From: Anton Kolesov 
+Date: Mon, 22 Aug 2016 19:39:46 +0300
+Subject: [PATCH 1/4] arc: Add support for signal handlers
+
+This patch adds the necessary infrastructure to handle signal frames for
+ARC architecture.  It is fairly similar to what any other architecture
+would have.  Linux specific parts will be in a separate patch.
+
+v2 [1]:
+- Make the logic of "arc_sigtramp_frame_sniffer ()" simpler.
+
+[1] Tom's remark for the first version
+https://sourceware.org/pipermail/gdb-patches/2020-November/173221.html
+
+gdb/ChangeLog:
+
+   * arc-tdep.c (arc_make_sigtramp_frame_cache): New function.
+   (arc_sigtramp_frame_this_id): Likewise.
+   (arc_sigtramp_frame_prev_register): Likewise.
+   (arc_sigtramp_frame_sniffer): Likewise.
+   (arc_siftramp_frame_unwind): New global variable.
+   (arc_gdbarch_init): Use sigtramp capabilities.
+   (arc_dump_tdep): Print sigtramp fields.
+   * arc-tdep.h (gdbarch_tdep): Add sigtramp fields.
+
+Upstream-Status: Backport 
[https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=b4e3cd0440109d0a5552d3313ccbd35c8103335b]
+
+Signed-off-by: Anton Kolesov 
+Signed-off-by: Shahab Vahedi 
+Signed-off-by: Alexey Brodkin 
+---
+ gdb/arc-tdep.c | 123 +
+ gdb/arc-tdep.h |  13 ++
+ 2 files changed, 136 insertions(+)
+
+diff --git a/gdb/arc-tdep.c b/gdb/arc-tdep.c
+index 93e2fd88a9a..3356252525d 100644
+--- a/gdb/arc-tdep.c
 b/gdb/arc-tdep.c
+@@ -1843,6 +1843,104 @@ arc_dwarf2_frame_init_reg (struct gdbarch *gdbarch, 
int regnum,
+ reg->how = DWARF2_FRAME_REG_CFA;
+ }
+ 
++/*  Signal trampoline frame unwinder.  Allows frame unwinding to happen
++from within signal handlers.  */
++
++static struct arc_frame_cache *
++arc_make_sigtramp_frame_cache (struct frame_info *this_frame)
++{
++  if (arc_debug)
++debug_printf ("arc: sigtramp_frame_cache\n");
++
++  struct gdbarch_tdep *tdep = gdbarch_tdep (get_frame_arch (this_frame));
++
++  /* Allocate new frame cache inst

[PATCH] gcc: Fixes for ARC

2021-06-11 Thread Alexey Brodkin
A couple of fixes to be a part of 11.2 whenever it happens

1. 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0061fabeb9393c362601486105202cfe837a5a68
   Fixes "harfbuzz" build, see 
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/382
   for all the gory details.

2. 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4186b7e93be73f8d68dc0fcc00a4cc8cc83e99a8
   Fixes ext4 run-time issue:
   ->8---
   Path: /bin/busybox
   CPU: 0 PID: 1 Comm: init Not tainted 5.13.0-rc2-dirty #23
   Invalid Read @ 0x41c9e600 by insn @ __bio_try_merge_page+0x4e/0xfc
   ECR: 0x00050100 EFA: 0x41c9e600 ERET: 0x80159656
   STAT: 0x80080202 [IE K ]   BTA: 0x80159648
SP: 0x80821b88  FP: 0x0008 BLK: bio_add_page+0x22/0x5c
   LPS: 0x801a6a94 LPE: 0x801a6a98 LPC: 0x
   r00: 0x80823300 r01: 0xbfb85e38 r02: 0x2000
   r03: 0x r04: 0x80821b9b r05: 0x80821bfc
   r06: 0x r07: 0x0700 r08: 0x
   r09: 0x r10: 0x r11: 0x
   r12: 0x8080b300
   Stack Trace:
 __bio_try_merge_page+0x4e/0xfc
 bio_add_page+0x22/0x5c
 do_mpage_readpage+0x534/0x65c
 mpage_readahead+0x30/0xdc
 read_pages+0x34/0x194
 page_cache_ra_unbounded+0x56/0x154
 filemap_fault+0x25a/0x5d8
 __do_fault+0x94/0xe8
 handle_mm_fault+0x4de/0xbd4
 do_page_fault+0x108/0x21c
 ret_from_exception+0x0/0x8
   ->8---

3. 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5a9b6a004f89fdd95b0470e1324dc4dee8c41d24
   Precautious fix for rare corner cases which we don't wnat to really end-up 
in.

Signed-off-by: Alexey Brodkin 
---
 meta/recipes-devtools/gcc/gcc-11.1.inc |   3 +
 ...0038-arc-Update-64bit-move-split-patterns.patch | 290 +
 .../gcc/gcc/0039-arc-Fix-u-maddhisi-patterns.patch | 127 +
 .../gcc/0040-arc-Update-doloop_end-patterns.patch  | 105 
 4 files changed, 525 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc/0038-arc-Update-64bit-move-split-patterns.patch
 create mode 100644 
meta/recipes-devtools/gcc/gcc/0039-arc-Fix-u-maddhisi-patterns.patch
 create mode 100644 
meta/recipes-devtools/gcc/gcc/0040-arc-Update-doloop_end-patterns.patch

diff --git a/meta/recipes-devtools/gcc/gcc-11.1.inc 
b/meta/recipes-devtools/gcc/gcc-11.1.inc
index bf29879ded..69e4c8bacc 100644
--- a/meta/recipes-devtools/gcc/gcc-11.1.inc
+++ b/meta/recipes-devtools/gcc/gcc-11.1.inc
@@ -69,6 +69,9 @@ SRC_URI = "\
file://0036-mingw32-Enable-operation_not_supported.patch \
file://0037-libatomic-Do-not-enforce-march-on-aarch64.patch \

file://0001-Revert-libstdc-Install-libstdc-gdb.py-more-robustly-.patch \
+   file://0038-arc-Update-64bit-move-split-patterns.patch \
+   file://0039-arc-Fix-u-maddhisi-patterns.patch \
+   file://0040-arc-Update-doloop_end-patterns.patch \
 "
 SRC_URI[sha256sum] = 
"4c4a6fb8a8396059241c2e674b85b351c26a5d678274007f076957afa1cc9ddf"
 SRC_URI[backports.sha256sum] = 
"69274bebd6c069a13443d4af61070e854740a639ec4d66eedf3e80070363587b"
diff --git 
a/meta/recipes-devtools/gcc/gcc/0038-arc-Update-64bit-move-split-patterns.patch 
b/meta/recipes-devtools/gcc/gcc/0038-arc-Update-64bit-move-split-patterns.patch
new file mode 100644
index 00..37fe95d711
--- /dev/null
+++ 
b/meta/recipes-devtools/gcc/gcc/0038-arc-Update-64bit-move-split-patterns.patch
@@ -0,0 +1,290 @@
+From 0061fabeb9393c362601486105202cfe837a5a68 Mon Sep 17 00:00:00 2001
+From: Claudiu Zissulescu 
+Date: Wed, 9 Jun 2021 12:12:57 +0300
+Subject: [PATCH] arc: Update 64bit move split patterns.
+
+ARCv2HS can use a limited number of instructions to implement 64bit
+moves. The VADD2 is used as a 64bit move, the LDD/STD are 64 bit loads
+and stores. All those instructions are not baseline, hence we need to
+provide alternatives when they are not available or cannot be generate
+due to instruction restriction.
+
+This patch is cleaning up those move patterns, and updates splits
+instruction lengths.
+
+This is a backport from mainline gcc.
+
+gcc/
+2021-06-09  Claudiu Zissulescu  
+
+   * config/arc/arc-protos.h (arc_split_move_p): New prototype.
+   * config/arc/arc.c (arc_split_move_p): New function.
+   (arc_split_move): Clean up.
+   * config/arc/arc.md (movdi_insn): Clean up, use arc_split_move_p.
+   (movdf_insn): Likewise.
+   * config/arc/simdext.md (mov_insn): Likewise.
+
+Upstream-Status: Backport 
[https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0061fabeb9393c362601486105202cfe837a5a68]
+
+Signed-off-by: Claudiu Zissulescu 
+(cherry picked from commit c0ba7a8af5366c37241f20e8be41e362f7260389)
+Signed-off-by: Alexey Brodkin 
+---
+ gcc/config/arc/arc-protos.h |  1 +
+ gcc/config/arc/arc.c| 44 --
+ gcc/config/arc/arc.md   | 91 +-

[PATCH] gcc: Fixes for ARC

2021-06-11 Thread Alexey Brodkin
A couple of fixes to be a part of 11.2 whenever it happens

1. 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0061fabeb9393c362601486105202cfe837a5a68
   Fixes "harfbuzz" build, see 
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/382
   for all the gory details.

2. 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4186b7e93be73f8d68dc0fcc00a4cc8cc83e99a8
   Fixes ext4 run-time issue:
   ->8---
   Path: /bin/busybox
   CPU: 0 PID: 1 Comm: init Not tainted 5.13.0-rc2-dirty #23
   Invalid Read @ 0x41c9e600 by insn @ __bio_try_merge_page+0x4e/0xfc
   ECR: 0x00050100 EFA: 0x41c9e600 ERET: 0x80159656
   STAT: 0x80080202 [IE K ]   BTA: 0x80159648
SP: 0x80821b88  FP: 0x0008 BLK: bio_add_page+0x22/0x5c
   LPS: 0x801a6a94 LPE: 0x801a6a98 LPC: 0x
   r00: 0x80823300 r01: 0xbfb85e38 r02: 0x2000
   r03: 0x r04: 0x80821b9b r05: 0x80821bfc
   r06: 0x r07: 0x0700 r08: 0x
   r09: 0x r10: 0x r11: 0x
   r12: 0x8080b300
   Stack Trace:
 __bio_try_merge_page+0x4e/0xfc
 bio_add_page+0x22/0x5c
 do_mpage_readpage+0x534/0x65c
 mpage_readahead+0x30/0xdc
 read_pages+0x34/0x194
 page_cache_ra_unbounded+0x56/0x154
 filemap_fault+0x25a/0x5d8
 __do_fault+0x94/0xe8
 handle_mm_fault+0x4de/0xbd4
 do_page_fault+0x108/0x21c
 ret_from_exception+0x0/0x8
   ->8---

3. 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5a9b6a004f89fdd95b0470e1324dc4dee8c41d24
   Precautious fix for rare corner cases which we don't wnat to really end-up 
in.

Signed-off-by: Alexey Brodkin 
---
 meta/recipes-devtools/gcc/gcc-11.1.inc |   3 +
 ...0038-arc-Update-64bit-move-split-patterns.patch | 290 +
 .../gcc/gcc/0039-arc-Fix-u-maddhisi-patterns.patch | 127 +
 .../gcc/0040-arc-Update-doloop_end-patterns.patch  | 105 
 4 files changed, 525 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc/0038-arc-Update-64bit-move-split-patterns.patch
 create mode 100644 
meta/recipes-devtools/gcc/gcc/0039-arc-Fix-u-maddhisi-patterns.patch
 create mode 100644 
meta/recipes-devtools/gcc/gcc/0040-arc-Update-doloop_end-patterns.patch

diff --git a/meta/recipes-devtools/gcc/gcc-11.1.inc 
b/meta/recipes-devtools/gcc/gcc-11.1.inc
index bf29879ded..69e4c8bacc 100644
--- a/meta/recipes-devtools/gcc/gcc-11.1.inc
+++ b/meta/recipes-devtools/gcc/gcc-11.1.inc
@@ -69,6 +69,9 @@ SRC_URI = "\
file://0036-mingw32-Enable-operation_not_supported.patch \
file://0037-libatomic-Do-not-enforce-march-on-aarch64.patch \

file://0001-Revert-libstdc-Install-libstdc-gdb.py-more-robustly-.patch \
+   file://0038-arc-Update-64bit-move-split-patterns.patch \
+   file://0039-arc-Fix-u-maddhisi-patterns.patch \
+   file://0040-arc-Update-doloop_end-patterns.patch \
 "
 SRC_URI[sha256sum] = 
"4c4a6fb8a8396059241c2e674b85b351c26a5d678274007f076957afa1cc9ddf"
 SRC_URI[backports.sha256sum] = 
"69274bebd6c069a13443d4af61070e854740a639ec4d66eedf3e80070363587b"
diff --git 
a/meta/recipes-devtools/gcc/gcc/0038-arc-Update-64bit-move-split-patterns.patch 
b/meta/recipes-devtools/gcc/gcc/0038-arc-Update-64bit-move-split-patterns.patch
new file mode 100644
index 00..37fe95d711
--- /dev/null
+++ 
b/meta/recipes-devtools/gcc/gcc/0038-arc-Update-64bit-move-split-patterns.patch
@@ -0,0 +1,290 @@
+From 0061fabeb9393c362601486105202cfe837a5a68 Mon Sep 17 00:00:00 2001
+From: Claudiu Zissulescu 
+Date: Wed, 9 Jun 2021 12:12:57 +0300
+Subject: [PATCH] arc: Update 64bit move split patterns.
+
+ARCv2HS can use a limited number of instructions to implement 64bit
+moves. The VADD2 is used as a 64bit move, the LDD/STD are 64 bit loads
+and stores. All those instructions are not baseline, hence we need to
+provide alternatives when they are not available or cannot be generate
+due to instruction restriction.
+
+This patch is cleaning up those move patterns, and updates splits
+instruction lengths.
+
+This is a backport from mainline gcc.
+
+gcc/
+2021-06-09  Claudiu Zissulescu  
+
+   * config/arc/arc-protos.h (arc_split_move_p): New prototype.
+   * config/arc/arc.c (arc_split_move_p): New function.
+   (arc_split_move): Clean up.
+   * config/arc/arc.md (movdi_insn): Clean up, use arc_split_move_p.
+   (movdf_insn): Likewise.
+   * config/arc/simdext.md (mov_insn): Likewise.
+
+Upstream-Status: Backport 
[https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0061fabeb9393c362601486105202cfe837a5a68]
+
+Signed-off-by: Claudiu Zissulescu 
+(cherry picked from commit c0ba7a8af5366c37241f20e8be41e362f7260389)
+Signed-off-by: Alexey Brodkin 
+---
+ gcc/config/arc/arc-protos.h |  1 +
+ gcc/config/arc/arc.c| 44 --
+ gcc/config/arc/arc.md   | 91 +-

Re: [linux-yocto] [PATCH] ARC: Rename nSIM HS to HAPS HS

2021-06-11 Thread Alexey Brodkin
> > > The author as it comes in on your patches is rejected by the yocto git
> > > servers, so yes, it had to be fixed up.
> >
> > Do you know what needs to be done to get that fixed?
> > I hope to keep sending patches from time to time
> > (and was about to send yet another one just now),
> > so would be good to make things simpler and exclude
> > that manual fix-up step.
> 
> Did you send the patch via git-send email ? And what smtp relay did
> you use (if that's the case).

I did sent it with "git send-email" as I always do. That was exactly my command:
>8---
 git send-email --to linux-yo...@lists.yoctoproject.org --cc 
linux-snps-arc@lists.infradead.org HEAD~1
>8---

I used our corporate SMPT server, again as I always used to do.
 
> The patch had a "via lists.yoctoproject.org" in the author, and that
> is what caused the server's pre-commit hook to reject it.

I think what might be wrong - on my first attempt to send it, it was discarded
by the mailing list as I didn't have my email alias properly set in the mailing 
list
settings. The thing is my internal and SoB email is "abrod...@synopsys.com",
while our email servers nicely convert that "shorter and supposedly ugly form"
into more beautiful "alexey.brod...@synopsys.com" once email leaves company's
premises.

So I added the latter email as an alias and on the second attempt it was 
accepted
by the mailing list.

Let's see. I'm going to post another patch now and hopefully it will work as it 
should.
If of any interest, I may add you as a Cc for it (it's for OE/gcc).

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


Re: [linux-yocto] [PATCH] ARC: Rename nSIM HS to HAPS HS

2021-06-11 Thread Alexey Brodkin
Hi Bruce,

> The author as it comes in on your patches is rejected by the yocto git
> servers, so yes, it had to be fixed up.

Do you know what needs to be done to get that fixed?
I hope to keep sending patches from time to time
(and was about to send yet another one just now),
so would be good to make things simpler and exclude
that manual fix-up step.

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


[PATCH] ARC: Rename nSIM HS to HAPS HS

2021-05-31 Thread Alexey Brodkin
In v5.5 kernel we merged "nsim_hs" config into "haps_hs", see [1],
and from then on we use the same one "haps_hs" for everything simulated:
nSIM/QEMU/FPGA.

Of important notes:
 * We switched from legacy ARC UART to a standard DW UART

 * QEMU port for ARC is under review upstream, see [2].
   But even today with WIP version from our GitHub fork [3] its possible
   to run this image for "hapshs" machine as simple as:
   ->8--
   $ qemu-system-arc -cpu archs -M virt -nographic -no-reboot -monitor none \
 -kernel build/tmp-glibc/deploy/images/hapshs/vmlinux-initramfs-hapshs.bin
   ->8--

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1681baa713aa138d3f0f77f05c3de1cd6416c7d6
[2] https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg00458.html
[3] https://github.com/foss-for-synopsys-dwc-arc-processors/qemu

Signed-off-by: Alexey Brodkin 
---
 .../nsimhs-standard.scc => hapshs/hapshs-standard.scc}   |  4 ++--
 bsp/hapshs/hapshs.cfg| 12 
 bsp/{nsimhs/nsimhs.scc => hapshs/hapshs.scc} |  2 +-
 bsp/nsimhs/nsimhs.cfg| 10 --
 4 files changed, 15 insertions(+), 13 deletions(-)
 rename bsp/{nsimhs/nsimhs-standard.scc => hapshs/hapshs-standard.scc} (72%)
 create mode 100644 bsp/hapshs/hapshs.cfg
 rename bsp/{nsimhs/nsimhs.scc => hapshs/hapshs.scc} (54%)
 delete mode 100644 bsp/nsimhs/nsimhs.cfg

diff --git a/bsp/nsimhs/nsimhs-standard.scc b/bsp/hapshs/hapshs-standard.scc
similarity index 72%
rename from bsp/nsimhs/nsimhs-standard.scc
rename to bsp/hapshs/hapshs-standard.scc
index 3201ca52..1842b00c 100644
--- a/bsp/nsimhs/nsimhs-standard.scc
+++ b/bsp/hapshs/hapshs-standard.scc
@@ -1,8 +1,8 @@
 # SPDX-License-Identifier: MIT
-define KMACHINE nsimhs
+define KMACHINE hapshs
 define KTYPE standard
 define KARCH arc
 
 include ktypes/standard/standard.scc
 
-include nsimhs.scc
+include hapshs.scc
diff --git a/bsp/hapshs/hapshs.cfg b/bsp/hapshs/hapshs.cfg
new file mode 100644
index ..adcc0531
--- /dev/null
+++ b/bsp/hapshs/hapshs.cfg
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: MIT
+# ARCv2 ISA
+CONFIG_ISA_ARCV2=y
+
+# Serial port
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_DW=y
+CONFIG_SERIAL_OF_PLATFORM=y
+
+# Built-in .dtb
+CONFIG_ARC_BUILTIN_DTB_NAME="haps_hs"
diff --git a/bsp/nsimhs/nsimhs.scc b/bsp/hapshs/hapshs.scc
similarity index 54%
rename from bsp/nsimhs/nsimhs.scc
rename to bsp/hapshs/hapshs.scc
index 3c1613a6..ea2b8b6c 100644
--- a/bsp/nsimhs/nsimhs.scc
+++ b/bsp/hapshs/hapshs.scc
@@ -1,2 +1,2 @@
 # SPDX-License-Identifier: MIT
-kconf hardware nsimhs.cfg
+kconf hardware hapshs.cfg
diff --git a/bsp/nsimhs/nsimhs.cfg b/bsp/nsimhs/nsimhs.cfg
deleted file mode 100644
index 34580a39..
--- a/bsp/nsimhs/nsimhs.cfg
+++ /dev/null
@@ -1,10 +0,0 @@
-# SPDX-License-Identifier: MIT
-# ARCv2 ISA
-CONFIG_ISA_ARCV2=y
-
-# Legacy ARC UART
-CONFIG_SERIAL_ARC=y
-CONFIG_SERIAL_ARC_CONSOLE=y
-
-# Built-in .dtb
-CONFIG_ARC_BUILTIN_DTB_NAME="nsim_hs"
-- 
2.16.2


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


[PATCH] ARC: Rename nSIM HS to HAPS HS

2021-05-31 Thread Alexey Brodkin
In v5.5 kernel we merged "nsim_hs" config into "haps_hs", see [1],
and from then on we use the same one "haps_hs" for everything simulated:
nSIM/QEMU/FPGA.

Of important notes:
 * We switched from legacy ARC UART to a standard DW UART

 * QEMU port for ARC is under review upstream, see [2].
   But even today with WIP version from our GitHub fork [3] its possible
   to run this image for "hapshs" machine as simple as:
   ->8--
   $ qemu-system-arc -cpu archs -M virt -nographic -no-reboot -monitor none \
 -kernel build/tmp-glibc/deploy/images/hapshs/vmlinux-initramfs-hapshs.bin
   ->8--

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1681baa713aa138d3f0f77f05c3de1cd6416c7d6
[2] https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg00458.html
[3] https://github.com/foss-for-synopsys-dwc-arc-processors/qemu

Signed-off-by: Alexey Brodkin 
---
 .../nsimhs-standard.scc => hapshs/hapshs-standard.scc}   |  4 ++--
 bsp/hapshs/hapshs.cfg| 12 
 bsp/{nsimhs/nsimhs.scc => hapshs/hapshs.scc} |  2 +-
 bsp/nsimhs/nsimhs.cfg| 10 --
 4 files changed, 15 insertions(+), 13 deletions(-)
 rename bsp/{nsimhs/nsimhs-standard.scc => hapshs/hapshs-standard.scc} (72%)
 create mode 100644 bsp/hapshs/hapshs.cfg
 rename bsp/{nsimhs/nsimhs.scc => hapshs/hapshs.scc} (54%)
 delete mode 100644 bsp/nsimhs/nsimhs.cfg

diff --git a/bsp/nsimhs/nsimhs-standard.scc b/bsp/hapshs/hapshs-standard.scc
similarity index 72%
rename from bsp/nsimhs/nsimhs-standard.scc
rename to bsp/hapshs/hapshs-standard.scc
index 3201ca52..1842b00c 100644
--- a/bsp/nsimhs/nsimhs-standard.scc
+++ b/bsp/hapshs/hapshs-standard.scc
@@ -1,8 +1,8 @@
 # SPDX-License-Identifier: MIT
-define KMACHINE nsimhs
+define KMACHINE hapshs
 define KTYPE standard
 define KARCH arc
 
 include ktypes/standard/standard.scc
 
-include nsimhs.scc
+include hapshs.scc
diff --git a/bsp/hapshs/hapshs.cfg b/bsp/hapshs/hapshs.cfg
new file mode 100644
index ..adcc0531
--- /dev/null
+++ b/bsp/hapshs/hapshs.cfg
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: MIT
+# ARCv2 ISA
+CONFIG_ISA_ARCV2=y
+
+# Serial port
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_DW=y
+CONFIG_SERIAL_OF_PLATFORM=y
+
+# Built-in .dtb
+CONFIG_ARC_BUILTIN_DTB_NAME="haps_hs"
diff --git a/bsp/nsimhs/nsimhs.scc b/bsp/hapshs/hapshs.scc
similarity index 54%
rename from bsp/nsimhs/nsimhs.scc
rename to bsp/hapshs/hapshs.scc
index 3c1613a6..ea2b8b6c 100644
--- a/bsp/nsimhs/nsimhs.scc
+++ b/bsp/hapshs/hapshs.scc
@@ -1,2 +1,2 @@
 # SPDX-License-Identifier: MIT
-kconf hardware nsimhs.cfg
+kconf hardware hapshs.cfg
diff --git a/bsp/nsimhs/nsimhs.cfg b/bsp/nsimhs/nsimhs.cfg
deleted file mode 100644
index 34580a39..
--- a/bsp/nsimhs/nsimhs.cfg
+++ /dev/null
@@ -1,10 +0,0 @@
-# SPDX-License-Identifier: MIT
-# ARCv2 ISA
-CONFIG_ISA_ARCV2=y
-
-# Legacy ARC UART
-CONFIG_SERIAL_ARC=y
-CONFIG_SERIAL_ARC_CONSOLE=y
-
-# Built-in .dtb
-CONFIG_ARC_BUILTIN_DTB_NAME="nsim_hs"
-- 
2.16.2


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


Re: Bug#980963: dpkg: Please add ARC architecture

2021-03-03 Thread Alexey Brodkin
Hi Helmut,

> On Sat, Feb 06, 2021 at 07:25:35PM +0000, Alexey Brodkin wrote:
> > Any chances to get updates on this one some time soon?
> 
> No. The triplet cannot be changed once added. Therefore, the addition is
> often deferred. The absence of the triplet can easily be worked around.
> A bootstrap can be prototyped already. A major missing piece though is
> glibc 2.32 being packaged in Debian. That likely is a prerequisite for
> resolving this bug.

Well not sure why there's a dependency on glibc as w/o ARC target support
in dpkg nothing could be built for ARC. For example I did built Binutils
with fixed dpkg.

> Things that often need architecture-specific support for a new
> architecture include:
>  * guile-X.Y (cross support)
>  * libgc

Above 2 are not [yet] supported but seems to be easy ones.

>  * libxcrypt (symbols)

Not sure about "libxcrypt" (whatver that means), but libgpg-error supports ARC 
since 2018, see:
https://github.com/gpg/libgpg-error/commit/48c8f8ddfc80551db7615e1eb3555c1dc3f6a657

>  * nspr

Done in 2019, see 
https://hg.mozilla.org/projects/nspr/rev/cc73b6c7dab2e8053533e1f2c0c23dc721e10b76

>  * openssl (packaging)

Not sure what needs to be done here as I know we build a lot of complex
things with OpenEmbedded/Yocto and openssl libs are being built for sure.

> Are any of these fixed or confirmed working for arc?

See above, quite some do work.
 
-Alexey
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


RE: dpkg: Please add ARC architecture

2021-02-11 Thread Alexey Brodkin
Hello,

Any chances to get updates on this one some time soon?

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


Re: [PATCH 18/20] arch: dts: Fix EHCI/OHCI DT nodes name

2020-10-14 Thread Alexey Brodkin
Hi Sergey,

>  arch/arc/boot/dts/axs10x_mb.dtsi   | 4 ++--
>  arch/arc/boot/dts/hsdk.dts | 4 ++--
>  arch/arc/boot/dts/vdk_axs10x_mb.dtsi   | 2 +-

For ARC boards

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


Re: [PATCH] ARC: [plat-hsdk]: Switch ethernet phy-mode to rgmii-id

2020-09-01 Thread Alexey Brodkin
Hi Vineet, Evgeniy!

> From: Vineet Gupta 
> Sent: Tuesday, September 1, 2020 9:41 PM
> To: Evgeniy Didin ; linux-snps-arc@lists.infradead.org 
> 
> Cc: Alexey Brodkin ; Eugeniy Paltsev 
> 
> Subject: Re: [PATCH] ARC: [plat-hsdk]: Switch ethernet phy-mode to rgmii-id 
>  
> On 7/7/20 8:38 AM, Evgeniy Didin wrote:
> > HSDK board has Micrel KSZ9031, recent commit
> > bcf3440c6dd ("net: phy: micrel: add phy-mode support for the KSZ9031 PHY")
> > caused a breakdown of Ethernet.
> > Using 'phy-mode = "rgmii"' is not correct because accodring RGMII
> > specification it is necessary to have delay on RX (PHY to MAX)
> > which is not generated in case of "rgmii".
> > Using "rgmii-id" adds necessary delay and solves the issue.
> >
> > Also adding name of PHY placed on HSDK board.
> >
> > Signed-off-by: Evgeniy Didin 
> > Cc: Eugeniy Paltsev 
> > Cc: Alexey Brodkin 
> 
> @Alexey - u ok with this change ?

Sure,

Acked-by: Alexey Brodkin 

> 
> -Vineet
> 
> > ---
> >  arch/arc/boot/dts/hsdk.dts | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts
> > index 9acbeba832c0..d6427d47e5a1 100644
> > --- a/arch/arc/boot/dts/hsdk.dts
> > +++ b/arch/arc/boot/dts/hsdk.dts
> > @@ -208,7 +208,7 @@
> >    reg = <0x8000 0x2000>;
> >    interrupts = <10>;
> >    interrupt-names = "macirq";
> > - phy-mode = "rgmii";
> > + phy-mode = "rgmii-id";
> >    snps,pbl = <32>;
> >    snps,multicast-filter-bins = <256>;
> >    clocks = <>;
> > @@ -226,7 +226,7 @@
> >    #address-cells = <1>;
> >    #size-cells = <0>;
> >    compatible = "snps,dwmac-mdio";
> > - phy0: ethernet-phy@0 {
> > + phy0: ethernet-phy@0 { /* Micrel KSZ9031 */
> >    reg = <0>;
> >    };
> >    };
> 
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


RE: [PATCH v2 1/4] ARC: allow to override default mcpu compiler flag

2020-06-05 Thread Alexey Brodkin
Hi Eugeniy,

A couple of minor notes below.

> -Original Message-
> From: Eugeniy Paltsev 
> Sent: Thursday, June 4, 2020 8:39 PM
> To: linux-snps-arc@lists.infradead.org; Vineet Gupta 
> Cc: linux-ker...@vger.kernel.org; Alexey Brodkin ; 
> Eugeniy Paltsev
> 
> Subject: [PATCH v2 1/4] ARC: allow to override default mcpu compiler flag
> 
> Kernel builds set their own default -mcpu for a given ISA build.

We used to use a default "-mcpu" per ARC ISA version (one for ARCompact
and one for ARCv2).

> But that gets in the way of "custom" -mcpu flags from propagating
> into kernel build.

But with more versions of CPUs & SoCs becoming available we want to
be able to fine-tune generated code more precise.

> This will also be used in next patches for HSDK-4xD board support which
> uses a different -mcpu to effect dual issue scheduling.

"...for utilization of the new CPU's dual-issue capabilities"?

> +++ b/arch/arc/Makefile
> @@ -10,8 +10,25 @@ CROSS_COMPILE := $(call cc-cross-prefix, arc-linux- 
> arceb-linux-)
>  endif
> 
>  cflags-y += -fno-common -pipe -fno-builtin -mmedium-calls -D__linux__
> -cflags-$(CONFIG_ISA_ARCOMPACT)   += -mA7
> -cflags-$(CONFIG_ISA_ARCV2)   += -mcpu=hs38
> +
> +tune-mcpu-def-$(CONFIG_ISA_ARCOMPACT):= -mA7

I'd suggest to either swap "-mA7" which is being obsoleted with "-mcpu=arc700"
right here or as a separate change, otherwise we may soon get ATC700 builds
broken with newer compilers.

-Alexey

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


RE: [RFC] ARC: initial ftrace support

2020-04-02 Thread Alexey Brodkin
Hi Claus,

> -Original Message-
> From: linux-snps-arc  On Behalf 
> Of Claudiu Zissulescu
> Ianculescu
> Sent: Thursday, April 2, 2020 11:10 AM
> To: Vineet Gupta 
> Cc: Alexey Brodkin ; linux-ker...@vger.kernel.org; 
> Steven Rostedt
> ; Ingo Molnar ; 
> linux-snps-arc@lists.infradead.org; Eugeniy
> Paltsev 
> Subject: Re: [RFC] ARC: initial ftrace support
> 
> Hi,
> 
> ARC-gcc has two modes to call the mcount routines. When using elf32
> configuration, the toolchain is set to use newlib mcount. When
> configured for linux, gcc toolchain is using a library call to _mcall
> (single underscore)  having blink as input argument.
> So, using the proper linux toolchain, your patch should work.


Is there a chance to switch to Linux-style mcount in Elf32 toolchain with a 
command-line
option?

Otherwise I guess we'll need to implement some warning which explicitly says 
why Elf32
toolchain is not usable for building the Linux kernel... at least in case with 
ftrace enabled.

-Alexey

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


RE: [PATCH] [ARC] Allow more ABIs in GLIBC_DYNAMIC_LINKER

2020-03-31 Thread Alexey Brodkin
Hi Claus,

> -Original Message-
> From: linux-snps-arc  On Behalf 
> Of Claudiu Zissulescu
> Ianculescu
> Sent: Tuesday, March 31, 2020 1:07 PM
> To: Vineet Gupta 
> Cc: linux-snps-arc@lists.infradead.org; gcc-patc...@gcc.gnu.org; Claudiu 
> Zissulescu
> 
> Subject: Re: [PATCH] [ARC] Allow more ABIs in GLIBC_DYNAMIC_LINKER
> 
> Pushed.

Is this one eligible for being back-ported to older GCCs?
At least GCC 9.x would be really good.

-Alexey
 

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


RE: Build regressions/improvements in v5.6

2020-03-30 Thread Alexey Brodkin
Hi Andy, Geert,

> -Original Message-
> From: Andy Shevchenko 
> Sent: Monday, March 30, 2020 4:28 PM
> To: Geert Uytterhoeven ; Alexey Brodkin 
> 
> Cc: Linux Kernel Mailing List 
> Subject: Re: Build regressions/improvements in v5.6
> 
> On Mon, Mar 30, 2020 at 4:26 PM Geert Uytterhoeven  
> wrote:
> >
> > Hi Andy,
> >
> > On Mon, Mar 30, 2020 at 3:08 PM Andy Shevchenko
> >  wrote:
> > > On Mon, Mar 30, 2020 at 12:00 PM Geert Uytterhoeven
> > >  wrote:
> > > > Below is the list of build error/warning regressions/improvements in
> > > > v5.6[1] compared to v5.5[2].
> > >
> > > >   + /kisskb/src/include/linux/dev_printk.h: warning: format '%zu' 
> > > > expects argument of type
> 'size_t', but argument 8 has type 'unsigned int' [-Wformat=]:  => 232:23
> > >
> > > This is interesting... I checked all dev_WARN_ONCE() and didn't find an 
> > > issue.
> >
> > arcv2/axs103_smp_defconfig
> >
> > It's probably due to a broken configuration for the arc toolchain.
> 
> Alexey, do have any insight?

I think I do have some but first I'd like to get it reproduced myself.
I just built v5.6 with help of both GCC 8.3.1- & 9.3.1-based toolchains
and didn't see a single warning. So I guess I was doing something wrong.

FWIW

1. My GCC 8.3.1 toolchain was exactly this:
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2019.09-release/arc_gnu_2019.09_prebuilt_uclibc_le_archs_linux_install.tar.gz

2. Linux kernel is vanilla v5.6.0

3. Configured and built as simple as:
   make axs103_smp_defconfig && make

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


RE: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )

2020-03-26 Thread Alexey Brodkin
Hi Helmut,

> > 2. libgpg-error has ARC support since v1.33, see:
> >
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.gnupg.org_cgi-2Dbin_gitweb.cgi-3Fp-
> 3Dlibgpg-2Derror.git-3Ba-3Dcommit-3Bh-
> 3D48c8f8ddfc80=DwIBAg=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=_zJyx
> Gdx_-O_dKHjFp6S-2ZXebEcmuHfmUsgpc4uEXA=myC306ViTlaxOV8nbOJR8pC74k2lsKmmB1hCGQR0PrE=
> 
> This is only the native-support. For rebootstrap, we also need cross
> build support, i.e. recording the generated lock-obj header (once glibc
> is done).
> 
> > And only for "libatomic-ops" & "guile" nothing has been done yet so if 
> > there's something
> > that really needs to be done please let us know.
> 
> I suggest that you focus on libatomic-ops then. And on glibc of course.
> I guess that the other issues are easily solvable when they arise.

Sorry for this stupid question but I'm not very familiar with use-cases for
libatomic-ops so would like to get some more clarification on what's needed 
here.

I know that GCC has quite a few built-ins for atomic ops and we do implement 
them.
I'm adding our GCC maintainer (Claudiu) in the Cc so he may jump in if needed.

-Alexey

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


RE: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )

2020-03-26 Thread Alexey Brodkin
Hi Helmut,

> On Wed, Mar 25, 2020 at 05:25:58PM -0700, Vineet Gupta wrote:
> > ARC glibc is still in works, but assuming that will happen in near future 
> > what
> > other upstream prerequisites are needed. The obvious ones would be Linux 
> > kernel,
> > gcc, binutils: all 3 of which are supported for ARC. From a quick glance at 
> > debian
> > wiki pages, I presume *bootstrap is mostly done native, so needs qemu ? 
> > (full/user
> > emulation ? And does qemu need to be upstream too ?
> 
> Given that I ran into the glibc issue, I can tell that at least
> rudimentary arc support support is already available in Debian unstable
> for binutils, linux and gcc. (Otherwise, I would not have come as far as
> glibc.) Once glibc is in place, work can proceed on the Debian side.
> guile, libatomic-ops, libffi, libgpg-error and nspr ususally need a
> little upstream support. dpkg, gmp, openssl, and perl usually need
> Debian-specific changes. I'd recommend looking into libatomic-ops and
> libffi early. The other packages are usually simple.

I guess almost all of the packages you mentioned already have
needed improvements for ARC.

1. libffi has ARC support since v3.1, see:
   
https://github.com/libffi/libffi/commit/b082e15091961373c03d10ed0251f619ebb6ed76

2. libgpg-error has ARC support since v1.33, see:
   
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commit;h=48c8f8ddfc80
   
3. nspr has ARC support since v4.1, see:
   
https://hg.mozilla.org/projects/nspr/rev/cc73b6c7dab2e8053533e1f2c0c23dc721e10b76

And only for "libatomic-ops" & "guile" nothing has been done yet so if there's 
something
that really needs to be done please let us know.

-Alexey

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


RE: [PATCH] ARC: [plat-axs10x]: PGU: remove unused encoder-slave property

2020-03-11 Thread Alexey Brodkin
Hi Eugeniy,

> -Original Message-
> From: Eugeniy Paltsev 
> Sent: Wednesday, March 11, 2020 10:37 PM
> To: linux-snps-arc@lists.infradead.org; Vineet Gupta 
> Cc: linux-ker...@vger.kernel.org; Alexey Brodkin ; 
> Eugeniy Paltsev
> 
> Subject: [PATCH] ARC: [plat-axs10x]: PGU: remove unused encoder-slave property
> 
> ARC PGU is looking for encoder via endpoint mechanism and doesn't
> use "encoder-slave" property for a long time. Let's drop unused
> "encoder-slave" property from ARC PGU node in axs10x.
> 
> Signed-off-by: Eugeniy Paltsev 

Acked-by: Alexey Brodkin 

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


[GIT PULL] drm/arc: Filter out interlaced mode

2020-03-11 Thread Alexey Brodkin
Hi David, Daniel!

The following changes since commit e3c3b6e66da1caeb39a504b03ddcdd3693e45254:

  Merge tag 'exynos-drm-fixes-for-v5.6-rc5-v2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes 
(2020-03-12 11:02:52 +1000)

are available in the Git repository at:

  g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2020.03.12

for you to fetch changes up to 1e8928584e8f29c31c8db1a50b5bdb1769047434:

  DRM: ARC: PGU: interlaced mode not supported (2020-03-12 07:59:06 +0300)


There's just one tiny fix this time around with explicit filtering
of interlaced modes as they are not supported by ARC PGU hardware.


Eugeniy Paltsev (1):
  DRM: ARC: PGU: interlaced mode not supported

 drivers/gpu/drm/arc/arcpgu_crtc.c | 3 +++
 1 file changed, 3 insertions(+)

Note this is based on the current drm/drm-fixes contents.

Thanks,
Alexey

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


RE: [PATCH] DRM: ARC: PGU: interlaced mode not supported

2020-03-11 Thread Alexey Brodkin
Hi Greg,

> -Original Message-
> From: Greg KH 
> Sent: Wednesday, March 11, 2020 8:22 PM
> To: Eugeniy Paltsev 
> Cc: dri-de...@lists.freedesktop.org; Alexey Brodkin ; 
> linux-snps-
> a...@lists.infradead.org; linux-ker...@vger.kernel.org; David Airlie 
> ; Daniel Vetter
> ; sta...@vger.kernel.org
> Subject: Re: [PATCH] DRM: ARC: PGU: interlaced mode not supported
> 
> On Wed, Mar 11, 2020 at 04:13:10PM +0300, Eugeniy Paltsev wrote:
> > Filter out interlaced modes as they are not supported by ARC PGU
> > hardware.
> >
> > Signed-off-by: Eugeniy Paltsev 
> > ---
> >  drivers/gpu/drm/arc/arcpgu_crtc.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
> > b/drivers/gpu/drm/arc/arcpgu_crtc.c
> > index 8ae1e1f97a73..c854066d4c75 100644
> > --- a/drivers/gpu/drm/arc/arcpgu_crtc.c
> > +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
> > @@ -67,6 +67,9 @@ static enum drm_mode_status 
> > arc_pgu_crtc_mode_valid(struct drm_crtc *crtc,
> > long rate, clk_rate = mode->clock * 1000;
> > long diff = clk_rate / 200; /* +-0.5% allowed by HDMI spec */
> >
> > +   if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> > +   return MODE_NO_INTERLACE;
> > +
> > rate = clk_round_rate(arcpgu->clk, clk_rate);
> > if ((max(rate, clk_rate) - min(rate, clk_rate) < diff) && (rate > 0))
> > return MODE_OK;
> > --
> > 2.21.1
> >
> 
> 
> 
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree.  Please read:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.kernel.org_doc_html_latest_process_stable-2Dkernel-
> 2Drules.html=DwIBAg=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=oXPD1Sz
> FBs-0-4u24Ah1rK1Y65Fma8tJZix0Jih-yqY=WTVW1dC7E2oD0muPxtNd9KAHzwIZwEU9jGuCHWx1iQk=
> for how to do this properly.
> 
> 

Thanks for the comment. I'll add "Cc: sta...@vger.kernel.org" tag to the
patch on committing it to my maintainer tree so one the patch makes its way
up to the Linus' tree you'll get notified as usual.

-Alexey

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


[PATCH 2/3 v2] ARC: nsim_{700|700be|hs38be}_defconfigs: Disable networking

2020-02-12 Thread Alexey Brodkin
We don't have yet any brc700 or big-enadian platforms with networking
support to run this particular configuration.

Whenever QEMU for ARC supports arc700 or big-endian targets we may revisit
this one.

Signed-off-by: Alexey Brodkin 
---

No changes v1 -> v2.

 configs/nsim_700_defconfig| 1 +
 configs/nsim_700be_defconfig  | 1 +
 configs/nsim_hs38be_defconfig | 1 +
 3 files changed, 3 insertions(+)

diff --git a/configs/nsim_700_defconfig b/configs/nsim_700_defconfig
index 2d4a58b178..6a38e2c246 100644
--- a/configs/nsim_700_defconfig
+++ b/configs/nsim_700_defconfig
@@ -14,6 +14,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_OF_EMBED=y
 CONFIG_DEFAULT_DEVICE_TREE="nsim"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+# CONFIG_NET is not set
 CONFIG_DM=y
 CONFIG_DM_SERIAL=y
 CONFIG_DEBUG_UART_SHIFT=2
diff --git a/configs/nsim_700be_defconfig b/configs/nsim_700be_defconfig
index 61eea91449..d3ed84a415 100644
--- a/configs/nsim_700be_defconfig
+++ b/configs/nsim_700be_defconfig
@@ -15,6 +15,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_OF_EMBED=y
 CONFIG_DEFAULT_DEVICE_TREE="nsim"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+# CONFIG_NET is not set
 CONFIG_DM=y
 CONFIG_DM_SERIAL=y
 CONFIG_DEBUG_UART_SHIFT=2
diff --git a/configs/nsim_hs38be_defconfig b/configs/nsim_hs38be_defconfig
index 5d2ea59d52..b074b4ca98 100644
--- a/configs/nsim_hs38be_defconfig
+++ b/configs/nsim_hs38be_defconfig
@@ -16,6 +16,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_OF_EMBED=y
 CONFIG_DEFAULT_DEVICE_TREE="nsim"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+# CONFIG_NET is not set
 CONFIG_DM=y
 CONFIG_DM_SERIAL=y
 CONFIG_DEBUG_UART_SHIFT=2
-- 
2.16.2


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


[PATCH 1/3 v2] ARC: nSIM: switch from ARC UART to DW UART

2020-02-12 Thread Alexey Brodkin
Since v2019.06 DesingWare nSIM supports DesignWare UART simulation
and so we may switch from pretty unusual ARC UART to much more standard
DesignWare UART (which in case of U-Boot is just an ordinary 16650 UART).

This among other things makes built dinaries compatible with our other
platforms to name a few: FPGA-based HAPS boards, QEMU and even ZeBU.

Signed-off-by: Alexey Brodkin 
---

Changes v1 -> v2:

 * Copyright year bumped to 2020.

 arch/arc/dts/nsim.dts | 12 +++-
 configs/nsim_700_defconfig|  8 
 configs/nsim_700be_defconfig  |  8 
 configs/nsim_hs38_defconfig   |  8 
 configs/nsim_hs38be_defconfig |  8 
 5 files changed, 23 insertions(+), 21 deletions(-)

diff --git a/arch/arc/dts/nsim.dts b/arch/arc/dts/nsim.dts
index 243ecb178e..43f281dfec 100644
--- a/arch/arc/dts/nsim.dts
+++ b/arch/arc/dts/nsim.dts
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Copyright (C) 2015-2016 Synopsys, Inc. (www.synopsys.com)
+ * Copyright (C) 2015-2016, 2020 Synopsys, Inc. (www.synopsys.com)
  */
 /dts-v1/;
 
@@ -10,7 +10,7 @@
model = "snps,nsim";
 
aliases {
-   console = 
+   console = 
};
 
cpu_card {
@@ -22,9 +22,11 @@
};
};
 
-   arcuart0: serial@0xc0fc1000 {
-   compatible = "snps,arc-uart";
-   reg = <0xc0fc1000 0x100>;
+   uart0: serial@f000 {
+   compatible = "snps,dw-apb-uart";
+   reg = <0xf000 0x1000>;
+   reg-shift = <2>;
+   reg-io-width = <4>;
clock-frequency = <7000>;
};
 
diff --git a/configs/nsim_700_defconfig b/configs/nsim_700_defconfig
index 5633113b09..2d4a58b178 100644
--- a/configs/nsim_700_defconfig
+++ b/configs/nsim_700_defconfig
@@ -1,13 +1,13 @@
 CONFIG_ARC=y
 CONFIG_TARGET_NSIM=y
 CONFIG_SYS_TEXT_BASE=0x8100
-CONFIG_DEBUG_UART_BASE=0xc0fc1000
+CONFIG_DEBUG_UART_BASE=0xf000
 CONFIG_DEBUG_UART_CLOCK=7000
 CONFIG_SYS_CLK_FREQ=7000
 CONFIG_DEBUG_UART=y
 CONFIG_BOOTDELAY=3
 CONFIG_USE_BOOTARGS=y
-CONFIG_BOOTARGS="console=ttyARC0,115200n8"
+CONFIG_BOOTARGS="console=ttyS0,115200n8"
 CONFIG_SYS_PROMPT="nsim# "
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_OF_CONTROL=y
@@ -16,6 +16,6 @@ CONFIG_DEFAULT_DEVICE_TREE="nsim"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_DM=y
 CONFIG_DM_SERIAL=y
-CONFIG_DEBUG_ARC_SERIAL=y
-CONFIG_ARC_SERIAL=y
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550=y
 CONFIG_USE_PRIVATE_LIBGCC=y
diff --git a/configs/nsim_700be_defconfig b/configs/nsim_700be_defconfig
index 40f7ec7e1f..61eea91449 100644
--- a/configs/nsim_700be_defconfig
+++ b/configs/nsim_700be_defconfig
@@ -2,13 +2,13 @@ CONFIG_ARC=y
 CONFIG_CPU_BIG_ENDIAN=y
 CONFIG_TARGET_NSIM=y
 CONFIG_SYS_TEXT_BASE=0x8100
-CONFIG_DEBUG_UART_BASE=0xc0fc1000
+CONFIG_DEBUG_UART_BASE=0xf000
 CONFIG_DEBUG_UART_CLOCK=7000
 CONFIG_SYS_CLK_FREQ=7000
 CONFIG_DEBUG_UART=y
 CONFIG_BOOTDELAY=3
 CONFIG_USE_BOOTARGS=y
-CONFIG_BOOTARGS="console=ttyARC0,115200n8"
+CONFIG_BOOTARGS="console=ttyS0,115200n8"
 CONFIG_SYS_PROMPT="nsim# "
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_OF_CONTROL=y
@@ -17,6 +17,6 @@ CONFIG_DEFAULT_DEVICE_TREE="nsim"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_DM=y
 CONFIG_DM_SERIAL=y
-CONFIG_DEBUG_ARC_SERIAL=y
-CONFIG_ARC_SERIAL=y
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550=y
 CONFIG_USE_PRIVATE_LIBGCC=y
diff --git a/configs/nsim_hs38_defconfig b/configs/nsim_hs38_defconfig
index 2820a6fca3..ce68de3251 100644
--- a/configs/nsim_hs38_defconfig
+++ b/configs/nsim_hs38_defconfig
@@ -2,13 +2,13 @@ CONFIG_ARC=y
 CONFIG_ISA_ARCV2=y
 CONFIG_TARGET_NSIM=y
 CONFIG_SYS_TEXT_BASE=0x8100
-CONFIG_DEBUG_UART_BASE=0xc0fc1000
+CONFIG_DEBUG_UART_BASE=0xf000
 CONFIG_DEBUG_UART_CLOCK=7000
 CONFIG_SYS_CLK_FREQ=7000
 CONFIG_DEBUG_UART=y
 CONFIG_BOOTDELAY=3
 CONFIG_USE_BOOTARGS=y
-CONFIG_BOOTARGS="console=ttyARC0,115200n8"
+CONFIG_BOOTARGS="console=ttyS0,115200n8"
 CONFIG_SYS_PROMPT="nsim# "
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_OF_CONTROL=y
@@ -17,6 +17,6 @@ CONFIG_DEFAULT_DEVICE_TREE="nsim"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_DM=y
 CONFIG_DM_SERIAL=y
-CONFIG_DEBUG_ARC_SERIAL=y
-CONFIG_ARC_SERIAL=y
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550=y
 CONFIG_USE_PRIVATE_LIBGCC=y
diff --git a/configs/nsim_hs38be_defconfig b/configs/nsim_hs38be_defconfig
index e533fae2b1..5d2ea59d52 100644
--- a/configs/nsim_hs38be_defconfig
+++ b/configs/nsim_hs38be_defconfig
@@ -3,13 +3,13 @@ CONFIG_ISA_ARCV2=y
 CONFIG_CPU_BIG_ENDIAN=y
 CONFIG_TARGET_NSIM=y
 CONFIG_SYS_TEXT_BASE=0x8100
-CONFIG_DEBUG_UART_BASE=0xc0fc1000
+CONFIG_DEBUG_UART_BASE=0xf000
 CONFIG_DEBUG_UART_CLOCK=7000
 CONFIG_SYS_CLK_FREQ=7000
 CONFIG_DEBUG_UART=y
 CONFIG_BOOTDELAY=3
 CONFIG_USE_BOOT

[PATCH 3/3 v2] ARC: nsim_hs38: Add support of Virtio NET & BLK

2020-02-12 Thread Alexey Brodkin
Given now nsim_hs38 configuration is usable on QEMU and in QEMU
we have Virtio working perfectly fine the next logical step
is to add support of supported & known to work net & bkl to this
config.

Signed-off-by: Alexey Brodkin 
---

Changes v1 -> v2:

 * Instead of adding IRQ parent it might be much cleaner solution
   to just get rid of "interrupt" properties in Virtio nodes.
   Again that's all OK for now since we don't really sync Linux .dts
   and U-Boot's ones. It's not that it's super good though but
   that's what we have today :)

 arch/arc/Kconfig  |  4 ++--
 arch/arc/dts/nsim.dts | 24 
 board/synopsys/{ => nsim}/Kconfig |  3 +++
 board/synopsys/nsim/MAINTAINERS   |  6 ++
 board/synopsys/nsim/Makefile  |  7 +++
 board/synopsys/nsim/nsim.c| 26 ++
 configs/nsim_hs38_defconfig   |  9 +
 7 files changed, 77 insertions(+), 2 deletions(-)
 rename board/synopsys/{ => nsim}/Kconfig (74%)
 create mode 100644 board/synopsys/nsim/MAINTAINERS
 create mode 100644 board/synopsys/nsim/Makefile
 create mode 100644 board/synopsys/nsim/nsim.c

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 0cb97207db..545fc3e243 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -160,7 +160,7 @@ config TARGET_TB100
bool "Support tb100"
 
 config TARGET_NSIM
-   bool "Support standalone nSIM & Free nSIM"
+   bool "Support ARC simulation & prototyping platforms"
 
 config TARGET_AXS101
bool "Support Synopsys Designware SDP board AXS101"
@@ -184,10 +184,10 @@ config TARGET_IOT_DEVKIT
 endchoice
 
 source "board/abilis/tb100/Kconfig"
-source "board/synopsys/Kconfig"
 source "board/synopsys/axs10x/Kconfig"
 source "board/synopsys/emsdp/Kconfig"
 source "board/synopsys/hsdk/Kconfig"
 source "board/synopsys/iot_devkit/Kconfig"
+source "board/synopsys/nsim/Kconfig"
 
 endmenu
diff --git a/arch/arc/dts/nsim.dts b/arch/arc/dts/nsim.dts
index 43f281dfec..c2899ef2ea 100644
--- a/arch/arc/dts/nsim.dts
+++ b/arch/arc/dts/nsim.dts
@@ -30,4 +30,28 @@
clock-frequency = <7000>;
};
 
+   virtio0: virtio@f010 {
+   compatible = "virtio,mmio";
+   reg = <0xf010 0x2000>;
+   };
+
+   virtio1: virtio@f0102000 {
+   compatible = "virtio,mmio";
+   reg = <0xf0102000 0x2000>;
+   };
+
+   virtio2: virtio@f0104000 {
+   compatible = "virtio,mmio";
+   reg = <0xf0104000 0x2000>;
+   };
+
+   virtio3: virtio@f0106000 {
+   compatible = "virtio,mmio";
+   reg = <0xf0106000 0x2000>;
+   };
+
+   virtio4: virtio@f0108000 {
+   compatible = "virtio,mmio";
+   reg = <0xf0108000 0x2000>;
+   };
 };
diff --git a/board/synopsys/Kconfig b/board/synopsys/nsim/Kconfig
similarity index 74%
rename from board/synopsys/Kconfig
rename to board/synopsys/nsim/Kconfig
index 27e5509b26..22287032bf 100644
--- a/board/synopsys/Kconfig
+++ b/board/synopsys/nsim/Kconfig
@@ -1,5 +1,8 @@
 if TARGET_NSIM
 
+config SYS_BOARD
+   default "nsim"
+
 config SYS_VENDOR
default "synopsys"
 
diff --git a/board/synopsys/nsim/MAINTAINERS b/board/synopsys/nsim/MAINTAINERS
new file mode 100644
index 00..ad23c8338e
--- /dev/null
+++ b/board/synopsys/nsim/MAINTAINERS
@@ -0,0 +1,6 @@
+ARC SIMULATION & PROTOTYPING PLATFORMS
+M: Alexey Brodkin 
+S: Maintained
+F: arch/arc/dts/nsim.dts
+F: board/synopsys/nsim/
+F: configs/nsim_*_defconfig
diff --git a/board/synopsys/nsim/Makefile b/board/synopsys/nsim/Makefile
new file mode 100644
index 00..6aaa73
--- /dev/null
+++ b/board/synopsys/nsim/Makefile
@@ -0,0 +1,7 @@
+#
+# Copyright (C) 2020 Synopsys, Inc. All rights reserved.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  += nsim.o
diff --git a/board/synopsys/nsim/nsim.c b/board/synopsys/nsim/nsim.c
new file mode 100644
index 00..f384f707f6
--- /dev/null
+++ b/board/synopsys/nsim/nsim.c
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Synopsys, Inc. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+int board_early_init_r(void)
+{
+   /*
+* Make sure virtio bus is enumerated so that peripherals
+* on the virtio bus can be discovered by their drivers
+*/
+   virtio_init();
+
+   return 0;
+}
+
+int checkboard(void)
+{
+   printf("Board: ARC virtual or prototyping platform\n");
+   return 0;
+};
diff --git a/configs/nsim_hs38_defconfig b/configs/nsim_hs38_defconfig
index ce68de3251..6cd01a505b 100644
--- a/configs/nsim_hs38_defconfi

[RFC 1/2] include: Import non-atomic.h from Linux

2020-01-20 Thread Alexey Brodkin
This header contains implementations of some common bit ops:
 * __set_bit()/__clear_bit()/__change_bit()/test_bit()
 * __test_and_set_bit()/__test_and_clear_bit()/__test_and_change_bit()

No point in copy-pasting that again & again.

Signed-off-by: Alexey Brodkin 
---
 include/asm-generic/bitops/non-atomic.h | 109 
 1 file changed, 109 insertions(+)
 create mode 100644 include/asm-generic/bitops/non-atomic.h

diff --git a/include/asm-generic/bitops/non-atomic.h 
b/include/asm-generic/bitops/non-atomic.h
new file mode 100644
index 00..9b3be37fff
--- /dev/null
+++ b/include/asm-generic/bitops/non-atomic.h
@@ -0,0 +1,109 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_GENERIC_BITOPS_NON_ATOMIC_H_
+#define _ASM_GENERIC_BITOPS_NON_ATOMIC_H_
+
+#include 
+
+/**
+ * __set_bit - Set a bit in memory
+ * @nr: the bit to set
+ * @addr: the address to start counting from
+ *
+ * Unlike set_bit(), this function is non-atomic and may be reordered.
+ * If it's called on the same region of memory simultaneously, the effect
+ * may be that only one operation succeeds.
+ */
+static inline void __set_bit(int nr, volatile unsigned long *addr)
+{
+   unsigned long mask = BIT_MASK(nr);
+   unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+
+   *p  |= mask;
+}
+
+static inline void __clear_bit(int nr, volatile unsigned long *addr)
+{
+   unsigned long mask = BIT_MASK(nr);
+   unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+
+   *p &= ~mask;
+}
+
+/**
+ * __change_bit - Toggle a bit in memory
+ * @nr: the bit to change
+ * @addr: the address to start counting from
+ *
+ * Unlike change_bit(), this function is non-atomic and may be reordered.
+ * If it's called on the same region of memory simultaneously, the effect
+ * may be that only one operation succeeds.
+ */
+static inline void __change_bit(int nr, volatile unsigned long *addr)
+{
+   unsigned long mask = BIT_MASK(nr);
+   unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+
+   *p ^= mask;
+}
+
+/**
+ * __test_and_set_bit - Set a bit and return its old value
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic and can be reordered.
+ * If two examples of this operation race, one can appear to succeed
+ * but actually fail.  You must protect multiple accesses with a lock.
+ */
+static inline int __test_and_set_bit(int nr, volatile unsigned long *addr)
+{
+   unsigned long mask = BIT_MASK(nr);
+   unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+   unsigned long old = *p;
+
+   *p = old | mask;
+   return (old & mask) != 0;
+}
+
+/**
+ * __test_and_clear_bit - Clear a bit and return its old value
+ * @nr: Bit to clear
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic and can be reordered.
+ * If two examples of this operation race, one can appear to succeed
+ * but actually fail.  You must protect multiple accesses with a lock.
+ */
+static inline int __test_and_clear_bit(int nr, volatile unsigned long *addr)
+{
+   unsigned long mask = BIT_MASK(nr);
+   unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+   unsigned long old = *p;
+
+   *p = old & ~mask;
+   return (old & mask) != 0;
+}
+
+/* WARNING: non atomic and it can be reordered! */
+static inline int __test_and_change_bit(int nr,
+   volatile unsigned long *addr)
+{
+   unsigned long mask = BIT_MASK(nr);
+   unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+   unsigned long old = *p;
+
+   *p = old ^ mask;
+   return (old & mask) != 0;
+}
+
+/**
+ * test_bit - Determine whether a bit is set
+ * @nr: bit number to test
+ * @addr: Address to start counting from
+ */
+static inline int test_bit(int nr, const volatile unsigned long *addr)
+{
+   return 1UL & (addr[BIT_WORD(nr)] >> (nr & (BITS_PER_LONG - 1)));
+}
+
+#endif /* _ASM_GENERIC_BITOPS_NON_ATOMIC_H_ */
-- 
2.16.2


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


[RFC 2/2] ARC: Add support of bitops via generic implementation

2020-01-20 Thread Alexey Brodkin
This allows building more things. In particular with
CONFIG_PKCS7_MESSAGE_PARSER=y we saw this:
>8--
lib/crypto/pkcs7_parser.c: In function 'pkcs7_sig_note_authenticated_attr':
lib/crypto/pkcs7_parser.c:489:7: warning: implicit declaration of function 
'__test_and_set_bit' [-Wimplicit-function-declaration]
  489 |   if (__test_and_set_bit(sinfo_has_content_type, >aa_set))
  |   ^~
  CC  lib/crc32.o
  CC  lib/ctype.o
  DTB test/overlay/test-fdt-overlay-stacked.dtb.S
  CC  lib/div64.o
lib/crypto/pkcs7_parser.c: In function 'pkcs7_sig_note_set_of_authattrs':
lib/crypto/pkcs7_parser.c:572:7: warning: implicit declaration of function 
'test_bit' [-Wimplicit-function-declaration]
  572 |  if (!test_bit(sinfo_has_content_type, >aa_set) ||
...
  LD  u-boot
arc-elf32-ld.bfd: lib/built-in.o: in function 
'pkcs7_sig_note_authenticated_attr':
.../lib/crypto/pkcs7_parser.c:489: undefined reference to '__test_and_set_bit'
arc-elf32-ld.bfd: .../lib/crypto/pkcs7_parser.c:489: undefined reference to 
'__test_and_set_bit'
arc-elf32-ld.bfd: .../lib/crypto/pkcs7_parser.c:501: undefined reference to 
'__test_and_set_bit'
arc-elf32-ld.bfd: .../lib/crypto/pkcs7_parser.c:501: undefined reference to 
'__test_and_set_bit'
arc-elf32-ld.bfd: .../lib/crypto/pkcs7_parser.c:510: undefined reference to 
'__test_and_set_bit'
arc-elf32-ld.bfd: lib/built-in.o:.../lib/crypto/pkcs7_parser.c:510: more 
undefined references to '__test_and_set_bit' follow
arc-elf32-ld.bfd: lib/built-in.o: in function 'pkcs7_sig_note_set_of_authattrs':
.../lib/crypto/pkcs7_parser.c:572: undefined reference to `test_bit'
arc-elf32-ld.bfd: .../lib/crypto/pkcs7_parser.c:572: undefined reference to 
`test_bit'
arc-elf32-ld.bfd: .../lib/crypto/pkcs7_parser.c:573: undefined reference to 
`test_bit'
arc-elf32-ld.bfd: .../lib/crypto/pkcs7_parser.c:573: undefined reference to 
`test_bit'
arc-elf32-ld.bfd: .../lib/crypto/pkcs7_parser.c:579: undefined reference to 
`test_bit'
arc-elf32-ld.bfd: lib/built-in.o:.../lib/crypto/pkcs7_parser.c:579: more 
undefined references to 'test_bit' follow
>8--

Signed-off-by: Alexey Brodkin 
---
 arch/arc/include/asm/bitops.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arc/include/asm/bitops.h b/arch/arc/include/asm/bitops.h
index c6dd28ecef..daa07e80a8 100644
--- a/arch/arc/include/asm/bitops.h
+++ b/arch/arc/include/asm/bitops.h
@@ -19,5 +19,6 @@
 #include 
 #include 
 #include 
+#include 
 
 #endif /* __ASM_ARC_BITOPS_H */
-- 
2.16.2


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


[RFC 0/2] Import and use non-atomic bit-ops

2020-01-20 Thread Alexey Brodkin
The following bitops are implemented pretty similarly for many
arches and now when we faced a need in them on ARC I guess there's
no point in copy-pasting them yet another time but instead it might
be better re-use generic version from the Linux kernel.

Since we had non of those bitops for ARC inclusion of imported header
works perfectly fine. As for other arches I do see they use a bit different
implementation but those might be just older versions etc.

Sobefore breaking stuff for other arches I'd like to get some feedback
from maintainers. Or we may just import proposed header and switch to
its usage arch-by-arch whenever people feel kile cleaning-up their bitops.

Alexey Brodkin (2):
  include: Import non-atomic.h from Linux
  ARC: Add support of bitops via generic implementation

 arch/arc/include/asm/bitops.h   |   1 +
 include/asm-generic/bitops/non-atomic.h | 109 
 2 files changed, 110 insertions(+)
 create mode 100644 include/asm-generic/bitops/non-atomic.h

-- 
2.16.2


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


[PATCH 1/3] ARC: nSIM: switch from ARC UART to DW UART

2020-01-20 Thread Alexey Brodkin
Since v2019.06 DesingWare nSIM supports DesignWare UART simulation
and so we may switch from pretty unusual ARC UART to much more standard
DesignWare UART (which in case of U-Boot is just an ordinary 16650 UART).

This among other things makes built dinaries compatible with our other
platforms to name a few: FPGA-based HAPS boards, QEMU and even ZeBU.

Signed-off-by: Alexey Brodkin 
---
 arch/arc/dts/nsim.dts | 12 +++-
 configs/nsim_700_defconfig|  8 
 configs/nsim_700be_defconfig  |  8 
 configs/nsim_hs38_defconfig   |  8 
 configs/nsim_hs38be_defconfig |  8 
 5 files changed, 23 insertions(+), 21 deletions(-)

diff --git a/arch/arc/dts/nsim.dts b/arch/arc/dts/nsim.dts
index 243ecb178e..a3f3964d35 100644
--- a/arch/arc/dts/nsim.dts
+++ b/arch/arc/dts/nsim.dts
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Copyright (C) 2015-2016 Synopsys, Inc. (www.synopsys.com)
+ * Copyright (C) 2015-2016, 2019 Synopsys, Inc. (www.synopsys.com)
  */
 /dts-v1/;
 
@@ -10,7 +10,7 @@
model = "snps,nsim";
 
aliases {
-   console = 
+   console = 
};
 
cpu_card {
@@ -22,9 +22,11 @@
};
};
 
-   arcuart0: serial@0xc0fc1000 {
-   compatible = "snps,arc-uart";
-   reg = <0xc0fc1000 0x100>;
+   uart0: serial@f000 {
+   compatible = "snps,dw-apb-uart";
+   reg = <0xf000 0x1000>;
+   reg-shift = <2>;
+   reg-io-width = <4>;
clock-frequency = <7000>;
};
 
diff --git a/configs/nsim_700_defconfig b/configs/nsim_700_defconfig
index 5633113b09..2d4a58b178 100644
--- a/configs/nsim_700_defconfig
+++ b/configs/nsim_700_defconfig
@@ -1,13 +1,13 @@
 CONFIG_ARC=y
 CONFIG_TARGET_NSIM=y
 CONFIG_SYS_TEXT_BASE=0x8100
-CONFIG_DEBUG_UART_BASE=0xc0fc1000
+CONFIG_DEBUG_UART_BASE=0xf000
 CONFIG_DEBUG_UART_CLOCK=7000
 CONFIG_SYS_CLK_FREQ=7000
 CONFIG_DEBUG_UART=y
 CONFIG_BOOTDELAY=3
 CONFIG_USE_BOOTARGS=y
-CONFIG_BOOTARGS="console=ttyARC0,115200n8"
+CONFIG_BOOTARGS="console=ttyS0,115200n8"
 CONFIG_SYS_PROMPT="nsim# "
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_OF_CONTROL=y
@@ -16,6 +16,6 @@ CONFIG_DEFAULT_DEVICE_TREE="nsim"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_DM=y
 CONFIG_DM_SERIAL=y
-CONFIG_DEBUG_ARC_SERIAL=y
-CONFIG_ARC_SERIAL=y
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550=y
 CONFIG_USE_PRIVATE_LIBGCC=y
diff --git a/configs/nsim_700be_defconfig b/configs/nsim_700be_defconfig
index 40f7ec7e1f..61eea91449 100644
--- a/configs/nsim_700be_defconfig
+++ b/configs/nsim_700be_defconfig
@@ -2,13 +2,13 @@ CONFIG_ARC=y
 CONFIG_CPU_BIG_ENDIAN=y
 CONFIG_TARGET_NSIM=y
 CONFIG_SYS_TEXT_BASE=0x8100
-CONFIG_DEBUG_UART_BASE=0xc0fc1000
+CONFIG_DEBUG_UART_BASE=0xf000
 CONFIG_DEBUG_UART_CLOCK=7000
 CONFIG_SYS_CLK_FREQ=7000
 CONFIG_DEBUG_UART=y
 CONFIG_BOOTDELAY=3
 CONFIG_USE_BOOTARGS=y
-CONFIG_BOOTARGS="console=ttyARC0,115200n8"
+CONFIG_BOOTARGS="console=ttyS0,115200n8"
 CONFIG_SYS_PROMPT="nsim# "
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_OF_CONTROL=y
@@ -17,6 +17,6 @@ CONFIG_DEFAULT_DEVICE_TREE="nsim"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_DM=y
 CONFIG_DM_SERIAL=y
-CONFIG_DEBUG_ARC_SERIAL=y
-CONFIG_ARC_SERIAL=y
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550=y
 CONFIG_USE_PRIVATE_LIBGCC=y
diff --git a/configs/nsim_hs38_defconfig b/configs/nsim_hs38_defconfig
index 2820a6fca3..ce68de3251 100644
--- a/configs/nsim_hs38_defconfig
+++ b/configs/nsim_hs38_defconfig
@@ -2,13 +2,13 @@ CONFIG_ARC=y
 CONFIG_ISA_ARCV2=y
 CONFIG_TARGET_NSIM=y
 CONFIG_SYS_TEXT_BASE=0x8100
-CONFIG_DEBUG_UART_BASE=0xc0fc1000
+CONFIG_DEBUG_UART_BASE=0xf000
 CONFIG_DEBUG_UART_CLOCK=7000
 CONFIG_SYS_CLK_FREQ=7000
 CONFIG_DEBUG_UART=y
 CONFIG_BOOTDELAY=3
 CONFIG_USE_BOOTARGS=y
-CONFIG_BOOTARGS="console=ttyARC0,115200n8"
+CONFIG_BOOTARGS="console=ttyS0,115200n8"
 CONFIG_SYS_PROMPT="nsim# "
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_OF_CONTROL=y
@@ -17,6 +17,6 @@ CONFIG_DEFAULT_DEVICE_TREE="nsim"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_DM=y
 CONFIG_DM_SERIAL=y
-CONFIG_DEBUG_ARC_SERIAL=y
-CONFIG_ARC_SERIAL=y
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550=y
 CONFIG_USE_PRIVATE_LIBGCC=y
diff --git a/configs/nsim_hs38be_defconfig b/configs/nsim_hs38be_defconfig
index e533fae2b1..5d2ea59d52 100644
--- a/configs/nsim_hs38be_defconfig
+++ b/configs/nsim_hs38be_defconfig
@@ -3,13 +3,13 @@ CONFIG_ISA_ARCV2=y
 CONFIG_CPU_BIG_ENDIAN=y
 CONFIG_TARGET_NSIM=y
 CONFIG_SYS_TEXT_BASE=0x8100
-CONFIG_DEBUG_UART_BASE=0xc0fc1000
+CONFIG_DEBUG_UART_BASE=0xf000
 CONFIG_DEBUG_UART_CLOCK=7000
 CONFIG_SYS_CLK_FREQ=7000
 CONFIG_DEBUG_UART=y
 CONFIG_BOOTDELAY=3
 CONFIG_USE_BOOTARGS=y
-CONFIG_BOOTARGS="console=ttyARC0

[PATCH 2/3] ARC: nsim_{700|700be|hs38be}_defconfigs: Disable networking

2020-01-20 Thread Alexey Brodkin
We don't have yet any brc700 or big-enadian platforms with networking
support to run this particular configuration.

Whenever QEMU for ARC supports arc700 or big-endian targets we may revisit
this one.

Signed-off-by: Alexey Brodkin 
---
 configs/nsim_700_defconfig| 1 +
 configs/nsim_700be_defconfig  | 1 +
 configs/nsim_hs38be_defconfig | 1 +
 3 files changed, 3 insertions(+)

diff --git a/configs/nsim_700_defconfig b/configs/nsim_700_defconfig
index 2d4a58b178..6a38e2c246 100644
--- a/configs/nsim_700_defconfig
+++ b/configs/nsim_700_defconfig
@@ -14,6 +14,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_OF_EMBED=y
 CONFIG_DEFAULT_DEVICE_TREE="nsim"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+# CONFIG_NET is not set
 CONFIG_DM=y
 CONFIG_DM_SERIAL=y
 CONFIG_DEBUG_UART_SHIFT=2
diff --git a/configs/nsim_700be_defconfig b/configs/nsim_700be_defconfig
index 61eea91449..d3ed84a415 100644
--- a/configs/nsim_700be_defconfig
+++ b/configs/nsim_700be_defconfig
@@ -15,6 +15,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_OF_EMBED=y
 CONFIG_DEFAULT_DEVICE_TREE="nsim"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+# CONFIG_NET is not set
 CONFIG_DM=y
 CONFIG_DM_SERIAL=y
 CONFIG_DEBUG_UART_SHIFT=2
diff --git a/configs/nsim_hs38be_defconfig b/configs/nsim_hs38be_defconfig
index 5d2ea59d52..b074b4ca98 100644
--- a/configs/nsim_hs38be_defconfig
+++ b/configs/nsim_hs38be_defconfig
@@ -16,6 +16,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_OF_EMBED=y
 CONFIG_DEFAULT_DEVICE_TREE="nsim"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+# CONFIG_NET is not set
 CONFIG_DM=y
 CONFIG_DM_SERIAL=y
 CONFIG_DEBUG_UART_SHIFT=2
-- 
2.16.2


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


[PATCH 3/3] ARC: nsim_hs38: Add support of Virtio NET & BLK

2020-01-20 Thread Alexey Brodkin
Given now nsim_hs38 configuration is usable on QEMU and in QEMU
we have Virtio working perfectly fine the next logical step
is to add support of supported & known to work net & bkl to this
config.

Note so far we don't have device tree descriptions synced from
the mainline Linux kernel (which we'll need to do anyway at some point)
and as of now we keep U-Boot's device trees as minimalistic as possible
in nSIM description we had to add core's interrupt controller node and
set it as everyone's interrupt-parent. That's required to make buildman
happy. Otherwise it complains like that:
>8
w+arch/arc/dts/nsim.dtb: Warning (interrupts_property): /virtio@f010: 
Missing interrupt-parent
>8

Signed-off-by: Alexey Brodkin 
---
 arch/arc/Kconfig  |  4 ++--
 arch/arc/dts/nsim.dts | 36 
 board/synopsys/{ => nsim}/Kconfig |  3 +++
 board/synopsys/nsim/MAINTAINERS   |  6 ++
 board/synopsys/nsim/Makefile  |  7 +++
 board/synopsys/nsim/nsim.c| 26 ++
 configs/nsim_hs38_defconfig   |  9 +
 7 files changed, 89 insertions(+), 2 deletions(-)
 rename board/synopsys/{ => nsim}/Kconfig (74%)
 create mode 100644 board/synopsys/nsim/MAINTAINERS
 create mode 100644 board/synopsys/nsim/Makefile
 create mode 100644 board/synopsys/nsim/nsim.c

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 0cb97207db..545fc3e243 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -160,7 +160,7 @@ config TARGET_TB100
bool "Support tb100"
 
 config TARGET_NSIM
-   bool "Support standalone nSIM & Free nSIM"
+   bool "Support ARC simulation & prototyping platforms"
 
 config TARGET_AXS101
bool "Support Synopsys Designware SDP board AXS101"
@@ -184,10 +184,10 @@ config TARGET_IOT_DEVKIT
 endchoice
 
 source "board/abilis/tb100/Kconfig"
-source "board/synopsys/Kconfig"
 source "board/synopsys/axs10x/Kconfig"
 source "board/synopsys/emsdp/Kconfig"
 source "board/synopsys/hsdk/Kconfig"
 source "board/synopsys/iot_devkit/Kconfig"
+source "board/synopsys/nsim/Kconfig"
 
 endmenu
diff --git a/arch/arc/dts/nsim.dts b/arch/arc/dts/nsim.dts
index a3f3964d35..a902c4c4fa 100644
--- a/arch/arc/dts/nsim.dts
+++ b/arch/arc/dts/nsim.dts
@@ -8,6 +8,7 @@
 
 / {
model = "snps,nsim";
+   interrupt-parent = <_intc>;
 
aliases {
console = 
@@ -20,6 +21,12 @@
clock-frequency = <7000>;
u-boot,dm-pre-reloc;
};
+
+   core_intc: interrupt-controller {
+   compatible = "snps,archs-intc";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   };
};
 
uart0: serial@f000 {
@@ -30,4 +37,33 @@
clock-frequency = <7000>;
};
 
+   virtio0: virtio@f010 {
+   compatible = "virtio,mmio";
+   reg = <0xf010 0x2000>;
+   interrupts = <31>;
+   };
+
+   virtio1: virtio@f0102000 {
+   compatible = "virtio,mmio";
+   reg = <0xf0102000 0x2000>;
+   interrupts = <32>;
+   };
+
+   virtio2: virtio@f0104000 {
+   compatible = "virtio,mmio";
+   reg = <0xf0104000 0x2000>;
+   interrupts = <33>;
+   };
+
+   virtio3: virtio@f0106000 {
+   compatible = "virtio,mmio";
+   reg = <0xf0106000 0x2000>;
+   interrupts = <34>;
+   };
+
+   virtio4: virtio@f0108000 {
+   compatible = "virtio,mmio";
+   reg = <0xf0108000 0x2000>;
+   interrupts = <35>;
+   };
 };
diff --git a/board/synopsys/Kconfig b/board/synopsys/nsim/Kconfig
similarity index 74%
rename from board/synopsys/Kconfig
rename to board/synopsys/nsim/Kconfig
index 27e5509b26..22287032bf 100644
--- a/board/synopsys/Kconfig
+++ b/board/synopsys/nsim/Kconfig
@@ -1,5 +1,8 @@
 if TARGET_NSIM
 
+config SYS_BOARD
+   default "nsim"
+
 config SYS_VENDOR
default "synopsys"
 
diff --git a/board/synopsys/nsim/MAINTAINERS b/board/synopsys/nsim/MAINTAINERS
new file mode 100644
index 00..ed4b9a9e78
--- /dev/null
+++ b/board/synopsys/nsim/MAINTAINERS
@@ -0,0 +1,6 @@
+EM DEVELOPMENT KIT BOARD
+M: Alexey Brodkin 
+S: Maintained
+F: arch/arc/dts/nsim.dts
+F: board/synopsys/nsim/
+F: configs/nsim_*_defconfig
diff --git a/board/synopsys/nsim/Makefile b/board/synopsys/nsim/Makefile
new file mode 100644
index 00

[PATCH 0/3] Improvements for ARC simulation platform

2020-01-20 Thread Alexey Brodkin
Along with some clean-up we make 2 important changes:
 1. Switch to more standard 16550 UART instead of our custom "ARC UART".
This paves the way for using this board in QEMU.

 2. Now when nSIM virtual board is usable in QEMU we add support of Virtio
NIC & block device similarly as we did that in the Linux kernel [1].

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=94b8beb972c524f42078281c9950ed3a946455fa

Alexey Brodkin (3):
  ARC: nSIM: switch from ARC UART to DW UART
  ARC: nsim_{700|700be|hs38be}_defconfigs: Disable networking
  ARC: nsim_hs38: Add support of Virtio NET & BLK

 arch/arc/Kconfig  |  4 ++--
 arch/arc/dts/nsim.dts | 48 +++
 board/synopsys/{ => nsim}/Kconfig |  3 +++
 board/synopsys/nsim/MAINTAINERS   |  6 +
 board/synopsys/nsim/Makefile  |  7 ++
 board/synopsys/nsim/nsim.c| 26 +
 configs/nsim_700_defconfig|  9 
 configs/nsim_700be_defconfig  |  9 
 configs/nsim_hs38_defconfig   | 17 ++
 configs/nsim_hs38be_defconfig |  9 
 10 files changed, 115 insertions(+), 23 deletions(-)
 rename board/synopsys/{ => nsim}/Kconfig (74%)
 create mode 100644 board/synopsys/nsim/MAINTAINERS
 create mode 100644 board/synopsys/nsim/Makefile
 create mode 100644 board/synopsys/nsim/nsim.c

-- 
2.16.2


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


[PATCH] ARC: Switch to generic accessors

2020-01-20 Thread Alexey Brodkin
First of all U-Boot is not that performance oriented as real run-time
software like OS or user bare-metal app so we may afford being not super
fast as we only being executed once. That in return allows us to be more
universal and support wider variety of devices.

And looking forward that will significantly reduce maintenance and simplify
support of newer architectures.

And while at it we add quad-word accessors like readq(), writeq() etc.

Signed-off-by: Alexey Brodkin 
---
 arch/arc/include/asm/io.h | 204 +-
 1 file changed, 75 insertions(+), 129 deletions(-)

diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
index fa844b54f4..70d050590d 100644
--- a/arch/arc/include/asm/io.h
+++ b/arch/arc/include/asm/io.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /*
- * Copyright (C) 2013-2014 Synopsys, Inc. All rights reserved.
+ * Copyright (C) 2013-2014, 2020 Synopsys, Inc. All rights reserved.
  */
 
 #ifndef __ASM_ARC_IO_H
@@ -54,135 +54,98 @@ static inline void sync(void)
/* Not yet implemented */
 }
 
-static inline u8 __raw_readb(const volatile void __iomem *addr)
-{
-   u8 b;
+#define __arch_getb(a) (*(unsigned char *)(a))
+#define __arch_getw(a) (*(unsigned short *)(a))
+#define __arch_getl(a) (*(unsigned int *)(a))
+#define __arch_getq(a) (*(unsigned long long *)(a))
 
-   __asm__ __volatile__("ldb%U1%0, %1\n"
-: "=r" (b)
-: "m" (*(volatile u8 __force *)addr)
-: "memory");
-   return b;
-}
+#define __arch_putb(v, a)  (*(unsigned char *)(a) = (v))
+#define __arch_putw(v, a)  (*(unsigned short *)(a) = (v))
+#define __arch_putl(v, a)  (*(unsigned int *)(a) = (v))
+#define __arch_putq(v, a)  (*(unsigned long long *)(a) = (v))
 
-static inline u16 __raw_readw(const volatile void __iomem *addr)
-{
-   u16 s;
+#define __raw_writeb(v, a) __arch_putb(v, a)
+#define __raw_writew(v, a) __arch_putw(v, a)
+#define __raw_writel(v, a) __arch_putl(v, a)
+#define __raw_writeq(v, a) __arch_putq(v, a)
 
-   __asm__ __volatile__("ldw%U1%0, %1\n"
-: "=r" (s)
-: "m" (*(volatile u16 __force *)addr)
-: "memory");
-   return s;
-}
+#define __raw_readb(a) __arch_getb(a)
+#define __raw_readw(a) __arch_getw(a)
+#define __raw_readl(a) __arch_getl(a)
+#define __raw_readq(a) __arch_getq(a)
 
-static inline u32 __raw_readl(const volatile void __iomem *addr)
+static inline void __raw_writesb(unsigned long addr, const void *data,
+int bytelen)
 {
-   u32 w;
+   u8 *buf = (uint8_t *)data;
 
-   __asm__ __volatile__("ld%U1 %0, %1\n"
-: "=r" (w)
-: "m" (*(volatile u32 __force *)addr)
-: "memory");
-   return w;
+   while (bytelen--)
+   __arch_putb(*buf++, addr);
 }
 
-static inline void __raw_writeb(u8 b, volatile void __iomem *addr)
+static inline void __raw_writesw(unsigned long addr, const void *data,
+int wordlen)
 {
-   __asm__ __volatile__("stb%U1%0, %1\n"
-:
-: "r" (b), "m" (*(volatile u8 __force *)addr)
-: "memory");
-}
+   u16 *buf = (uint16_t *)data;
 
-static inline void __raw_writew(u16 s, volatile void __iomem *addr)
-{
-   __asm__ __volatile__("stw%U1%0, %1\n"
-:
-: "r" (s), "m" (*(volatile u16 __force *)addr)
-: "memory");
+   while (wordlen--)
+   __arch_putw(*buf++, addr);
 }
 
-static inline void __raw_writel(u32 w, volatile void __iomem *addr)
+static inline void __raw_writesl(unsigned long addr, const void *data,
+int longlen)
 {
-   __asm__ __volatile__("st%U1 %0, %1\n"
-:
-: "r" (w), "m" (*(volatile u32 __force *)addr)
-: "memory");
-}
+   u32 *buf = (uint32_t *)data;
 
-static inline int __raw_readsb(unsigned int addr, void *data, int bytelen)
-{
-   __asm__ __volatile__ ("1:ld.di  r8, [r0]\n"
- "sub.fr2, r2, 1\n"
- "bnz.d1b\n"
- "stb.ab   r8, [r1, 1]\n"
- :
- : "r" (addr), "r" (data), &qu

[PATCH] ARC: Don't mess with endianess settings

2020-01-20 Thread Alexey Brodkin
There seem to be not that much sense in explicitly setting endianess
flags for the tools as we assume the tool with required endianess is
used. I.e. we use LE tools for building for LE targets and BE tools
for BE targets.

Signed-off-by: Alexey Brodkin 
---
 arch/arc/config.mk | 10 --
 1 file changed, 10 deletions(-)

diff --git a/arch/arc/config.mk b/arch/arc/config.mk
index 18005d9993..4b8a0870eb 100644
--- a/arch/arc/config.mk
+++ b/arch/arc/config.mk
@@ -8,16 +8,6 @@ else
 CONFIG_SYS_BIG_ENDIAN = 1
 endif
 
-ifdef CONFIG_SYS_LITTLE_ENDIAN
-PLATFORM_LDFLAGS += -EL
-PLATFORM_CPPFLAGS += -mlittle-endian
-endif
-
-ifdef CONFIG_SYS_BIG_ENDIAN
-PLATFORM_LDFLAGS += -EB
-PLATFORM_CPPFLAGS += -mbig-endian
-endif
-
 ifdef CONFIG_ARC_MMU_VER
 CONFIG_MMU = 1
 endif
-- 
2.16.2


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


RE: [PATCH net 4/4] ARC: [plat-axs10x]: Add missing multicast filter number to GMAC node

2020-01-14 Thread Alexey Brodkin
Hi Jose,

> -Original Message-
> From: Jose Abreu 
> Sent: Tuesday, January 14, 2020 7:09 PM
> To: net...@vger.kernel.org
> Cc: Joao Pinto ; Jose Abreu ; 
> Alexey Brodkin
> ; Rob Herring ; Mark Rutland 
> ; Vineet
> Gupta ; devicet...@vger.kernel.org; 
> linux-snps-arc@lists.infradead.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH net 4/4] ARC: [plat-axs10x]: Add missing multicast filter 
> number to GMAC node
> 
> Add a missing property to GMAC node so that multicast filtering works
> correctly.
> 
> Fixes: 556cc1c5f528 ("ARC: [axs101] Add support for AXS101 SDP (software 
> development platform)")
> Signed-off-by: Jose Abreu 

Acked-by: Alexey Brodkin 


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


RE: [PATCH v2 5/9] arc: Constify ioreadX() iomem argument (as in generic implementation)

2020-01-08 Thread Alexey Brodkin
Hi Krzysztof,

> The ioreadX() helpers have inconsistent interface.  On some architectures
> void *__iomem address argument is a pointer to const, on some not.
> 
> Implementations of ioreadX() do not modify the memory under the
> address so they can be converted to a "const" version for const-safety
> and consistency among architectures.

Thanks for this clean-up. Looks good to me, so ...

Acked-by: Alexey Brodkin 


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


[PATCH 3/3] ARC: nsim_hs38: Add support of Virtio NET & BLK

2019-12-26 Thread Alexey Brodkin
Given now nsim_hs38 configuration is usable on QEMU and in QEMU
we have Virtio working perfectly fine the next logical step
is to add support of supported & known to work net & bkl to this
config.

Signed-off-by: Alexey Brodkin 
---
 arch/arc/Kconfig  |  4 ++--
 arch/arc/dts/nsim.dts | 29 +
 board/synopsys/{ => nsim}/Kconfig |  3 +++
 board/synopsys/nsim/MAINTAINERS   |  6 ++
 board/synopsys/nsim/Makefile  |  7 +++
 board/synopsys/nsim/nsim.c| 26 ++
 configs/nsim_hs38_defconfig   |  9 +
 7 files changed, 82 insertions(+), 2 deletions(-)
 rename board/synopsys/{ => nsim}/Kconfig (74%)
 create mode 100644 board/synopsys/nsim/MAINTAINERS
 create mode 100644 board/synopsys/nsim/Makefile
 create mode 100644 board/synopsys/nsim/nsim.c

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 0cb97207db..545fc3e243 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -160,7 +160,7 @@ config TARGET_TB100
bool "Support tb100"
 
 config TARGET_NSIM
-   bool "Support standalone nSIM & Free nSIM"
+   bool "Support ARC simulation & prototyping platforms"
 
 config TARGET_AXS101
bool "Support Synopsys Designware SDP board AXS101"
@@ -184,10 +184,10 @@ config TARGET_IOT_DEVKIT
 endchoice
 
 source "board/abilis/tb100/Kconfig"
-source "board/synopsys/Kconfig"
 source "board/synopsys/axs10x/Kconfig"
 source "board/synopsys/emsdp/Kconfig"
 source "board/synopsys/hsdk/Kconfig"
 source "board/synopsys/iot_devkit/Kconfig"
+source "board/synopsys/nsim/Kconfig"
 
 endmenu
diff --git a/arch/arc/dts/nsim.dts b/arch/arc/dts/nsim.dts
index a3f3964d35..376a776a78 100644
--- a/arch/arc/dts/nsim.dts
+++ b/arch/arc/dts/nsim.dts
@@ -30,4 +30,33 @@
clock-frequency = <7000>;
};
 
+   virtio0: virtio@f010 {
+   compatible = "virtio,mmio";
+   reg = <0xf010 0x2000>;
+   interrupts = <31>;
+   };
+
+   virtio1: virtio@f0102000 {
+   compatible = "virtio,mmio";
+   reg = <0xf0102000 0x2000>;
+   interrupts = <32>;
+   };
+
+   virtio2: virtio@f0104000 {
+   compatible = "virtio,mmio";
+   reg = <0xf0104000 0x2000>;
+   interrupts = <33>;
+   };
+
+   virtio3: virtio@f0106000 {
+   compatible = "virtio,mmio";
+   reg = <0xf0106000 0x2000>;
+   interrupts = <34>;
+   };
+
+   virtio4: virtio@f0108000 {
+   compatible = "virtio,mmio";
+   reg = <0xf0108000 0x2000>;
+   interrupts = <35>;
+   };
 };
diff --git a/board/synopsys/Kconfig b/board/synopsys/nsim/Kconfig
similarity index 74%
rename from board/synopsys/Kconfig
rename to board/synopsys/nsim/Kconfig
index 27e5509b26..22287032bf 100644
--- a/board/synopsys/Kconfig
+++ b/board/synopsys/nsim/Kconfig
@@ -1,5 +1,8 @@
 if TARGET_NSIM
 
+config SYS_BOARD
+   default "nsim"
+
 config SYS_VENDOR
    default "synopsys"
 
diff --git a/board/synopsys/nsim/MAINTAINERS b/board/synopsys/nsim/MAINTAINERS
new file mode 100644
index 00..ed4b9a9e78
--- /dev/null
+++ b/board/synopsys/nsim/MAINTAINERS
@@ -0,0 +1,6 @@
+EM DEVELOPMENT KIT BOARD
+M: Alexey Brodkin 
+S: Maintained
+F: arch/arc/dts/nsim.dts
+F: board/synopsys/nsim/
+F: configs/nsim_*_defconfig
diff --git a/board/synopsys/nsim/Makefile b/board/synopsys/nsim/Makefile
new file mode 100644
index 00..f4bc65d213
--- /dev/null
+++ b/board/synopsys/nsim/Makefile
@@ -0,0 +1,7 @@
+#
+# Copyright (C) 2019 Synopsys, Inc. All rights reserved.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  += nsim.o
diff --git a/board/synopsys/nsim/nsim.c b/board/synopsys/nsim/nsim.c
new file mode 100644
index 00..988ceabf30
--- /dev/null
+++ b/board/synopsys/nsim/nsim.c
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Synopsys, Inc. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+int board_early_init_r(void)
+{
+   /*
+* Make sure virtio bus is enumerated so that peripherals
+* on the virtio bus can be discovered by their drivers
+*/
+   virtio_init();
+
+   return 0;
+}
+
+int checkboard(void)
+{
+   printf("Board: ARC virtual or prototyping platform\n");
+   return 0;
+};
diff --git a/configs/nsim_hs38_defconfig b/configs/nsim_hs38_defconfig
index ce68de3251..6cd01a505b 100644
--- a/configs/nsim_hs38_defconfig
+++ b/configs/nsim_hs38_defconfig
@@ -9,14 +9,23 @@ CONFIG_DEBUG_UART=y
 CONFIG_BOOTDELAY=3
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="

[PATCH 0/3] ARC nSIM (AKA virtual & prototyping platform) updates

2019-12-26 Thread Alexey Brodkin
In this small series we refubrish olde good nSIM configs & platform
so that it no uses standard 16650 (in fact DesignWare) UART and
little-endian HS version also gets Virtio support (Net & BLK) for use
with QEMU.

Alexey Brodkin (3):
  ARC: nSIM: switch from ARC UART to DW UART
  ARC: nsim_{700|700be|hs38be}_defconfigs: Disable networking
  ARC: nsim_hs38: Add support of Virtio NET & BLK

 arch/arc/Kconfig  |  4 ++--
 arch/arc/dts/nsim.dts | 41 ++-
 board/synopsys/{ => nsim}/Kconfig |  3 +++
 board/synopsys/nsim/MAINTAINERS   |  6 ++
 board/synopsys/nsim/Makefile  |  7 +++
 board/synopsys/nsim/nsim.c| 26 +
 configs/nsim_700_defconfig|  9 +
 configs/nsim_700be_defconfig  |  9 +
 configs/nsim_hs38_defconfig   | 17 
 configs/nsim_hs38be_defconfig |  9 +
 10 files changed, 108 insertions(+), 23 deletions(-)
 rename board/synopsys/{ => nsim}/Kconfig (74%)
 create mode 100644 board/synopsys/nsim/MAINTAINERS
 create mode 100644 board/synopsys/nsim/Makefile
 create mode 100644 board/synopsys/nsim/nsim.c

-- 
2.16.2


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


[PATCH 1/3] ARC: nSIM: switch from ARC UART to DW UART

2019-12-26 Thread Alexey Brodkin
Since v2019.06 DesingWare nSIM supports DesignWare UART simulation
and so we may switch from pretty unusual ARC UART to much more standard
DesignWare UART (which in case of U-Boot is just an ordinary 16650 UART).

This among other things makes built dinaries compatible with our other
platforms to name a few: FPGA-based HAPS boards, QEMU and even ZeBU.

Signed-off-by: Alexey Brodkin 
---
 arch/arc/dts/nsim.dts | 12 +++-
 configs/nsim_700_defconfig|  8 
 configs/nsim_700be_defconfig  |  8 
 configs/nsim_hs38_defconfig   |  8 
 configs/nsim_hs38be_defconfig |  8 
 5 files changed, 23 insertions(+), 21 deletions(-)

diff --git a/arch/arc/dts/nsim.dts b/arch/arc/dts/nsim.dts
index 243ecb178e..a3f3964d35 100644
--- a/arch/arc/dts/nsim.dts
+++ b/arch/arc/dts/nsim.dts
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Copyright (C) 2015-2016 Synopsys, Inc. (www.synopsys.com)
+ * Copyright (C) 2015-2016, 2019 Synopsys, Inc. (www.synopsys.com)
  */
 /dts-v1/;
 
@@ -10,7 +10,7 @@
model = "snps,nsim";
 
aliases {
-   console = 
+   console = 
};
 
cpu_card {
@@ -22,9 +22,11 @@
};
};
 
-   arcuart0: serial@0xc0fc1000 {
-   compatible = "snps,arc-uart";
-   reg = <0xc0fc1000 0x100>;
+   uart0: serial@f000 {
+   compatible = "snps,dw-apb-uart";
+   reg = <0xf000 0x1000>;
+   reg-shift = <2>;
+   reg-io-width = <4>;
clock-frequency = <7000>;
};
 
diff --git a/configs/nsim_700_defconfig b/configs/nsim_700_defconfig
index 5633113b09..2d4a58b178 100644
--- a/configs/nsim_700_defconfig
+++ b/configs/nsim_700_defconfig
@@ -1,13 +1,13 @@
 CONFIG_ARC=y
 CONFIG_TARGET_NSIM=y
 CONFIG_SYS_TEXT_BASE=0x8100
-CONFIG_DEBUG_UART_BASE=0xc0fc1000
+CONFIG_DEBUG_UART_BASE=0xf000
 CONFIG_DEBUG_UART_CLOCK=7000
 CONFIG_SYS_CLK_FREQ=7000
 CONFIG_DEBUG_UART=y
 CONFIG_BOOTDELAY=3
 CONFIG_USE_BOOTARGS=y
-CONFIG_BOOTARGS="console=ttyARC0,115200n8"
+CONFIG_BOOTARGS="console=ttyS0,115200n8"
 CONFIG_SYS_PROMPT="nsim# "
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_OF_CONTROL=y
@@ -16,6 +16,6 @@ CONFIG_DEFAULT_DEVICE_TREE="nsim"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_DM=y
 CONFIG_DM_SERIAL=y
-CONFIG_DEBUG_ARC_SERIAL=y
-CONFIG_ARC_SERIAL=y
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550=y
 CONFIG_USE_PRIVATE_LIBGCC=y
diff --git a/configs/nsim_700be_defconfig b/configs/nsim_700be_defconfig
index 40f7ec7e1f..61eea91449 100644
--- a/configs/nsim_700be_defconfig
+++ b/configs/nsim_700be_defconfig
@@ -2,13 +2,13 @@ CONFIG_ARC=y
 CONFIG_CPU_BIG_ENDIAN=y
 CONFIG_TARGET_NSIM=y
 CONFIG_SYS_TEXT_BASE=0x8100
-CONFIG_DEBUG_UART_BASE=0xc0fc1000
+CONFIG_DEBUG_UART_BASE=0xf000
 CONFIG_DEBUG_UART_CLOCK=7000
 CONFIG_SYS_CLK_FREQ=7000
 CONFIG_DEBUG_UART=y
 CONFIG_BOOTDELAY=3
 CONFIG_USE_BOOTARGS=y
-CONFIG_BOOTARGS="console=ttyARC0,115200n8"
+CONFIG_BOOTARGS="console=ttyS0,115200n8"
 CONFIG_SYS_PROMPT="nsim# "
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_OF_CONTROL=y
@@ -17,6 +17,6 @@ CONFIG_DEFAULT_DEVICE_TREE="nsim"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_DM=y
 CONFIG_DM_SERIAL=y
-CONFIG_DEBUG_ARC_SERIAL=y
-CONFIG_ARC_SERIAL=y
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550=y
 CONFIG_USE_PRIVATE_LIBGCC=y
diff --git a/configs/nsim_hs38_defconfig b/configs/nsim_hs38_defconfig
index 2820a6fca3..ce68de3251 100644
--- a/configs/nsim_hs38_defconfig
+++ b/configs/nsim_hs38_defconfig
@@ -2,13 +2,13 @@ CONFIG_ARC=y
 CONFIG_ISA_ARCV2=y
 CONFIG_TARGET_NSIM=y
 CONFIG_SYS_TEXT_BASE=0x8100
-CONFIG_DEBUG_UART_BASE=0xc0fc1000
+CONFIG_DEBUG_UART_BASE=0xf000
 CONFIG_DEBUG_UART_CLOCK=7000
 CONFIG_SYS_CLK_FREQ=7000
 CONFIG_DEBUG_UART=y
 CONFIG_BOOTDELAY=3
 CONFIG_USE_BOOTARGS=y
-CONFIG_BOOTARGS="console=ttyARC0,115200n8"
+CONFIG_BOOTARGS="console=ttyS0,115200n8"
 CONFIG_SYS_PROMPT="nsim# "
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_OF_CONTROL=y
@@ -17,6 +17,6 @@ CONFIG_DEFAULT_DEVICE_TREE="nsim"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_DM=y
 CONFIG_DM_SERIAL=y
-CONFIG_DEBUG_ARC_SERIAL=y
-CONFIG_ARC_SERIAL=y
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550=y
 CONFIG_USE_PRIVATE_LIBGCC=y
diff --git a/configs/nsim_hs38be_defconfig b/configs/nsim_hs38be_defconfig
index e533fae2b1..5d2ea59d52 100644
--- a/configs/nsim_hs38be_defconfig
+++ b/configs/nsim_hs38be_defconfig
@@ -3,13 +3,13 @@ CONFIG_ISA_ARCV2=y
 CONFIG_CPU_BIG_ENDIAN=y
 CONFIG_TARGET_NSIM=y
 CONFIG_SYS_TEXT_BASE=0x8100
-CONFIG_DEBUG_UART_BASE=0xc0fc1000
+CONFIG_DEBUG_UART_BASE=0xf000
 CONFIG_DEBUG_UART_CLOCK=7000
 CONFIG_SYS_CLK_FREQ=7000
 CONFIG_DEBUG_UART=y
 CONFIG_BOOTDELAY=3
 CONFIG_USE_BOOTARGS=y
-CONFIG_BOOTARGS="console=ttyARC0

[PATCH 2/3] ARC: nsim_{700|700be|hs38be}_defconfigs: Disable networking

2019-12-26 Thread Alexey Brodkin
We don't have yet any brc700 or big-enadian platforms with networking
support to run this particular configuration.

Whenever QEMU for ARC supports arc700 or big-endian targets we may revisit
this one.

Signed-off-by: Alexey Brodkin 
---
 configs/nsim_700_defconfig| 1 +
 configs/nsim_700be_defconfig  | 1 +
 configs/nsim_hs38be_defconfig | 1 +
 3 files changed, 3 insertions(+)

diff --git a/configs/nsim_700_defconfig b/configs/nsim_700_defconfig
index 2d4a58b178..6a38e2c246 100644
--- a/configs/nsim_700_defconfig
+++ b/configs/nsim_700_defconfig
@@ -14,6 +14,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_OF_EMBED=y
 CONFIG_DEFAULT_DEVICE_TREE="nsim"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+# CONFIG_NET is not set
 CONFIG_DM=y
 CONFIG_DM_SERIAL=y
 CONFIG_DEBUG_UART_SHIFT=2
diff --git a/configs/nsim_700be_defconfig b/configs/nsim_700be_defconfig
index 61eea91449..d3ed84a415 100644
--- a/configs/nsim_700be_defconfig
+++ b/configs/nsim_700be_defconfig
@@ -15,6 +15,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_OF_EMBED=y
 CONFIG_DEFAULT_DEVICE_TREE="nsim"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+# CONFIG_NET is not set
 CONFIG_DM=y
 CONFIG_DM_SERIAL=y
 CONFIG_DEBUG_UART_SHIFT=2
diff --git a/configs/nsim_hs38be_defconfig b/configs/nsim_hs38be_defconfig
index 5d2ea59d52..b074b4ca98 100644
--- a/configs/nsim_hs38be_defconfig
+++ b/configs/nsim_hs38be_defconfig
@@ -16,6 +16,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_OF_EMBED=y
 CONFIG_DEFAULT_DEVICE_TREE="nsim"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+# CONFIG_NET is not set
 CONFIG_DM=y
 CONFIG_DM_SERIAL=y
 CONFIG_DEBUG_UART_SHIFT=2
-- 
2.16.2


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


RE: [RFC PATCH v1] devres: align devres.data strictly only for devm_kmalloc()

2019-12-20 Thread Alexey Brodkin
Hi Peter,

> > Well it somehow used to work for quite some time now with the data-buffer
> > being allocated with 4 words offset (which is 16 bytes for 32-bit platform
> 
> 3 words, devres_node is 3 words.

Correct, but 4th word was implicitly there due to the fact
on most of 32-bit arches "long long" is aligned by 2 words.
 
> Which is exactly why we had to change it, the odd alignment caused ARC
> to explode.

I know that better than anybody else as it was my pain & grief :)
 
> > and 32 for 64-bit which is still much less than mentioned 128 bytes).
> > Or we just never managed to identify those rare cases when data corruption
> > really happened?
> 
> The races are rather rare methinks, you'd have to get a list-op
> concurrently with a DMA.
> 
> If you get the list corrupted, I'm thinking the crash is fairly likely,
> albeit really difficuly to debug.

So that alone IMHO is a good reason to not allow that thing to happen even
in theory.

> > > No matter which way round you allocate devres and data, by necessity
> > > they're always going to consume the same total amount of memory.
> >
> > So then the next option I guess is to separate meta-data from data buffers
> > completely. Are there any reasons to not do that
> 
> Dunno, should work just fine I think.
> 
> > other than the hack we're
> > discussing here (meta-data in the beginning of the buffer) used to work 
> > OK-ish?
> 
> If meta-data at the beginngin used to work, I don't see why meta-data at
> the end wouldn't work equally well. They'd be equally broken.

Agree. But if we imagine devm allocations are not used for DMA
(which is yet another case of interface usage which was never designed for
but alas this happens left and right) then move of the meta-data to the end of
the buffers solves [mostly my] problem... but given that DMA case we discuss
exists I'm not sure if this move actually worth spending time on.

-Alexey

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


RE: [RFC PATCH v1] devres: align devres.data strictly only for devm_kmalloc()

2019-12-20 Thread Alexey Brodkin
Hi Robin, Peter, all,

[snip]
 
> On 2019-12-20 2:06 pm, Peter Zijlstra wrote:
> > On Fri, Dec 20, 2019 at 11:19:27AM +0100, Marc Gonzalez wrote:
> >> Would anyone else have any suggestions, comments, insights, 
> >> recommendations,
> >> improvements, guidance, or wisdom? :-)
> >
> > Flip devres upside down!
> 
> Which doesn't really help :(
> 
> > **WARNING, wear protective glasses when reading the below**
> >
> >
> > struct devres {
> > struct devres_node  node;
> > void*data;
> > };
> >
> > /*
> >   * We place struct devres at the tail of the memory allocation
> >   * such that data retains the ARCH_KMALLOC_MINALIGN alignment.
> >   * struct devres itself is just 4 pointers and should therefore
> >   * only require trivial alignment.
> >   */
> > static inline struct devres *data2devres(void *data)
> > {
> > return (struct devres *)(data + ksize(data) - sizeof(struct devres));
> > }
> >
> > void *alloc_dr(...)
> > {
> > struct devres *dr;
> > void *data;
> >
> > data = kmalloc(size + sizeof(struct devres), GFP_KERNEL);
> 
> At this point, you'd still need to special-case devm_kmalloc() to ensure
> size is rounded up to the next ARCH_KMALLOC_MINALIGN granule, or you'd
> go back to the original problem of the struct devres fields potentially
> sharing a cache line with the data buffer. That needs to be avoided,
> because if the devres list is modified while the buffer is mapped for
> noncoherent DMA (which could legitimately happen as they are nominally
> distinct allocations with different owners) there's liable to be data
> corruption one way or the other.

Well it somehow used to work for quite some time now with the data-buffer
being allocated with 4 words offset (which is 16 bytes for 32-bit platform
and 32 for 64-bit which is still much less than mentioned 128 bytes).
Or we just never managed to identify those rare cases when data corruption
really happened?

> No matter which way round you allocate devres and data, by necessity
> they're always going to consume the same total amount of memory.

So then the next option I guess is to separate meta-data from data buffers
completely. Are there any reasons to not do that other than the hack we're
discussing here (meta-data in the beginning of the buffer) used to work OK-ish?

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


RE: [RFC PATCH v1] devres: align devres.data strictly only for devm_kmalloc()

2019-12-18 Thread Alexey Brodkin
Hi Marc,

We sort of expected something like that to happen at some point.
Funny enough it's been a year since my change was accepted in v4.20
and only now somebody noticed :)

Though quite a few questions below.

> Commit a66d972465d15 ("devres: Align data[] to ARCH_KMALLOC_MINALIGN")
> increased the alignment of devres.data unconditionally.
> 
> Some platforms have very strict alignment requirements for DMA-safe
> addresses, e.g. 128 bytes on arm64. There, struct devres amounts to:
>   3 pointers + pad_to_128 + data + pad_to_256
> i.e. ~220 bytes of padding.

Could you please elaborate a bit on mentioned paddings?
I may understand the first one for 128 bytes but where does the
second one for 256 bytes come from?

> Let's enforce the alignment only for devm_kmalloc().

Ok so for devm_kmalloc() we don't change anything, right?
We still add the same padding before real data array.

> ---
> I had not been aware that dynamic allocation granularity on arm64 was
> 128 bytes. This means there's a lot of waste on small allocations.

Now probably I'm missing something but when do you expect to save something?
If those smaller allocations are done with devm_kmalloc() you aren't
saving anything.

> I suppose there's no easy solution, though.

Right! It took a while till I was able to propose something
people [almost silently] agreed with.

> ---
>  drivers/base/devres.c | 23 +--
>  1 file changed, 13 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/base/devres.c b/drivers/base/devres.c
> index 0bbb328bd17f..bf39188613d9 100644
> --- a/drivers/base/devres.c
> +++ b/drivers/base/devres.c
> @@ -26,14 +26,7 @@ struct devres_node {
> 
>  struct devres {
>   struct devres_node  node;
> - /*
> -  * Some archs want to perform DMA into kmalloc caches
> -  * and need a guaranteed alignment larger than
> -  * the alignment of a 64-bit integer.
> -  * Thus we use ARCH_KMALLOC_MINALIGN here and get exactly the same
> -  * buffer alignment as if it was allocated by plain kmalloc().
> -  */
> - u8 __aligned(ARCH_KMALLOC_MINALIGN) data[];
> + u8  data[];
>  };
> 
>  struct devres_group {
> @@ -789,9 +782,16 @@ static void devm_kmalloc_release(struct device *dev, 
> void *res)
>   /* noop */
>  }
> 
> +#define DEVM_KMALLOC_PADDING_SIZE \
> + (ARCH_KMALLOC_MINALIGN - sizeof(struct devres) % ARCH_KMALLOC_MINALIGN)

Even given your update with:
--->8
#define DEVM_KMALLOC_PADDING_SIZE \
  ((ARCH_KMALLOC_MINALIGN - sizeof(struct devres)) % ARCH_KMALLOC_MINALIGN)
--->8
I don't think I understand why do you need that "% ARCH_KMALLOC_MINALIGN" part?

>  static int devm_kmalloc_match(struct device *dev, void *res, void *data)
>  {
> - return res == data;
> + /*
> +  * 'res' is dr->data (not DMA-safe)
> +  * 'data' is the hand-aligned address from devm_kmalloc
> +  */
> + return res + DEVM_KMALLOC_PADDING_SIZE == data;
>  }
> 
>  /**
> @@ -811,6 +811,9 @@ void * devm_kmalloc(struct device *dev, size_t size, 
> gfp_t gfp)
>  {
>   struct devres *dr;
> 
> + /* Add enough padding to provide a DMA-safe address */
> + size += DEVM_KMALLOC_PADDING_SIZE;

This implementation gets ugly and potentially will lead to problems later
when people will start changing code here. Compared to that initially aligned by
the compiler dr->data looks much more foolproof.

>   /* use raw alloc_dr for kmalloc caller tracing */
>   dr = alloc_dr(devm_kmalloc_release, size, gfp, dev_to_node(dev));
>   if (unlikely(!dr))
> @@ -822,7 +825,7 @@ void * devm_kmalloc(struct device *dev, size_t size, 
> gfp_t gfp)
>*/
>   set_node_dbginfo(>node, "devm_kzalloc_release", size);
>   devres_add(dev, dr->data);
> - return dr->data;
> + return dr->data + DEVM_KMALLOC_PADDING_SIZE;

Ditto. But first I'd like to understand what are you trying to really do
with your change and then we'll see if there could be any better implementation.

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


[GIT PULL REBASED] drm/arc: Yet another set of minor fixes

2019-12-16 Thread Alexey Brodkin
Hi David, Daniel!

The following changes since commit d1eef1c619749b2a57e514a3fa67d9a516ffa919:

  Linux 5.5-rc2 (2019-12-15 15:16:08 -0800)

are available in the Git repository at:

  g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.12.16

for you to fetch changes up to 0ff916e2ef6fb742e4906aac26c470314b59bae8:

  DRM: ARC: PGU: add ARGB format to supported format list (2019-12-16 
13:53:05 +0300)


Clean-up and fixes for FourCC handling in ARC PGU.


Eugeniy Paltsev (4):
  DRM: ARC: PGU: fix framebuffer format switching
  DRM: ARC: PGU: cleanup supported format list code
  DRM: ARC: PGU: replace unsupported by HW RGB888 format by XRGB888
  DRM: ARC: PGU: add ARGB format to supported format list

 drivers/gpu/drm/arc/arcpgu_crtc.c | 36 ++--
 drivers/gpu/drm/arc/arcpgu_regs.h |  2 +-
 2 files changed, 19 insertions(+), 19 deletions(-)

Note this is based on the current drm/drm-next contents.

Thanks,
Alexey

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


RE: [GIT PULL] drm/arc: Yet another set of minor fixes

2019-12-13 Thread Alexey Brodkin
Hi Daniel,

> -Original Message-
> From: Daniel Vetter 
> Sent: Friday, December 13, 2019 1:22 PM
> To: Alexey Brodkin 
> Cc: Daniel Vetter ; David Airlie ; arcml 
>  a...@lists.infradead.org>; Eugeniy Paltsev ; 
> dri-de...@lists.freedesktop.org
> Subject: Re: [GIT PULL] drm/arc: Yet another set of minor fixes
> 

[snip]

> > Not sure if you noticed re-spin of my pull-request in the previous message.
> > Do you want me to send it in a separate email?
> 
> Yeah I guess this got lost again.

So should I re-send it in another email or you will pick it up
from existing thread?

If I'm going to re-send it do I need to re-base it on today's drm/drm-next?

-Alexey

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


RE: [GIT PULL] drm/arc: Yet another set of minor fixes

2019-12-13 Thread Alexey Brodkin
Hi Daniel,

[snip]

> > Thanks for the pointers
> >
> > > Or respin this one, but these small pulls have a habit of occasionally
> > > getting lost :-/
> >
> > Well I'd better re-spin this, see below.
> >
> > The following changes since commit acc61b8929365e63a3e8c8c8913177795aa45594:
> >
> >   Merge tag 'drm-next-5.5-2019-11-22' of 
> > git://people.freedesktop.org/~agd5f/linux into drm-next
> (2019-11-26 08:40:23 +1000)
> >
> > are available in the Git repository at:
> >
> >   g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.11.27
> >
> > for you to fetch changes up to 9c2acc26c899aa12ad009dff10a5573ef769a7fd:
> >
> >   DRM: ARC: PGU: add ARGB format to supported format list (2019-11-27 
> > 16:43:39 +0300)
> >
> > 
> > Clean-up and fixes for FourCC handling in ARC PGU.
> >
> > 
> > Eugeniy Paltsev (4):
> >   DRM: ARC: PGU: fix framebuffer format switching
> >   DRM: ARC: PGU: cleanup supported format list code
> >   DRM: ARC: PGU: replace unsupported by HW RGB888 format by XRGB888
> >   DRM: ARC: PGU: add ARGB format to supported format list
> >
> >  drivers/gpu/drm/arc/arcpgu_crtc.c | 36 ++--
> >  drivers/gpu/drm/arc/arcpgu_regs.h |  2 +-
> >  2 files changed, 19 insertions(+), 19 deletions(-)

Not sure if you noticed re-spin of my pull-request in the previous message.
Do you want me to send it in a separate email?

-Alexey

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


RE: [GIT PULL] drm/arc: Yet another set of minor fixes

2019-11-27 Thread Alexey Brodkin
Hi Daniel,

> -Original Message-
> From: Daniel Vetter 
> Sent: Wednesday, November 27, 2019 1:07 PM
> To: Alexey Brodkin 
> Cc: Daniel Vetter ; David Airlie ; arcml 
>  a...@lists.infradead.org>; Eugeniy Paltsev ; 
> dri-de...@lists.freedesktop.org
> Subject: Re: [GIT PULL] drm/arc: Yet another set of minor fixes
> 
> On Wed, Nov 27, 2019 at 07:48:04AM +, Alexey Brodkin wrote:
> > Hi David, Daniel!
> >
> > The following changes since commit 8082731830a0b95f7f7a63b78de67de446013c80:
> >
> >   drm/vram: remove unused declaration (2019-11-27 07:51:49 +0100)
> >
> > are available in the Git repository at:
> >
> >   g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.11.27
> >
> > for you to fetch changes up to b2c68fb15a4c2e27f80353d3067dce30882a0972:
> >
> >   DRM: ARC: PGU: add ARGB format to supported format list (2019-11-27 
> > 10:38:24 +0300)
> >
> > 
> > Clean-up and fixes for FourCC handling in ARC PGU.
> >
> > 
> > Eugeniy Paltsev (4):
> >   DRM: ARC: PGU: fix framebuffer format switching
> >   DRM: ARC: PGU: cleanup supported format list code
> >   DRM: ARC: PGU: replace unsupported by HW RGB888 format by XRGB888
> >   DRM: ARC: PGU: add ARGB format to supported format list
> 
> Uh, this seems to be based on some random snapshot of drm-misc-next, so
> contains a _lot_ more than just these 4 patches (compared to drm-next).

Indeed it's based off of today's "drm-misc-next". That's because I still get
lost when I have to deal with DRM trees which we have a plenty.

I guess there should be a clean explanation of which repo and branch should be
used for which purpose, right? May I have a reference to it then?

> If you want to move arcpgu to drm-misc (which would make tons of sense imo)

Could you please elaborate a bit on this? Given we have a couple a patches if
at all for each kernel release I'd prefer to escape a need to use yet another
repo, tools etc as this doesn't simplify anything but instead makes simple
things much more complex (if done rarely).

> then:
> - create a MAINTAINER patch to add drm-misc as the git repo for it
> - request your account for drm-misc, see 
> https://www.freedesktop.org/wiki/AccountRequests/
> - and set up the scripts 
> https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html 

Thanks for the pointers

> Or respin this one, but these small pulls have a habit of occasionally
> getting lost :-/

Well I'd better re-spin this, see below.

The following changes since commit acc61b8929365e63a3e8c8c8913177795aa45594:

  Merge tag 'drm-next-5.5-2019-11-22' of 
git://people.freedesktop.org/~agd5f/linux into drm-next (2019-11-26 08:40:23 
+1000)

are available in the Git repository at:

  g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.11.27

for you to fetch changes up to 9c2acc26c899aa12ad009dff10a5573ef769a7fd:

  DRM: ARC: PGU: add ARGB format to supported format list (2019-11-27 
16:43:39 +0300)


Clean-up and fixes for FourCC handling in ARC PGU.


Eugeniy Paltsev (4):
  DRM: ARC: PGU: fix framebuffer format switching
  DRM: ARC: PGU: cleanup supported format list code
  DRM: ARC: PGU: replace unsupported by HW RGB888 format by XRGB888
  DRM: ARC: PGU: add ARGB format to supported format list

 drivers/gpu/drm/arc/arcpgu_crtc.c | 36 ++--
 drivers/gpu/drm/arc/arcpgu_regs.h |  2 +-
 2 files changed, 19 insertions(+), 19 deletions(-)

-Alexey


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


RE: [GIT PULL] drm/arc: Minor improvements

2019-11-27 Thread Alexey Brodkin
Hi all,

As Jose suggested I'm adding "drm-misc" maintainers as that tree
might be a better fit for ARC PGU patches.

-Alexey

> -Original Message-
> From: linux-snps-arc  On Behalf 
> Of Alexey Brodkin
> Sent: Wednesday, November 27, 2019 10:25 AM
> To: Daniel Vetter ; David Airlie 
> Cc: arcml ; Eugeniy Paltsev 
> ; dri-
> de...@lists.freedesktop.org
> Subject: RE: [GIT PULL] drm/arc: Minor improvements
> 
> Hi Daniel, David!
> 
> Any chance for this one to be processed sometime soon?
> It's been quite some time since July when I initially sent
> this pull-request.
> 
> -Alexey
> 
> > -Original Message-
> > From: linux-snps-arc  On Behalf 
> > Of Alexey Brodkin
> > Sent: Wednesday, November 13, 2019 2:30 PM
> > To: Daniel Vetter ; David Airlie 
> > Cc: arcml ; Eugeniy Paltsev 
> > ; dri-
> > de...@lists.freedesktop.org
> > Subject: RE: [GIT PULL] drm/arc: Minor improvements
> >
> > Hi Daniel, David,
> >
> > > -Original Message-
> > > From: linux-snps-arc  On 
> > > Behalf Of Alexey Brodkin
> > > Sent: Thursday, July 18, 2019 12:09 AM
> > > To: Daniel Vetter ; David Airlie 
> > > Cc: arcml ; 
> > > dri-de...@lists.freedesktop.org
> > > Subject: [GIT PULL] drm/arc: Minor improvements
> > >
> > > Hi Dave, Daniel,
> > >
> > > The following changes since commit 
> > > 7aaddd96d5febcf5b24357a326b3038d49a20532:
> > >
> > >   drm/modes: Don't apply cmdline's rotation if it wasn't specified 
> > > (2019-07-16 10:34:38 +0200)
> > >
> > > are available in the Git repository at:
> > >
> > >   g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.07.18
> > >
> > > for you to fetch changes up to cee17a71656e9e1b5ffc01767844026550d5f4a9:
> > >
> > >   drm/arcpgu: rework encoder search (2019-07-17 23:36:56 +0300)
> > >
> > > 
> > > This is a pretty simple improvement that allows to find encoder
> > > as the one and only (ARC PGU doesn't support more than one) endpoint
> > > instead of using non-standard "encoder-slave" property.
> > >
> > > 
> > > Eugeniy Paltsev (1):
> > >   drm/arcpgu: rework encoder search
> > >
> > >  drivers/gpu/drm/arc/arcpgu_drv.c | 16 +---
> > >  1 file changed, 13 insertions(+), 3 deletions(-)
> >
> > Any chance for this one to get pulled into your tree(s) sometime soon?
> >
> > -Alexey
> >
> > ___
> > linux-snps-arc mailing list
> > linux-snps-arc@lists.infradead.org
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-
> 2Dsnps-
> >
> 2Darc=DwICAg=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=f3bFSjs3gZI9vC
> > LJW5sa6Kxu43yXUsCXhaUNhtEymmk=eFO6mnw8IJyfrQZYrMEbJ-bryplfw9LvcYBSCEyj5XA=
> 
> ___
> linux-snps-arc mailing list
> linux-snps-arc@lists.infradead.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dsnps-
> 2Darc=DwICAg=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=c8DhCL8_-
> 0iY2tS35o8kpDyvbHZ_Cu762s4qtn2hDVg=sGFaDT7yPIbVcjW49E_rjb6ND82Nrq0kplYjbztlh3A=

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


RE: [GIT PULL] drm/arc: Minor improvements

2019-11-27 Thread Alexey Brodkin
Hi Daniel, David!

Any chance for this one to be processed sometime soon?
It's been quite some time since July when I initially sent
this pull-request.

-Alexey

> -Original Message-
> From: linux-snps-arc  On Behalf 
> Of Alexey Brodkin
> Sent: Wednesday, November 13, 2019 2:30 PM
> To: Daniel Vetter ; David Airlie 
> Cc: arcml ; Eugeniy Paltsev 
> ; dri-
> de...@lists.freedesktop.org
> Subject: RE: [GIT PULL] drm/arc: Minor improvements
> 
> Hi Daniel, David,
> 
> > -Original Message-
> > From: linux-snps-arc  On Behalf 
> > Of Alexey Brodkin
> > Sent: Thursday, July 18, 2019 12:09 AM
> > To: Daniel Vetter ; David Airlie 
> > Cc: arcml ; 
> > dri-de...@lists.freedesktop.org
> > Subject: [GIT PULL] drm/arc: Minor improvements
> >
> > Hi Dave, Daniel,
> >
> > The following changes since commit 7aaddd96d5febcf5b24357a326b3038d49a20532:
> >
> >   drm/modes: Don't apply cmdline's rotation if it wasn't specified 
> > (2019-07-16 10:34:38 +0200)
> >
> > are available in the Git repository at:
> >
> >   g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.07.18
> >
> > for you to fetch changes up to cee17a71656e9e1b5ffc01767844026550d5f4a9:
> >
> >   drm/arcpgu: rework encoder search (2019-07-17 23:36:56 +0300)
> >
> > 
> > This is a pretty simple improvement that allows to find encoder
> > as the one and only (ARC PGU doesn't support more than one) endpoint
> > instead of using non-standard "encoder-slave" property.
> >
> > 
> > Eugeniy Paltsev (1):
> >   drm/arcpgu: rework encoder search
> >
> >  drivers/gpu/drm/arc/arcpgu_drv.c | 16 +---
> >  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> Any chance for this one to get pulled into your tree(s) sometime soon?
> 
> -Alexey
> 
> ___
> linux-snps-arc mailing list
> linux-snps-arc@lists.infradead.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dsnps-
> 2Darc=DwICAg=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=f3bFSjs3gZI9vC
> LJW5sa6Kxu43yXUsCXhaUNhtEymmk=eFO6mnw8IJyfrQZYrMEbJ-bryplfw9LvcYBSCEyj5XA=

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


RE: [PATCH] ARC: perf: Accommodate big-endian CPU

2019-11-27 Thread Alexey Brodkin
Hi Greg,

> -Original Message-
> From: linux-snps-arc  On Behalf 
> Of Greg Kroah-Hartman
> Sent: Thursday, November 21, 2019 11:40 PM
> To: Alexey Brodkin 
> Cc: Sasha Levin ; linux-snps-arc@lists.infradead.org; 
> linux-ker...@vger.kernel.org;
> sta...@vger.kernel.org
> Subject: Re: [PATCH] ARC: perf: Accommodate big-endian CPU
> 
> On Tue, Nov 05, 2019 at 07:52:16PM +, Alexey Brodkin wrote:
> > Hi Sasha, Greg,
> >
> > > -Original Message-
> > > From: Sasha Levin 
> > > Sent: Saturday, October 26, 2019 4:11 PM
> > > To: Sasha Levin ; Alexey Brodkin 
> > > ; linux-snps-
> > > a...@lists.infradead.org
> > > Cc: linux-ker...@vger.kernel.org; sta...@vger.kernel.org; 
> > > sta...@vger.kernel.org
> > > Subject: Re: [PATCH] ARC: perf: Accommodate big-endian CPU
> > >
> > > Hi,
> > >
> > > [This is an automated email]
> > >
> > > This commit has been processed because it contains a -stable tag.
> > > The stable tag indicates that it's relevant for the following trees: all
> > >
> > > The bot has tested the following trees: v5.3.7, v4.19.80, v4.14.150, 
> > > v4.9.197, v4.4.197.
> > >
> > > v5.3.7: Build OK!
> > > v4.19.80: Failed to apply! Possible dependencies:
> > > 0e956150fe09f ("ARC: perf: introduce Kernel PMU events support")
> > > 14f81a91ad29a ("ARC: perf: trivial code cleanup")
> > > baf9cc85ba01f ("ARC: perf: move HW events mapping to separate 
> > > function")
> > > v4.14.150: Failed to apply! Possible dependencies:
> > > v4.9.197: Failed to apply! Possible dependencies:
> > > v4.4.197: Failed to apply! Possible dependencies:
> >
> > Indeed the clash is due to
> > commit baf9cc85ba01f ("ARC: perf: move HW events mapping to separate 
> > function") as tmp variable "j"
> was changed on "i". So that's a fixed hunk:
> > >8--
> > diff --git a/arch/arc/kernel/perf_event.c b/arch/arc/kernel/perf_event.c
> > index 8aec462d90fb..30f66b123541 100644
> > --- a/arch/arc/kernel/perf_event.c
> > +++ b/arch/arc/kernel/perf_event.c
> > @@ -490,8 +490,8 @@ static int arc_pmu_device_probe(struct platform_device 
> > *pdev)
> > /* loop thru all available h/w condition indexes */
> > for (j = 0; j < cc_bcr.c; j++) {
> > write_aux_reg(ARC_REG_CC_INDEX, j);
> > -   cc_name.indiv.word0 = read_aux_reg(ARC_REG_CC_NAME0);
> > -   cc_name.indiv.word1 = read_aux_reg(ARC_REG_CC_NAME1);
> > +   cc_name.indiv.word0 = 
> > le32_to_cpu(read_aux_reg(ARC_REG_CC_NAME0));
> > +   cc_name.indiv.word1 = 
> > le32_to_cpu(read_aux_reg(ARC_REG_CC_NAME1));
> >
> > /* See if it has been mapped to a perf event_id */
> > for (i = 0; i < ARRAY_SIZE(arc_pmu_ev_hw_map); i++) {
> > >8--
> >
> > Should I send a formal patch with it or it's OK for now?
> 
> We need a "formal" patch that we can apply if you want it applied.

Done, see https://patchwork.ozlabs.org/patch/1201398/ and your inbox.

-Alexey


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


[PATCH] ARC: perf: Accommodate big-endian CPU

2019-11-27 Thread Alexey Brodkin
8-letter strings representing ARC perf events are stores in two
32-bit registers as ASCII characters like that: "IJMP", "IALL", "IJMPTAK" etc.

And the same order of bytes in the word is used regardless CPU endianness.

Which means in case of big-endian CPU core we need to swap bytes to get
the same order as if it was on little-endian CPU.

Otherwise we're seeing the following error message on boot:
->8--
ARC perf: 8 counters (32 bits), 40 conditions, [overflow IRQ support]
sysfs: cannot create duplicate filename '/devices/arc_pct/events/pmji'
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3
Stack Trace:
  arc_unwind_core+0xd4/0xfc
  dump_stack+0x64/0x80
  sysfs_warn_dup+0x46/0x58
  sysfs_add_file_mode_ns+0xb2/0x168
  create_files+0x70/0x2a0
[ cut here ]
WARNING: CPU: 0 PID: 1 at kernel/events/core.c:12144 
perf_event_sysfs_init+0x70/0xa0
Failed to register pmu: arc_pct, reason -17
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3
Stack Trace:
  arc_unwind_core+0xd4/0xfc
  dump_stack+0x64/0x80
  __warn+0x9c/0xd4
  warn_slowpath_fmt+0x22/0x2c
  perf_event_sysfs_init+0x70/0xa0
---[ end trace a75fb9a9837bd1ec ]---
->8--

What happens here we're trying to register more than one raw perf event
with the same name "PMJI". Why? Because ARC perf events are 4 to 8 letters
and encoded into two 32-bit words. In this particular case we deal with 2
events:
 * "IJMP" which counts all jump & branch instructions
 * "IJMPC___" which counts only conditional jumps & branches

Those strings are split in two 32-bit words this way "IJMP" + "" &
"IJMP" + "C___" correspondingly. Now if we read them swapped due to CPU core
being big-endian then we read "PMJI" + "" & "PMJI" + "___C".

And since we interpret read array of ASCII letters as a null-terminated string
on big-endian CPU we end up with 2 events of the same name "PMJI".

Signed-off-by: Alexey Brodkin 
Cc: sta...@vger.kernel.org
---

Greg, Sasha, this is the same patch as
commit 5effc09c4907 ("ARC: perf: Accommodate big-endian CPU")
but fine-tuned to be applicable to kernels 4.19 and older.

 arch/arc/kernel/perf_event.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arc/kernel/perf_event.c b/arch/arc/kernel/perf_event.c
index 8aec462d90fb..30f66b123541 100644
--- a/arch/arc/kernel/perf_event.c
+++ b/arch/arc/kernel/perf_event.c
@@ -490,8 +490,8 @@ static int arc_pmu_device_probe(struct platform_device 
*pdev)
/* loop thru all available h/w condition indexes */
for (j = 0; j < cc_bcr.c; j++) {
write_aux_reg(ARC_REG_CC_INDEX, j);
-   cc_name.indiv.word0 = read_aux_reg(ARC_REG_CC_NAME0);
-   cc_name.indiv.word1 = read_aux_reg(ARC_REG_CC_NAME1);
+   cc_name.indiv.word0 = 
le32_to_cpu(read_aux_reg(ARC_REG_CC_NAME0));
+   cc_name.indiv.word1 = 
le32_to_cpu(read_aux_reg(ARC_REG_CC_NAME1));
 
/* See if it has been mapped to a perf event_id */
for (i = 0; i < ARRAY_SIZE(arc_pmu_ev_hw_map); i++) {
-- 
2.16.2


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


[GIT PULL] drm/arc: Yet another set of minor fixes

2019-11-26 Thread Alexey Brodkin
Hi David, Daniel!

The following changes since commit 8082731830a0b95f7f7a63b78de67de446013c80:

  drm/vram: remove unused declaration (2019-11-27 07:51:49 +0100)

are available in the Git repository at:

  g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.11.27

for you to fetch changes up to b2c68fb15a4c2e27f80353d3067dce30882a0972:

  DRM: ARC: PGU: add ARGB format to supported format list (2019-11-27 
10:38:24 +0300)


Clean-up and fixes for FourCC handling in ARC PGU.


Eugeniy Paltsev (4):
  DRM: ARC: PGU: fix framebuffer format switching
  DRM: ARC: PGU: cleanup supported format list code
  DRM: ARC: PGU: replace unsupported by HW RGB888 format by XRGB888
  DRM: ARC: PGU: add ARGB format to supported format list

 drivers/gpu/drm/arc/arcpgu_crtc.c | 36 ++--
 drivers/gpu/drm/arc/arcpgu_regs.h |  2 +-
 2 files changed, 19 insertions(+), 19 deletions(-)

Thanks,
Alexey

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


RE: [GIT PULL] drm/arc: Minor improvements

2019-11-13 Thread Alexey Brodkin
Hi Daniel, David,

> -Original Message-
> From: linux-snps-arc  On Behalf 
> Of Alexey Brodkin
> Sent: Thursday, July 18, 2019 12:09 AM
> To: Daniel Vetter ; David Airlie 
> Cc: arcml ; 
> dri-de...@lists.freedesktop.org
> Subject: [GIT PULL] drm/arc: Minor improvements
> 
> Hi Dave, Daniel,
> 
> The following changes since commit 7aaddd96d5febcf5b24357a326b3038d49a20532:
> 
>   drm/modes: Don't apply cmdline's rotation if it wasn't specified 
> (2019-07-16 10:34:38 +0200)
> 
> are available in the Git repository at:
> 
>   g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.07.18
> 
> for you to fetch changes up to cee17a71656e9e1b5ffc01767844026550d5f4a9:
> 
>   drm/arcpgu: rework encoder search (2019-07-17 23:36:56 +0300)
> 
> 
> This is a pretty simple improvement that allows to find encoder
> as the one and only (ARC PGU doesn't support more than one) endpoint
> instead of using non-standard "encoder-slave" property.
> 
> 
> Eugeniy Paltsev (1):
>   drm/arcpgu: rework encoder search
> 
>  drivers/gpu/drm/arc/arcpgu_drv.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)

Any chance for this one to get pulled into your tree(s) sometime soon?

-Alexey

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


RE: [PATCH] ARC: perf: Accommodate big-endian CPU

2019-11-05 Thread Alexey Brodkin
Hi Sasha, Greg,

> -Original Message-
> From: Sasha Levin 
> Sent: Saturday, October 26, 2019 4:11 PM
> To: Sasha Levin ; Alexey Brodkin ; 
> linux-snps-
> a...@lists.infradead.org
> Cc: linux-ker...@vger.kernel.org; sta...@vger.kernel.org; 
> sta...@vger.kernel.org
> Subject: Re: [PATCH] ARC: perf: Accommodate big-endian CPU
> 
> Hi,
> 
> [This is an automated email]
> 
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
> 
> The bot has tested the following trees: v5.3.7, v4.19.80, v4.14.150, 
> v4.9.197, v4.4.197.
> 
> v5.3.7: Build OK!
> v4.19.80: Failed to apply! Possible dependencies:
> 0e956150fe09f ("ARC: perf: introduce Kernel PMU events support")
> 14f81a91ad29a ("ARC: perf: trivial code cleanup")
> baf9cc85ba01f ("ARC: perf: move HW events mapping to separate function")
> v4.14.150: Failed to apply! Possible dependencies:
> v4.9.197: Failed to apply! Possible dependencies:
> v4.4.197: Failed to apply! Possible dependencies:

Indeed the clash is due to
commit baf9cc85ba01f ("ARC: perf: move HW events mapping to separate function") 
as tmp variable "j" was changed on "i". So that's a fixed hunk:
>8--
diff --git a/arch/arc/kernel/perf_event.c b/arch/arc/kernel/perf_event.c
index 8aec462d90fb..30f66b123541 100644
--- a/arch/arc/kernel/perf_event.c
+++ b/arch/arc/kernel/perf_event.c
@@ -490,8 +490,8 @@ static int arc_pmu_device_probe(struct platform_device 
*pdev)
/* loop thru all available h/w condition indexes */
for (j = 0; j < cc_bcr.c; j++) {
write_aux_reg(ARC_REG_CC_INDEX, j);
-   cc_name.indiv.word0 = read_aux_reg(ARC_REG_CC_NAME0);
-   cc_name.indiv.word1 = read_aux_reg(ARC_REG_CC_NAME1);
+   cc_name.indiv.word0 = 
le32_to_cpu(read_aux_reg(ARC_REG_CC_NAME0));
+   cc_name.indiv.word1 = 
le32_to_cpu(read_aux_reg(ARC_REG_CC_NAME1));

/* See if it has been mapped to a perf event_id */
for (i = 0; i < ARRAY_SIZE(arc_pmu_ev_hw_map); i++) {
>8--

Should I send a formal patch with it or it's OK for now?

-Alexey

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


RE: [PATCH] toolchain,glibc: Allow ARC big endian glibc builds

2019-11-05 Thread Alexey Brodkin
Hi Vineet,

> -Original Message-
> From: Vineet Gupta 
> Sent: Friday, November 1, 2019 10:04 PM
> To: buildr...@busybox.net
> Cc: linux-snps-arc@lists.infradead.org; Alexey Brodkin 
> ; Evgeniy Didin
> ; Vineet Gupta 
> Subject: [PATCH] toolchain,glibc: Allow ARC big endian glibc builds
> 
> Apparently big endian glibc builds just work, if we let the endian
> header allow that (which prev was #error).
> 
> So this patch bumps glibc to version which fixes the header (this
> hopefully will become arc-2019.09-release) and then enables arceb
> in glibc toolchain builds
> 
> Signed-off-by: Vineet Gupta 
> ---
>  package/glibc/glibc.mk  | 2 +-
>  toolchain/toolchain-buildroot/Config.in | 3 ++-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/package/glibc/glibc.mk b/package/glibc/glibc.mk
> index d46063c5d111..754408881397 100644
> --- a/package/glibc/glibc.mk
> +++ b/package/glibc/glibc.mk
> @@ -5,7 +5,7 @@
>  
> 
> 
>  ifeq ($(BR2_arc),y)
> -GLIBC_VERSION =  arc-2019.03-release
> +GLIBC_VERSION = ec681dddfa99894513c85da7d5d257b60d04f915
>  GLIBC_SITE = $(call 
> github,foss-for-synopsys-dwc-arc-processors,glibc,$(GLIBC_VERSION))
>  else ifeq ($(BR2_RISCV_32),y)
>  GLIBC_VERSION = 06983fe52cfe8e4779035c27e8cc5d2caab31531
> diff --git a/toolchain/toolchain-buildroot/Config.in 
> b/toolchain/toolchain-buildroot/Config.in
> index c0612bf04176..587e097a9c92 100644
> --- a/toolchain/toolchain-buildroot/Config.in
> +++ b/toolchain/toolchain-buildroot/Config.in
> @@ -48,7 +48,8 @@ config BR2_TOOLCHAIN_BUILDROOT_GLIBC
>  BR2_powerpc || BR2_powerpc64  || BR2_powerpc64le || \
>  BR2_riscv   || BR2_sh || BR2_sparc64 || \
>  BR2_x86_64  || BR2_microblaze || BR2_nios2   || \
> -(BR2_arcle && BR2_ARC_ATOMIC_EXT) || BR2_csky
> +((BR2_arcle || BR2_arceb) && BR2_ARC_ATOMIC_EXT) || \
> +BR2_csky

I guess here we may just use "BR2_arc" which is set for both BR2_arcle && 
BR2_arceb,
see https://git.buildroot.org/buildroot/tree/arch/Config.in.arc#n54

-Alexey

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


[PATCH] ARC: perf: Accommodate big-endian CPU

2019-10-22 Thread Alexey Brodkin
8-letter strings representing ARC perf events are stores in two
32-bit registers as ASCII characters like that: "IJMP", "IALL", "IJMPTAK" etc.

And the same order of bytes in the word is used regardless CPU endianness.

Which means in case of big-endian CPU core we need to swap bytes to get
the same order as if it was on little-endian CPU.

Otherwise we're seeing the following error message on boot:
->8--
ARC perf: 8 counters (32 bits), 40 conditions, [overflow IRQ support]
sysfs: cannot create duplicate filename '/devices/arc_pct/events/pmji'
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3
Stack Trace:
  arc_unwind_core+0xd4/0xfc
  dump_stack+0x64/0x80
  sysfs_warn_dup+0x46/0x58
  sysfs_add_file_mode_ns+0xb2/0x168
  create_files+0x70/0x2a0
[ cut here ]
WARNING: CPU: 0 PID: 1 at kernel/events/core.c:12144 
perf_event_sysfs_init+0x70/0xa0
Failed to register pmu: arc_pct, reason -17
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3
Stack Trace:
  arc_unwind_core+0xd4/0xfc
  dump_stack+0x64/0x80
  __warn+0x9c/0xd4
  warn_slowpath_fmt+0x22/0x2c
  perf_event_sysfs_init+0x70/0xa0
---[ end trace a75fb9a9837bd1ec ]---
->8--

What happens here we're trying to register more than one raw perf event
with the same name "PMJI". Why? Because ARC perf events are 4 to 8 letters
and encoded into two 32-bit words. In this particular case we deal with 2
events:
 * "IJMP" which counts all jump & branch instructions
 * "IJMPC___" which counts only conditional jumps & branches

Those strings are split in two 32-bit words this way "IJMP" + "" &
"IJMP" + "C___" correspondingly. Now if we read them swapped due to CPU core
being big-endian then we read "PMJI" + "" & "PMJI" + "___C".

And since we interpret read array of ASCII letters as a null-terminated string
on big-endian CPU we end up with 2 events of the same name "PMJI".

Signed-off-by: Alexey Brodkin 
Cc: sta...@vger.kernel.org
---
 arch/arc/kernel/perf_event.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arc/kernel/perf_event.c b/arch/arc/kernel/perf_event.c
index 861a8aea51f9..661fd842ea97 100644
--- a/arch/arc/kernel/perf_event.c
+++ b/arch/arc/kernel/perf_event.c
@@ -614,8 +614,8 @@ static int arc_pmu_device_probe(struct platform_device 
*pdev)
/* loop thru all available h/w condition indexes */
for (i = 0; i < cc_bcr.c; i++) {
write_aux_reg(ARC_REG_CC_INDEX, i);
-   cc_name.indiv.word0 = read_aux_reg(ARC_REG_CC_NAME0);
-   cc_name.indiv.word1 = read_aux_reg(ARC_REG_CC_NAME1);
+   cc_name.indiv.word0 = 
le32_to_cpu(read_aux_reg(ARC_REG_CC_NAME0));
+   cc_name.indiv.word1 = 
le32_to_cpu(read_aux_reg(ARC_REG_CC_NAME1));
 
arc_pmu_map_hw_event(i, cc_name.str);
arc_pmu_add_raw_event_attr(i, cc_name.str);
-- 
2.16.2


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


RE: [PATCH 0/2] ARC: [plat-hsdk]: enable on-board SPI peripherals

2019-10-18 Thread Alexey Brodkin
Hi Eugeniy,

> -Original Message-
> From: Eugeniy Paltsev 
> Sent: Friday, October 18, 2019 2:11 PM
> To: linux-snps-arc@lists.infradead.org; Vineet Gupta 
> Cc: linux-ker...@vger.kernel.org; Alexey Brodkin ; Rob 
> Herring
> ; devicet...@vger.kernel.org; Eugeniy Paltsev 
> 
> Subject: [PATCH 0/2] ARC: [plat-hsdk]: enable on-board SPI peripherals
> 
> HSDK board has SPI flash IC and SPI ADC IC. As all SPI-related
> blocking changes/fixes are finally applied we can enable them.
> 
> Eugeniy Paltsev (2):
>   ARC: [plat-hsdk]: Enable on-board SPI NOR flash IC
>   ARC: [plat-hsdk]: Enable on-boardi SPI ADC IC

For both patches in the series

Acked-by: Alexey Brodkin 


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


[PATCH v3] arc: emsdp/iotdk: Switch to DM_MMC

2019-10-09 Thread Alexey Brodkin
Somehow EMSDP & IoT DK boards were skipped on ARC boads conversion
to DM MMC. So doing it now.

Signed-off-by: Alexey Brodkin 
---

Changes v2 -> v3:
 * Fixed SDIO bus interface unit clock (BIU)
   According to the documentation SDIO BIU clock is just "apb_clk"
   which is 50 MHz by default while SDIO CIU clock is "sdio_ref_clk"
   and by default is 100 MHz.

Changes v1 -> v2:
 * FIFO size on IoTDK is 128 bytes as compared to 256 on EM SDP.
   That gave us timeouts on data read with some cards. Fixed now.

 arch/arc/dts/emsdp.dts | 23 ++
 arch/arc/dts/iot_devkit.dts| 22 ++
 board/synopsys/emsdp/emsdp.c   | 29 ---
 board/synopsys/iot_devkit/iot_devkit.c | 32 --
 configs/emsdp_defconfig|  2 ++
 configs/iot_devkit_defconfig   |  2 ++
 6 files changed, 49 insertions(+), 61 deletions(-)

diff --git a/arch/arc/dts/emsdp.dts b/arch/arc/dts/emsdp.dts
index d307b95d8e..dbebdb4e76 100644
--- a/arch/arc/dts/emsdp.dts
+++ b/arch/arc/dts/emsdp.dts
@@ -32,4 +32,27 @@
reg-shift = <2>;
reg-io-width = <4>;
};
+
+   mmcclk_biu: mmcclk-biu {
+   compatible = "fixed-clock";
+   clock-frequency = <5000>;
+   #clock-cells = <0>;
+   };
+
+   mmcclk_ciu: mmcclk-ciu {
+   compatible = "fixed-clock";
+   clock-frequency = <1>;
+   #clock-cells = <0>;
+   };
+
+   mmc: mmc0@f001 {
+   compatible = "snps,dw-mshc";
+   reg = <0xf001 0x400>;
+   bus-width = <4>;
+   fifo-depth = <256>;
+   clocks = <_biu>, <_ciu>;
+   clock-names = "biu", "ciu";
+   max-frequency = <2500>;
+   };
+
 };
diff --git a/arch/arc/dts/iot_devkit.dts b/arch/arc/dts/iot_devkit.dts
index ebf5a950f0..c0173fa5ab 100644
--- a/arch/arc/dts/iot_devkit.dts
+++ b/arch/arc/dts/iot_devkit.dts
@@ -42,4 +42,26 @@
compatible = "nop-phy";
#phy-cells = <0>;
};
+
+   mmcclk_biu: mmcclk-biu {
+   compatible = "fixed-clock";
+   clock-frequency = <5000>;
+   #clock-cells = <0>;
+   };
+
+   mmcclk_ciu: mmcclk-ciu {
+   compatible = "fixed-clock";
+   clock-frequency = <5000>;
+   #clock-cells = <0>;
+   };
+
+   mmc: mmc0@f000b000 {
+   compatible = "snps,dw-mshc";
+   reg = <0xf000b000 0x400>;
+   bus-width = <4>;
+   fifo-depth = <128>;
+   clocks = <_biu>, <_ciu>;
+   clock-names = "biu", "ciu";
+   max-frequency = <2500>;
+   };
 };
diff --git a/board/synopsys/emsdp/emsdp.c b/board/synopsys/emsdp/emsdp.c
index 7a3fd5b7f2..5ba9f862e1 100644
--- a/board/synopsys/emsdp/emsdp.c
+++ b/board/synopsys/emsdp/emsdp.c
@@ -85,35 +85,6 @@ int board_early_init_r(void)
return 0;
 }
 
-int board_mmc_init(bd_t *bis)
-{
-   struct dwmci_host *host = NULL;
-
-   host = malloc(sizeof(struct dwmci_host));
-   if (!host) {
-   printf("dwmci_host malloc fail!\n");
-   return 1;
-   }
-
-   memset(host, 0, sizeof(struct dwmci_host));
-   host->name = "Synopsys Mobile storage";
-   host->ioaddr = SDIO_BASE;
-   host->buswidth = 4;
-   host->dev_index = 0;
-   host->bus_hz = 5000;
-
-   add_dwmci(host, host->bus_hz / 2, 40);
-
-   return 0;
-}
-
-int board_mmc_getcd(struct mmc *mmc)
-{
-   struct dwmci_host *host = mmc->priv;
-
-   return !(dwmci_readl(host, DWMCI_CDETECT) & 1);
-}
-
 #define CREG_BASE  0xF0001000
 #define CREG_BOOT  (void *)(CREG_BASE + 0x0FF0)
 #define CREG_IP_SW_RESET   (void *)(CREG_BASE + 0x0FF0)
diff --git a/board/synopsys/iot_devkit/iot_devkit.c 
b/board/synopsys/iot_devkit/iot_devkit.c
index 8424e09bd3..9dbdc128f8 100644
--- a/board/synopsys/iot_devkit/iot_devkit.c
+++ b/board/synopsys/iot_devkit/iot_devkit.c
@@ -145,38 +145,6 @@ int mach_cpu_init(void)
return set_cpu_freq(gd->cpu_clk);
 }
 
-#define ARC_PERIPHERAL_BASE0xF000
-#define SDIO_BASE  (ARC_PERIPHERAL_BASE + 0xB000)
-
-int board_mmc_init(bd_t *bis)
-{
-   struct dwmci_host *host = NULL;
-
-   host = malloc(sizeof(struct dwmci_host));
-   if (!host) {
-   printf("dwmci_host malloc fail!\n");
-   return -ENOMEM;
-   }
-
-   memset(host, 0, sizeof(struct dwmci_host));
-   host->name = 

[PATCH v2] arc: emsdp/iotdk: Switch to DM_MMC

2019-10-08 Thread Alexey Brodkin
Somehow EMSDP & IoT DK boards were skipped on ARC boads conversion
to DM MMC. So doing it now.

Signed-off-by: Alexey Brodkin 
---

Changes v1 -> v2:

 * FIFO size on IoTDK is 128 bytes as compared to 256 on EM SDP.
   That gave us timeouts on data read with some cards. Fixed now.

 arch/arc/dts/emsdp.dts | 23 ++
 arch/arc/dts/iot_devkit.dts| 22 ++
 board/synopsys/emsdp/emsdp.c   | 29 ---
 board/synopsys/iot_devkit/iot_devkit.c | 32 --
 configs/emsdp_defconfig|  2 ++
 configs/iot_devkit_defconfig   |  2 ++
 6 files changed, 49 insertions(+), 61 deletions(-)

diff --git a/arch/arc/dts/emsdp.dts b/arch/arc/dts/emsdp.dts
index d307b95d8e..77362354d5 100644
--- a/arch/arc/dts/emsdp.dts
+++ b/arch/arc/dts/emsdp.dts
@@ -32,4 +32,27 @@
reg-shift = <2>;
reg-io-width = <4>;
};
+
+   mmcclk_biu: mmcclk-biu {
+   compatible = "fixed-clock";
+   clock-frequency = <1>;
+   #clock-cells = <0>;
+   };
+
+   mmcclk_ciu: mmcclk-ciu {
+   compatible = "fixed-clock";
+   clock-frequency = <1>;
+   #clock-cells = <0>;
+   };
+
+   mmc: mmc0@f001 {
+   compatible = "snps,dw-mshc";
+   reg = <0xf001 0x400>;
+   bus-width = <4>;
+   fifo-depth = <256>;
+   clocks = <_biu>, <_ciu>;
+   clock-names = "biu", "ciu";
+   max-frequency = <2500>;
+   };
+
 };
diff --git a/arch/arc/dts/iot_devkit.dts b/arch/arc/dts/iot_devkit.dts
index ebf5a950f0..c0173fa5ab 100644
--- a/arch/arc/dts/iot_devkit.dts
+++ b/arch/arc/dts/iot_devkit.dts
@@ -42,4 +42,26 @@
compatible = "nop-phy";
#phy-cells = <0>;
};
+
+   mmcclk_biu: mmcclk-biu {
+   compatible = "fixed-clock";
+   clock-frequency = <5000>;
+   #clock-cells = <0>;
+   };
+
+   mmcclk_ciu: mmcclk-ciu {
+   compatible = "fixed-clock";
+   clock-frequency = <5000>;
+   #clock-cells = <0>;
+   };
+
+   mmc: mmc0@f000b000 {
+   compatible = "snps,dw-mshc";
+   reg = <0xf000b000 0x400>;
+   bus-width = <4>;
+   fifo-depth = <128>;
+   clocks = <_biu>, <_ciu>;
+   clock-names = "biu", "ciu";
+   max-frequency = <2500>;
+   };
 };
diff --git a/board/synopsys/emsdp/emsdp.c b/board/synopsys/emsdp/emsdp.c
index 7a3fd5b7f2..5ba9f862e1 100644
--- a/board/synopsys/emsdp/emsdp.c
+++ b/board/synopsys/emsdp/emsdp.c
@@ -85,35 +85,6 @@ int board_early_init_r(void)
return 0;
 }
 
-int board_mmc_init(bd_t *bis)
-{
-   struct dwmci_host *host = NULL;
-
-   host = malloc(sizeof(struct dwmci_host));
-   if (!host) {
-   printf("dwmci_host malloc fail!\n");
-   return 1;
-   }
-
-   memset(host, 0, sizeof(struct dwmci_host));
-   host->name = "Synopsys Mobile storage";
-   host->ioaddr = SDIO_BASE;
-   host->buswidth = 4;
-   host->dev_index = 0;
-   host->bus_hz = 5000;
-
-   add_dwmci(host, host->bus_hz / 2, 40);
-
-   return 0;
-}
-
-int board_mmc_getcd(struct mmc *mmc)
-{
-   struct dwmci_host *host = mmc->priv;
-
-   return !(dwmci_readl(host, DWMCI_CDETECT) & 1);
-}
-
 #define CREG_BASE  0xF0001000
 #define CREG_BOOT  (void *)(CREG_BASE + 0x0FF0)
 #define CREG_IP_SW_RESET   (void *)(CREG_BASE + 0x0FF0)
diff --git a/board/synopsys/iot_devkit/iot_devkit.c 
b/board/synopsys/iot_devkit/iot_devkit.c
index 8424e09bd3..9dbdc128f8 100644
--- a/board/synopsys/iot_devkit/iot_devkit.c
+++ b/board/synopsys/iot_devkit/iot_devkit.c
@@ -145,38 +145,6 @@ int mach_cpu_init(void)
return set_cpu_freq(gd->cpu_clk);
 }
 
-#define ARC_PERIPHERAL_BASE0xF000
-#define SDIO_BASE  (ARC_PERIPHERAL_BASE + 0xB000)
-
-int board_mmc_init(bd_t *bis)
-{
-   struct dwmci_host *host = NULL;
-
-   host = malloc(sizeof(struct dwmci_host));
-   if (!host) {
-   printf("dwmci_host malloc fail!\n");
-   return -ENOMEM;
-   }
-
-   memset(host, 0, sizeof(struct dwmci_host));
-   host->name = "Synopsys Mobile storage";
-   host->ioaddr = (void *)SDIO_BASE;
-   host->buswidth = 4;
-   host->dev_index = 0;
-   host->bus_hz = 5000;
-
-   add_dwmci(host, host->bus_hz / 2, 40);
-
-   re

[PATCH] arc: emsdp/iotdk: Switch to DM_MMC

2019-10-08 Thread Alexey Brodkin
Somehow EMSDP & IoT DK boards were skipped on ARC boads conversion
to DM MMC. So doing it now.

Signed-off-by: Alexey Brodkin 
---
 arch/arc/dts/emsdp.dts | 23 ++
 arch/arc/dts/iot_devkit.dts| 22 ++
 board/synopsys/emsdp/emsdp.c   | 29 ---
 board/synopsys/iot_devkit/iot_devkit.c | 32 --
 configs/emsdp_defconfig|  2 ++
 configs/iot_devkit_defconfig   |  2 ++
 6 files changed, 49 insertions(+), 61 deletions(-)

diff --git a/arch/arc/dts/emsdp.dts b/arch/arc/dts/emsdp.dts
index d307b95d8e..77362354d5 100644
--- a/arch/arc/dts/emsdp.dts
+++ b/arch/arc/dts/emsdp.dts
@@ -32,4 +32,27 @@
reg-shift = <2>;
reg-io-width = <4>;
};
+
+   mmcclk_biu: mmcclk-biu {
+   compatible = "fixed-clock";
+   clock-frequency = <1>;
+   #clock-cells = <0>;
+   };
+
+   mmcclk_ciu: mmcclk-ciu {
+   compatible = "fixed-clock";
+   clock-frequency = <1>;
+   #clock-cells = <0>;
+   };
+
+   mmc: mmc0@f001 {
+   compatible = "snps,dw-mshc";
+   reg = <0xf001 0x400>;
+   bus-width = <4>;
+   fifo-depth = <256>;
+   clocks = <_biu>, <_ciu>;
+   clock-names = "biu", "ciu";
+   max-frequency = <2500>;
+   };
+
 };
diff --git a/arch/arc/dts/iot_devkit.dts b/arch/arc/dts/iot_devkit.dts
index ebf5a950f0..e2cb602cae 100644
--- a/arch/arc/dts/iot_devkit.dts
+++ b/arch/arc/dts/iot_devkit.dts
@@ -42,4 +42,26 @@
compatible = "nop-phy";
#phy-cells = <0>;
};
+
+   mmcclk_biu: mmcclk-biu {
+   compatible = "fixed-clock";
+   clock-frequency = <5000>;
+   #clock-cells = <0>;
+   };
+
+   mmcclk_ciu: mmcclk-ciu {
+   compatible = "fixed-clock";
+   clock-frequency = <5000>;
+   #clock-cells = <0>;
+   };
+
+   mmc: mmc0@f000b000 {
+   compatible = "snps,dw-mshc";
+   reg = <0xf000b000 0x400>;
+   bus-width = <4>;
+   fifo-depth = <256>;
+   clocks = <_biu>, <_ciu>;
+   clock-names = "biu", "ciu";
+   max-frequency = <2500>;
+   };
 };
diff --git a/board/synopsys/emsdp/emsdp.c b/board/synopsys/emsdp/emsdp.c
index 7a3fd5b7f2..5ba9f862e1 100644
--- a/board/synopsys/emsdp/emsdp.c
+++ b/board/synopsys/emsdp/emsdp.c
@@ -85,35 +85,6 @@ int board_early_init_r(void)
return 0;
 }
 
-int board_mmc_init(bd_t *bis)
-{
-   struct dwmci_host *host = NULL;
-
-   host = malloc(sizeof(struct dwmci_host));
-   if (!host) {
-   printf("dwmci_host malloc fail!\n");
-   return 1;
-   }
-
-   memset(host, 0, sizeof(struct dwmci_host));
-   host->name = "Synopsys Mobile storage";
-   host->ioaddr = SDIO_BASE;
-   host->buswidth = 4;
-   host->dev_index = 0;
-   host->bus_hz = 5000;
-
-   add_dwmci(host, host->bus_hz / 2, 40);
-
-   return 0;
-}
-
-int board_mmc_getcd(struct mmc *mmc)
-{
-   struct dwmci_host *host = mmc->priv;
-
-   return !(dwmci_readl(host, DWMCI_CDETECT) & 1);
-}
-
 #define CREG_BASE  0xF0001000
 #define CREG_BOOT  (void *)(CREG_BASE + 0x0FF0)
 #define CREG_IP_SW_RESET   (void *)(CREG_BASE + 0x0FF0)
diff --git a/board/synopsys/iot_devkit/iot_devkit.c 
b/board/synopsys/iot_devkit/iot_devkit.c
index 8424e09bd3..9dbdc128f8 100644
--- a/board/synopsys/iot_devkit/iot_devkit.c
+++ b/board/synopsys/iot_devkit/iot_devkit.c
@@ -145,38 +145,6 @@ int mach_cpu_init(void)
return set_cpu_freq(gd->cpu_clk);
 }
 
-#define ARC_PERIPHERAL_BASE0xF000
-#define SDIO_BASE  (ARC_PERIPHERAL_BASE + 0xB000)
-
-int board_mmc_init(bd_t *bis)
-{
-   struct dwmci_host *host = NULL;
-
-   host = malloc(sizeof(struct dwmci_host));
-   if (!host) {
-   printf("dwmci_host malloc fail!\n");
-   return -ENOMEM;
-   }
-
-   memset(host, 0, sizeof(struct dwmci_host));
-   host->name = "Synopsys Mobile storage";
-   host->ioaddr = (void *)SDIO_BASE;
-   host->buswidth = 4;
-   host->dev_index = 0;
-   host->bus_hz = 5000;
-
-   add_dwmci(host, host->bus_hz / 2, 40);
-
-   return 0;
-}
-
-int board_mmc_getcd(struct mmc *mmc)
-{
-   struct dwmci_host *host = mmc->priv;
-
-   return !(dwmci_readl(host, DWMCI_CDETECT) &a

[PATCH] arc: emsdp: Increase max FAT cluster size

2019-10-08 Thread Alexey Brodkin
Some especially large SD-cards come from stock formatted with
larger FAT cluster size so to accommodate those we just increase
what we expect to have here in U-Boot given we have a plenty of
space on EM SDP (16 MiB).

Signed-off-by: Alexey Brodkin 
---
 configs/emsdp_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/emsdp_defconfig b/configs/emsdp_defconfig
index 42415ea713..09fe388e58 100644
--- a/configs/emsdp_defconfig
+++ b/configs/emsdp_defconfig
@@ -29,6 +29,6 @@ CONFIG_MMC_DW=y
 CONFIG_MMC_DW_SNPS=y
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
-CONFIG_FS_FAT_MAX_CLUSTSIZE=4096
+CONFIG_FS_FAT_MAX_CLUSTSIZE=32768
 CONFIG_USE_PRIVATE_LIBGCC=y
 CONFIG_PANIC_HANG=y
-- 
2.17.1



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


RE: [PATCH 3/6] ARC: mm: TLB Miss optim: avoid re-reading ECR

2019-09-16 Thread Alexey Brodkin
Hi Vineet,

> -Original Message-
> From: Vineet Gupta 
> Sent: Monday, September 16, 2019 2:32 PM
> To: linux-snps-arc@lists.infradead.org
> Cc: Alexey Brodkin ; Vineet Gupta 
> Subject: [PATCH 3/6] ARC: mm: TLB Miss optim: avoid re-reading ECR
> 
> For setting PTE Dirty bit, reuse the prior test for ST miss.
> 
> No need to reload ECR and test for ST cause code as the prev
> condition code is still valid (uncloberred)
> 
> Signed-off-by: Vineet Gupta 
> ---
>  arch/arc/mm/tlbex.S | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arc/mm/tlbex.S b/arch/arc/mm/tlbex.S
> index 110c72536e8b..4c88148d4cd1 100644
> --- a/arch/arc/mm/tlbex.S
> +++ b/arch/arc/mm/tlbex.S
> @@ -380,9 +380,7 @@ ENTRY(EV_TLBMissD)
> 
>   ;
>   ; UPDATE_PTE: Let Linux VM know that page was accessed/dirty

I'd suggest to put a BOLD comment here saying that we rely on previously
set condition flag so that whoever reads or (even worse) modifies that or
previous code keeps in mind that we shouldn't clobber a particular flag.

> - lr  r3, [ecr]
>   or  r0, r0, _PAGE_ACCESSED; Accessed bit always
> - btst_s  r3,  ECR_C_BIT_DTLB_ST_MISS   ; See if it was a Write Access ?
>   or.nz   r0, r0, _PAGE_DIRTY   ; if Write, set Dirty bit as well
>   st_sr0, [r1]  ; Write back PTE

-Alexey


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


RE: [U-Boot] [RFC PATCH] net: designware: drop compatible altr, socfpga-stmmac

2019-09-03 Thread Alexey Brodkin
Hi Joe,

> -Original Message-
> From: Joe Hershberger 
> Sent: Wednesday, September 4, 2019 1:10 AM
> To: Alexey Brodkin 
> Cc: Ralph Siemsen ; Joseph Hershberger 
> ; u-
> b...@lists.denx.de; linux-snps-arc@lists.infradead.org; Eugeniy Paltsev 
> 
> Subject: Re: [U-Boot] [RFC PATCH] net: designware: drop compatible altr, 
> socfpga-stmmac
> 
> On Tue, Aug 20, 2019 at 3:07 AM Alexey Brodkin
>  wrote:
> >
> > Hi Ralph,
> >
> > > -Original Message-
> > > From: Ralph Siemsen 
> > > Sent: Monday, August 19, 2019 9:43 PM
> > > To: u-b...@lists.denx.de; Joe Hershberger ; 
> > > Alexey Brodkin
> > > ; Vlad Zakharov 
> > > Cc: Ralph Siemsen 
> > > Subject: [RFC PATCH] net: designware: drop compatible altr,socfpga-stmmac
> > >
> > > The same compatible = "altr,socfpga-stmmac" appears in both
> > > drivers/net/designware.c and drivers/net/dwmac_socfgpa.c,
> > > creating ambiguity in which driver will be bound.
> > >
> > > For Intel/Altera SoC devices, dwmac_socfpga.c is the correct driver.
> > > So drop the compatible string from designware.c.
> > >
> > > Signed-off-by: Ralph Siemsen 
> > > ---
> > > This compatible string also appears in: axs10x_mb.dtsi and hsdk.dts.
> > > Maintainers of those boards have been copied, kindly review.
> >
> > Thanks for this clean-up.
> >
> > Speaking about AXS10x board where we do have DW GMAC
> > I cannot recall the reason I chose to use "altr,socfpga-stmmac"
> > for the board here [1] 3 years ago.
> >
> > But given we don't have any special quirks implemented whatever
> > is the most generic DW GMAC compatible string is should be good for us.
> >
> > Joe, could you please suggest if we need to use just "st,stm32-dwmac"
> > or add our own compatible as the ASIC is not from ST obviously but
> > an FPGA with Synopsys ARC SoC?
> 
> I think we should only be using what Linux does, so I'm afraid I have
> to defer to what exists in the DTs there.

In the Linux kernel we use "snps,dwmac", see [1].
But maybe we need to switch to "snps,dwmac-3.70a" even as what we really have 
is 3.73a.

While in U-Boot we don't have either one, the most generic is "st,stm32-dwmac", 
see [2].
So maybe we want to add at least "snps,dwmac".

@Jose Abreu could you please confirm if "snps,dwmac-3.70a" is OK for GMAC IP 
v3.73a?

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arc/boot/dts/axs10x_mb.dtsi#n74
[2] 
https://gitlab.denx.de/u-boot/u-boot/blob/master/drivers/net/designware.c#L855

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


RE: [PATCH] mmc: dw_mmc: fix timeout calculate method

2019-09-03 Thread Alexey Brodkin
H Tom,

[snip]

> > > This is the patch with problem, and here is the link on patchwork:
> > > https://patchwork.ozlabs.org/patch/1146845/
> >
> > Please find my fixes here:
> > https://patchwork.ozlabs.org/patch/1156541/
> > https://patchwork.ozlabs.org/patch/1156617/
> >
> > Tom do we want https://patchwork.ozlabs.org/patch/1146845/ and fixes for it
> > (see 2 items above) to become a part of upcoming v2019.10 release or
> > it will be slated for the next one?
> 
> I think we should aim to get all the fixes in for this release.

Done, see https://lists.denx.de/pipermail/u-boot/2019-September/382628.html

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


RE: [PATCH] mmc: dw_mmc: fix timeout calculate method

2019-09-02 Thread Alexey Brodkin
Hi Kever,

> -Original Message-
> From: Kever Yang 
> Sent: Monday, September 2, 2019 11:05 AM
> To: Alexey Brodkin 
> Cc: tr...@konsulko.com; eugeniy.palt...@synopsys.com; Simon Glass 
> ; Peng Fan
> ; u-b...@lists.denx.de
> Subject: Re: [PATCH] mmc: dw_mmc: fix timeout calculate method
> 
> Hi Alexey,
> 
> On 2019/8/30 下午9:28, Alexey Brodkin wrote:
> > Hi Kever,
> >
> > [snip]
> >
> >> I think this tree does not including this patch, Peng drop it because of
> >> this issue,
> >> so you need to apply this patch in your branch to reproduce the problem.
> >> I have send out V2 patch for this fix with only using 32bit variable
> > Could you please refer me to the problematic patch so I may try it?
> 
> This is the patch with problem, and here is the link on patchwork:
> https://patchwork.ozlabs.org/patch/1146845/

Please find my fixes here:
https://patchwork.ozlabs.org/patch/1156541/
https://patchwork.ozlabs.org/patch/1156617/

Tom do we want https://patchwork.ozlabs.org/patch/1146845/ and fixes for it
(see 2 items above) to become a part of upcoming v2019.10 release or
it will be slated for the next one?

-Alexey


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


[PATCH] arc: emsdp: Add more platform-specific compiler options

2019-09-02 Thread Alexey Brodkin
Even though EM SDP is FPGA-based board and different FPGA
images (known as .bit-files) are awailable for the board still
there's a common subset of options we may rely on for all configs.

These are:
 * Normalizer
 * Swap instructions
 * Simple multiplier
 * Barrel-shifter
 * Floating-point unit
 * Shorter instructions (code density)

This among other improvements allows to compile code with
64-bit divisions, see [1].

[1] https://patchwork.ozlabs.org/patch/1156541/

Signed-off-by: Alexey Brodkin 
Cc: Kever Yang 
---
 board/synopsys/emsdp/config.mk | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 board/synopsys/emsdp/config.mk

diff --git a/board/synopsys/emsdp/config.mk b/board/synopsys/emsdp/config.mk
new file mode 100644
index 00..67fd7bf82a
--- /dev/null
+++ b/board/synopsys/emsdp/config.mk
@@ -0,0 +1,2 @@
+PLATFORM_CPPFLAGS += -mlittle-endian -mnorm -mswap -mmpy-option=3 \
+ -mbarrel-shifter -mfpu=fpuda_all -mcode-density
-- 
2.16.2


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


RE: [PATCH] arc: libgcc: Import __udivdi3 & __udivmoddi4 to allow 64-bit division

2019-09-02 Thread Alexey Brodkin
Hi,

> -Original Message-
> From: Alexey Brodkin 
> Sent: Monday, September 2, 2019 12:43 PM
> To: u-b...@lists.denx.de
> Cc: uboot-snps-...@synopsys.com; linux-snps-arc@lists.infradead.org; Alexey 
> Brodkin
> ; Kever Yang 
> Subject: [PATCH] arc: libgcc: Import __udivdi3 & __udivmoddi4 to allow 64-bit 
> division
> 
> As reported by Kever here [1] we were unable to compile 64-bit division
> code due to missing definition of __udivdi3().
> 
> Import its implementation and __udivmoddi4() as its direct dependency
> from today's libgcc [2].
> 
> [1] https://patchwork.ozlabs.org/patch/1146845/
> [2] 
> https://github.com/gcc-mirror/gcc/commit/5d8723600bc0eed41226b5a6785bc02a053b45d5
> 
> Signed-off-by: Alexey Brodkin 
> Cc: Kever Yang 

For the record for EM SDP (emsdp_defconfig) building still
fails this way:
->8-
arc-linux-ld.bfd: arch/arc/lib/lib.a(libgcc2.o): in function `__udivmoddi4':
.../arch/arc/lib/libgcc2.c:195: undefined reference to `__clzdi2'
arc-linux-ld.bfd: .../arch/arc/lib/libgcc2.c:195: undefined reference to 
`__clzdi2'
arc-linux-ld.bfd: .../arch/arc/lib/libgcc2.c:196: undefined reference to 
`__clzdi2'
arc-linux-ld.bfd: .../arch/arc/lib/libgcc2.c:196: undefined reference to 
`__clzdi2'
->8-

That happens because we use a very simple -mcpu=arcem which doesn't use
HW normalizer unit. I'm preparing a patch that will improve EM SDP's compiler
options.

-Alexey

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


[PATCH] arc: libgcc: Import __udivdi3 & __udivmoddi4 to allow 64-bit division

2019-09-02 Thread Alexey Brodkin
As reported by Kever here [1] we were unable to compile 64-bit division
code due to missing definition of __udivdi3().

Import its implementation and __udivmoddi4() as its direct dependency
from today's libgcc [2].

[1] https://patchwork.ozlabs.org/patch/1146845/
[2] 
https://github.com/gcc-mirror/gcc/commit/5d8723600bc0eed41226b5a6785bc02a053b45d5

Signed-off-by: Alexey Brodkin 
Cc: Kever Yang 
---
 arch/arc/lib/libgcc2.c | 75 ++
 1 file changed, 75 insertions(+)

diff --git a/arch/arc/lib/libgcc2.c b/arch/arc/lib/libgcc2.c
index b92a841a37..ab1dbe1c13 100644
--- a/arch/arc/lib/libgcc2.c
+++ b/arch/arc/lib/libgcc2.c
@@ -158,3 +158,78 @@ __umodsi3(long a, long b)
 {
return udivmodsi4(a, b, 1);
 }
+
+UDWtype
+__udivmoddi4(UDWtype n, UDWtype d, UDWtype *rp)
+{
+   UDWtype q = 0, r = n, y = d;
+   UWtype lz1, lz2, i, k;
+
+   /*
+* Implements align divisor shift dividend method. This algorithm
+* aligns the divisor under the dividend and then perform number of
+* test-subtract iterations which shift the dividend left. Number of
+* iterations is k + 1 where k is the number of bit positions the
+* divisor must be shifted left  to align it under the dividend.
+* quotient bits can be saved in the rightmost positions of the
+* dividend as it shifts left on each test-subtract iteration.
+*/
+
+   if (y <= r) {
+   lz1 = __builtin_clzll(d);
+   lz2 = __builtin_clzll(n);
+
+   k = lz1 - lz2;
+   y = (y << k);
+
+   /*
+* Dividend can exceed 2 ^ (width - 1) - 1 but still be less
+* than the aligned divisor. Normal iteration can drops the
+* high order bit of the dividend. Therefore, first
+* test-subtract iteration is a special case, saving its
+* quotient bit in a separate location and not shifting
+* the dividend.
+*/
+
+   if (r >= y) {
+   r = r - y;
+   q = (1ULL << k);
+   }
+
+   if (k > 0) {
+   y = y >> 1;
+
+   /*
+* k additional iterations where k regular test
+* subtract shift dividend iterations are done.
+*/
+   i = k;
+   do {
+   if (r >= y)
+   r = ((r - y) << 1) + 1;
+   else
+   r = (r << 1);
+   i = i - 1;
+   } while (i != 0);
+
+   /*
+* First quotient bit is combined with the quotient
+* bits resulting from the k regular iterations.
+*/
+   q = q + r;
+   r = r >> k;
+   q = q - (r << k);
+   }
+   }
+
+   if (rp)
+   *rp = r;
+
+   return q;
+}
+
+UDWtype
+__udivdi3(UDWtype n, UDWtype d)
+{
+   return __udivmoddi4(n, d, (UDWtype *)0);
+}
-- 
2.16.2


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


[PATCH] arc: emsdp: Add initialization of PSRAM

2019-08-29 Thread Alexey Brodkin
If the "Page Mode" is not enabled on the device,
read operations from PSRAM may result in incorrect data.

Signed-off-by: Alexey Brodkin 
---
 board/synopsys/emsdp/emsdp.c | 37 +
 configs/emsdp_defconfig  |  1 +
 2 files changed, 38 insertions(+)

diff --git a/board/synopsys/emsdp/emsdp.c b/board/synopsys/emsdp/emsdp.c
index c0770b58c1..3bf4a1879b 100644
--- a/board/synopsys/emsdp/emsdp.c
+++ b/board/synopsys/emsdp/emsdp.c
@@ -48,6 +48,43 @@ int mach_cpu_init(void)
return 0;
 }
 
+int board_early_init_r(void)
+{
+#define EMSDP_PSRAM_BASE   0xf2001000
+#define PSRAM_FLASH_CONFIG_REG_0   (void *)(EMSDP_PSRAM_BASE + 0x10)
+#define PSRAM_FLASH_CONFIG_REG_1   (void *)(EMSDP_PSRAM_BASE + 0x14)
+#define CRE_ENABLE BIT(31)
+#define CRE_DRIVE_CMD  BIT(6)
+
+#define PSRAM_RCR_DPD  BIT(4)
+#define PSRAM_RCR_PAGE_MODEBIT(7)
+
+/*
+ * PSRAM_FLASH_CONFIG_REG_x[30:15] to the address lines[16:1] of flash,
+ * thus "<< 1".
+ */
+#define PSRAM_RCR_SETUP((PSRAM_RCR_DPD | PSRAM_RCR_PAGE_MODE) 
<< 1)
+
+   // Switch PSRAM controller to command mode
+   writel(CRE_ENABLE | CRE_DRIVE_CMD, PSRAM_FLASH_CONFIG_REG_0);
+   // Program Refresh Configuration Register (RCR) for BANK0
+   writew(0, (void *)(0x1000 + PSRAM_RCR_SETUP));
+   // Switch PSRAM controller back to memory mode
+   writel(0, PSRAM_FLASH_CONFIG_REG_0);
+
+
+   // Switch PSRAM controller to command mode
+   writel(CRE_ENABLE | CRE_DRIVE_CMD, PSRAM_FLASH_CONFIG_REG_1);
+   // Program Refresh Configuration Register (RCR) for BANK1
+   writew(0, (void *)(0x1080 + PSRAM_RCR_SETUP));
+   // Switch PSRAM controller back to memory mode
+   writel(0, PSRAM_FLASH_CONFIG_REG_1);
+
+   printf("PSRAM initialized.\n");
+
+   return 0;
+}
+
 int board_mmc_init(bd_t *bis)
 {
struct dwmci_host *host = NULL;
diff --git a/configs/emsdp_defconfig b/configs/emsdp_defconfig
index 64281d0529..5e55e3e2b2 100644
--- a/configs/emsdp_defconfig
+++ b/configs/emsdp_defconfig
@@ -7,6 +7,7 @@ CONFIG_ENV_SIZE=0x1000
 CONFIG_SYS_CLK_FREQ=4000
 # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
 CONFIG_VERSION_VARIABLE=y
+CONFIG_BOARD_EARLY_INIT_R=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="emsdp# "
 # CONFIG_CMD_BOOTD is not set
-- 
2.16.2


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


RE: [RFC PATCH] net: designware: drop compatible altr,socfpga-stmmac

2019-08-20 Thread Alexey Brodkin
Hi Ralph,

> -Original Message-
> From: Ralph Siemsen 
> Sent: Monday, August 19, 2019 9:43 PM
> To: u-b...@lists.denx.de; Joe Hershberger ; Alexey 
> Brodkin
> ; Vlad Zakharov 
> Cc: Ralph Siemsen 
> Subject: [RFC PATCH] net: designware: drop compatible altr,socfpga-stmmac
> 
> The same compatible = "altr,socfpga-stmmac" appears in both
> drivers/net/designware.c and drivers/net/dwmac_socfgpa.c,
> creating ambiguity in which driver will be bound.
> 
> For Intel/Altera SoC devices, dwmac_socfpga.c is the correct driver.
> So drop the compatible string from designware.c.
> 
> Signed-off-by: Ralph Siemsen 
> ---
> This compatible string also appears in: axs10x_mb.dtsi and hsdk.dts.
> Maintainers of those boards have been copied, kindly review.

Thanks for this clean-up.

Speaking about AXS10x board where we do have DW GMAC
I cannot recall the reason I chose to use "altr,socfpga-stmmac"
for the board here [1] 3 years ago.

But given we don't have any special quirks implemented whatever
is the most generic DW GMAC compatible string is should be good for us.

Joe, could you please suggest if we need to use just "st,stm32-dwmac"
or add our own compatible as the ASIC is not from ST obviously but
an FPGA with Synopsys ARC SoC?

[1] 
https://gitlab.denx.de/u-boot/u-boot/commit/fb2dea60e8f355ae00d427db09112a90839c96ec

-Alexey

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


RE: [PATCH v2 2/2] ARC: enable uboot support unconditionally

2019-08-02 Thread Alexey Brodkin
Hi Greg,

> > May we have this one back-ported to linux-4.19.y?
> >
> > It was initially applied to Linus' tree during 5.0 development
> > cycle [1] but was never back-ported.
> >
> > Now w/o that patch in KernelCI we see boot failure on ARC HSDK
> > board [2] as opposed to normally working later kernel versions.
> >
> > [1] 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=493a2f812446e92bcb1e69a77381b4d39808d730
> > [2] 
> > https://storage.kernelci.org/stable/linux-4.19.y/v4.19.59/arc/hsdk_defconfig/gcc-8/lab-baylibre/boot-hsdk.txt
> >
> > Below is that same patch but rebased on linux-4.19 as in its pristine
> > form it won't apply due to offset of one of hunks.
> 
> Why is this patch ok for stable kernel trees?  Are you not removing
> existing support in 4.19 for a feature that people might be using there?
> What bug is this fixing that requires this removal?

This patch removes a Kconfig option in a trade for properly working
detection of arguments passed from U-Boot.

Back in the day [3] we had to add that option to get kernel reliably working
in use-cases w/o U-Boot (those were typically loading kernel image via JTAG).
But with a couple of fixes applied to linux-4.19.y already we no longer need
that explicit toggle as we may rely on data passed via dedicated registers
and thus automatically know if there was U-Boot which passed some info to
the kernel or there was no U-Boot and we don't need to mess with garbage in
those registers.

Main reason is to make vanilla 4.19.y kernels usable on HSDK board in KernelCI
environment. Now they don't boot, see [2] as in HSDK's defconfig 
ARC_UBOOT_SUPPORT
is not set. So we have 2 solutions:

1. Add ARC_UBOOT_SUPPORT to arch/arc/configs/hsdk_defconfig
   But we cannot do it for vanilla kernel because we simply cannot even submit 
that
   change to the Linus' tree as that Kconfig option was removed.
   Which means we cannot back-port it, right :)

2. Back-port proposed patch which already exists in the Linus'tree and thus is
   perfectly back-portable.

Makes sense?

-Alexey

[2] 
https://storage.kernelci.org/stable/linux-4.19.y/v4.19.59/arc/hsdk_defconfig/gcc-8/lab-baylibre/boot-hsdk.txt
[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=036b2c5664281e7da5a89c9f742491f30966485f

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


RE: [PATCH 2/2] dt-bindings: IDU-intc: Add support for edge-triggered interrupts

2019-07-24 Thread Alexey Brodkin
Hi Mischa,

> -Original Message-
> From: Mischa Jonker 
> Sent: Tuesday, July 23, 2019 1:26 PM
> To: Vineet Gupta ; Alexey Brodkin 
> ;
> kstew...@linuxfoundation.org; t...@linutronix.de; robh...@kernel.org; 
> linux-snps-
> a...@lists.infradead.org; linux-ker...@vger.kernel.org; 
> devicet...@vger.kernel.org
> Cc: Mischa Jonker 
> Subject: [PATCH 2/2] dt-bindings: IDU-intc: Add support for edge-triggered 
> interrupts
> 
> This updates the documentation for supporting  a optional extra interrupt
> cell to specify edge vs level triggered.

LGTM as well. But maybe split pure clean-up changes from addition of
the new property description so that info about addition of new property is
clearly seen? Otherwise it gets a bit lost among nice and useful generic fixes.

-Alexey


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


RE: [PATCH 1/2] ARCv2: IDU-intc: Add support for edge-triggered interrupts

2019-07-24 Thread Alexey Brodkin
Hi Mischa,

> -Original Message-
> From: Mischa Jonker 
> Sent: Tuesday, July 23, 2019 1:26 PM
> To: Vineet Gupta ; Alexey Brodkin 
> ;
> kstew...@linuxfoundation.org; t...@linutronix.de; robh...@kernel.org; 
> linux-snps-
> a...@lists.infradead.org; linux-ker...@vger.kernel.org; 
> devicet...@vger.kernel.org
> Cc: Mischa Jonker 
> Subject: [PATCH 1/2] ARCv2: IDU-intc: Add support for edge-triggered 
> interrupts
> 
> This adds support for an optional extra interrupt cell to specify edge
> vs level triggered. It is backward compatible with dts files with only
> one cell, and will default to level-triggered in such a case.

In general LGTM. Still a couple of comments.

It might be useful to explain changes
made to idu_irq_set_affinity() as it's not immediately clear what affinity
has to do with IRQ modes (in theory it should be orthogonal).

But what happens we're actually fixing previously implemented short-cut
when instead of a separately set IRQ mode we were doing it together with
setup of distribution since it's done with the same one command
(anyways we relied on the one and only IRQ type being supported).

And now we have a proper implementation with separated setup of IRQ mode and
affinity.

>  static int
>  idu_irq_set_affinity(struct irq_data *data, const struct cpumask *cpumask,
>bool force)
> @@ -263,13 +285,32 @@ idu_irq_set_affinity(struct irq_data *data, const 
> struct cpumask *cpumask,
>   else
>   distribution_mode = IDU_M_DISTRI_RR;
> 
> - idu_set_mode(data->hwirq, IDU_M_TRIG_LEVEL, distribution_mode);
> + idu_set_mode(data->hwirq, false, 0, true, distribution_mode);
> 
>   raw_spin_unlock_irqrestore(_lock, flags);
> 
>   return IRQ_SET_MASK_OK;
>  }
> 
> +static int idu_irq_set_type(struct irq_data *data, u32 type)
> +{
> + unsigned long flags;
> +
> + if (type & ~(IRQ_TYPE_EDGE_RISING | IRQ_TYPE_LEVEL_HIGH))
> + return -EINVAL;

Maybe add an explanation why only these types are supported?

-Alexey

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


RE: [PATCH v2] ARC: [plat-hsdk]: allow to switch between AXI DMAC port configurations

2019-07-22 Thread Alexey Brodkin
Hi Eugeniy,

> -Original Message-
> From: Eugeniy Paltsev 
> Sent: Monday, July 22, 2019 12:32 PM
> To: linux-snps-arc@lists.infradead.org; Vineet Gupta 
> Cc: linux-ker...@vger.kernel.org; Alexey Brodkin ; 
> Eugeniy Paltsev
> 
> Subject: [PATCH v2] ARC: [plat-hsdk]: allow to switch between AXI DMAC port 
> configurations
> 
> We want to use DW AXI DMAC on HSDK board in our automated verification
> to test cache & dma kernel code changes. This is perfect candidate
> as we don't depend on any external peripherals like MMC card / USB
> storage / etc.
> To increase test coverage we want to test both options:
>  * DW AXI DMAC is connected through IOC port & dma direct ops used
>  * DW AXI DMAC is connected to DDR port & dma noncoherent ops used
> 
> Introduce 'arc_hsdk_axi_dmac_coherent' global variable which can be
> modified by debugger (same way as we patch 'ioc_enable') to switch
> between these options without recompiling the kernel.
> Depend on this value we tweak memory bridge configuration and
> "dma-coherent" DTS property of DW AXI DMAC.

Looks good to me.

Acked-by: Alexey Brodkin 

-Thanks


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


RE: [PATCH v2 2/2] ARC: enable uboot support unconditionally

2019-07-18 Thread Alexey Brodkin
Hi Greg,

> -Original Message-
> From: Eugeniy Paltsev 
> Sent: Thursday, February 14, 2019 6:08 PM
> To: linux-snps-arc@lists.infradead.org; Vineet Gupta 
> Cc: linux-ker...@vger.kernel.org; Alexey Brodkin ; 
> Corentin Labbe
> ; khil...@baylibre.com; Eugeniy Paltsev 
> 
> Subject: [PATCH v2 2/2] ARC: enable uboot support unconditionally
> 
> After reworking U-boot args handling code and adding paranoid
> arguments check we can eliminate CONFIG_ARC_UBOOT_SUPPORT and
> enable uboot support unconditionally.
> 
> For JTAG case we can assume that core registers will come up
> reset value of 0 or in worst case we rely on user passing
> '-on=clear_regs' to Metaware debugger.
> 
> Signed-off-by: Eugeniy Paltsev 

May we have this one back-ported to linux-4.19.y?

It was initially applied to Linus' tree during 5.0 development
cycle [1] but was never back-ported.

Now w/o that patch in KernelCI we see boot failure on ARC HSDK
board [2] as opposed to normally working later kernel versions.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=493a2f812446e92bcb1e69a77381b4d39808d730
[2] 
https://storage.kernelci.org/stable/linux-4.19.y/v4.19.59/arc/hsdk_defconfig/gcc-8/lab-baylibre/boot-hsdk.txt

Below is that same patch but rebased on linux-4.19 as in its pristine
form it won't apply due to offset of one of hunks.

-Alexey

>8
>From 3e565355f6a2d1a82bc9ecd47a46d1fa3c0cd2c1 Mon Sep 17 00:00:00 2001
From: Eugeniy Paltsev 
Date: Thu, 14 Feb 2019 18:07:45 +0300
Subject: [PATCH] ARC: enable uboot support unconditionally

After reworking U-boot args handling code and adding paranoid
arguments check we can eliminate CONFIG_ARC_UBOOT_SUPPORT and
enable uboot support unconditionally.

For JTAG case we can assume that core registers will come up
reset value of 0 or in worst case we rely on user passing
'-on=clear_regs' to Metaware debugger.

Cc: sta...@vger.kernel.org
Tested-by: Corentin LABBE 
Signed-off-by: Eugeniy Paltsev 
Signed-off-by: Vineet Gupta 
---
 arch/arc/Kconfig| 13 -
 arch/arc/configs/nps_defconfig  |  1 -
 arch/arc/configs/vdk_hs38_defconfig |  1 -
 arch/arc/configs/vdk_hs38_smp_defconfig |  2 --
 arch/arc/kernel/head.S  |  2 --
 arch/arc/kernel/setup.c |  2 --
 6 files changed, 21 deletions(-)

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 85eb7fc2e241..97b45fe8f0c2 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -199,7 +199,6 @@ config NR_CPUS
 
 config ARC_SMP_HALT_ON_RESET
bool "Enable Halt-on-reset boot mode"
-   default y if ARC_UBOOT_SUPPORT
help
  In SMP configuration cores can be configured as Halt-on-reset
  or they could all start at same time. For Halt-on-reset, non
@@ -538,18 +537,6 @@ config ARC_DBG_TLB_PARANOIA
 
 endif
 
-config ARC_UBOOT_SUPPORT
-   bool "Support uboot arg Handling"
-   default n
-   help
- ARC Linux by default checks for uboot provided args as pointers to
- external cmdline or DTB. This however breaks in absence of uboot,
- when booting from Metaware debugger directly, as the registers are
- not zeroed out on reset by mdb and/or ARCv2 based cores. The bogus
- registers look like uboot args to kernel which then chokes.
- So only enable the uboot arg checking/processing if users are sure
- of uboot being in play.
-
 config ARC_BUILTIN_DTB_NAME
string "Built in DTB"
help
diff --git a/arch/arc/configs/nps_defconfig b/arch/arc/configs/nps_defconfig
index 6e84060e7c90..621f59407d76 100644
--- a/arch/arc/configs/nps_defconfig
+++ b/arch/arc/configs/nps_defconfig
@@ -31,7 +31,6 @@ CONFIG_ARC_CACHE_LINE_SHIFT=5
 # CONFIG_ARC_HAS_LLSC is not set
 CONFIG_ARC_KVADDR_SIZE=402
 CONFIG_ARC_EMUL_UNALIGNED=y
-CONFIG_ARC_UBOOT_SUPPORT=y
 CONFIG_PREEMPT=y
 CONFIG_NET=y
 CONFIG_UNIX=y
diff --git a/arch/arc/configs/vdk_hs38_defconfig 
b/arch/arc/configs/vdk_hs38_defconfig
index 1e59a2e9c602..e447ace6fa1c 100644
--- a/arch/arc/configs/vdk_hs38_defconfig
+++ b/arch/arc/configs/vdk_hs38_defconfig
@@ -13,7 +13,6 @@ CONFIG_PARTITION_ADVANCED=y
 CONFIG_ARC_PLAT_AXS10X=y
 CONFIG_AXS103=y
 CONFIG_ISA_ARCV2=y
-CONFIG_ARC_UBOOT_SUPPORT=y
 CONFIG_ARC_BUILTIN_DTB_NAME="vdk_hs38"
 CONFIG_PREEMPT=y
 CONFIG_NET=y
diff --git a/arch/arc/configs/vdk_hs38_smp_defconfig 
b/arch/arc/configs/vdk_hs38_smp_defconfig
index b5c3f6c54b03..c82cdb10aaf4 100644
--- a/arch/arc/configs/vdk_hs38_smp_defconfig
+++ b/arch/arc/configs/vdk_hs38_smp_defconfig
@@ -15,8 +15,6 @@ CONFIG_AXS103=y
 CONFIG_ISA_ARCV2=y
 CONFIG_SMP=y
 # CONFIG_ARC_TIMERS_64BIT is not set
-# CONFIG_ARC_SMP_HALT_ON_RESET is not set
-CONFIG_ARC_UBOOT_SUPPORT=y
 CONFIG_ARC_BUILTIN_DTB_NAME="vdk_hs38_smp"
 CONFIG_PREEMPT=y
 

[GIT PULL] drm/arc: Minor improvements

2019-07-17 Thread Alexey Brodkin
Hi Dave, Daniel,

The following changes since commit 7aaddd96d5febcf5b24357a326b3038d49a20532:

  drm/modes: Don't apply cmdline's rotation if it wasn't specified (2019-07-16 
10:34:38 +0200)

are available in the Git repository at:

  g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.07.18

for you to fetch changes up to cee17a71656e9e1b5ffc01767844026550d5f4a9:

  drm/arcpgu: rework encoder search (2019-07-17 23:36:56 +0300)


This is a pretty simple improvement that allows to find encoder
as the one and only (ARC PGU doesn't support more than one) endpoint
instead of using non-standard "encoder-slave" property.


Eugeniy Paltsev (1):
  drm/arcpgu: rework encoder search

 drivers/gpu/drm/arc/arcpgu_drv.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

Regards,
Alexey

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


[PATCH] ARCv2: Don't pretend we may set U & DE bits in STATUS32 with kflag

2019-07-16 Thread Alexey Brodkin
As per PRM "kflag" instruction doesn't change state of
DE-flag ("Delayed branch is pending") and U-flag ("User mode")
in STATUS32 register so let's not act as if we can affect those bits.

Signed-off-by: Alexey Brodkin 
---
 arch/arc/include/asm/entry-arcv2.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arc/include/asm/entry-arcv2.h 
b/arch/arc/include/asm/entry-arcv2.h
index 225e7df2d8ed..6558e2edb583 100644
--- a/arch/arc/include/asm/entry-arcv2.h
+++ b/arch/arc/include/asm/entry-arcv2.h
@@ -237,7 +237,7 @@
 
 .macro FAKE_RET_FROM_EXCPN
lr  r9, [status32]
-   bic r9, r9, (STATUS_U_MASK|STATUS_DE_MASK|STATUS_AE_MASK)
+   bic r9, r9, STATUS_AE_MASK
or  r9, r9, STATUS_IE_MASK
kflag   r9
 .endm
-- 
2.16.2


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


[PATCH] ARC: [haps] Add Virtio support

2019-07-02 Thread Alexey Brodkin
As a preparation for QEMU usage for ARC let's add basic Virtio-MMIO
peripherals support for the platform we're going to use.

For now we add 5 Virtio slots in .dts and enable block and network devices
via Virtio-MMIO.

Note even though typically Virtio register set fits in 0x200 bytes
we "allocate" here 0x2000 so that it matches ARC's default 8KiB page size
and so remapping of that area is done clearly.

We also enable DEVTMPFS automount for more convenient use
of external root file-stystem. Before that we used to use built-in
Initramfs which didn't automount DEVTMPFS anyways so we didn't need
that option, while now it starts making sense.

Signed-off-by: Alexey Brodkin 
Cc: Rob Herring 
---
 arch/arc/boot/dts/haps_hs.dts  | 30 ++
 arch/arc/configs/haps_hs_defconfig |  5 -
 2 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/arch/arc/boot/dts/haps_hs.dts b/arch/arc/boot/dts/haps_hs.dts
index 1ebfa046492b..44bc522fdec8 100644
--- a/arch/arc/boot/dts/haps_hs.dts
+++ b/arch/arc/boot/dts/haps_hs.dts
@@ -62,5 +62,35 @@
#interrupt-cells = <1>;
interrupts = <20>;
};
+
+   virtio0: virtio@f010 {
+   compatible = "virtio,mmio";
+   reg = <0xf010 0x2000>;
+   interrupts = <31>;
+   };
+
+   virtio1: virtio@f0102000 {
+   compatible = "virtio,mmio";
+   reg = <0xf0102000 0x2000>;
+   interrupts = <32>;
+   };
+
+   virtio2: virtio@f0104000 {
+   compatible = "virtio,mmio";
+   reg = <0xf0104000 0x2000>;
+   interrupts = <33>;
+   };
+
+   virtio3: virtio@f0106000 {
+   compatible = "virtio,mmio";
+   reg = <0xf0106000 0x2000>;
+   interrupts = <34>;
+   };
+
+   virtio4: virtio@f0108000 {
+   compatible = "virtio,mmio";
+   reg = <0xf0108000 0x2000>;
+   interrupts = <35>;
+   };
};
 };
diff --git a/arch/arc/configs/haps_hs_defconfig 
b/arch/arc/configs/haps_hs_defconfig
index b117e6c16d41..436f2135bdc1 100644
--- a/arch/arc/configs/haps_hs_defconfig
+++ b/arch/arc/configs/haps_hs_defconfig
@@ -35,10 +35,12 @@ CONFIG_INET=y
 # CONFIG_IPV6 is not set
 # CONFIG_WIRELESS is not set
 CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_STANDALONE is not set
 # CONFIG_PREVENT_FIRMWARE_BUILD is not set
-# CONFIG_BLK_DEV is not set
+CONFIG_VIRTIO_BLK=y
 CONFIG_NETDEVICES=y
+CONFIG_VIRTIO_NET=y
 # CONFIG_NET_VENDOR_ARC is not set
 # CONFIG_NET_VENDOR_BROADCOM is not set
 # CONFIG_NET_VENDOR_INTEL is not set
@@ -68,6 +70,7 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_LOGO=y
 # CONFIG_HID is not set
 # CONFIG_USB_SUPPORT is not set
+CONFIG_VIRTIO_MMIO=y
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_EXT2_FS=y
 CONFIG_EXT2_FS_XATTR=y
-- 
2.16.2


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


RE: [uclibc-ng-devel] state of uClibc ARC soft-float support

2019-06-21 Thread Alexey Brodkin
Hi Waldemar,

> -Original Message-
> From: Waldemar Brodkorb 
> Sent: Friday, June 21, 2019 1:26 PM
> To: Vineet Gupta 
> Cc: de...@uclibc-ng.org; arcml ; Alexey 
> Brodkin
> 
> Subject: Re: [uclibc-ng-devel] state of uClibc ARC soft-float support
> 
> Hi Vineet,
> 
> I tried to sync the libm tests from glibc to uClibc-ng, but I think
> I broke it. May be we should revert the commit?
> 3384c45e66ddf18f235654b67ae34ac7dcb07534

There seems to be no commit with such hash:
https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=3384c45e66ddf18f235654b67ae34ac7dcb07534

Did you mean something else?

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


RE: [PATCH] ARC: ARCv2: jump label: implement jump label patching

2019-06-21 Thread Alexey Brodkin
Hi Vineet,

> -Original Message-
> From: linux-snps-arc  On Behalf 
> Of Vineet Gupta
> Sent: Thursday, June 20, 2019 11:50 PM
> To: Peter Zijlstra 
> Cc: linux-a...@vger.kernel.org; Ard Biesheuvel ; 
> Alexey Brodkin
> ; linux-ker...@vger.kernel.org; Jason Baron 
> ; Paolo Bonzini
> ; linux-snps-arc@lists.infradead.org; Eugeniy Paltsev
> 
> Subject: Re: [PATCH] ARC: ARCv2: jump label: implement jump label patching

[snip]

> Insn encoding is always middl eendina - irrespective of endianness.

Apparently only in little-endian mode instructions are encoded as middle-endian,
see:
-->8-
# cat endian.S

.global myfunc
myfunc:
mov r0, r1
-->8-

Little-endian:
-->8-
# arc-linux-gcc -c -mcpu=archs endian.S -EL
# arc-linux-objdump -d endian.o

endian.o: file format elf32-littlearc

Disassembly of section .text:
 :
   0:   200a 0040   mov r0,r1

# arc-linux-readelf -x .text endian.o
Hex dump of section '.text':
  0x 0a204000. @.
-->8-

Big-endian:
-->8-
# arc-linux-gcc -c -mcpu=archs endian.S -EB
# arc-linux-objdump -d endian.o

endian.o: file format elf32-bigarc

Disassembly of section .text:
 :
   0:   200a 0040   mov r0,r1

# arc-linux-readelf -x .text endian.o

Hex dump of section '.text':
  0x 200a0040 ..@
-->8-

-Alexey

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


RE: [PATCH] ARC: [plat-hsdk]: enable DW SPI controller

2019-06-07 Thread Alexey Brodkin
Hi Eugeniy,

> -Original Message-
> From: Eugeniy Paltsev 
> Sent: Friday, June 7, 2019 5:48 PM
> To: linux-snps-arc@lists.infradead.org; Vineet Gupta 
> Cc: linux-ker...@vger.kernel.org; Alexey Brodkin ; 
> Eugeniy Paltsev
> 
> Subject: [PATCH] ARC: [plat-hsdk]: enable DW SPI controller
> 
> HSDK SoC has DW SPI controller. Enable it in preparation of
> enabling on-board SPI peripherals.
> 
> Signed-off-by: Eugeniy Paltsev 

Adding Rob and...

Acked-by: Alexey Brodkin 

>  arch/arc/boot/dts/hsdk.dts  | 14 ++
>  arch/arc/configs/hsdk_defconfig |  3 +++
>  2 files changed, 17 insertions(+)
> 
> diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts
> index e57b24dd02e7..42e1c961ba48 100644
> --- a/arch/arc/boot/dts/hsdk.dts
> +++ b/arch/arc/boot/dts/hsdk.dts
> @@ -11,6 +11,7 @@
>   */
>  /dts-v1/;
> 
> +#include 
>  #include 
> 
>  / {
> @@ -233,6 +234,19 @@
>   dma-coherent;
>   };
> 
> + spi0: spi@2 {
> + compatible = "snps,dw-apb-ssi";
> + reg = <0x2 0x100>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupts = <16>;
> + num-cs = <2>;
> + reg-io-width = <4>;
> + clocks = <_clk>;
> + cs-gpios = <_gpio 0 GPIO_ACTIVE_LOW>,
> +<_gpio 1 GPIO_ACTIVE_LOW>;
> + };
> +
>   creg_gpio: gpio@14b0 {
>   compatible = "snps,creg-gpio-hsdk";
>   reg = <0x14b0 0x4>;
> diff --git a/arch/arc/configs/hsdk_defconfig b/arch/arc/configs/hsdk_defconfig
> index 0c4411f50948..ccfa744fe755 100644
> --- a/arch/arc/configs/hsdk_defconfig
> +++ b/arch/arc/configs/hsdk_defconfig
> @@ -46,6 +46,9 @@ CONFIG_SERIAL_8250_CONSOLE=y
>  CONFIG_SERIAL_8250_DW=y
>  CONFIG_SERIAL_OF_PLATFORM=y
>  # CONFIG_HW_RANDOM is not set
> +CONFIG_SPI=y
> +CONFIG_SPI_DESIGNWARE=y
> +CONFIG_SPI_DW_MMIO=y
>  CONFIG_GPIOLIB=y
>  CONFIG_GPIO_SYSFS=y
>  CONFIG_GPIO_DWAPB=y
> --
> 2.21.0


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


RE: Pass config-time variable to LIBC_SLIBDIR_RTLDDIR

2019-06-03 Thread Alexey Brodkin
Hi Joseph,

> -Original Message-
> From: Joseph Myers 
> Sent: Monday, June 3, 2019 6:41 PM
> To: Alexey Brodkin 
> Cc: Andreas Schwab ; libc-al...@sourceware.org; 
> linux-snps-arc@lists.infradead.org
> Subject: Re: Pass config-time variable to LIBC_SLIBDIR_RTLDDIR
> 
> On Fri, 31 May 2019, Alexey Brodkin wrote:
> 
> > Hi Andreas,
> >
> > I'm trying to implement multilib support for ARC port of Glibc
> > and for that we seem to need to have unique slibdir/rtlddir pair per
> > each machine flavor. In our case these are at least:
> >  - ARC700 (legacy ARCompact architecture)
> >  - ARC HS38 (new gen ARCv2 architecture)
> >  - ARC HS38 with hardware floating-point
> >  - ARC HS48 (binary-compatible with HS38 but with different pipeline so
> >  compiler schedules instructions differently)
> 
> If two processors are binary-compatible, in general you wouldn't have
> different library directories.  (The HWCAP mechanism can be used to have a
> single dynamic linker search different directories for optimized libraries
> depending on the processor; put the relevant HWCAP bits in
> HWCAP_IMPORTANT.  And of course you can just install different library
> builds depending on the processor you'll be running the resulting OS on.)
> 
> Different library directories are intended for the case where binaries for
> different ABIs can be executed on the same system (e.g. 32-bit and 64-bit;
> https://sourceware.org/ml/libc-alpha/2018-01/msg8.html gives more
> details of the various places that need updating to support such a
> configuration in glibc).  For other cases of different ABIs, there should
> be different dynamic linker names, to support multiarch configurations
> that might run different-architecture binaries under emulation, but
> different library directories are not required.

Well I'm trying to solve a little bit different problem - to build
a universal multilib cross-toolchain which will be usable for building
binaries optimized for different ARC cores. Different I mean:
 - Binary-incompatible architecture generations: ARCv1/ARCv2 (both still 32-bit)
 - Hard/soft floating-point
 - etc.

GCC itself handles multilib perfectly fine as long as C library components
are installed in proper locations. And bare-metal toolchain with Newlib as
well as uClibc Linux toolchain are known to work as expected: C libraries
get installed to a subfolder referenced by "arc-linux-gcc -print-multi-lib".

As for Glibc at least in Crosstool-NG (the one and only toolchain builder
that supports multilib toolchains) Glibc's smarts are used for libs installation
in sysroot.

I think it used to be done similarly to Newlib & uClibc but then was
converted to a current state by this commit:
https://github.com/crosstool-ng/crosstool-ng/commit/43c303c946c61469181d633cd5620cb92e44c329

That said since I'm not yet interested in multiple libs on target
maybe I'm just looking at a wrong place and instead CT-NG should be
improved. Alexey Neyman (in CC) might have more to add here.

> > Given we have in GCC a dedicated "-mcpu" value for each of items above
> > my first thought was to "automatically" setup slibdir/rtlddir
> > based on "-mcpu" value passed in CC during configuration.
> 
> Checking -mcpu in CC is a bad idea, given that the compiler might have
> been configured with a default CPU rather than passing it on the command
> line.

Well this case (no "-mcpu" in CC) is handled - then we just installed
libs in default non-multilib location, i.e. simple "/lib".
 
> Rather, you should test how the compiler behaves: either run $CC $CFLAGS
> $CPPFLAGS -E -dM -xc /dev/null and extract and examine predefined macros,
> or use AC_EGREP_CPP or AC_COMPILE_IFELSE for the same purpose.  (If you
> don't have predefined macros that make all the required ABI distinctions,
> obviously you need to add them.)  There are various examples of this in
> existing configure / preconfigure fragments.

Right I did see a lot of those.

> Since there should be a finite list of known ABIs (which would be listed
> on https://sourceware.org/glibc/wiki/ABIList for a port included in
> glibc), you can then have a finite number of LIBC_SLIBDIR_RTLDDIR calls in
> a case statement.

Agree, but again this is more for run-time libs on target where having
many flavors of libs is quite an overkill.

-Alexey
 

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


RE: [PATCH] ARC: build: Try to guess CROSS_COMPILE with cc-cross-prefix

2019-06-03 Thread Alexey Brodkin
Hi Vineet,

> -Original Message-
> From: Vineet Gupta 
> Sent: Monday, June 3, 2019 7:25 PM
> To: Alexey Brodkin ; linux-snps-arc@lists.infradead.org
> Cc: linux-ker...@vger.kernel.org; Masahiro Yamada 
> 
> Subject: Re: [PATCH] ARC: build: Try to guess CROSS_COMPILE with 
> cc-cross-prefix
> 
> On 6/2/19 11:31 PM, Alexey Brodkin wrote:
> > For a long time we used to hard-code CROSS_COMPILE prefix
> > for ARC until it started to cause problems, so we decided to
> > solely rely on CROSS_COMPILE externally set by a user:
> > commit 40660f1fcee8 ("ARC: build: Don't set CROSS_COMPILE in arch's 
> > Makefile").
> >
> > While it works perfectly fine for build-systems where the prefix
> > gets defined anyways for us human beings it's quite an annoying
> > requirement especially given most of time the same one prefix
> > "arc-linux-" is all what we need.
> >
> > It looks like finally we're getting the best of both worlds:
> >  1. W/o cross-toolchain we still may install headers, build .dtb etc
> >  2. W/ cross-toolchain get the kerne built with only ARCH=arc
> >
> > Inspired by [1] & [2].
> >
> > [1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-May/005788.html
> > [2] 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc2b47b55f17
> >
> > A side note: even though "cc-cross-prefix" does its job it pollutes
> > console with output of "which" for all the prefixes it didn't manage to find
> > a matching cross-compiler for like that:
> > | # ARCH=arc make defconfig
> > | which: no arceb-linux-gcc in (~/.local/bin:~/bin:/usr/bin:/usr/sbin)
> > | *** Default configuration is based on 'nsim_hs_defconfig'
> >
> > Signed-off-by: Alexey Brodkin 
> > Cc: Masahiro Yamada 
> > Cc: Vineet Gupta 
> 
> Not a big deal but I'd propose we add "Suggested-by: vgupta" since that is 
> where
> it came from.

Ooops, indeed that should have been added, but instead I just
mentioned your earlier email in the mailing list.

Care to add yourself on patch application?

-Alexey


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


RE: [PATCH] kbuild: use more portable 'command -v' for cc-cross-prefix

2019-06-03 Thread Alexey Brodkin
Hi Masahiro-san,

> -Original Message-
> From: linux-snps-arc  On Behalf 
> Of Masahiro Yamada
> Sent: Monday, June 3, 2019 1:49 PM
> To: linux-kbu...@vger.kernel.org
> Cc: Michal Marek ; Vineet Gupta 
> ; Alexey Brodkin
> ; linux-ker...@vger.kernel.org; linux-stable 
> ; Masahiro
> Yamada ; linux-snps-arc@lists.infradead.org
> Subject: [PATCH] kbuild: use more portable 'command -v' for cc-cross-prefix

[snip]
 
> Fixes: bd55f96fa9fc ("kbuild: refactor cc-cross-prefix implementation")
> Cc: linux-stable  # 5.1
> Reported-by: Alexey Brodkin 
> Signed-off-by: Masahiro Yamada 
> ---

Thanks for the prompt fix - it does the trick, now no junk in the console!

Tested-by: Alexey Brodkin 

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


RE: [PATCH] ARC: build: Try to guess CROSS_COMPILE with cc-cross-prefix

2019-06-03 Thread Alexey Brodkin
Hi Masahiro-san,

> -Original Message-
> From: Masahiro Yamada 
> Sent: Monday, June 3, 2019 11:18 AM
> To: Alexey Brodkin 
> Cc: arcml ; Linux Kernel Mailing List 
>  ker...@vger.kernel.org>; Vineet Gupta 
> Subject: Re: [PATCH] ARC: build: Try to guess CROSS_COMPILE with 
> cc-cross-prefix
> 
> Hi Alexey,
> 
> On Mon, Jun 3, 2019 at 3:42 PM Alexey Brodkin
>  wrote:

[snip]

> > A side note: even though "cc-cross-prefix" does its job it pollutes
> > console with output of "which" for all the prefixes it didn't manage to find
> > a matching cross-compiler for like that:
> > | # ARCH=arc make defconfig
> > | which: no arceb-linux-gcc in (~/.local/bin:~/bin:/usr/bin:/usr/sbin)
> > | *** Default configuration is based on 'nsim_hs_defconfig'
> 
> 
> Oh really?
> 
> masahiro@pug:~$ which arc-linux-gcc
> /home/masahiro/tools/arc/bin/arc-linux-gcc
> masahiro@pug:~$ which dummy-linux-gcc
> masahiro@pug:~$ echo $?
> 1
> 
> 
> When 'which' cannot find the given command,
> it does not print anything to stderr.
> 
> Does it work differently on your machine?

Well on Ubuntu 18.04 indeed which doesn't show anything
but on my build-server with CentOS 7 I'm getting mentioned verbose output:
| # cat /etc/redhat-release
| CentOS Linux release 7.3.1611 (Core)

| # /usr/bin/which -v
| GNU which v2.20, Copyright (C) 1999 - 2008 Carlo Wood.
| GNU which comes with ABSOLUTELY NO WARRANTY;
| This program is free software; your freedom to use, change
| and distribute this program is protected by the GPL.

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

[PATCH] ARC: build: Try to guess CROSS_COMPILE with cc-cross-prefix

2019-06-03 Thread Alexey Brodkin
For a long time we used to hard-code CROSS_COMPILE prefix
for ARC until it started to cause problems, so we decided to
solely rely on CROSS_COMPILE externally set by a user:
commit 40660f1fcee8 ("ARC: build: Don't set CROSS_COMPILE in arch's Makefile").

While it works perfectly fine for build-systems where the prefix
gets defined anyways for us human beings it's quite an annoying
requirement especially given most of time the same one prefix
"arc-linux-" is all what we need.

It looks like finally we're getting the best of both worlds:
 1. W/o cross-toolchain we still may install headers, build .dtb etc
 2. W/ cross-toolchain get the kerne built with only ARCH=arc

Inspired by [1] & [2].

[1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-May/005788.html
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc2b47b55f17

A side note: even though "cc-cross-prefix" does its job it pollutes
console with output of "which" for all the prefixes it didn't manage to find
a matching cross-compiler for like that:
| # ARCH=arc make defconfig
| which: no arceb-linux-gcc in (~/.local/bin:~/bin:/usr/bin:/usr/sbin)
| *** Default configuration is based on 'nsim_hs_defconfig'

Signed-off-by: Alexey Brodkin 
Cc: Masahiro Yamada 
Cc: Vineet Gupta 
---
 arch/arc/Makefile | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index e2b991f75bc5..9cfd2ba7a12d 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -8,6 +8,10 @@
 
 KBUILD_DEFCONFIG := nsim_hs_defconfig
 
+ifeq ($(CROSS_COMPILE),)
+CROSS_COMPILE := $(call cc-cross-prefix, arc-linux- arceb-linux-)
+endif
+
 cflags-y   += -fno-common -pipe -fno-builtin -mmedium-calls -D__linux__
 cflags-$(CONFIG_ISA_ARCOMPACT) += -mA7
 cflags-$(CONFIG_ISA_ARCV2) += -mcpu=hs38
-- 
2.16.2


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


Pass config-time variable to LIBC_SLIBDIR_RTLDDIR

2019-05-31 Thread Alexey Brodkin
Hi Andreas,

I'm trying to implement multilib support for ARC port of Glibc
and for that we seem to need to have unique slibdir/rtlddir pair per
each machine flavor. In our case these are at least:
 - ARC700 (legacy ARCompact architecture)
 - ARC HS38 (new gen ARCv2 architecture)
 - ARC HS38 with hardware floating-point
 - ARC HS48 (binary-compatible with HS38 but with different pipeline so
 compiler schedules instructions differently)
 - eventually there'll be newer generations like ARCv3/v4 etc

Given we have in GCC a dedicated "-mcpu" value for each of items above
my first thought was to "automatically" setup slibdir/rtlddir
based on "-mcpu" value passed in CC during configuration.

Something like that:
-->8
+++ b/sysdeps/unix/sysv/linux/arc/configure.ac
@@ -2,3 +2,10 @@ GLIBC_PROVIDES dnl See aclocal.m4 in the top level source 
directory.
 # Local configure fragment for sysdeps/unix/sysv/linux/arc.

 arch_minimum_kernel=3.9.0
+
+# Extract "-mcpu=xxx" value from CC to install libs in a separate folder
+arc_mcpu=[`echo $CC | grep -Po '\-mcpu=\K[^ ]+'`]
+
+if test "$arc_mcpu" != "" ; then
+   LIBC_SLIBDIR_RTLDDIR([lib/${arc_mcpu}], [lib/${arc_mcpu}])
+fi
-->8

But apparently that doesn't work due to your change [1] in
commit 128c43a2d630 ("LIBC_SLIBDIR_RTLDDIR: substitute arguments in single 
quotes").

I guess mentioned change is not supposed to be reverted but then
how do you think it's possible [if at all] to implement that kind of
"automatic" setup of slibdir/rtlddir?

[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=128c43a2d630

-Alexey

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


RE: [PATCH] ARC: [plat-hsdk]: enable creg-gpio controller

2019-05-28 Thread Alexey Brodkin
Hi Eugeniy,

> -Original Message-
> From: Eugeniy Paltsev 
> Sent: Tuesday, May 28, 2019 12:41 PM
> To: linux-snps-arc@lists.infradead.org; Vineet Gupta 
> Cc: linux-ker...@vger.kernel.org; Alexey Brodkin ; 
> Eugeniy Paltsev
> 
> Subject: [PATCH] ARC: [plat-hsdk]: enable creg-gpio controller
> 
> HSDK SOC has CREG GPIO controller which can be used to control

SoC

> SPI chip select lines.
> Enable it in preparation of enabling SPI peripherals.

Acked-by: Alexey Brodkin 

Adding Rob to the Cc list.

-Alexey


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


RE: [PATCH] ARC: [plat-hsdk]: unify memory apertures configuration

2019-05-28 Thread Alexey Brodkin
Hi Eugeniy,

> -Original Message-
> From: Eugeniy Paltsev 
> Sent: Tuesday, May 28, 2019 11:55 AM
> To: linux-snps-arc@lists.infradead.org; Vineet Gupta 
> Cc: linux-ker...@vger.kernel.org; Alexey Brodkin ; 
> Eugeniy Paltsev
> 
> Subject: [PATCH] ARC: [plat-hsdk]: unify memory apertures configuration
> 
> HSDK SOC has memory bridge which allows to configure memory map

SoC (which stands for "System on Chip").

> for different AXI masters in runtime.
> As of today we adjust memory apertures configuration in U-boot
> so we have different configuration in case of loading kernel
> via U-boot and JTAG.
>
> It isn't really critical in case of existing platform configuration
> as configuration differs for  unused address space
> regions or unused AXI masters. However we may face with this
> issue when we'll bringup new peripherals or touch their address
> space.

Maybe add some background what do we change and why?
 
> Fix that by copy memory apertures configuration from U-boot to
> HSDK platform code.
> 
> Signed-off-by: Eugeniy Paltsev 

A couple of nitpicks, still...

Acked-by: Alexey Brodkin 

> ---
> This should be done a long time ago and this could save me from a lot

...should have been done... ...could have saved...

> of debugging while bringing up GPU on HSDKv2...
> 
>  arch/arc/plat-hsdk/platform.c | 144 --
>  1 file changed, 136 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arc/plat-hsdk/platform.c b/arch/arc/plat-hsdk/platform.c
> index 2588b842407c..e336e34925b7 100644
> --- a/arch/arc/plat-hsdk/platform.c
> +++ b/arch/arc/plat-hsdk/platform.c
> @@ -35,8 +35,6 @@ static void __init hsdk_init_per_cpu(unsigned int cpu)
> 
>  #define ARC_PERIPHERAL_BASE  0xf000
>  #define CREG_BASE(ARC_PERIPHERAL_BASE + 0x1000)
> -#define CREG_PAE (CREG_BASE + 0x180)
> -#define CREG_PAE_UPDATE  (CREG_BASE + 0x194)
> 
>  #define SDIO_BASE(ARC_PERIPHERAL_BASE + 0xA000)
>  #define SDIO_UHS_REG_EXT (SDIO_BASE + 0x108)
> @@ -102,20 +100,150 @@ static void __init hsdk_enable_gpio_intc_wire(void)
>   iowrite32(GPIO_INT_CONNECTED_MASK, (void __iomem *) GPIO_INTEN);
>  }
> 
> -static void __init hsdk_init_early(void)
> +enum hsdk_axi_masters {
> + M_HS_CORE = 0,
> + M_HS_RTT,
> + M_AXI_TUN,
> + M_HDMI_VIDEO,
> + M_HDMI_AUDIO,
> + M_USB_HOST,
> + M_ETHERNET,
> + M_SDIO,
> + M_GPU,
> + M_DMAC_0,
> + M_DMAC_1,
> + M_DVFS
> +};
> +
> +#define UPDATE_VAL   1

I'd add some explanation of what that is here like:
 - Default (or modified) table from the manual xxx.
 - AXI_M_m_SLVx & AXI_M_m_OFFSETx are MMIO regs which are used for ...

> +/*
> + * m master  AXI_M_m_SLV0AXI_M_m_SLV1AXI_M_m_OFFSET0 
> AXI_M_m_OFFSET1
> + * 0 HS (CBU)0x  0x6311  0xFEDCBA98  
> 0x0E543210
> + * 1 HS (RTT)0x  0x  0xFEDCBA98  
> 0x76543210
> + * 2 AXI Tunnel  0x  0x  0xFEDCBA98  
> 0x76543210
> + * 3 HDMI-VIDEO  0x  0x  0xFEDCBA98  
> 0x76543210
> + * 4 HDMI-ADUIO  0x  0x  0xFEDCBA98  
> 0x76543210
> + * 5 USB-HOST0x  0x7799  0xFEDCBA98  
> 0x76DCBA98
> + * 6 ETHERNET0x  0x7799  0xFEDCBA98  
> 0x76DCBA98
> + * 7 SDIO0x  0x7799  0xFEDCBA98  
> 0x76DCBA98
> + * 8 GPU 0x  0x  0xFEDCBA98  
> 0x76543210
> + * 9 DMAC (port #1)  0x  0x  0xFEDCBA98  
> 0x76543210
> + * 10DMAC (port #2)  0x  0x  0xFEDCBA98  
> 0x76543210
> + * 11DVFS0x  0x6000  0x  
> 0x
> + *
> + * Please read ARC HS Development IC Specification, section 17.2 for more
> + * information about apertures configuration.
> + * NOTE: we intentionally modify default settings in U-boot. Default settings
> + * are specified in "Table 111 CREG Address Decoder register reset values".
> + */
> +
> +#define CREG_AXI_M_SLV0(m)  ((void __iomem *)(CREG_BASE + 0x020 * (m)))
> +#define CREG_AXI_M_SLV1(m)  ((void __iomem *)(CREG_BASE + 0x020 * (m) + 
> 0x004))
> +#define CREG_AXI_M_OFT0(m)  ((void __iomem *)(CREG_BASE + 0x020 * (m) + 
> 0x008))
> +#define CREG_AXI_M_OFT1(m)  ((void __iomem *)(CREG_BASE + 0x020 * (m) + 
> 0x00C))
> +#define CREG_AXI_M_UPDT(m)  ((void __iomem *)(CREG_BASE + 0x020 * (m) + 
> 0x014))

Maybe skip 1 zero? I.e. use 0x04/0x08/0x0c/0x14?

> +
> +#define 

RE: [PATCH 0/2] ARC: [plat-hsdk]: GMAC DT Bindings Improvements

2019-05-21 Thread Alexey Brodkin
Hi Jose, all,

> -Original Message-
> From: Jose Abreu 
> Sent: Monday, May 20, 2019 4:43 PM
> To: devicet...@vger.kernel.org; linux-snps-arc@lists.infradead.org; 
> linux-ker...@vger.kernel.org
> Cc: Jose Abreu ; Joao Pinto ; Rob 
> Herring
> ; Mark Rutland ; Vineet Gupta 
> ; Eugeniy
> Paltsev ; Alexey Brodkin 
> Subject: [PATCH 0/2] ARC: [plat-hsdk]: GMAC DT Bindings Improvements
> 
> Add two missing bindings.
> 

For entire series:

Acked-by: Alexey Brodkin 

@Vineet Gupta could you please pick this on up?

-Alexey

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


RE: [PATCH 4/9] ARC: mm: do_page_fault refactor #3: tidyup vma access permission code

2019-05-16 Thread Alexey Brodkin
Hi Vineet,

> -Original Message-
> From: Vineet Gupta 
> Sent: Thursday, May 16, 2019 8:38 PM
> To: Eugeniy Paltsev 
> Cc: palt...@snyopsys.com; linux-ker...@vger.kernel.org; Alexey Brodkin 
> ; linux-
> snps-...@lists.infradead.org
> Subject: Re: [PATCH 4/9] ARC: mm: do_page_fault refactor #3: tidyup vma 
> access permission code
> 
> On 5/16/19 10:24 AM, Eugeniy Paltsev wrote:
> >> +  unsigned int write = 0, exec = 0, mask;
> > Probably it's better to use 'bool' type for 'write' and 'exec' as we really 
> > use them as a boolean
> variables.
> 
> Right those are semantics, but the generated code for "bool" is not ideal - 
> given
> it is inherently a "char" it is promoted first to an int with an additional 
> EXTB
> which I really dislike.
> Guess it is more of a style thing.

In that sense maybe think about re-definition of "bool" type to 32-bit one
for entire architecture and get that benefit across the entire source tree?

-Alexey


  1   2   3   4   5   6   >