Re: [PATCH] arc: arcv2: cache: Explicitly set MSB counterpart of region ops addresses

On 08/01/2017 03:29 PM, Alexey Brodkin wrote: It is necessary to explicitly set both SLC_AUX_RGN_START1 and SLC_AUX_RGN_END1 which hold MSB bits of the physical address correspondingly of region start and end otherwise SLC region operation is executed in unpredictable manner, for example on HSDK

Re: [PATCH 5/5] ARC: DTS: Add device-tree for Anarion-based development board

On 07/29/2017 03:37 AM, Alexandru Gagniuc wrote: Signed-off-by: Alexandru Gagniuc --- arch/arc/boot/dts/adaptrum_anarion.dtsi | 107 arch/arc/boot/dts/adaptrum_anarion_fpga.dts | 49 + 2 files changed, 156 insertions(+)

Re: [PATCH 5/5] ARC: DTS: Add device-tree for Anarion-based development board

On 07/29/2017 03:37 AM, Alexandru Gagniuc wrote: Signed-off-by: Alexandru Gagniuc --- arch/arc/boot/dts/adaptrum_anarion.dtsi | 107 arch/arc/boot/dts/adaptrum_anarion_fpga.dts | 49 + 2 files changed, 156 insertions(+) create mode 100644

Re: [PATCH] ARC: clk: introduce HSDKv1 pll driver

Hi Stephen, On 07/14/2017 09:01 PM, Eugeniy Paltsev wrote: HSDKv1 boards manages it's clocks using various PLLs. These PLL has same dividers and corresponding control registers mapped to different addresses. So we add one common driver for such PLLs. Each PLL on HSDK board consist of three

Re: [PATCH] ARC: clk: introduce HSDKv1 pll driver

Hi Stephen, On 07/14/2017 09:01 PM, Eugeniy Paltsev wrote: HSDKv1 boards manages it's clocks using various PLLs. These PLL has same dividers and corresponding control registers mapped to different addresses. So we add one common driver for such PLLs. Each PLL on HSDK board consist of three

Re: [PATCH] arc: Hardcode ARCH_DMA_MINALIGN to max line length we may have

On 07/18/2017 07:31 AM, Alexey Brodkin wrote: Current implementation relies on L1 line length which might easily be smaller than L2 line (which is usually the case BTW). Imagine this typical case: L2 line is 128 bytes while L1 line is 64-bytes. Now we want to allocate small buffer and later use

Re: [PATCH] arc: Hardcode ARCH_DMA_MINALIGN to max line length we may have

On 07/18/2017 07:31 AM, Alexey Brodkin wrote: Current implementation relies on L1 line length which might easily be smaller than L2 line (which is usually the case BTW). Imagine this typical case: L2 line is 128 bytes while L1 line is 64-bytes. Now we want to allocate small buffer and later use

Re: semantics of dma_map_single()

Hi Christoph, On 07/16/2017 11:42 PM, Christoph Hellwig wrote: I would expect that it would support any contiguous range in the kernel mapping (e.g. no vmalloc and friends). But it's not documented anywhere, and if no in kernel users makes use of that fact at the moment it might be better to

Re: semantics of dma_map_single()

Hi Christoph, On 07/16/2017 11:42 PM, Christoph Hellwig wrote: I would expect that it would support any contiguous range in the kernel mapping (e.g. no vmalloc and friends). But it's not documented anywhere, and if no in kernel users makes use of that fact at the moment it might be better to

semantics of dma_map_single()

P.S. Apologies in advance for the explicit TO list, it seemed adding people who've touched the dma mapping code (for ARC atleast), would respond sooner ;-) The question is does dma_map_single() imply a single region (possibly > PAGE_SIZE) or does it imply PAGE_SIZE. Documentation/DMA-API* is

semantics of dma_map_single()

P.S. Apologies in advance for the explicit TO list, it seemed adding people who've touched the dma mapping code (for ARC atleast), would respond sooner ;-) The question is does dma_map_single() imply a single region (possibly > PAGE_SIZE) or does it imply PAGE_SIZE. Documentation/DMA-API* is

Re: [PATCH] ARC: AXS: prepare dts files for enabling PAE40 on axs103

On 06/26/2017 04:47 AM, Eugeniy Paltsev wrote: Enable 64bit adressing, where it needed, to make possible enabling PAE40 on axs103. This patch doesn't affect on any functionality. Signed-off-by: Eugeniy Paltsev --- arch/arc/boot/dts/axc001.dtsi | 20

Re: [PATCH] ARC: AXS: prepare dts files for enabling PAE40 on axs103

On 06/26/2017 04:47 AM, Eugeniy Paltsev wrote: Enable 64bit adressing, where it needed, to make possible enabling PAE40 on axs103. This patch doesn't affect on any functionality. Signed-off-by: Eugeniy Paltsev --- arch/arc/boot/dts/axc001.dtsi | 20 +---

Re: [PATCH 3/3 v6] ARC: hsdk: initial port for HSDK board

