* still nfs problems [Was: Linux 2.6.37-rc8]
From: Russell King - ARM Linux @ 2011-01-05 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294256169.16957.18.camel@mulgrave.site>
On Wed, Jan 05, 2011 at 01:36:09PM -0600, James Bottomley wrote:
> On Wed, 2011-01-05 at 11:18 -0800, Linus Torvalds wrote:
> > On Wed, Jan 5, 2011 at 11:05 AM, James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > >
> > > I think the solution for the kernel direct mapping problem is to take
> > > the expected flushes and invalidates into kmap/kunmap[_atomic].
> >
> > No, we really can't do that. Most of the time, the kmap() is the only
> > way we access the page anyway, so flushing things would just be
> > stupid. Why waste time and energy on doing something pointless?
>
> It's hardly pointless. The kmap sets up an inequivalent alias in the
> cache.
No it doesn't. For pages which are inaccessible, it sets up a mapping
for those pages. On aliasing cache architectures, when you tear down
such a mapping, you have to flush the cache before you do so (otherwise
you can end up with cache lines existing in the cache for inaccessible
mappings.)
For lowmem pages, kmap() (should always) bypass the 'setup mapping' stage
because all lowmem pages are already accessible. So kunmap() doesn't
do anything - just like the !HIGHMEM implementation for these macros.
So, for highmem-enabled systems:
low_addr = kmap_atomic(lowmem_page);
high_addr = kmap_atomic(highmem_page);
results in low_addr in the kernel direct-mapped region, and high_addr
in the kmap_atomic region.
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Linus Torvalds @ 2011-01-05 19:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294256169.16957.18.camel@mulgrave.site>
2011/1/5 James Bottomley <James.Bottomley@hansenpartnership.com>:
>>
>> No, we really can't do that. Most of the time, the kmap() is the only
>> way we access the page anyway, so flushing things would just be
>> stupid. Why waste time and energy on doing something pointless?
>
> It's hardly pointless. ?The kmap sets up an inequivalent alias in the
> cache.
NO IT DOES NOT.
Stop arguing, when you are so wrong.
kmap() does not create any aliases. For low-memory, it just returns
the physical address. No alias. And for high memory, there is no
equivalent low memory address to alias _with_.
Now, when you actually mix multiple kmap's and you have a virtually
based cache, then the kmap's obviously need to flush that particular
page when switching between each other. But that has nothing to do
with the actual page being kmap'ed, it's entirely an internal issue
about the particular virtual memory area being re-used. And ARM (and
any other virtually based CPU) already does that in __kunmap_atomic().
But notice the case of the low-mem. And understand that you are WRONG
about the "inequivalent alias" thing.
So I repeat: this has absolutely *NOTHING* to do with kmap(). Stop blathering.
It's _purely_ an issue of vm_map_ram(). Nothing else.
Linus
^ permalink raw reply
* [PATCH] arm: mm: Poison freed init memory
From: Stephen Boyd @ 2011-01-05 19:47 UTC (permalink / raw)
To: linux-arm-kernel
Poisoning __init marked memory can be useful when tracking down
obscure memory corruption bugs. When a pointer is 0xCCCCCCCC in an
oops it's much more obvious that somebody is using __init marked
memory after kernel initialization. This should help find
incorrect __init markings earlier and mimics what other
architectures are doing already.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
This is a minimal patch to get the idea across. I'm tempted to duplicate
free_area() and rename it to free_init_area() and then have it take virtual
addresses instead of pfns. Then the call sites could be cleaned up to pass
virtual addresses in the case of init memory, and we could remove the NULL
argument for the highpages and DMA users. Thoughts?
arch/arm/mm/init.c | 20 +++++++++++++-------
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 5164069..b7535ec 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -19,6 +19,7 @@
#include <linux/gfp.h>
#include <linux/memblock.h>
#include <linux/sort.h>
+#include <linux/poison.h>
#include <asm/mach-types.h>
#include <asm/sections.h>
@@ -358,7 +359,8 @@ void __init bootmem_init(void)
max_pfn = max_high - PHYS_PFN_OFFSET;
}
-static inline int free_area(unsigned long pfn, unsigned long end, char *s)
+static inline int free_area(unsigned long pfn, unsigned long end, char *s,
+ bool init_mem)
{
unsigned int pages = 0, size = (end - pfn) << (PAGE_SHIFT - 10);
@@ -366,6 +368,9 @@ static inline int free_area(unsigned long pfn, unsigned long end, char *s)
struct page *page = pfn_to_page(pfn);
ClearPageReserved(page);
init_page_count(page);
+ if (init_mem)
+ memset(__va(__pfn_to_phys(pfn)), POISON_FREE_INITMEM,
+ PAGE_SIZE);
__free_page(page);
pages++;
}
@@ -472,7 +477,7 @@ static void __init free_highpages(void)
res_end = end;
if (res_start != start)
totalhigh_pages += free_area(start, res_start,
- NULL);
+ NULL, false);
start = res_end;
if (start == end)
break;
@@ -480,7 +485,7 @@ static void __init free_highpages(void)
/* And now free anything which remains */
if (start < end)
- totalhigh_pages += free_area(start, end, NULL);
+ totalhigh_pages += free_area(start, end, NULL, false);
}
totalram_pages += totalhigh_pages;
#endif
@@ -512,7 +517,8 @@ void __init mem_init(void)
#ifdef CONFIG_SA1111
/* now that our DMA memory is actually so designated, we can free it */
totalram_pages += free_area(PHYS_PFN_OFFSET,
- __phys_to_pfn(__pa(swapper_pg_dir)), NULL);
+ __phys_to_pfn(__pa(swapper_pg_dir)), NULL,
+ false);
#endif
free_highpages();
@@ -644,13 +650,13 @@ void free_initmem(void)
totalram_pages += free_area(__phys_to_pfn(__pa(&__tcm_start)),
__phys_to_pfn(__pa(&__tcm_end)),
- "TCM link");
+ "TCM link", true);
#endif
if (!machine_is_integrator() && !machine_is_cintegrator())
totalram_pages += free_area(__phys_to_pfn(__pa(__init_begin)),
__phys_to_pfn(__pa(__init_end)),
- "init");
+ "init", true);
}
#ifdef CONFIG_BLK_DEV_INITRD
@@ -662,7 +668,7 @@ void free_initrd_mem(unsigned long start, unsigned long end)
if (!keep_initrd)
totalram_pages += free_area(__phys_to_pfn(__pa(start)),
__phys_to_pfn(__pa(end)),
- "initrd");
+ "initrd", true);
}
static int __init keepinitrd_setup(char *__unused)
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH v3 08/10] ARM: mxs: add ocotp read function
From: Jamie Lokier @ 2011-01-05 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110105183509.GH8638@n2100.arm.linux.org.uk>
Russell King - ARM Linux wrote:
> > By the way, I see ARM defines cpu_relax as smp_mb() on arch >= 6. Is
> > that correct and useful? On other architectures*, barrier() is enough
> > of a barrier, but it's conceivable that smp_mb() would have some
> > ARM-specific fairness or bus activity benefit - in which case it
> > should probably be mb().
>
> See a discussion last year with Linus. It's there to ensure that one CPU
> spinning on a variable can see a write by another CPU to that same
> variable. Without the barrier, the visibility effects are unbounded on
> ARMv6 - and it's only like that for ARMv6, not >= ARMv6.
Ah, thanks.
It might be relevant to this thread; I'm not sure.
'git show 534be1d5' explains how it works: cpu_relax() flushes buffered
writes from _this_ CPU, so that other CPUs which are polling can make
progress, which avoids this CPU getting stuck if there is an indirect
dependency (no matter how convoluted) between what it's polling and which
it wrote just before.
So cpu_relax() is *essential* in some polling loops, not a hint.
In principle that could happen for I/O polling, if (a) buffered memory
writes are delayed by I/O read transactions, and (b) the device state we're
waiting on depends on I/O yet to be done on another CPU, which could be
polling memory first (e.g. a spinlock).
I doubt (a) in practice - but what about buses that block during I/O read?
(I have a chip like that here, but it's ARMv4T.)
If so, readl() doesn't have a barrier that addresses the issue.
(b) is conceivable, and if the memory is a spinlock, spin_unlock() does
_not_ deal with this on ARMv6, as it has no barrier after the write.
('git show c5113b61' doesn't really explain why.)
It's convoluted and unlikely, but (imho) suggests cpu_relax() is good
practice in polling loops, even if not needed. It doesn't cost anything.
-- Jamie
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: James Bottomley @ 2011-01-05 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=VZUxNFd7n-qwf5aiOeK5rkk8qBmo+kOpgg7up@mail.gmail.com>
On Wed, 2011-01-05 at 11:18 -0800, Linus Torvalds wrote:
> On Wed, Jan 5, 2011 at 11:05 AM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> >
> > I think the solution for the kernel direct mapping problem is to take
> > the expected flushes and invalidates into kmap/kunmap[_atomic].
>
> No, we really can't do that. Most of the time, the kmap() is the only
> way we access the page anyway, so flushing things would just be
> stupid. Why waste time and energy on doing something pointless?
It's hardly pointless. The kmap sets up an inequivalent alias in the
cache. When you write to the kmap region, you dirty the CPU caches for
that alias. If you tear down the mapping without flushing, the CPU will
write out the cache lines at its leisure. If you access the line via
the other mapping *before* the CPU does writeout, you see stale data.
When the kernel dirties a kmap region, it always has to flush somehow
before kunmap. One of the problems here is that that flush isn't in the
NFS code.
> In fact, kmap() here is a total non-issue. It's not the kmap() that
> introduces any virtual aliases, and never has been. It's the
> "vm_map_ram()" that is the problem. Unlike the kmap(), that really
> _does_ introduce a virtual alias, and is a problem for any virtual
> cache.
>
> So don't blame kmap(). It's innocent and irrelevant - the bug could
> happen entirely without it (think a 64-bit address space that doesn't
> even _have_ kmap, but has software that mixes vm_map_ram() with
> non-mapped accesses).
I didn't say it was kmap's entire problem ... I just said, can't we
simplify some of this by consolidating the flushing into the interfaces.
James
^ permalink raw reply
* [PATCH 1/1] arm: omap: gpio: define .disable callback for gpio irq chip
From: Eduardo Valentin @ 2011-01-05 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110105181918.GB8717@n2100.arm.linux.org.uk>
Hello Russell,
On Wed, Jan 05, 2011 at 06:19:18PM +0000, Russell King wrote:
> On Wed, Jan 05, 2011 at 07:58:03PM +0200, Eduardo Valentin wrote:
> > Currently, if one calls disable_irq(gpio_irq), the irq
> > won't get disabled.
> >
> > This is happening because the omap gpio code defines only
> > a .mask callback. And the default_disable function is just
> > a stub. The result is that, when someone calls disable_irq
> > for an irq in a gpio line, it will be kept enabled.
> >
> > This patch solves this issue by setting the .disable
> > callback to point to the same .mask callback.
>
> Amd this is a problem because?
errr.. because the interrupt is enabled when it was supposed to be disabled?
>
> The way this works is that although it isn't disabled at that point,
> if it never triggers, then everything remains happy. However, if it
> does trigger, the genirq code will then mask the interrupt and won't
> call the handler.
Right.. I didn't see from this point. I will check how that gets unmasked.
But even so, if I understood correctly what you described, it would still
open a time window which the system would see at least 1 interrupt during
the time it was not suppose to. And that can wakeup a system which is in
deep sleep mode, either via dynamic idle or static suspend.
It is unlikely, I know. But it can still happen. And can be avoided.
Regards,
--
Eduardo Valentin
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Linus Torvalds @ 2011-01-05 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294254337.16957.13.camel@mulgrave.site>
On Wed, Jan 5, 2011 at 11:05 AM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> I think the solution for the kernel direct mapping problem is to take
> the expected flushes and invalidates into kmap/kunmap[_atomic].
No, we really can't do that. Most of the time, the kmap() is the only
way we access the page anyway, so flushing things would just be
stupid. Why waste time and energy on doing something pointless?
In fact, kmap() here is a total non-issue. It's not the kmap() that
introduces any virtual aliases, and never has been. It's the
"vm_map_ram()" that is the problem. Unlike the kmap(), that really
_does_ introduce a virtual alias, and is a problem for any virtual
cache.
So don't blame kmap(). It's innocent and irrelevant - the bug could
happen entirely without it (think a 64-bit address space that doesn't
even _have_ kmap, but has software that mixes vm_map_ram() with
non-mapped accesses).
Linus
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Russell King - ARM Linux @ 2011-01-05 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294253705.3574.21.camel@heimdal.trondhjem.org>
On Wed, Jan 05, 2011 at 01:55:05PM -0500, Trond Myklebust wrote:
> On Wed, 2011-01-05 at 18:27 +0000, Russell King - ARM Linux wrote:
> > I do still think you need _something_ there, otherwise data can remain
> > in the direct map alias and not be visible via the vmap alias. I don't
> > see that we have anything in place to handle this at present though.
>
> Is that perhaps what flush_kernel_dcache_page() is supposed to do?
Well, given how we have things currently setup on ARM, this ends up
being a no-op - as new page cache pages are marked dirty and their
flushing done at the point when they're mapped into userspace.
I guess we could do the flushing there and mark the page clean, but
it'd need some careful examination of various code paths to confirm
that it's safe - we may be avoiding this because some ARM arch
versions need to manually IPI cache flushes to other cores (which
can only be done with IRQs enabled.)
So, I don't think it'll do at the present time.
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: James Bottomley @ 2011-01-05 19:05 UTC (permalink / raw)
To: linux-arm-kernel
[sorry for the unthreaded insertion. We're seeing this on parisc too]
> On Wed, Jan 05, 2011 at 10:14:17AM -0500, Trond Myklebust wrote:
> > OK. So,the new behaviour in 2.6.37 is that we're writing to a series of
> > pages via the usual kmap_atomic()/kunmap_atomic() and kmap()/kunmap()
> > interfaces, but we can end up reading them via a virtual address range
> > that gets set up via vm_map_ram() (that range gets set up before the
> > write occurs).
>
> kmap of lowmem pages will always reuses the existing kernel direct
> mapping, so there won't be a problem there.
>
> > Do we perhaps need an invalidate_kernel_vmap_range() before we can read
> > the data on ARM in this kind of scenario?
>
> Firstly, vm_map_ram() does no cache maintainence of any sort, nor does
> it take care of page colouring - so any architecture where cache aliasing
> can occur will see this problem. It should not limited to ARM.
>
> Secondly, no, invalidate_kernel_vmap_range() probably isn't sufficient.
> There's two problems here:
>
> addr = kmap(lowmem_page);
> *addr = stuff;
> kunmap(lowmem_page);
>
> Such lowmem pages are accessed through their kernel direct mapping.
>
> ptr = vm_map_ram(lowmem_page);
> read = *ptr;
>
> This creates a new mapping which can alias with the kernel direct mapping.
> Now, as this is a new mapping, there should be no cache lines associated
> with it. (Looking at vm_unmap_ram(), it calls free_unmap_vmap_area_addr(),
> free_unmap_vmap_area(), which then calls flush_cache_vunmap() on the
> region. vb_free() also calls flush_cache_vunmap() too.)
>
> If the write after kmap() hits an already present cache line, the cache
> line will be updated, but it won't be written back to memory. So, on
> a subsequent vm_map_ram(), with any kind of aliasing cache, there's
> no guarantee that you'll hit that cache line and read the data just
> written there.
>
> The kernel direct mapping would need to be flushed.
>
> I'm really getting to the point of hating the poliferation of RAM
> remapping interfaces - it's going to (and is) causing nothing but lots
> of pain on virtual cache architectures, needing more and more cache
> flushing interfaces to be created.
>
> Is there any other solution to this?
I think the solution for the kernel direct mapping problem is to take
the expected flushes and invalidates into kmap/kunmap[_atomic]. I think
the original reason for not doing this was efficiency: the user should
know what they did with the data (i.e. if they're only reading it, it
doesn't need to be flushed on unmap). However, the difficulty of
getting all this right seems to outweigh the efficiency of only using
the necessary flushing. At least on some architectures, we can look at
the TLB flags to see if the page was dirtied (and only flush if it was).
James
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Trond Myklebust @ 2011-01-05 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110105182753.GG8638@n2100.arm.linux.org.uk>
On Wed, 2011-01-05 at 18:27 +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 05, 2011 at 01:12:25PM -0500, Trond Myklebust wrote:
> > On Wed, 2011-01-05 at 17:26 +0000, Russell King - ARM Linux wrote:
> > > On Wed, Jan 05, 2011 at 12:17:27PM -0500, Trond Myklebust wrote:
> > > > We should already be flushing the kernel direct mapping after writing by
> > > > means of the calls to flush_dcache_page() in xdr_partial_copy_from_skb()
> > > > and all the helpers in net/sunrpc/xdr.c.
> > >
> > > Hmm, we're getting into the realms of what flush_dcache_page() is supposed
> > > to do and what it's not supposed to do.
> > >
> > > Is this page an associated with a mapping (iow, page_mapping(page) is non-
> > > NULL)? If not, flush_dcache_page() won't do anything, and from my
> > > understanding, its flush_anon_page() which you want to be using there
> > > instead.
> >
> > Actually, none of these pages are ever mapped into userspace, nor are
> > they mapped into the page cache.
> >
> > They are allocated directly using alloc_page() by the thread that called
> > the readdir() syscall, so afaics there should be no incoherent mappings
> > other than the kernel direct mapping and the one created by
> > vm_map_ram().
> >
> > So, yes, you are right that we don't need the flush_dcache_page() here.
>
> I do still think you need _something_ there, otherwise data can remain
> in the direct map alias and not be visible via the vmap alias. I don't
> see that we have anything in place to handle this at present though.
Is that perhaps what flush_kernel_dcache_page() is supposed to do?
> jejb mentioned something about making kunmap_atomic() always flush the
> cache, even for lowmem pages, but I think that's going to be exceedingly
> painful, to the extent that I believe it will prevent our PIO-only MMC
> drivers working - or we need a scatterlist API that will let drivers
> iterate over the scatterlist without needing to continually kmap_atomic
> and kunmap_atomic each page.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust at netapp.com
www.netapp.com
^ permalink raw reply
* [PATCH v3 08/10] ARM: mxs: add ocotp read function
From: Russell King - ARM Linux @ 2011-01-05 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110105175617.GD12222@shareable.org>
On Wed, Jan 05, 2011 at 05:56:17PM +0000, Jamie Lokier wrote:
> cpu_relax() is a hint to the CPU to, for example, save power or be
> less aggressive on the memory bus (to save power or be fairer).
>
> Currently these architectures do more than just a barrier in cpu_relax():
> x86, IA64, PowerPC, Tile and S390.
>
> Although it's just a hint on ARM at the moment, it might change in
> future - especially with power mattering on so many ARM systems.
> (Even now, just changing it to a very short udelay might save power
> on existing ARMs without breaking drivers.)
I think that's a matter for what the loop is doing. If it's polling
a memory location then it probably has no effect what so ever. If
the loop is spinning on a device, then the CPU will have to wait for
the read to complete which will slow it down.
It's something that would need very careful evaluation, and is probably
something that's very platform and loop specific.
> By the way, I see ARM defines cpu_relax as smp_mb() on arch >= 6. Is
> that correct and useful? On other architectures*, barrier() is enough
> of a barrier, but it's conceivable that smp_mb() would have some
> ARM-specific fairness or bus activity benefit - in which case it
> should probably be mb().
See a discussion last year with Linus. It's there to ensure that one CPU
spinning on a variable can see a write by another CPU to that same
variable. Without the barrier, the visibility effects are unbounded on
ARMv6 - and it's only like that for ARMv6, not >= ARMv6.
^ permalink raw reply
* [PATCH] [ARM] orion5x: accelerate NAND on the TS-78xx
From: Alexander Clouter @ 2011-01-05 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110105003316.GJ24935@n2100.arm.linux.org.uk>
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>
> On Tue, Jan 04, 2011 at 11:51:59PM +0000, Alexander Clouter wrote:
>> The NAND supports 32bit reads and writes so lets stop shunting 8bit
>> chunks across the bus.
>>
>> Doing a dumb 'dd' benchmark, this increases performance roughly like so:
>> * read: 1.3MB/s to 3.4MB/s
>> * write: 614kB/s to 882kB/s
>
> Try something like the below. It's slightly more typing, but the
> underlying string IO functions should improve your transfer speed.
> Note that they won't do endian conversions.
>
I get roughly the same speeds with your approach...I am happy to swing
either your way or my original implementation; well actually it was
stolen from Nico's orion_nand implementation :)
What should I submit? These functions will at somestage get DMA support
added.
Cheers
--
Alexander Clouter
.sigmonster says: Live Free or Live in Massachusetts.
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Russell King - ARM Linux @ 2011-01-05 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294251145.3574.16.camel@heimdal.trondhjem.org>
On Wed, Jan 05, 2011 at 01:12:25PM -0500, Trond Myklebust wrote:
> On Wed, 2011-01-05 at 17:26 +0000, Russell King - ARM Linux wrote:
> > On Wed, Jan 05, 2011 at 12:17:27PM -0500, Trond Myklebust wrote:
> > > We should already be flushing the kernel direct mapping after writing by
> > > means of the calls to flush_dcache_page() in xdr_partial_copy_from_skb()
> > > and all the helpers in net/sunrpc/xdr.c.
> >
> > Hmm, we're getting into the realms of what flush_dcache_page() is supposed
> > to do and what it's not supposed to do.
> >
> > Is this page an associated with a mapping (iow, page_mapping(page) is non-
> > NULL)? If not, flush_dcache_page() won't do anything, and from my
> > understanding, its flush_anon_page() which you want to be using there
> > instead.
>
> Actually, none of these pages are ever mapped into userspace, nor are
> they mapped into the page cache.
>
> They are allocated directly using alloc_page() by the thread that called
> the readdir() syscall, so afaics there should be no incoherent mappings
> other than the kernel direct mapping and the one created by
> vm_map_ram().
>
> So, yes, you are right that we don't need the flush_dcache_page() here.
I do still think you need _something_ there, otherwise data can remain
in the direct map alias and not be visible via the vmap alias. I don't
see that we have anything in place to handle this at present though.
jejb mentioned something about making kunmap_atomic() always flush the
cache, even for lowmem pages, but I think that's going to be exceedingly
painful, to the extent that I believe it will prevent our PIO-only MMC
drivers working - or we need a scatterlist API that will let drivers
iterate over the scatterlist without needing to continually kmap_atomic
and kunmap_atomic each page.
^ permalink raw reply
* [PATCH 1/1] arm: omap: gpio: define .disable callback for gpio irq chip
From: Russell King - ARM Linux @ 2011-01-05 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294250283-18182-1-git-send-email-eduardo.valentin@nokia.com>
On Wed, Jan 05, 2011 at 07:58:03PM +0200, Eduardo Valentin wrote:
> Currently, if one calls disable_irq(gpio_irq), the irq
> won't get disabled.
>
> This is happening because the omap gpio code defines only
> a .mask callback. And the default_disable function is just
> a stub. The result is that, when someone calls disable_irq
> for an irq in a gpio line, it will be kept enabled.
>
> This patch solves this issue by setting the .disable
> callback to point to the same .mask callback.
Amd this is a problem because?
The way this works is that although it isn't disabled at that point,
if it never triggers, then everything remains happy. However, if it
does trigger, the genirq code will then mask the interrupt and won't
call the handler.
^ permalink raw reply
* [PATCH v2 0/3] add CNS3xxx AHCI support
From: Jeff Garzik @ 2011-01-05 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294206187-11487-1-git-send-email-mkl0301@gmail.com>
On 01/05/2011 12:43 AM, mkl0301 at gmail.com wrote:
> From: Mac Lin<mkl0301@gmail.com>
>
> v2:
> - Switch ahci_platform to module device table matching to add SoC specific support
>
> v1: http://www.spinics.net/lists/arm-kernel/msg106236.html
> - Add CNS3xxx SoC specific AHCI support
>
> This patchset is based on linux-2.6.37-rc2
>
> Mac Lin (3):
> ahci_platform: rename to ahci_pltfm, but keep the original module name
> ahci_pltfm: switch to module device table matching
> ahci_platform: add support for CNS3xxx SoC devices
>
> arch/arm/mach-cns3xxx/devices.c | 2 +-
> drivers/ata/Kconfig | 11 ++
> drivers/ata/Makefile | 5 +-
> drivers/ata/ahci_cns3xxx.c | 62 +++++++++++
> drivers/ata/ahci_platform.c | 197 ------------------------------------
> drivers/ata/ahci_pltfm.c | 212 +++++++++++++++++++++++++++++++++++++++
> drivers/ata/ahci_pltfm.h | 19 ++++
> 7 files changed, 309 insertions(+), 199 deletions(-)
> create mode 100644 drivers/ata/ahci_cns3xxx.c
> delete mode 100644 drivers/ata/ahci_platform.c
> create mode 100644 drivers/ata/ahci_pltfm.c
> create mode 100644 drivers/ata/ahci_pltfm.h
It is overkill to rename the entirety of ahci_platform just for one
override function.
This sort of thing I would have expected to be added directly to
ahci_platform.c.
Jeff
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Trond Myklebust @ 2011-01-05 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110105172641.GF8638@n2100.arm.linux.org.uk>
On Wed, 2011-01-05 at 17:26 +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 05, 2011 at 12:17:27PM -0500, Trond Myklebust wrote:
> > We should already be flushing the kernel direct mapping after writing by
> > means of the calls to flush_dcache_page() in xdr_partial_copy_from_skb()
> > and all the helpers in net/sunrpc/xdr.c.
>
> Hmm, we're getting into the realms of what flush_dcache_page() is supposed
> to do and what it's not supposed to do.
>
> Is this page an associated with a mapping (iow, page_mapping(page) is non-
> NULL)? If not, flush_dcache_page() won't do anything, and from my
> understanding, its flush_anon_page() which you want to be using there
> instead.
Actually, none of these pages are ever mapped into userspace, nor are
they mapped into the page cache.
They are allocated directly using alloc_page() by the thread that called
the readdir() syscall, so afaics there should be no incoherent mappings
other than the kernel direct mapping and the one created by
vm_map_ram().
So, yes, you are right that we don't need the flush_dcache_page() here.
> > The only new thing is the read access through the virtual address
> > mapping. That mapping is created outside the loop in
> > nfs_readdir_xdr_to_array(), which is why I'm thinking we do need the
> > invalidate_kernel_vmap_range(): we're essentially doing a series of
> > writes through the kernel direct mapping (i.e. readdir RPC calls), then
> > reading the results through the virtual mapping.
> >
> > i.e. we're doing
> >
> > ptr = vm_map_ram(lowmem_pages);
> > while (need_more_data) {
> >
> > for (i = 0; i < npages; i++) {
> > addr = kmap_atomic(lowmem_page[i]);
> > *addr = rpc_stuff;
> > flush_dcache_page(lowmem_page[i]);
> > kunmap_atomic(lowmem_page[i]);
> > }
> >
> > invalidate_kernel_vmap_range(ptr); // Needed here?
>
> Yes, you're going to need some cache maintainence in there to make it work,
> because accessing 'ptr' will load that data into the cache, and that won't
> be updated by the writes via kmap_atomic().
>
> Provided you don't write to ptr, then using invalidate_kernel_vmap_range()
> will be safe.
Thanks! That is what Marc's testing appears to confirm.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust at netapp.com
www.netapp.com
^ permalink raw reply
* [PATCH] MAINTAINERS: Update Atmel AT91 entry
From: Nicolas Ferre @ 2011-01-05 18:04 UTC (permalink / raw)
To: linux-arm-kernel
Add two co-maintainers and update the entry with new information.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Andrew Victor <linux@maxim.org.za>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
---
MAINTAINERS | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7585e9d..cb58500 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -552,11 +552,15 @@ M: Lennert Buytenhek <kernel@wantstofly.org>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Maintained
-ARM/ATMEL AT91RM9200 ARM ARCHITECTURE
+ARM/ATMEL AT91RM9200 AND AT91SAM ARM ARCHITECTURES
M: Andrew Victor <linux@maxim.org.za>
+M: Nicolas Ferre <nicolas.ferre@atmel.com>
+M: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
W: http://maxim.org.za/at91_26.html
-S: Maintained
+W: http://www.linux4sam.org
+S: Supported
+F: arch/arm/mach-at91/
ARM/BCMRING ARM ARCHITECTURE
M: Jiandong Zheng <jdzheng@broadcom.com>
--
1.7.3
^ permalink raw reply related
* [PATCH 1/1] arm: omap: gpio: define .disable callback for gpio irq chip
From: Eduardo Valentin @ 2011-01-05 17:58 UTC (permalink / raw)
To: linux-arm-kernel
Currently, if one calls disable_irq(gpio_irq), the irq
won't get disabled.
This is happening because the omap gpio code defines only
a .mask callback. And the default_disable function is just
a stub. The result is that, when someone calls disable_irq
for an irq in a gpio line, it will be kept enabled.
This patch solves this issue by setting the .disable
callback to point to the same .mask callback.
Signed-off-by: Eduardo Valentin <eduardo.valentin@nokia.com>
---
arch/arm/plat-omap/gpio.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index c05c653..033197f 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1433,6 +1433,7 @@ static struct irq_chip gpio_irq_chip = {
.shutdown = gpio_irq_shutdown,
.ack = gpio_ack_irq,
.mask = gpio_mask_irq,
+ .disable = gpio_mask_irq,
.unmask = gpio_unmask_irq,
.set_type = gpio_irq_type,
.set_wake = gpio_wake_enable,
@@ -1469,6 +1470,7 @@ static struct irq_chip mpuio_irq_chip = {
.name = "MPUIO",
.ack = mpuio_ack_irq,
.mask = mpuio_mask_irq,
+ .disable = mpuio_mask_irq,
.unmask = mpuio_unmask_irq,
.set_type = gpio_irq_type,
#ifdef CONFIG_ARCH_OMAP16XX
--
1.6.3.GIT
^ permalink raw reply related
* [PATCH v3 08/10] ARM: mxs: add ocotp read function
From: Jamie Lokier @ 2011-01-05 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110105172501.GB2112@gallagher>
Jamie Iles wrote:
> On Wed, Jan 05, 2011 at 05:44:09PM +0100, Uwe Kleine-K?nig wrote:
> > Hello Jamie,
> > On Wed, Jan 05, 2011 at 04:16:46PM +0000, Jamie Iles wrote:
> > > On Wed, Jan 05, 2011 at 10:07:35PM +0800, Shawn Guo wrote:
> > > > + /* check both BUSY and ERROR cleared */
> > > > + while ((__raw_readl(ocotp_base) &
> > > > + (BM_OCOTP_CTRL_BUSY | BM_OCOTP_CTRL_ERROR)) && --timeout)
> > > > + /* nothing */;
> > >
> > > Is it worth using cpu_relax() in these polling loops?
> > I don't know what cpu_relax does for other platforms, but on ARM it's
> > just a memory barrier which AFAICT doesn't help here at all (which
> > doesn't need to be correct). Why do you think it would be better?
>
> Well I don't see that there's anything broken without cpu_relax() but
> using cpu_relax() seems to be the most common way of doing busy polling
> loops that I've seen. It's also a bit easier to read than a comment and
> semi-colon. Perhaps it's just personal preference.
cpu_relax() is a hint to the CPU to, for example, save power or be
less aggressive on the memory bus (to save power or be fairer).
Currently these architectures do more than just a barrier in cpu_relax():
x86, IA64, PowerPC, Tile and S390.
Although it's just a hint on ARM at the moment, it might change in
future - especially with power mattering on so many ARM systems.
(Even now, just changing it to a very short udelay might save power
on existing ARMs without breaking drivers.)
By the way, I see ARM defines cpu_relax as smp_mb() on arch >= 6. Is
that correct and useful? On other architectures*, barrier() is enough
of a barrier, but it's conceivable that smp_mb() would have some
ARM-specific fairness or bus activity benefit - in which case it
should probably be mb().
* - except Blackfin, which historically derived a lot from ARM headers.
-- Jamie
^ permalink raw reply
* [PATCH] omap: wd_timer: Fix crash frm wdt_probe when !CONFIG_RUNTIME_PM
From: Kevin Hilman @ 2011-01-05 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <68789fa8ba11b9427aa6321da55c9a8b@mail.gmail.com>
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> Commit ff2516fb 'wd_timer: disable on boot via hwmod postsetup mechanism'
> introduced watchdog timer state state management using postsetup_state.
> This was done to allow some board files to support watchdog coverage
> throughout kernel initialization and it work as intended when RUNTIME_PM
> is enabled.
>
> With !CONFIG_RUNTIME_PM and no board is specifically requests watchdog
> to remain enabled the omap_wdt_probe crashesh. This is because hwmod
> in absense of runtime PM unable to turn watchdog clocks because it's
> state is set to be disabled. For rest of the device, the state is
> set as enabled in absense of RUNTIME_PM
>
> [ 1.372558] Unhandled fault: imprecise external abort (0x1406) at
> 0xad733eeb
> [ 1.379913] Internal error: : 1406 [#1] SMP
> [ 1.384277] last sysfs file:
> [ 1.387359] Modules linked in:
> [ 1.390563] CPU: 0 Tainted: G W
> (2.6.37-rc7-00265-g4298a4c-dirty #23)
> [ 1.398468] PC is at omap_wdt_disable+0x2c/0x3c
> [ 1.403198] LR is at omap_wdt_probe+0x124/0x1e0
> [ 1.407928] pc : [<c02f5bf4>] lr : [<c03be10c>] psr: 60000013
> [ 1.407958] sp : df833f00 ip : 00000000 fp : 00000000
> [ 1.419921] r10: c0ac57ac r9 : df959e00 r8 : 00000000
> [ 1.425384] r7 : df959e08 r6 : df8000c0 r5 : df95bebc r4 : df87dde0
> [ 1.432189] r3 : fc314000 r2 : 00005555 r1 : fc314034 r0 : df87dde0
>
> This patch make the default watchdog state to be enabled in case of
> !CONFIG_RUNTIME_PM. This fixes the crash
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> ---
> Paul, I am not too sure if it breaks your _shutdown idea of watchdog
> timer. Patch generated against 'omap-for-linus' branch and boot
> tested on OMAP4 with and without CONFIG_OMAP_WATCHDOG.
>
> arch/arm/mach-omap2/io.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index e66687b..b879a16 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -378,7 +378,11 @@ void __init omap2_init_common_infrastructure(void)
> * XXX ideally we could detect whether the MPU WDT was currently
> * enabled here and make this conditional
> */
> +#ifdef CONFIG_PM_RUNTIME
> postsetup_state = _HWMOD_STATE_DISABLED;
> +#else
> + postsetup_state = _HWMOD_STATE_ENABLED;
> +#endif
You shouldn't need the 'else' part of this since the default a few lines
above this code is already setting that for the !CONFIG_PM_RUNTIME case.
Kevin
> omap_hwmod_for_each_by_class("wd_timer",
> _set_hwmod_postsetup_state,
> &postsetup_state);
^ permalink raw reply
* [PATCH v2 1/5] omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask
From: Kevin Hilman @ 2011-01-05 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294225024-21857-1-git-send-email-santosh.shilimkar@ti.com>
Hi Santosh,
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> struct clockdomain member clktrctrl_mask is available for only for OMAP2
> and OMAP3 architectures. Technially it is also used only for these archs
> but this breaks the build with custom OMAP4 configuration.
I'll queue patches 3-5 for the 2.6.38-rc fixes cycle.
With Paul's ack, I can queue the others too, or Paul can decide to take
them via his tree. Paul can decide.
Kevin
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Russell King - ARM Linux @ 2011-01-05 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294247847.2998.23.camel@heimdal.trondhjem.org>
On Wed, Jan 05, 2011 at 12:17:27PM -0500, Trond Myklebust wrote:
> We should already be flushing the kernel direct mapping after writing by
> means of the calls to flush_dcache_page() in xdr_partial_copy_from_skb()
> and all the helpers in net/sunrpc/xdr.c.
Hmm, we're getting into the realms of what flush_dcache_page() is supposed
to do and what it's not supposed to do.
Is this page an associated with a mapping (iow, page_mapping(page) is non-
NULL)? If not, flush_dcache_page() won't do anything, and from my
understanding, its flush_anon_page() which you want to be using there
instead.
> The only new thing is the read access through the virtual address
> mapping. That mapping is created outside the loop in
> nfs_readdir_xdr_to_array(), which is why I'm thinking we do need the
> invalidate_kernel_vmap_range(): we're essentially doing a series of
> writes through the kernel direct mapping (i.e. readdir RPC calls), then
> reading the results through the virtual mapping.
>
> i.e. we're doing
>
> ptr = vm_map_ram(lowmem_pages);
> while (need_more_data) {
>
> for (i = 0; i < npages; i++) {
> addr = kmap_atomic(lowmem_page[i]);
> *addr = rpc_stuff;
> flush_dcache_page(lowmem_page[i]);
> kunmap_atomic(lowmem_page[i]);
> }
>
> invalidate_kernel_vmap_range(ptr); // Needed here?
Yes, you're going to need some cache maintainence in there to make it work,
because accessing 'ptr' will load that data into the cache, and that won't
be updated by the writes via kmap_atomic().
Provided you don't write to ptr, then using invalidate_kernel_vmap_range()
will be safe.
^ permalink raw reply
* [PATCH 3/6] i2c/pxa2xx: Add PCI support for PXA I2C controller
From: Sebastian Andrzej Siewior @ 2011-01-05 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201012141535.30589.ffainelli@freebox.fr>
Florian Fainelli wrote:
>> diff --git a/drivers/i2c/busses/i2c-pxa-pci.c
>> b/drivers/i2c/busses/i2c-pxa-pci.c new file mode 100644
>> index 0000000..f7b74b9
>> --- /dev/null
>> +++ b/drivers/i2c/busses/i2c-pxa-pci.c
>> +
>> +/*
>> + * the number of bars is hardcoded because pci_select_bars() reports the
>> + * wrong thing.
>> + */
>> +#define CE4100_PCI_I2C_DEVS 3
>
> I am surprised of your comment about pci_select_bars, it works fine here on a
> CE4100 device, beware that it will report a bitmask of valid resources (7).
>
> Changing it later would be quite simple anyway.
yep, my bad. I removed the comment and we can make it fully dynamic once
it is required.
Sebastian
^ permalink raw reply
* [PATCH v3 08/10] ARM: mxs: add ocotp read function
From: Jamie Iles @ 2011-01-05 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110105164409.GV25121@pengutronix.de>
On Wed, Jan 05, 2011 at 05:44:09PM +0100, Uwe Kleine-K?nig wrote:
> Hello Jamie,
> On Wed, Jan 05, 2011 at 04:16:46PM +0000, Jamie Iles wrote:
> > On Wed, Jan 05, 2011 at 10:07:35PM +0800, Shawn Guo wrote:
> > > + /* check both BUSY and ERROR cleared */
> > > + while ((__raw_readl(ocotp_base) &
> > > + (BM_OCOTP_CTRL_BUSY | BM_OCOTP_CTRL_ERROR)) && --timeout)
> > > + /* nothing */;
> >
> > Is it worth using cpu_relax() in these polling loops?
> I don't know what cpu_relax does for other platforms, but on ARM it's
> just a memory barrier which AFAICT doesn't help here at all (which
> doesn't need to be correct). Why do you think it would be better?
Well I don't see that there's anything broken without cpu_relax() but
using cpu_relax() seems to be the most common way of doing busy polling
loops that I've seen. It's also a bit easier to read than a comment and
semi-colon. Perhaps it's just personal preference.
Jamie
^ permalink raw reply
* [PATCH 0/5] omap2plus: Trivial build break fixes
From: Kevin Hilman @ 2011-01-05 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6a39d0124306a5ac6b567edca88f0671@mail.gmail.com>
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
[...]
>> Minor nit in your git-send-email config.
>>
>> Can you add the following to your ~/.gitconfig, or update to newer
>> git
>> where this is now the default:
>>
>> [sendemail]
>> chainreplyto = false
>>
>> This will make all patches a reply to PATCH 0 instead of to the
>> previous
>> patch.
>>
> Have tried this in v2 I posted but it didn't appear to be a
> reply for PATCH 0.
You didn't have (or I didn't see) a PATCH 0 in your v2 version. After
patch 1, all patches are replies to patch 1 (using In-Reply-To: and
References:) resulting in proper threading.
> May be I missed something.
I don't think so, it looks right now.
Kevin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox