Re: Build regressions/improvements in v4.9-rc1

2016-10-26 Thread Michael Ellerman 
Alexey Brodkin  writes:
> On Wed, 2016-10-19 at 22:50 +1100, Michael Ellerman wrote:
>> Vineet Gupta  writes:
>> > On 10/17/2016 02:02 PM, Arnd Bergmann wrote:
>> > > On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote:
>> > > > On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
>> > > > > > 48 error regressions:
>> > > > > > > 
>> > > > > > >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: 
>> > > > > > > bad instruction `llockd r2,[r0]':  => 476
>> > > > > > >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: 
>> > > > > > > bad instruction `llockd r2,[r13]':  =>
>> > > > > > > 475
>> > > > 
>> > > > [snip...]
>> > > > > > > 
>> > > > > > >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: 
>> > > > > > > bad instruction `scondd r4,[r8]':  => 516
>> > > > > > >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: 
>> > > > > > > bad instruction `scondd r6,[r3]':  => 478
>> > > > > arcv2/axs103_smp_defconfig
>> > 
>> > @Michael can I bother you to upgrade the tools or is this absolutely must 
>> > for you.
>> 
>> Happy to, just short on time.
>> 
>> I tried building a new toolchain with buildroot, using the instructions
>> from last time, but the resulting toolchain doesn't relocate, ie. it has
>> hard-coded paths in it. Any ideas?
>
> Hm... that's strange - it used to work but doesn't work with newer 
> Buildroot...
>
> Anyways if something very simple (i.e. with no extra libraries) works for you 
> just go
> ahead and grab pre-built image that Thomas Petazzoni builds.
>
> That's the most recent one:
> http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2016.08-613-ge98b4dd.tar.bz2

Thanks, I grabbed that and it works for axs103_smp_defconfig:

  http://kisskb.ellerman.id.au/kisskb/buildresult/12840656/


It doesn't work for axs101_defconfig, saying:

  arch/arc/Makefile:29: *** Toolchain not configured for ARCompact builds.  
Stop.


So those are still failing:

  http://kisskb.ellerman.id.au/kisskb/buildresult/12841194/


cheers

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

[RFC] dma-mapping: fix dma_common_mmap() for ARC

2016-10-26 Thread Alexey Brodkin 
ARC CPU with enabled MMU sees entire 32-bit address space divided in 2
big parts:
 1) 0 - 0x7fff_ (lower 2Gb): translated memory
I.e. all reads/writes from/to this region go through MMU and after
translation land somewhere in physical memory.

 2) 0x8000_ - 0x_: untranslated memory
ARC CPU in kernel mode accesses this memory directly, i.e. MMU is
not used at all.
One important note: data accesses in this region go through data
cache!

If some peripheral wants to use DMA Linux kernel just allocates data
buffer in upper 2Gb (i.e. above 0x8000_).
In that case dma_addr = cpu_addr. Everything is simple.

But if a driver wants to allocate uncached buffer for DMA (very good
example and that's how I actually caught the issue is DRM frame-buffer)
things become a little-bit more complicated.

Now kernel wants to write data in memory bypassing data cache.
For that to happen we have to program MMU so that TLB entry gets
"cached flag" reset for a particular page(s). And keeping in mind
explanation above the only way to utilize MMU is to access data via
lower part of address space. In other words we implement page mapping
similarly to what we do for user-space, see:
>8---
arc_dma_alloc()
  ioremap_nocache() AKA ioremap()
ioremap_prot()
  get_vm_area() + ioremap_page_range() on obtained vaddr
>8---

As a result we get TLB entry of the following kind:
>8---
vaddr = 0x7200_
paddr = 0x8200_
flags = _uncached_
>8---

Kerenl thinks frame buffer is located @ 0x7200_ and uses it
perfectly fine.

But here comes a time for user-space application to request frame buffer
to be mapped for it. That happens easily with the following call path:
>8---
fb_mmap()
  drm_fb_cma_mmap()
dma_mmap_writecombine() AKA dma_mmap_wc()
  dma_mmap_attrs()
dma_common_mmap() since we don't [yet] have dma_map_ops.mmap()
  for ARC
>8---

And in dma_common_mmap() we first calculate pfn of what we think is
"physical page" and then do remap_pfn_range() to that "physical page".

Here we're getting to the interesting thing - how pfn is calculated.
As of now this is done as simple as:
>8---
pfn = page_to_pfn(virt_to_page(cpu_addr));
>8---

Below is a nice set of defines we need to use to evaluate pfn:
>8---
 #define virt_to_pfn(kaddr)  (__pa(kaddr) >> PAGE_SHIFT)
 #define virt_to_page(kaddr) pfn_to_page(virt_to_pfn(kaddr))
 #define page_to_pfn __page_to_pfn
 #define pfn_to_page __pfn_to_page
 #define __pfn_to_page(pfn)  (mem_map + ((pfn) - ARCH_PFN_OFFSET))
 #define __page_to_pfn(page) ((unsigned long)((page) - mem_map) + \
   ARCH_PFN_OFFSET)