On 06/26/2017 06:11 PM, Eugeniy Paltsev wrote: From: Alexey Brodkin diff --git a/arch/arc/configs/hsdk_defconfig b/arch/arc/configs/hsdk_defconfig new file mode 100644 index 000..53bc9f3 --- /dev/null +++ b/arch/arc/configs/hsdk_defconfig @@ -0,0 +1,75 @@

Re: [PATCH 3/3 v6] ARC: hsdk: initial port for HSDK board

On 06/26/2017 06:11 PM, Eugeniy Paltsev wrote: From: Alexey Brodkin diff --git a/arch/arc/configs/hsdk_defconfig b/arch/arc/configs/hsdk_defconfig new file mode 100644 index 000..53bc9f3 --- /dev/null +++ b/arch/arc/configs/hsdk_defconfig @@ -0,0 +1,75 @@

stdout-path (was Re: [PATCH 3/3 v6] ARC: hsdk: initial port for HSDK board)

On 06/26/2017 07:25 PM, Alexey Brodkin wrote: + + chosen { + bootargs = "earlycon=uart8250,mmio32,0xf0005000,115200n8 console=ttyS0,115200n8 debug print-fatal-signals=1"; Use stdout-path for the console. Really, the bootargs should be blank and populated by the bootloader

stdout-path (was Re: [PATCH 3/3 v6] ARC: hsdk: initial port for HSDK board)

On 06/26/2017 07:25 PM, Alexey Brodkin wrote: + + chosen { + bootargs = "earlycon=uart8250,mmio32,0xf0005000,115200n8 console=ttyS0,115200n8 debug print-fatal-signals=1"; Use stdout-path for the console. Really, the bootargs should be blank and populated by the bootloader

Re: [PATCHv2 1/3] x86/mm: Provide pmdp_establish() helper

On 06/21/2017 10:16 AM, Kirill A. Shutemov wrote: On Wed, Jun 21, 2017 at 08:49:03AM -0700, Vineet Gupta wrote: On 06/21/2017 04:27 AM, Catalin Marinas wrote: On Wed, Jun 21, 2017 at 12:53:03PM +0300, Kirill A. Shutemov wrote: On Thu, Jun 15, 2017 at 05:52:22PM +0300, Kirill A. Shutemov wrote

Re: [PATCHv2 1/3] x86/mm: Provide pmdp_establish() helper

On 06/21/2017 10:16 AM, Kirill A. Shutemov wrote: On Wed, Jun 21, 2017 at 08:49:03AM -0700, Vineet Gupta wrote: On 06/21/2017 04:27 AM, Catalin Marinas wrote: On Wed, Jun 21, 2017 at 12:53:03PM +0300, Kirill A. Shutemov wrote: On Thu, Jun 15, 2017 at 05:52:22PM +0300, Kirill A. Shutemov wrote

Re: [PATCHv2 1/3] x86/mm: Provide pmdp_establish() helper

On 06/21/2017 04:27 AM, Catalin Marinas wrote: On Wed, Jun 21, 2017 at 12:53:03PM +0300, Kirill A. Shutemov wrote: On Thu, Jun 15, 2017 at 05:52:22PM +0300, Kirill A. Shutemov wrote: We need an atomic way to setup pmd page table entry, avoiding races with CPU setting dirty/accessed bits. This

Re: [PATCHv2 1/3] x86/mm: Provide pmdp_establish() helper

On 06/21/2017 04:27 AM, Catalin Marinas wrote: On Wed, Jun 21, 2017 at 12:53:03PM +0300, Kirill A. Shutemov wrote: On Thu, Jun 15, 2017 at 05:52:22PM +0300, Kirill A. Shutemov wrote: We need an atomic way to setup pmd page table entry, avoiding races with CPU setting dirty/accessed bits. This

Re: [PATCH] arc: implement DMA_ATTR_NO_KERNEL_MAPPING

On 06/16/2017 12:11 AM, Christoph Hellwig wrote: This way allocations like the NVMe HMB don't consume iomap space Signed-off-by: Christoph Hellwig --- Note: compile tested only, I stumbled over this when researching dma api quirks for HMB support. arch/arc/mm/dma.c | 42

Re: [PATCH] arc: implement DMA_ATTR_NO_KERNEL_MAPPING

On 06/16/2017 12:11 AM, Christoph Hellwig wrote: This way allocations like the NVMe HMB don't consume iomap space Signed-off-by: Christoph Hellwig --- Note: compile tested only, I stumbled over this when researching dma api quirks for HMB support. arch/arc/mm/dma.c | 42

Re: [PATCH v2 08/12] ARC: [plat-eznps] new command line argument for HW scheduler at MTM

On 06/13/2017 07:03 AM, Noam Camus wrote: From: Noam Camus We add ability for all cores at NPS SoC to control the number of cycles HW thread can execute before it is replace with another eligible HW thread within the same core. The replacement is done by the HE scheduler.

Re: [PATCH v2 08/12] ARC: [plat-eznps] new command line argument for HW scheduler at MTM

On 06/13/2017 07:03 AM, Noam Camus wrote: From: Noam Camus We add ability for all cores at NPS SoC to control the number of cycles HW thread can execute before it is replace with another eligible HW thread within the same core. The replacement is done by the HE scheduler. Signed-off-by: Noam

Re: [PATCH v2 02/12] ARC: set level of log per CPU during boot to be debug level

On 06/13/2017 07:03 AM, Noam Camus wrote: From: Noam Camus The reasons are: 1) speeding up boot time, becomes critical for many CPUs machine, e.g. NPS400 with 4K CPUs 2) shorten kernel log at boot time, again easy to scan for large scale machines such NPS400

Re: [PATCH v2 02/12] ARC: set level of log per CPU during boot to be debug level

On 06/13/2017 07:03 AM, Noam Camus wrote: From: Noam Camus The reasons are: 1) speeding up boot time, becomes critical for many CPUs machine, e.g. NPS400 with 4K CPUs 2) shorten kernel log at boot time, again easy to scan for large scale machines such NPS400 Signed-off-by: Noam Camus

Re: [PATCH v2 01/12] ARC: [plat-eznps] Handle memory error as an exception

On 06/13/2017 07:03 AM, Noam Camus wrote: From: Noam Camus On ARC700, user mode memory error is treated as L2 interrupt, but NPS hardware treats it as Machine Check exception. Address this by defining an NPS specific bus error handler. This still leaves too much to dig

Re: [PATCH v2 01/12] ARC: [plat-eznps] Handle memory error as an exception

On 06/13/2017 07:03 AM, Noam Camus wrote: From: Noam Camus On ARC700, user mode memory error is treated as L2 interrupt, but NPS hardware treats it as Machine Check exception. Address this by defining an NPS specific bus error handler. This still leaves too much to dig thru. I've rewritten

Re: [PATCH v2 11/11] ARC: [plat-eznps] Handle memory error as an exception

On 06/08/2017 08:17 PM, Noam Camus wrote: *> From:*Vineet Gupta <vineet.gup...@synopsys.com> *> Sent:* Thursday, June 8, 2017 10:00 PM >> With EZsim we try to simulate NPS400 CTOP core and not ARC core, and as such we >> strive to have similar echo system for both s

Re: [PATCH v2 11/11] ARC: [plat-eznps] Handle memory error as an exception

On 06/08/2017 08:17 PM, Noam Camus wrote: *> From:*Vineet Gupta *> Sent:* Thursday, June 8, 2017 10:00 PM >> With EZsim we try to simulate NPS400 CTOP core and not ARC core, and as such we >> strive to have similar echo system for both silicon and its simulator.

Re: [RFC][PATCH] atomic: Fix atomic_set_release() for 'funny' architectures

On 06/09/2017 04:13 AM, Peter Zijlstra wrote: On Fri, Jun 09, 2017 at 01:05:06PM +0200, Peter Zijlstra wrote: The spinlock based atomics should be SC, that is, none of them appear to place extra barriers in atomic_cmpxchg() or any of the other SC atomic primitives and therefore seem to rely on

Re: [RFC][PATCH] atomic: Fix atomic_set_release() for 'funny' architectures

On 06/09/2017 04:13 AM, Peter Zijlstra wrote: On Fri, Jun 09, 2017 at 01:05:06PM +0200, Peter Zijlstra wrote: The spinlock based atomics should be SC, that is, none of them appear to place extra barriers in atomic_cmpxchg() or any of the other SC atomic primitives and therefore seem to rely on

Re: [PATCH v2 11/11] ARC: [plat-eznps] Handle memory error as an exception

On 06/08/2017 11:23 AM, Noam Camus wrote: *> From:* Vineet Gupta <vineet.gup...@synopsys.com> *> Sent:* Thursday, June 8, 2017 7:38 PM >> >> With simulator we just turn this configuration on, so we redirect the Legacy >> Synopsys L2 ISR from nSIM into machin

Re: [PATCH v2 11/11] ARC: [plat-eznps] Handle memory error as an exception

On 06/08/2017 11:23 AM, Noam Camus wrote: *> From:* Vineet Gupta *> Sent:* Thursday, June 8, 2017 7:38 PM >> >> With simulator we just turn this configuration on, so we redirect the Legacy >> Synopsys L2 ISR from nSIM into machine check. >> This way we

Re: [PATCH v2 11/11] ARC: [plat-eznps] Handle memory error as an exception

On 06/07/2017 08:29 PM, Noam Camus wrote: *From:* Noam Camus *Sent:* Wednesday, June 7, 2017 8:06:17 PM *To:* Vineet Gupta; linux-snps-...@lists.infradead.org *Cc:* linux-kernel@vger.kernel.org; Elad Kanfi *Subject:* Re: [PATCH v2 11/11] ARC: [plat-eznps] Handle memory error as an exception