>8---

If we do some obvious calculations we'll get:
>8---
pfn = cpu_addr >> PAGE_SHIFT;
>8---

In our case cpu_addr here is 0x7200_ from TLB entry above and this
what is used to create another TLB entry this time for user-space app.
We'll get something like this:
>8---
vaddr = 0x0200_
paddr = 0x7200_
flags = _uncached_
>8---

This is obviously wrong! We cannot map vaddr to vaddr with MMU.

Simplest fix for ARC is to use dma_addr instead because it matches
real physical memory address and so mapping for user-space we're
getting then is this:
>8---
vaddr = 0x0200_
paddr = 0x8200_
flags = _uncached_
>8---
And it works perfectly fine.

But I'm pretty sure that's not the best approach for other
architectures. Indeed we may create ARC-specific dma_map_ops.mmap()
which only differs from dma_common_mmap() with addr being used
but IMHO it's not the best idea to duplicate that much of code
for such a simple change.

Would be interesting to get more opinions on how to handle that thing in
the most graceful way.

Signed-off-by: Alexey Brodkin 
Cc: Greg Kroah-Hartman 
Cc: Marek Szyprowski 
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-a...@vger.kernel.org
---
 drivers/base/dma-mapping.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 8f8b68c80986..16307eed453f 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -252,7 +252,7 @@ int

Re: [PATCH v2 4/5] ARC: MCIP: Set an initial affinity value in idu_irq_map

2016-10-26 Thread Vineet Gupta 
On 10/26/2016 09:36 AM, Marc Zyngier wrote:
> On Wed, Oct 26 2016 at 05:17:34 PM, Vineet Gupta  
> wrote:
>> On 10/26/2016 07:05 AM, Marc Zyngier wrote:
>>> It definitely feels weird to encode the interrupt affinity in the DT
>>> (the kernel and possible userspace usually know much better than the
>>> firmware). What is the actual reason for storing the affinity there?
>>
>> The IDU intc supports various interrupt distribution modes (Round
>> Robin, send to one cpu only etc) whcih in turn map to affinity
>> setting. When doing the DT binding, we decided to add that this to DT
>> to get the "seed" value for affinity - which user could optionally
>> changed after boot. This seemed like a benign design choice at the
>> time.
> 
> Right. But is this initial setting something that the kernel has to
> absolutely honor? 

Not necessarily.

> The usual behavior is to let kernel pick something
> sensible, and let the user mess with it afterwards.

Right !


> Is there any part of the kernel that would otherwise depend on this
> affinity being set to a particular mode? If the answer is "none", then I
> believe we can safely ignore that part of the binding (and maybe
> deprecate it in the documentation).

Not really. It was relevant for initial bring up of IDU software and hardware.
e.g. checking that uart behind idu works fine in both modes for very first user
mode prints, which is before you could make the init script cmds to change the
affinity etc. But that bridge has long been crossed.

So agree that we will ignore the affinity settings from DT and deprecate the 
binding.

Thx for steering us in the right direction. Much appreciated.

-Vineet

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

Re: [PATCH v2 4/5] ARC: MCIP: Set an initial affinity value in idu_irq_map

2016-10-26 Thread Marc Zyngier 
On Wed, Oct 26 2016 at 05:17:34 PM, Vineet Gupta  
wrote:
> On 10/26/2016 07:05 AM, Marc Zyngier wrote:
>> It definitely feels weird to encode the interrupt affinity in the DT
>> (the kernel and possible userspace usually know much better than the
>> firmware). What is the actual reason for storing the affinity there?
>
> The IDU intc supports various interrupt distribution modes (Round
> Robin, send to one cpu only etc) whcih in turn map to affinity
> setting. When doing the DT binding, we decided to add that this to DT
> to get the "seed" value for affinity - which user could optionally
> changed after boot. This seemed like a benign design choice at the
> time.

Right. But is this initial setting something that the kernel has to
absolutely honor? The usual behavior is to let kernel pick something
sensible, and let the user mess with it afterwards.

Is there any part of the kernel that would otherwise depend on this
affinity being set to a particular mode? If the answer is "none", then I
believe we can safely ignore that part of the binding (and maybe
deprecate it in the documentation).

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.

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

Re: [PATCH v2 4/5] ARC: MCIP: Set an initial affinity value in idu_irq_map

2016-10-26 Thread Vineet Gupta 
On 10/26/2016 07:05 AM, Marc Zyngier wrote:
> It definitely feels weird to encode the interrupt affinity in the DT
> (the kernel and possible userspace usually know much better than the
> firmware). What is the actual reason for storing the affinity there?

The IDU intc supports various interrupt distribution modes (Round Robin, send to
one cpu only etc) whcih in turn map to affinity setting. When doing the DT
binding, we decided to add that this to DT to get the "seed" value for affinity 
-
which user could optionally changed after boot. This seemed like a benign design
choice at the time.

Thx,
-Vineet

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