Re: [PATCH v2 11/11] ARC: [plat-eznps] Handle memory error as an exception

On 06/07/2017 08:29 PM, Noam Camus wrote: *From:* Noam Camus *Sent:* Wednesday, June 7, 2017 8:06:17 PM *To:* Vineet Gupta; linux-snps-...@lists.infradead.org *Cc:* linux-kernel@vger.kernel.org; Elad Kanfi *Subject:* Re: [PATCH v2 11/11] ARC: [plat-eznps] Handle memory error as an exception

Re: [PATCH 17/35] ARC: defconfig: Cleanup from old Kconfig options

On 06/08/2017 09:10 AM, Krzysztof Kozlowski wrote: Remove old, dead Kconfig option INET_LRO. It is gone since commit 7bbf3cae65b6 ("ipv4: Remove inet_lro library"). Signed-off-by: Krzysztof Kozlowski <k...@kernel.org> Acked-by: vineet Gupta <vgu...@synopsys.com>

Re: [PATCH 17/35] ARC: defconfig: Cleanup from old Kconfig options

On 06/08/2017 09:10 AM, Krzysztof Kozlowski wrote: Remove old, dead Kconfig option INET_LRO. It is gone since commit 7bbf3cae65b6 ("ipv4: Remove inet_lro library"). Signed-off-by: Krzysztof Kozlowski Acked-by: vineet Gupta Do you want me to pick this up via ARC tree ? Thx, -Vineet

Re: [PATCH] arc: Remove sometimes misleading toolchain check

On 05/25/2017 10:24 AM, Alexey Brodkin wrote: Thinking of a toolchains for ARCompact and ARCv2 ISAs we implicitly think about libgcc.a build for one of those ISAs which we're linking with. And given there's no multiarch uClibc toolchain for ARC (as probably for any other architecture) the

Re: [PATCH] arc: Remove sometimes misleading toolchain check

On 05/25/2017 10:24 AM, Alexey Brodkin wrote: Thinking of a toolchains for ARCompact and ARCv2 ISAs we implicitly think about libgcc.a build for one of those ISAs which we're linking with. And given there's no multiarch uClibc toolchain for ARC (as probably for any other architecture) the

Re: [PATCH v2 11/11] ARC: [plat-eznps] Handle memory error as an exception

On 06/07/2017 04:14 AM, Noam Camus wrote: +config EZNPS_MEM_ERROR + bool "ARC-EZchip Memory error as an exception" + depends on ARC_PLAT_EZNPS + default n So you set default to "n" - thus by default it works for the simulator not silicon ? Correct, this way I "align" Sim

Re: [PATCH v2 11/11] ARC: [plat-eznps] Handle memory error as an exception

On 06/07/2017 04:14 AM, Noam Camus wrote: +config EZNPS_MEM_ERROR + bool "ARC-EZchip Memory error as an exception" + depends on ARC_PLAT_EZNPS + default n So you set default to "n" - thus by default it works for the simulator not silicon ? Correct, this way I "align" Sim

Re: [PATCH v4] hsdk: initial port for HSDK board

<abrod...@synopsys.com> Cc: Vineet Gupta <vgu...@synopsys.com> Cc: Rob Herring <robh...@kernel.org> --- Changes v3 -> v4: * Removed senseless "ranges" property from "memory" node in .dts * Refined early-boot code: - CREG_PAE should be set only once th

Re: [PATCH v4] hsdk: initial port for HSDK board

-aware peripherals. Note as opposed to other ARC boards we link Linux kernel to 0x9000_ intentionally because cores 1 and 3 configured with DCCM situated at our more usual link base 0x8000_. Signed-off-by: Eugeniy Paltsev Signed-off-by: Alexey Brodkin Cc: Vineet Gupta Cc: Rob Herring

Re: [PATCH v2 11/11] ARC: [plat-eznps] Handle memory error as an exception

On 05/27/2017 11:52 PM, Noam Camus wrote: From: Noam Camus This commit adds the configuration CONFIG_EZNPS_MEM_ERROR. If set, it will cause the kernel to handle user memory error as a machine check exception. It is required in order to align the NPS simulator memory error

Re: [PATCH v2 11/11] ARC: [plat-eznps] Handle memory error as an exception

On 05/27/2017 11:52 PM, Noam Camus wrote: From: Noam Camus This commit adds the configuration CONFIG_EZNPS_MEM_ERROR. If set, it will cause the kernel to handle user memory error as a machine check exception. It is required in order to align the NPS simulator memory error handling to the one

Re: [PATCH 10/10] ARC: [plat-eznps] Handle memory error as an exception

On 05/25/2017 04:30 AM, Alexey Brodkin wrote: Hi Noam, On Thu, 2017-05-25 at 11:26 +, Noam Camus wrote: From: Alexey Brodkin [mailto:alexey.brod...@synopsys.com] Sent: Thursday, May 25, 2017 14:15 PM diff --git a/arch/arc/kernel/entry-compact.S b/arch/arc/kernel/entry-compact.S index

Re: [PATCH 10/10] ARC: [plat-eznps] Handle memory error as an exception

On 05/25/2017 04:30 AM, Alexey Brodkin wrote: Hi Noam, On Thu, 2017-05-25 at 11:26 +, Noam Camus wrote: From: Alexey Brodkin [mailto:alexey.brod...@synopsys.com] Sent: Thursday, May 25, 2017 14:15 PM diff --git a/arch/arc/kernel/entry-compact.S b/arch/arc/kernel/entry-compact.S index

Re: [PATCH v2 11/11] ARC: [plat-eznps] Handle memory error as an exception

On 05/27/2017 11:52 PM, Noam Camus wrote: From: Noam Camus This commit adds the configuration CONFIG_EZNPS_MEM_ERROR. If set, it will cause the kernel to handle user memory error as a machine check exception. It is required in order to align the NPS simulator memory error

Re: [PATCH v2 11/11] ARC: [plat-eznps] Handle memory error as an exception

On 05/27/2017 11:52 PM, Noam Camus wrote: From: Noam Camus This commit adds the configuration CONFIG_EZNPS_MEM_ERROR. If set, it will cause the kernel to handle user memory error as a machine check exception. It is required in order to align the NPS simulator memory error handling to the one

Re: [PATCH v2 08/11] ARC: [plat-eznps] spinlock aware for MTM

On 05/27/2017 11:52 PM, Noam Camus wrote: From: Noam Camus This way when we execute "ex" during trying to hold lock we can switch to other HW thread and utilize the core intead of just spinning on a lock. We noticed about 10% improvement of execution time with hackbench

Re: [PATCH v2 08/11] ARC: [plat-eznps] spinlock aware for MTM

On 05/27/2017 11:52 PM, Noam Camus wrote: From: Noam Camus This way when we execute "ex" during trying to hold lock we can switch to other HW thread and utilize the core intead of just spinning on a lock. We noticed about 10% improvement of execution time with hackbench test. Signed-off-by:

Re: [PATCH v3] hsdk: initial port for HSDK board

<abrod...@synopsys.com> Cc: Vineet Gupta <vgu...@synopsys.com> Cc: Rob Herring <robh...@kernel.org> --- Changes v2 -> v3: * Added Rob to Cc-list for DT binding approval * Removed mention of prerequsite patch from commit message * Removed hsdk_early_init() as hsdk_init_per_cpu() i

Re: [PATCH v3] hsdk: initial port for HSDK board

-aware peripherals. Note as opposed to other ARC boards we link Linux kernel to 0x9000_ intentionally because cores 1 and 3 configured with DCCM situated at our more usual link base 0x8000_. Signed-off-by: Eugeniy Paltsev Signed-off-by: Alexey Brodkin Cc: Vineet Gupta Cc: Rob Herring

Re: [PATCH 06/10] ARC: [plat-eznps] Fix TLB Errata

On 05/25/2017 04:00 AM, Alexey Brodkin wrote: Hi Noam, On Thu, 2017-05-25 at 05:34 +0300, Noam Camus wrote: From: Noam Camus Due to a HW bug in NPS400 we get from time to time false TLB miss. Workaround this by validating each miss. Signed-off-by: Noam Camus

Re: [PATCH 06/10] ARC: [plat-eznps] Fix TLB Errata

On 05/25/2017 04:00 AM, Alexey Brodkin wrote: Hi Noam, On Thu, 2017-05-25 at 05:34 +0300, Noam Camus wrote: From: Noam Camus Due to a HW bug in NPS400 we get from time to time false TLB miss. Workaround this by validating each miss. Signed-off-by: Noam Camus --- arch/arc/mm/tlbex.S |

Re: [PATCH v2] hsdk: initial port for HSDK board

On 05/31/2017 10:49 AM, Alexey Brodkin wrote: This initial port add support of ARC HS Development Kit board with some basic features such as SMP and serial port, USB, SD/MMC and Ethernet. Note as opposed to other ARC boards we link Linux kernel to 0x9000_ intentionally because cores 1 and 3

Re: [PATCH v2] hsdk: initial port for HSDK board

On 05/31/2017 10:49 AM, Alexey Brodkin wrote: This initial port add support of ARC HS Development Kit board with some basic features such as SMP and serial port, USB, SD/MMC and Ethernet. Note as opposed to other ARC boards we link Linux kernel to 0x9000_ intentionally because cores 1 and 3

Re: [PATCH] hsdk: initial port for HSDK board

On 05/30/2017 07:25 AM, Alexey Brodkin wrote: This initial port add support of ARC HS Development Kit board with some basic features such as SMP and serial port, USB, SD/MMC and Ethernet. Note as opposed to other ARC boards we link Linux kernel to 0x9000_ intentionally because cores 1 and 3

Re: [PATCH] hsdk: initial port for HSDK board