kisskb: OK linux-next/axs103_smp_defconfig/arcv2 Wed Oct 26, 23:35

2016-10-26 Thread noreply 
OK linux-next/axs103_smp_defconfig/arcv2 Wed Oct 26, 23:35

http://kisskb.ellerman.id.au/kisskb/buildresult/12840656/

Commit:   Add linux-next specific files for 20161025
  556dd18b9e4d9f4d75d3218a374b3b5834991ed1
Compiler: arc-linux-gcc.br_real (Buildroot 2016.11-git-00613-ge98b4dd) 6.2.1 
20160824

Possible errors
---

 #define KERN_ERR KERN_SOH "3" /* error conditions */
 #define KERN_ERR KERN_SOH "3" /* error conditions */
 #define KERN_ERR KERN_SOH "3" /* error conditions */
 #define KERN_ERR KERN_SOH "3" /* error conditions */

Possible warnings (80)
--

kernel/sched/core.c:3292:1: warning: control reaches end of non-void function 
[-Wreturn-type]
mm/percpu.c:891:14: warning: format '%zu' expects argument of type 'size_t', 
but argument 4 has type 'unsigned int' [-Wformat=]
mm/percpu.c:891:14: warning: format '%zu' expects argument of type 'size_t', 
but argument 5 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:4:18: warning: format '%zu' expects argument of 
type 'size_t', but argument 2 has type 'unsigned int' [-Wformat=]
 #define KERN_WARNING KERN_SOH "4" /* warning conditions */
include/linux/kern_levels.h:4:18: warning: format '%zu' expects argument of 
type 'size_t', but argument 3 has type 'unsigned int' [-Wformat=]
 #define KERN_WARNING KERN_SOH "4" /* warning conditions */
mm/percpu.c:1458:27: warning: format '%zu' expects argument of type 'size_t', 
but argument 3 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1458:32: warning: format '%zu' expects argument of type 'size_t', 
but argument 4 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1458:37: warning: format '%zu' expects argument of type 'size_t', 
but argument 5 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1458:42: warning: format '%zu' expects argument of type 'size_t', 
but argument 6 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1458:52: warning: format '%zu' expects argument of type 'size_t', 
but argument 7 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1458:56: warning: format '%zu' expects argument of type 'size_t', 
but argument 8 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:4:18: warning: format '%zu' expects argument of 
type 'size_t', but argument 2 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:4:18: warning: format '%zu' expects argument of 
type 'size_t', but argument 4 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:4:18: warning: format '%zu' expects argument of 
type 'size_t', but argument 5 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:4:18: warning: format '%zu' expects argument of 
type 'size_t', but argument 6 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:4:18: warning: format '%zu' expects argument of 
type 'size_t', but argument 7 has type 'unsigned int' [-Wformat=]
mm/slab_common.c:786:45: warning: format '%zu' expects argument of type 
'size_t', but argument 3 has type 'unsigned int' [-Wformat=]
include/linux/kernel.h:740:16: warning: comparison of distinct pointer types 
lacks a cast
include/linux/kernel.h:740:16: warning: comparison of distinct pointer types 
lacks a cast
include/linux/kernel.h:740:16: warning: comparison of distinct pointer types 
lacks a cast
include/linux/kernel.h:740:16: warning: comparison of distinct pointer types 
lacks a cast
include/linux/kernel.h:740:16: warning: comparison of distinct pointer types 
lacks a cast
include/linux/kernel.h:740:16: warning: comparison of distinct pointer types 
lacks a cast
include/linux/kernel.h:740:16: warning: comparison of distinct pointer types 
lacks a cast
mm/dmapool.c:96:46: warning: format '%Zu' expects argument of type 'size_t', 
but argument 6 has type 'unsigned int' [-Wformat=]
mm/dmapool.c:96:51: warning: format '%Zu' expects argument of type 'size_t', 
but argument 7 has type 'unsigned int' [-Wformat=]
include/linux/kernel.h:740:16: warning: comparison of distinct pointer types 
lacks a cast
fs/buffer.c:242:37: warning: format '%zu' expects argument of type 'size_t', 
but argument 3 has type 'unsigned int' [-Wformat=]
include/linux/kernel.h:740:16: warning: comparison of distinct pointer types 
lacks a cast
drivers/base/component.c:101:24: warning: format '%zu' expects argument of type 
'size_t', but argument 4 has type 'unsigned int' [-Wformat=]
fs/ext4/ext4_jbd2.h:428:1: warning: control reaches end of non-void function 
[-Wreturn-type]
fs/ext4/ext4_jbd2.h:428:1: warning: control reaches end of non-void function 
[-Wreturn-type]
include/linux/kern_levels.h:4:18: warning: format '%zu' expects argument of 
type 'size_t', but argument 2 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:4:18: warning: format '%zu' expects argument of 
type 'size_t', but argument 2 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:4:18: warning: format '%zd' expects argument of 
type 'signed size_t', but argument 3 has type 'size_t {aka unsigned int}' 
[-Wformat=]