On 05/30/2017 07:25 AM, Alexey Brodkin wrote: This initial port add support of ARC HS Development Kit board with some basic features such as SMP and serial port, USB, SD/MMC and Ethernet. Note as opposed to other ARC boards we link Linux kernel to 0x9000_ intentionally because cores 1 and 3

Re: [PATCH v2 02/11] ARC: send ipi to all cpus sharing task mm in case of page fault

On 05/27/2017 11:51 PM, Noam Camus wrote: From: Noam Camus This patch is derived due to performance issue. The use case is a page fault that resides on more than the local cpu. Trying to broadcast all CPUs results on performance degradation. So we try to avoid this by

Re: [PATCH v2 02/11] ARC: send ipi to all cpus sharing task mm in case of page fault

On 05/27/2017 11:51 PM, Noam Camus wrote: From: Noam Camus This patch is derived due to performance issue. The use case is a page fault that resides on more than the local cpu. Trying to broadcast all CPUs results on performance degradation. So we try to avoid this by sending only to the

Re: [PATCH] arc: Add "include chroot" for DT bindings

On 05/30/2017 06:22 AM, Alexey Brodkin wrote: Basically this extends c58299aa8754 "kbuild: create an "include chroot" for DT bindings" for ARC where we extensively use Device Tree and there're good reasons to use DT bindings, especially if those are required. Otherwise on attempt to compile

Re: [PATCH] arc: Add "include chroot" for DT bindings

On 05/30/2017 06:22 AM, Alexey Brodkin wrote: Basically this extends c58299aa8754 "kbuild: create an "include chroot" for DT bindings" for ARC where we extensively use Device Tree and there're good reasons to use DT bindings, especially if those are required. Otherwise on attempt to compile

asm/mmu.h using NR_CPUS (was Re: kisskb: FAILED linux-next/axs101_defconfig/arcompact Thu May 04, 18:53)

+CC Michal, linux-arch as it potentially affects other arches ! Hi, On 05/04/2017 01:53 AM, nore...@ellerman.id.au wrote: > FAILED linux-next/axs101_defconfig/arcompact Thu May 04, 18:53 > > http://kisskb.ellerman.id.au/kisskb/buildresult/13022475/ > > Commit: Add linux-next specific files

asm/mmu.h using NR_CPUS (was Re: kisskb: FAILED linux-next/axs101_defconfig/arcompact Thu May 04, 18:53)

+CC Michal, linux-arch as it potentially affects other arches ! Hi, On 05/04/2017 01:53 AM, nore...@ellerman.id.au wrote: > FAILED linux-next/axs101_defconfig/arcompact Thu May 04, 18:53 > > http://kisskb.ellerman.id.au/kisskb/buildresult/13022475/ > > Commit: Add linux-next specific files

4.2+ stable inclusion request: ARCv2: save r30 on kernel entry as gcc uses it for code-gen

Hi, Can we please backport upstream ecd43afdbe72017aefe48080631eb625e177ef4d ("ARCv2: save r30 on kernel entry as gcc uses it for code-gen") to 4.2 to 4.9 kernels. While the issue cites gcc, it is general deficiency of kernel as userspace programs can modify r30 register in hand/inline assembly

4.2+ stable inclusion request: ARCv2: save r30 on kernel entry as gcc uses it for code-gen

Hi, Can we please backport upstream ecd43afdbe72017aefe48080631eb625e177ef4d ("ARCv2: save r30 on kernel entry as gcc uses it for code-gen") to 4.2 to 4.9 kernels. While the issue cites gcc, it is general deficiency of kernel as userspace programs can modify r30 register in hand/inline assembly

Re: [RESEND PATCH 1/2] arc: axs10x: Add DT bindings for I2S audio playback

On 04/27/2017 11:42 AM, Jose Abreu wrote: > Hi Vineet, > > > On 27-04-2017 00:31, Vineet Gupta wrote: >> On 04/26/2017 01:55 AM, Jose Abreu wrote: >>> Hi Vineet, >>> >>> >>> On 24-04-2017 18:36, Vineet Gupta wrote: >>>> On 04/21/20

Re: [RESEND PATCH 1/2] arc: axs10x: Add DT bindings for I2S audio playback

On 04/27/2017 11:42 AM, Jose Abreu wrote: > Hi Vineet, > > > On 27-04-2017 00:31, Vineet Gupta wrote: >> On 04/26/2017 01:55 AM, Jose Abreu wrote: >>> Hi Vineet, >>> >>> >>> On 24-04-2017 18:36, Vineet Gupta wrote: >>>> On 04/21/20

Re: [RESEND PATCH 1/2] arc: axs10x: Add DT bindings for I2S audio playback

On 04/26/2017 01:55 AM, Jose Abreu wrote: > Hi Vineet, > > > On 24-04-2017 18:36, Vineet Gupta wrote: >> On 04/21/2017 03:15 AM, Jose Abreu wrote: >>> This patch adds the necessary DT bindings to get HDMI audio >>> output in ARC AXS10x SDP. The bindings for I

Re: [RESEND PATCH 1/2] arc: axs10x: Add DT bindings for I2S audio playback

On 04/26/2017 01:55 AM, Jose Abreu wrote: > Hi Vineet, > > > On 24-04-2017 18:36, Vineet Gupta wrote: >> On 04/21/2017 03:15 AM, Jose Abreu wrote: >>> This patch adds the necessary DT bindings to get HDMI audio >>> output in ARC AXS10x SDP. The bindings for I

[GIT PULL] ARC fixes for 4.11-final

700) Last minute fixes for ARC - Build error in Mellanox nps platform - addressing lack of saving FPU regs in releavnt configs Noam Camus (1): ARC: [plat-eznps] Fix build error Vineet Gupta (1): AR

[GIT PULL] ARC fixes for 4.11-final

700) Last minute fixes for ARC - Build error in Mellanox nps platform - addressing lack of saving FPU regs in releavnt configs Noam Camus (1): ARC: [plat-eznps] Fix build error Vineet Gupta (1): AR

Re: [RESEND PATCH 1/2] arc: axs10x: Add DT bindings for I2S audio playback

for 4.12 ? -Vineet > > Signed-off-by: Jose Abreu <joab...@synopsys.com> > Acked-by: Alexey Brodkin <abrod...@synopsys.com> > Cc: Carlos Palminha <palmi...@synopsys.com> > Cc: Alexey Brodkin <abrod...@synopsys.com> > Cc: Rob Herring <robh...@kernel.org&g

Re: [RESEND PATCH 1/2] arc: axs10x: Add DT bindings for I2S audio playback

for 4.12 ? -Vineet > > Signed-off-by: Jose Abreu > Acked-by: Alexey Brodkin > Cc: Carlos Palminha > Cc: Alexey Brodkin > Cc: Rob Herring > Cc: Vineet Gupta > Cc: devicet...@vger.kernel.org > Cc: linux-snps-...@lists.infradead.org > Cc: linux-kernel@vge

Re: [RFC][CFT][PATCHSET v1] uaccess unification

On 03/29/2017 05:27 PM, Linus Torvalds wrote: > On Wed, Mar 29, 2017 at 5:02 PM, Vineet Gupta > <vineet.gup...@synopsys.com> wrote: >> >> I guess I can in next day or two - but mind you the inline version for ARC >> is kind >> of special vs. other ar

Re: [RFC][CFT][PATCHSET v1] uaccess unification

On 03/29/2017 05:27 PM, Linus Torvalds wrote: > On Wed, Mar 29, 2017 at 5:02 PM, Vineet Gupta > wrote: >> >> I guess I can in next day or two - but mind you the inline version for ARC >> is kind >> of special vs. other arches. We have this "manual

Re: [RFC][CFT][PATCHSET v1] uaccess unification

On 03/29/2017 04:42 PM, Al Viro wrote: > On Wed, Mar 29, 2017 at 02:14:22PM -0700, Vineet Gupta wrote: > >>> BTW, I wonder if inlining all of the copy_{to,from}_user() is actually a >>> win. >> >> Just to be clear, your series was doing this for ever

Re: [RFC][CFT][PATCHSET v1] uaccess unification

On 03/29/2017 04:42 PM, Al Viro wrote: > On Wed, Mar 29, 2017 at 02:14:22PM -0700, Vineet Gupta wrote: > >>> BTW, I wonder if inlining all of the copy_{to,from}_user() is actually a >>> win. >> >> Just to be clear, your series was doing this for ever

Re: [RFC][CFT][PATCHSET v1] uaccess unification

On 03/29/2017 01:29 PM, Al Viro wrote: > On Wed, Mar 29, 2017 at 01:08:12PM -0700, Vineet Gupta wrote: > >> Hi Al, >> >> Thx for taking this up. It seems ARC was missing INLINE_COPY* switch likely >> due to >> existing 2 variants (inline/out-of-line) we

Re: [RFC][CFT][PATCHSET v1] uaccess unification

On 03/29/2017 01:29 PM, Al Viro wrote: > On Wed, Mar 29, 2017 at 01:08:12PM -0700, Vineet Gupta wrote: > >> Hi Al, >> >> Thx for taking this up. It seems ARC was missing INLINE_COPY* switch likely >> due to >> existing 2 variants (inline/out-of-line) we

Re: [RFC][CFT][PATCHSET v1] uaccess unification

Definitely next cycle. > > I'm not sure if mailbombing linux-arch would be a good idea; there are > 90 patches in that pile, with total size nearly half a megabyte. If anyone > wants that posted, I'll do so, but it might be more convenient to just > use git. > > Comments, review

Re: [RFC][CFT][PATCHSET v1] uaccess unification

Definitely next cycle. > > I'm not sure if mailbombing linux-arch would be a good idea; there are > 90 patches in that pile, with total size nearly half a megabyte. If anyone > wants that posted, I'll do so, but it might be more convenient to just > use git. > > Comments, review

Re: [PATCH] arc: vdk: Fix support of UIO

gt; > Signed-off-by: Alexey Brodkin <abrod...@synopsys.com> > Cc: Vineet Gupta <vgu...@synopsys.com> > Cc: Ruud Derwig <rder...@synopsys.com> > Cc: sta...@vger.kernel.org Added to for-curr. Thx, -Vineet

Re: [PATCH] arc: vdk: Fix support of UIO

gt; > Signed-off-by: Alexey Brodkin > Cc: Vineet Gupta > Cc: Ruud Derwig > Cc: sta...@vger.kernel.org Added to for-curr. Thx, -Vineet

Re: [PATCH V8 1/3] irq: Add flags to request_percpu_irq function

QF_TIMER > flag is a valid parameter to be passed to the request_percpu_irq function. > > Signed-off-by: Daniel Lezcano <daniel.lezc...@linaro.org> Acked-by: Vineet Gupta <vgu...@synopsys.com> # for arch/arc, arc_timer bits

Re: [PATCH V8 1/3] irq: Add flags to request_percpu_irq function

QF_TIMER > flag is a valid parameter to be passed to the request_percpu_irq function. > > Signed-off-by: Daniel Lezcano Acked-by: Vineet Gupta# for arch/arc, arc_timer bits

Re: [PATCH] arc: vdk: Fix support of UIO

gs in runtime. > > Signed-off-by: Alexey Brodkin <abrod...@synopsys.com> > Cc: Vineet Gupta <vgu...@synopsys.com> > Cc: Ruud Derwig <rder...@synopsys.com> > Cc: sta...@vger.kernel.org > --- > arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 20 +--- &g

Re: [PATCH] arc: vdk: Fix support of UIO

gs in runtime. > > Signed-off-by: Alexey Brodkin > Cc: Vineet Gupta > Cc: Ruud Derwig > Cc: sta...@vger.kernel.org > --- > arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 20 +--- > 1 file changed, 13 insertions(+), 7 deletions(-) > > diff --git a/arch

Re: [RFC PATCH 10/13] mm: Introduce first class virtual address spaces

+CC Ingo, tglx Hi Till, On 03/13/2017 03:14 PM, Till Smejkal wrote: > Introduce a different type of address spaces which are first class citizens > in the OS. That means that the kernel now handles two types of AS, those > which are closely coupled with a process and those which aren't. While

Re: [RFC PATCH 10/13] mm: Introduce first class virtual address spaces

+CC Ingo, tglx Hi Till, On 03/13/2017 03:14 PM, Till Smejkal wrote: > Introduce a different type of address spaces which are first class citizens > in the OS. That means that the kernel now handles two types of AS, those > which are closely coupled with a process and those which aren't. While

Re: [PATCH 1/3] futex: remove duplicated code

t gets > optimized away anyway). Acked-by: Vineet Gupta <vgu...@synopsys.com> # Boot tested on ARC Thx, -Vineet

Re: [PATCH 1/3] futex: remove duplicated code

t gets > optimized away anyway). Acked-by: Vineet Gupta# Boot tested on ARC Thx, -Vineet

Re: [PATCH 0/3] ARC: get frequency via clock driver instead of reading device tree

On 03/03/2017 03:29 AM, Vlad Zakharov wrote: > This patch series replaces reading device tree with getting CPU > clock frequency via clock driver in show_cpuinfo function. > > In order to achieve this we also add cpu nodes to device tree which > describes SMP system and add "clocks" properties to

Re: [PATCH 0/3] ARC: get frequency via clock driver instead of reading device tree

On 03/03/2017 03:29 AM, Vlad Zakharov wrote: > This patch series replaces reading device tree with getting CPU > clock frequency via clock driver in show_cpuinfo function. > > In order to achieve this we also add cpu nodes to device tree which > describes SMP system and add "clocks" properties to

Re: [PATCH] arc: get rate from clk driver instead of reading device tree

On 02/22/2017 02:36 AM, Vlad Zakharov wrote: > We were reading clock rate directly from device tree "clock-frequency" > property of corresponding clock node in show_cpuinfo function. > > Such approach is correct only in case cpu is always clocked by > "fixed-clock". If we use clock driver that

Re: [PATCH] arc: get rate from clk driver instead of reading device tree

On 02/22/2017 02:36 AM, Vlad Zakharov wrote: > We were reading clock rate directly from device tree "clock-frequency" > property of corresponding clock node in show_cpuinfo function. > > Such approach is correct only in case cpu is always clocked by > "fixed-clock". If we use clock driver that

Re: [PATCH] arc: get rate from clk driver instead of reading device tree

On 02/22/2017 02:36 AM, Vlad Zakharov wrote: > We were reading clock rate directly from device tree "clock-frequency" > property of corresponding clock node in show_cpuinfo function. > > Such approach is correct only in case cpu is always clocked by > "fixed-clock". If we use clock driver that

<    1   2   3   4   5   6   7   8   9   10   >