* mmci: U300 "sync with blockend" broken for multi-block?
From: Russell King - ARM Linux @ 2011-01-14 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTim4J8xrj9axhsu4=_7YkEy_ndiJ6cjDNf2WfzEg@mail.gmail.com>
On Fri, Jan 14, 2011 at 09:13:05PM +0100, Linus Walleij wrote:
> 2011/1/5 Russell King - ARM Linux <linux@arm.linux.org.uk>:
>
> > Any chance of pr_debug'ing the complete status register each time you
> > service an interrupt? ?You'll probably need to set the kernel log
> > buffer fairly large to ensure that you capture everything.
>
> I did this test now.
Just to complete the picture, can I see the patch between the version
which produced this and mainline?
^ permalink raw reply
* [GIT PULL] pxa: fixes for 2.6.38-rc
From: Russell King - ARM Linux @ 2011-01-14 22:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114133435.GD15996@n2100.arm.linux.org.uk>
On Fri, Jan 14, 2011 at 01:34:35PM +0000, Russell King - ARM Linux wrote:
> On Thu, Jan 13, 2011 at 11:02:35PM +0000, Russell King - ARM Linux wrote:
> > On Thu, Jan 13, 2011 at 03:15:21PM -0600, Eric Miao wrote:
> > > Hi Russell,
> > >
> > > The following changes since commit aebf2fc9dc974270b4b25a83816c7051c73f07c8:
> > >
> > > it8152: add IT8152_LAST_IRQ definition to fix build error
> > > (2011-01-02 23:21:14 +0800)
> >
> > Nope, not pulling.
> >
> > I don't have this in my tree, and it doesn't appear to exist in Linus'
> > tree either. There is this commit:
>
> Eric, I'm planning to do my final push for this merge window this
> evening, so I'd like to know whether it's likely that you'll have
> this fixed by then?
Okay, I'm deferring until tomorrow - there's still a patch and one
git tree (PXA) containing fixes with problems.
^ permalink raw reply
* [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
From: Paul Walmsley @ 2011-01-14 22:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114212027.GD22505@n2100.arm.linux.org.uk>
On Fri, 14 Jan 2011, Russell King - ARM Linux wrote:
> On Fri, Jan 14, 2011 at 12:18:50PM -0700, Paul Walmsley wrote:
> > On Thu, 13 Jan 2011, Russell King - ARM Linux wrote:
> > > On Thu, Jan 13, 2011 at 07:51:53AM -0800, Tony Lindgren wrote:
> > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110113 01:15]:
> > > > > Given the very sorry state of OMAP in mainline at present, I'm surprised
> > > > > that this kind of stuff is still going on...
> > > >
> > > > At least I boot test the patches I send..
> > >
> > > Which is why OMAP3 and OMAP4 can't be built in mainline because they
> > > spit out lots of compile errors in the OMAP code... As they won't
> > > even compile they couldn't have been boot tested.
> >
> > Current mainline != the patches that Tony sent to Linus[1].
> >
> > The patches that Tony sent to Linus, which Linus merged, build fine
> > with omap2plus_defconfig[2].
>
> Right, but is that sufficient testing?
>
> Can I read into your statement that the only testing which was done was
> a build of the omap2plus defconfig?
No. The patches that Tony merged from me were built with omap1_defconfig
and boot-tested on OMAP5912 OSK; they were built with an N8x0-specific
configuration and boot-tested on N800; and they were built with
omap2plus_defconfig and boot-tested on 2430SDP, OMAP3530 Beagle, DM37xx
Beagle XM, and OMAP4430 ES2 Panda. A brief summary of that testing was
part of the pull request that was sent to Tony[1].
The problem in this case was that I did not compile-test them with an
OMAP4-only configuration - hence the clockdomain and PRM breakage.
> Weren't builds specific to OMAP2, OMAP3, and OMAP4 tried?
>
> As there is stuff like:
>
> struct clockdomain {
> const char *name;
> union {
> const char *name;
> struct powerdomain *ptr;
> } pwrdm;
> #if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
> const u16 clktrctrl_mask;
> #endif
>
> would you consider it's a good idea to at least run a build test with
> an OMAP4-only configuration?
Yes. Given the clockdomain and PRM breakage from this merge window, I
plan to compile-test future branches that I send to Tony with quite a few
non-multi-OMAP configs. I consider it my responsibility to catch breakage
from my branches before it makes it to Tony.
> If it helps, here's what I do - not only do I run a few of the standard
> defconfigs in the tree, but I also run a number of platform specific
> builds, both covering platforms I do and do not have. I'll pick a random
> selection of existing build trees to rebuild and see what the results are.
> This shows the spread of trees which I've built over the last year - and
> note that many of these I don't even have:
>
> drwxrwxr-x. 20 rmk rmk 4096 Jan 14 20:30 omap4
> drwxrwxr-x. 21 rmk rmk 4096 Jan 14 11:45 versatile
> drwxrwxr-x. 21 rmk rmk 4096 Jan 14 11:14 iop13xx
> drwxrwxr-x. 20 rmk rmk 4096 Jan 13 23:10 vexpress
> drwxrwxr-x. 21 rmk rmk 4096 Jan 11 13:48 integrator
> drwxrwxr-x. 21 rmk rmk 4096 Jan 11 13:44 realview
> drwxrwxr-x. 21 rmk rmk 4096 Jan 8 11:10 assabet
> drwxrwxr-x. 21 rmk rmk 4096 Jan 8 11:07 rpc
> drwxrwxr-x. 21 rmk rmk 4096 Jan 7 17:34 omap3
> drwxrwxr-x. 20 rmk rmk 4096 Jan 6 14:24 nommu
> drwxrwxr-x. 21 rmk rmk 4096 Jan 6 10:44 omap2
> drwxrwxr-x. 21 rmk rmk 4096 Jan 6 10:27 omap
> drwxrwxr-x. 21 rmk rmk 4096 Jan 6 10:24 u300
> drwxrwxr-x. 21 rmk rmk 4096 Jan 5 19:14 pxa
> drwxrwxr-x. 21 rmk rmk 4096 Jan 5 10:30 msm
> drwxrwxr-x. 21 rmk rmk 4096 Jan 4 17:25 orion-kirkwood
> drwxrwxr-x. 21 rmk rmk 4096 Dec 24 11:06 ks8695
> drwxrwxr-x. 21 rmk rmk 4096 Dec 16 16:12 s3c2410
> drwxrwxr-x. 21 rmk rmk 4096 Dec 11 17:17 ixp4xx
> drwxrwxr-x. 20 rmk rmk 4096 Oct 9 22:59 netwinder2
> drwxrwxr-x. 21 rmk rmk 4096 Sep 5 23:54 ebsa285
> drwxrwxr-x. 21 rmk rmk 4096 Aug 4 2010 zylonite
> drwxrwxr-x. 21 rmk rmk 4096 Jul 8 2010 ep93xx
> drwxrwxr-x. 21 rmk rmk 4096 Jun 29 2010 corgi
> drwxrwxr-x. 21 rmk rmk 4096 Apr 25 2010 ebsa110
> drwxrwxr-x. 21 rmk rmk 4096 Mar 25 2010 clps711x
> drwxrwxr-x. 21 rmk rmk 4096 Mar 24 2010 ixp23xx
> drwxrwxr-x. 21 rmk rmk 4096 Mar 20 2010 n2100
> drwxrwxr-x. 21 rmk rmk 4096 Feb 19 2010 iop32x
> drwxrwxr-x. 21 rmk rmk 4096 Jan 20 2010 mx1
> drwxrwxr-x. 21 rmk rmk 4096 Jan 10 2010 w90p910evb
>
> omap4 = 4430SDP only (I have).
> omap3 = 3430LDP (I have) + 3430SDP + RX51 (I don't)
> omap2 = H2 (whose config can be traced to 2005 from when I once had one.)
> omap = some random omap1 config
> realview = realview eb/smp only
> assabet = assabet+neponset daugter board
>
> All those are build trees, built from my git tree with:
> make ARCH=arm CROSS_COMPILE=arm-linux- O=../build/$tree <args>
>
> You can see from the above that I built a kernel for at least orion-kirkwood,
> msm, u300, omap, nommu trees before sending my pull to Linus on the 6th,
> none of which I have (ever) had hardware for. I also built omap3, omap4,
> and a bunch of the ARM evaluation platforms as well as older platforms
> like RiscPC, but those are hidden by later re-builds for work I've been
> doing since (which is all based upon commit 9e9bc97.)
>
> I'm not saying that's perfect - it isn't. It's better than just testing
> the defconfigs - and with regular checking of kautobuild/linux-next, it
> seems to catch quite a bit of really silly stuff.
I agree with you. I do think it's a good idea, and it's something that I
plan to do for future branches that I send to Tony.
regards
- Paul
1. Walmsley, Paul. _[GIT PULL v3] OMAP: core/PM architecture: pull request
for 2.6.38_. Posted to linux-omap at vger.kernel.org mailing list on 22
December 2010. Available from
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41289.html
(among others).
^ permalink raw reply
* [GIT PULL v3] pxa: patches for v2.6.38-rc
From: Russell King - ARM Linux @ 2011-01-14 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114173147.GK15996@n2100.arm.linux.org.uk>
On Fri, Jan 14, 2011 at 05:31:47PM +0000, Russell King - ARM Linux wrote:
> On Fri, Jan 14, 2011 at 11:08:59AM -0600, Eric Miao wrote:
> > Hi Russell,
> >
> > I rebased the branch on top of devel-stable. The conflict in irq.c is
> > fixed. And there is a one-liner patch fixing a building issue in spitz.c
> > missing of physmap.h. Please re-pull and let know any other issue.
>
> Pulled cleanly, thanks.
Building my PXA config:
arch/arm/mach-pxa/irq.c:124: warning: initialization from incompatible pointer type
arch/arm/mach-pxa/irq.c:125: warning: initialization from incompatible pointer type
arch/arm/mach-pxa/irq.c:126: warning: initialization from incompatible pointer type
arch/arm/mach-pxa/irq.c:127: warning: initialization from incompatible pointer type
Seems the initializers want to be .irq_ack rather than .ack etc.
I also need to remove asm/pgtable.h from arch/arm/mach-pxa/generic.c:
CC arch/arm/mach-pxa/generic.o
In file included from arch/arm/include/asm/pgtable.h:461,
from arch/arm/mach-pxa/generic.c:26:
include/asm-generic/pgtable.h: In function ?ptep_test_and_clear_young?:
include/asm-generic/pgtable.h:29: error: dereferencing pointer to incomplete type
and I also got:
arch/arm/mach-pxa/tosa-bt.c: In function ?tosa_bt_probe?:
arch/arm/mach-pxa/tosa-bt.c:84: error: implicit declaration of function ?rfkill_set_led_trigger_name?
which looks like a missing dependency.
Do you want to fix these and send an updated pull?
^ permalink raw reply
* [PATCHv2] hwrng: add support for picoxcell TRNG
From: Jamie Iles @ 2011-01-14 21:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <v7p608-mqv.ln1@chipmunk.wormnet.eu>
On Fri, Jan 14, 2011 at 08:45:19PM +0000, Alexander Clouter wrote:
> In gmane.linux.ports.arm.kernel Jamie Iles <jamie@jamieiles.com> wrote:
> >
> > This driver adds support for the True Random Number Generator in
> > the Picochip PC3X3 and later devices.
> >
> > [snipped]
> >
> > +/*
> > + * Take the random number generator out of reset and make sure the interrupts
> > + * are masked. We shouldn't need to get large amounts of random bytes so just
> > + * poll the status register. The hardware generates 32 bits every 320ns so we
> > + * shouldn't have to wait long enough to warrant waiting for an IRQ.
> > + */
> >
> timeriomem-rng? Example of usage in
> arch/arm/mach-orion5x/ts78xx-setup.c.
No, that's not quite suitable for our hardware. Although the hardware
generates the data every 320ns, it also performs self test of the data
in hardware to make sure it satisfies certain random qualities. If the
data doesn't pass the tests then it's rejected and not placed into the
FIFO so we'd have the possibility of an underflow with the
timeriomem-rng driver.
Jamie
^ permalink raw reply
* [PATCH] ARM: vfp: Fix up exception location in Thumb mode
From: Russell King - ARM Linux @ 2011-01-14 21:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimd44_FjnJUCNwz412Ned5S_+YcyHjfitus3vLQ@mail.gmail.com>
On Fri, Jan 14, 2011 at 11:51:38AM -0800, Colin Cross wrote:
> On Fri, Jan 14, 2011 at 11:23 AM, Colin Cross <ccross@android.com> wrote:
> > I tested copying r2 to regs->ARM_pc like this patch does, and it fixes
> > my test case. ?Could this second patch go first so it can be applied
> > to stable?
> >
>
> Also, both patches together Tested-by: Colin Cross <ccross@android.com>
Thanks. I do want to hear back from Catalin before merging them, so
they won't be part of tonight's push.
^ permalink raw reply
* [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
From: Russell King - ARM Linux @ 2011-01-14 21:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1101141216040.28621@utopia.booyaka.com>
On Fri, Jan 14, 2011 at 12:18:50PM -0700, Paul Walmsley wrote:
> On Thu, 13 Jan 2011, Russell King - ARM Linux wrote:
> > On Thu, Jan 13, 2011 at 07:51:53AM -0800, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110113 01:15]:
> > > > Given the very sorry state of OMAP in mainline at present, I'm surprised
> > > > that this kind of stuff is still going on...
> > >
> > > At least I boot test the patches I send..
> >
> > Which is why OMAP3 and OMAP4 can't be built in mainline because they
> > spit out lots of compile errors in the OMAP code... As they won't
> > even compile they couldn't have been boot tested.
>
> Current mainline != the patches that Tony sent to Linus[1].
>
> The patches that Tony sent to Linus, which Linus merged, build fine
> with omap2plus_defconfig[2].
Right, but is that sufficient testing?
Can I read into your statement that the only testing which was done was
a build of the omap2plus defconfig? Weren't builds specific to OMAP2,
OMAP3, and OMAP4 tried?
As there is stuff like:
struct clockdomain {
const char *name;
union {
const char *name;
struct powerdomain *ptr;
} pwrdm;
#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
const u16 clktrctrl_mask;
#endif
would you consider it's a good idea to at least run a build test with
an OMAP4-only configuration?
If it helps, here's what I do - not only do I run a few of the standard
defconfigs in the tree, but I also run a number of platform specific
builds, both covering platforms I do and do not have. I'll pick a random
selection of existing build trees to rebuild and see what the results are.
This shows the spread of trees which I've built over the last year - and
note that many of these I don't even have:
drwxrwxr-x. 20 rmk rmk 4096 Jan 14 20:30 omap4
drwxrwxr-x. 21 rmk rmk 4096 Jan 14 11:45 versatile
drwxrwxr-x. 21 rmk rmk 4096 Jan 14 11:14 iop13xx
drwxrwxr-x. 20 rmk rmk 4096 Jan 13 23:10 vexpress
drwxrwxr-x. 21 rmk rmk 4096 Jan 11 13:48 integrator
drwxrwxr-x. 21 rmk rmk 4096 Jan 11 13:44 realview
drwxrwxr-x. 21 rmk rmk 4096 Jan 8 11:10 assabet
drwxrwxr-x. 21 rmk rmk 4096 Jan 8 11:07 rpc
drwxrwxr-x. 21 rmk rmk 4096 Jan 7 17:34 omap3
drwxrwxr-x. 20 rmk rmk 4096 Jan 6 14:24 nommu
drwxrwxr-x. 21 rmk rmk 4096 Jan 6 10:44 omap2
drwxrwxr-x. 21 rmk rmk 4096 Jan 6 10:27 omap
drwxrwxr-x. 21 rmk rmk 4096 Jan 6 10:24 u300
drwxrwxr-x. 21 rmk rmk 4096 Jan 5 19:14 pxa
drwxrwxr-x. 21 rmk rmk 4096 Jan 5 10:30 msm
drwxrwxr-x. 21 rmk rmk 4096 Jan 4 17:25 orion-kirkwood
drwxrwxr-x. 21 rmk rmk 4096 Dec 24 11:06 ks8695
drwxrwxr-x. 21 rmk rmk 4096 Dec 16 16:12 s3c2410
drwxrwxr-x. 21 rmk rmk 4096 Dec 11 17:17 ixp4xx
drwxrwxr-x. 20 rmk rmk 4096 Oct 9 22:59 netwinder2
drwxrwxr-x. 21 rmk rmk 4096 Sep 5 23:54 ebsa285
drwxrwxr-x. 21 rmk rmk 4096 Aug 4 2010 zylonite
drwxrwxr-x. 21 rmk rmk 4096 Jul 8 2010 ep93xx
drwxrwxr-x. 21 rmk rmk 4096 Jun 29 2010 corgi
drwxrwxr-x. 21 rmk rmk 4096 Apr 25 2010 ebsa110
drwxrwxr-x. 21 rmk rmk 4096 Mar 25 2010 clps711x
drwxrwxr-x. 21 rmk rmk 4096 Mar 24 2010 ixp23xx
drwxrwxr-x. 21 rmk rmk 4096 Mar 20 2010 n2100
drwxrwxr-x. 21 rmk rmk 4096 Feb 19 2010 iop32x
drwxrwxr-x. 21 rmk rmk 4096 Jan 20 2010 mx1
drwxrwxr-x. 21 rmk rmk 4096 Jan 10 2010 w90p910evb
omap4 = 4430SDP only (I have).
omap3 = 3430LDP (I have) + 3430SDP + RX51 (I don't)
omap2 = H2 (whose config can be traced to 2005 from when I once had one.)
omap = some random omap1 config
realview = realview eb/smp only
assabet = assabet+neponset daugter board
All those are build trees, built from my git tree with:
make ARCH=arm CROSS_COMPILE=arm-linux- O=../build/$tree <args>
You can see from the above that I built a kernel for at least orion-kirkwood,
msm, u300, omap, nommu trees before sending my pull to Linus on the 6th,
none of which I have (ever) had hardware for. I also built omap3, omap4,
and a bunch of the ARM evaluation platforms as well as older platforms
like RiscPC, but those are hidden by later re-builds for work I've been
doing since (which is all based upon commit 9e9bc97.)
I'm not saying that's perfect - it isn't. It's better than just testing
the defconfigs - and with regular checking of kautobuild/linux-next, it
seems to catch quite a bit of really silly stuff.
Please test a (small) selection of configurations to improve build
coverage. Try to develop a set of configurations which trip up common
issues which won't be found with the omap2plus defconfig. Don't assume
that just because the omap2plus defconfig builds that it's ready.
^ permalink raw reply
* [PATCH v4] ARM: Thumb-2: Symbol manipulation macros for function body copying
From: Dave Martin @ 2011-01-14 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In low-level board support code, there is sometimes a need to
copy a function body to another location at run-time.
A straightforward call to memcpy doesn't work in Thumb-2,
because bit 0 of external Thumb function symbols is set to 1,
indicating that the function is Thumb. Without corrective
measures, this will cause an off-by-one copy, and the copy
may be called using the wrong instruction set.
This patch adds an fncpy() macro to help with such copies.
Particular care is needed, because C doesn't guarantee any
defined behaviour when casting a function pointer to any other
type. This has been observed to lead to strange optimisation
side-effects when doing the arithmetic which is required in
order to copy/move function bodies correctly in Thumb-2.
Thanks to Russell King and Nicolas Pitre for their input
on this patch.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Tested-by: Jean Pihet <j-pihet@ti.com>
---
arch/arm/include/asm/fncpy.h | 96 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 96 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/fncpy.h
diff --git a/arch/arm/include/asm/fncpy.h b/arch/arm/include/asm/fncpy.h
new file mode 100644
index 0000000..8b94b5f
--- /dev/null
+++ b/arch/arm/include/asm/fncpy.h
@@ -0,0 +1,96 @@
+/*
+ * arch/arm/include/asm/fncpy.h - helper macros for function body copying
+ *
+ * Copyright (C) 2011 Linaro Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+/*
+ * These macros are intended for use when there is a need to copy a low-level
+ * function body into special memory.
+ *
+ * For example, when reconfiguring the SDRAM controller, the code doing the
+ * reconfiguration may need to run from SRAM.
+ *
+ * NOTE: that the copied function body must be entirely self-contained and
+ * position-independent in order for this to work properly.
+ *
+ * NOTE: in order for embedded literals and data to get referenced correctly,
+ * the alignment of functions must be preserved when copying. To ensure this,
+ * the source and destination addresses for fncpy() must be aligned to a
+ * multiple of 8 bytes: you will be get a BUG() if this condition is not met.
+ * You will typically need a ".align 3" directive in the assembler where the
+ * function to be copied is defined, and ensure that your allocator for the
+ * destination buffer returns 8-byte-aligned pointers.
+ *
+ * Typical usage example:
+ *
+ * extern int f(args);
+ * extern uint32_t size_of_f;
+ * int (*copied_f)(args);
+ * void *sram_buffer;
+ *
+ * copied_f = fncpy(sram_buffer, &f, size_of_f);
+ *
+ * ... do any required D-side/I-side synchronisation ...
+ *
+ * ... later, call the function: ...
+ *
+ * copied_f(args);
+ *
+ * The size of the function to be copied can't be determined from C:
+ * this must be determined by other means, such as adding assmbler directives
+ * in the file where f is defined.
+ */
+
+#ifndef __ASM_FNCPY_H
+#define __ASM_FNCPY_H
+
+#include <linux/types.h>
+#include <linux/string.h>
+
+#include <asm/bug.h>
+#include <asm/cacheflush.h>
+
+/*
+ * Minimum alignment requirement for the source and destination addresses
+ * for function copying.
+ */
+#define FNCPY_ALIGN 8
+
+#define fncpy(dest_buf, funcp, size) ({ \
+ uintptr_t __funcp_address; \
+ typeof(funcp) __result; \
+ \
+ asm("" : "=r" (__funcp_address) : "0" (funcp)); \
+ \
+ /* \
+ * Ensure alignment of source and destination addresses, \
+ * disregarding the function's Thumb bit: \
+ */ \
+ BUG_ON((uintptr_t)(dest_buf) & (FNCPY_ALIGN - 1) || \
+ (__funcp_address & ~(uintptr_t)1 & (FNCPY_ALIGN - 1))); \
+ \
+ memcpy(dest_buf, (void const *)(__funcp_address & ~1), size); \
+ flush_icache_range((unsigned long)(dest_buf), \
+ (unsigned long)(dest_buf) + (size)); \
+ \
+ asm("" : "=r" (__result) \
+ : "0" ((uintptr_t)(dest_buf) | (__funcp_address & 1))); \
+ \
+ __result; \
+})
+
+#endif /* !__ASM_FNCPY_H */
--
1.7.1
^ permalink raw reply related
* [PATCH] ARM: msm: 7x30: don't force a gpiomux table for the whole arch
From: Daniel Walker @ 2011-01-14 21:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D2FC49A.1000505@codeaurora.org>
On Thu, 2011-01-13 at 19:35 -0800, Rohit Vaswani wrote:
> On 1/10/2011 11:00 AM, Dima Zavin wrote:
> > This is completely board specific and therefore must be provided
> > on a per-board basis.
> >
> > Change-Id: I96f922ad9bb9cbce7874c5ae6ac0d7479b7a2124
> > Signed-off-by: Dima Zavin<dima@android.com>
> >
> Tested-by: Rohit Vaswani <rvaswani@codeaurora.org>
Rohit, do you have patches to do this for all the SoCs?
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
^ permalink raw reply
* [PATCHv2] hwrng: add support for picoxcell TRNG
From: Alexander Clouter @ 2011-01-14 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295030661-16364-1-git-send-email-jamie@jamieiles.com>
In gmane.linux.ports.arm.kernel Jamie Iles <jamie@jamieiles.com> wrote:
>
> This driver adds support for the True Random Number Generator in
> the Picochip PC3X3 and later devices.
>
> [snipped]
>
> +/*
> + * Take the random number generator out of reset and make sure the interrupts
> + * are masked. We shouldn't need to get large amounts of random bytes so just
> + * poll the status register. The hardware generates 32 bits every 320ns so we
> + * shouldn't have to wait long enough to warrant waiting for an IRQ.
> + */
>
timeriomem-rng? Example of usage in
arch/arm/mach-orion5x/ts78xx-setup.c.
Cheers
--
Alexander Clouter
.sigmonster says: The more I know men the more I like my horse.
^ permalink raw reply
* mmci: U300 "sync with blockend" broken for multi-block?
From: Linus Walleij @ 2011-01-14 20:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110105164344.GD8638@n2100.arm.linux.org.uk>
2011/1/5 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> Any chance of pr_debug'ing the complete status register each time you
> service an interrupt? ?You'll probably need to set the kernel log
> buffer fairly large to ensure that you capture everything.
I did this test now.
Typical read/write test:
dd if=/dev/mmcblk0 of=/dev/null bs=16384 count=16 of=/dev/null
dd if=/dev/zero of=/dev/mmcblk0 bs=16384 count=16
The MCI_DATABLOCKENDMASK is set in both modes so it should appear
after every block (512 bytes) no matter whether you're using DMA
or not. In this case you would expect 0x80 x MCI_DATABLOCKEND
followed by MCI_DATAEND, repeated 16 times.
But this is what happens:
TEST WITH PIO ON U8500 READ:
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0018 flags 00000200
mmci-pl18x sdi2: MCI_DATABLOCKEND && MCI_DATAEND
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0028 flags 00000200
mmci-pl18x sdi2: MCI_DATABLOCKEND && MCI_DATAEND
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0080 flags 00000200
mmci-pl18x sdi2: MCI_DATABLOCKEND && MCI_DATAEND
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0080 flags 00000200
mmci-pl18x sdi2: MCI_DATABLOCKEND && MCI_DATAEND
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0080 flags 00000200
mmci-pl18x sdi2: MCI_DATABLOCKEND && MCI_DATAEND
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0080 flags 00000200
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATAEND
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0080 flags 00000200
mmci-pl18x sdi2: MCI_DATABLOCKEND && MCI_DATAEND
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0080 flags 00000200
mmci-pl18x sdi2: MCI_DATABLOCKEND && MCI_DATAEND
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0080 flags 00000200
mmci-pl18x sdi2: MCI_DATABLOCKEND && MCI_DATAEND
So MCI_DATABLOCKEND only appear if MCI_DATAEND appear
at the same time or soon thereafter.
TEST WITH PIO ON U8500 WRITE:
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0080 flags 00000100
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND
mmci-pl18x sdi2: MCI_DATABLOCKEND && MCI_DATAEND
Note: too few MCI_DATABLOCKEND, 32 of them, while
you're expecting 128 of them. This would lead you
to think that maybe you get MCI_DATABLOCKEND for every
fourth block, which has some kind of twisted logic
to it. But in reality this varies: there are sometimes
things like this
for a very large number of blocks:
mmci-pl18x sdi4: START DATA: blksz 0200 blks 01e2 flags 00000100
mmci-pl18x sdi4: MCI_DATABLOCKEND
mmci-pl18x sdi4: MCI_DATABLOCKEND
mmci-pl18x sdi4: MCI_DATABLOCKEND
mmci-pl18x sdi4: MCI_DATABLOCKEND
mmci-pl18x sdi4: MCI_DATABLOCKEND && MCI_DATAEND
Just 4 MCI_DATABLOCKEND for 0x1e2 blocks!
Totally unpredictable.
TEST WITH DMA ON U8500 READ:
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0008 flags 00000200
mmci-pl18x sdi2: MCI_DATAEND
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0038 flags 00000200
mmci-pl18x sdi2: MCI_DATAEND
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0080 flags 00000200
mmci-pl18x sdi2: MCI_DATAEND
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0080 flags 00000200
mmci-pl18x sdi2: MCI_DATAEND
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0080 flags 00000200
mmci-pl18x sdi2: MCI_DATAEND
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0080 flags 00000200
mmci-pl18x sdi2: MCI_DATAEND
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0080 flags 00000200
mmci-pl18x sdi2: MCI_DATAEND
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0080 flags 00000200
mmci-pl18x sdi2: MCI_DATAEND
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0080 flags 00000200
mmci-pl18x sdi2: MCI_DATAEND
TEST WITH DMA ON U8500 WRITE:
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0018 flags 00000100
mmci-pl18x sdi2: MCI_DATAEND
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0080 flags 00000100
mmci-pl18x sdi2: MCI_DATAEND
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0080 flags 00000100
mmci-pl18x sdi2: MCI_DATAEND
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0080 flags 00000100
mmci-pl18x sdi2: MCI_DATAEND
mmci-pl18x sdi2: START DATA: blksz 0200 blks 0068 flags 00000100
mmci-pl18x sdi2: MCI_DATAEND
No sign of MCI_DATABLOCKEND when using DMA. It's not there.
TEST WITH PIO ON U300 READ:
[ 699.219323] mmci-pl18x mmci: START DATA: blksz 0200 blks 0080 flags 00000200
[ 699.226623] mmci-pl18x mmci: MCI_DATABLOCKEND
[ 699.231085] mmci-pl18x mmci: MCI_DATABLOCKEND
(.. 0x80 in total ...)
[ 699.236598] mmci-pl18x mmci: MCI_DATABLOCKEND
[ 699.759572] mmci-pl18x mmci: MCI_DATABLOCKEND && MCI_DATAEND
(repeat x16)
WRITE looks the same, just flags=00000100 instead
So yes, MCI_DATABLOCKEND indeed does work if you're not
using DMA. Haven't been able to provoke READ nor WRITE
to get the flags after each other, they always seem to appear
simultaneously.
What it problematic with the reads *and* writes is that
sometimes there us a MCI_DATABLOCKEND missing, so the
blocks simply don't add up! This is the real bug that
the sync code was trying to solve, and not in a very
good way.
TEST WITH DMA ON U300 READ:
[ 43.402718] mmci-pl18x mmci: START DATA: blksz 0200 blks 0040 flags 00000200
[ 43.414096] mmci-pl18x mmci: MCI_DATAEND
[ 43.424922] mmci-pl18x mmci: START DATA: blksz 0200 blks 0078 flags 00000200
[ 43.439449] mmci-pl18x mmci: MCI_DATAEND
[ 43.449258] mmci-pl18x mmci: START DATA: blksz 0200 blks 0078 flags 00000200
[ 43.463692] mmci-pl18x mmci: MCI_DATAEND
[ 43.474446] mmci-pl18x mmci: START DATA: blksz 0200 blks 0078 flags 00000200
[ 43.488953] mmci-pl18x mmci: MCI_DATAEND
[ 43.498793] mmci-pl18x mmci: START DATA: blksz 0200 blks 0078 flags 00000200
[ 43.513341] mmci-pl18x mmci: MCI_DATAEND
[ 43.524605] mmci-pl18x mmci: START DATA: blksz 0200 blks 0078 flags 00000200
[ 43.539141] mmci-pl18x mmci: MCI_DATAEND
[ 43.547262] mmci-pl18x mmci: START DATA: blksz 0200 blks 0078 flags 00000200
[ 43.561702] mmci-pl18x mmci: MCI_DATAEND
[ 43.569592] mmci-pl18x mmci: START DATA: blksz 0200 blks 0078 flags 00000200
[ 43.584066] mmci-pl18x mmci: MCI_DATAEND
[ 43.591893] mmci-pl18x mmci: START DATA: blksz 0200 blks 0038 flags 00000200
[ 43.602723] mmci-pl18x mmci: MCI_DATAEND
TEST WITH DMA ON U300 WRITE:
[ 40.266289] mmci-pl18x mmci: START DATA: blksz 0200 blks 0078 flags 00000100
[ 40.301415] mmci-pl18x mmci: MCI_DATAEND
[ 40.310951] mmci-pl18x mmci: START DATA: blksz 0200 blks 0078 flags 00000100
[ 40.325644] mmci-pl18x mmci: MCI_DATAEND
[ 40.334980] mmci-pl18x mmci: START DATA: blksz 0200 blks 0078 flags 00000100
[ 40.349552] mmci-pl18x mmci: MCI_DATAEND
[ 40.358561] mmci-pl18x mmci: START DATA: blksz 0200 blks 0078 flags 00000100
[ 40.373245] mmci-pl18x mmci: MCI_DATAEND
[ 40.382234] mmci-pl18x mmci: START DATA: blksz 0200 blks 0078 flags 00000100
[ 40.396811] mmci-pl18x mmci: MCI_DATAEND
[ 40.406151] mmci-pl18x mmci: START DATA: blksz 0200 blks 0078 flags 00000100
[ 40.420838] mmci-pl18x mmci: MCI_DATAEND
[ 40.430276] mmci-pl18x mmci: START DATA: blksz 0200 blks 0078 flags 00000100
[ 40.444852] mmci-pl18x mmci: MCI_DATAEND
[ 40.453939] mmci-pl18x mmci: START DATA: blksz 0200 blks 0078 flags 00000100
[ 40.468638] mmci-pl18x mmci: MCI_DATAEND
[ 40.477697] mmci-pl18x mmci: START DATA: blksz 0200 blks 0078 flags 00000100
[ 40.492269] mmci-pl18x mmci: MCI_DATAEND
[ 40.501770] mmci-pl18x mmci: START DATA: blksz 0200 blks 003b flags 00000100
[ 40.512910] mmci-pl18x mmci: MCI_DATAEND
[ 40.522388] mmci-pl18x mmci: START DATA: blksz 0200 blks 0001 flags 00000100
[ 40.529674] mmci-pl18x mmci: MCI_DATAEND
[ 40.537511] mmci-pl18x mmci: START DATA: blksz 0200 blks 0001 flags 00000100
[ 40.544790] mmci-pl18x mmci: MCI_DATAEND
[ 40.552528] mmci-pl18x mmci: START DATA: blksz 0200 blks 0001 flags 00000100
[ 40.559804] mmci-pl18x mmci: MCI_DATAEND
These tests were done using a file rather than dd but
the pattern is the same as on the U8500: you only get
MCI_DATAEND when using DMA on U300.
So in conclusion:
- The sync code (to make sure both MCI_DATAEND and
MCI_DATABLOCKEND both arrived) is not necessary.
- Both U300 and Ux500 (and presumably also their
sibling Nomadik) should be marked as
.broken_blockend = true, it is simply broken, for
PIO as well as for DMA.
So we should fix a patch that simplifies the code
accordingly: remove the sync and drop the
.broken_blockend_dma flag for U300, it's simply just
broken, all agree?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: vfp: Fix up exception location in Thumb mode
From: Colin Cross @ 2011-01-14 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=J2A1Qv6NGB1bsMr6d+1VFV26KEBQ=NJ=791s0@mail.gmail.com>
On Fri, Jan 14, 2011 at 11:23 AM, Colin Cross <ccross@android.com> wrote:
> On Fri, Jan 14, 2011 at 10:47 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> So... this incrementally on top of the previous patch (which I've
>> reproduced below as there's a subtle comment change in there wrt IRQ
>> state.)
>>
>> This means we have consistent state - both r2 and regs->ARM_pc always
>> point to the next instruction to be executed in every case, which means
>> its easy to understand and remember while reading through the code.
>>
>> diff -u b/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
>> --- b/arch/arm/kernel/entry-armv.S
>> +++ b/arch/arm/kernel/entry-armv.S
>> @@ -499,10 +499,11 @@
>> ? ? ? ?blo ? ? __und_usr_unknown
>> ?3: ? ? ldrht ? r0, [r4]
>> ? ? ? ?add ? ? r2, r2, #2 ? ? ? ? ? ? ? ? ? ? ?@ r2 is PC + 2, make it PC + 4
>> - ? ? ? orr ? ? r0, r0, r5, lsl #16
>> + ? ? ? str ? ? r2, [sp, #S_PC] ? ? ? ? ? ? ? ? @ it's a 2x16bit instr, update
>> + ? ? ? orr ? ? r0, r0, r5, lsl #16 ? ? ? ? ? ? @ ?regs->ARM_pc
>> ? ? ? ?@
>> ? ? ? ?@ r0 = the two 16-bit Thumb instructions which caused the exception
>> - ? ? ? @ r2 = PC value for the following Thumb instruction (:= regs->ARM_pc+2)
>> + ? ? ? @ r2 = PC value for the following Thumb instruction (:= regs->ARM_pc)
>> ? ? ? ?@ r4 = PC value for the first 16-bit Thumb instruction
>> ? ? ? ?@
>> ?#else
>>
>> 8<-x-x-
>>
>> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
>> index 2b46fea..5876eec 100644
>> --- a/arch/arm/kernel/entry-armv.S
>> +++ b/arch/arm/kernel/entry-armv.S
>> @@ -461,27 +461,35 @@ ENDPROC(__irq_usr)
>> ? ? ? ?.align ?5
>> ?__und_usr:
>> ? ? ? ?usr_entry
>> -
>> - ? ? ? @
>> - ? ? ? @ fall through to the emulation code, which returns using r9 if
>> - ? ? ? @ it has emulated the instruction, or the more conventional lr
>> - ? ? ? @ if we are to treat this as a real undefined instruction
>> ? ? ? ?@
>> - ? ? ? @ ?r0 - instruction
>> + ? ? ? @ The emulation code returns using r9 if it has emulated the
>> + ? ? ? @ instruction, or the more conventional lr if we are to treat
>> + ? ? ? @ this as a real undefined instruction
>> ? ? ? ?@
>> ? ? ? ?adr ? ? r9, BSYM(ret_from_exception)
>> ? ? ? ?adr ? ? lr, BSYM(__und_usr_unknown)
>> + ? ? ? @
>> + ? ? ? @ r2 = regs->ARM_pc, which is either 2 or 4 bytes ahead of the
>> + ? ? ? @ faulting instruction depending on Thumb mode.
>> + ? ? ? @ r3 = regs->ARM_cpsr
>> + ? ? ? @
>> ? ? ? ?tst ? ? r3, #PSR_T_BIT ? ? ? ? ? ? ? ? ?@ Thumb mode?
>> - ? ? ? itet ? ?eq ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?@ explicit IT needed for the 1f label
>> + ? ? ? itttt ? eq ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?@ explicit IT needed for the 1f label
>> ? ? ? ?subeq ? r4, r2, #4 ? ? ? ? ? ? ? ? ? ? ?@ ARM instr at LR - 4
>> - ? ? ? subne ? r4, r2, #2 ? ? ? ? ? ? ? ? ? ? ?@ Thumb instr at LR - 2
>> ?1: ? ? ldreqt ?r0, [r4]
>> ?#ifdef CONFIG_CPU_ENDIAN_BE8
>> ? ? ? ?reveq ? r0, r0 ? ? ? ? ? ? ? ? ? ? ? ? ?@ little endian instruction
>> ?#endif
>> + ? ? ? @
>> + ? ? ? @ r0 = 32-bit ARM instruction which caused the exception
>> + ? ? ? @ r2 = PC value for the following instruction (:= regs->ARM_pc)
>> + ? ? ? @ r4 = PC value for the faulting instruction
>> + ? ? ? @
>> ? ? ? ?beq ? ? call_fpe
>> +
>> ? ? ? ?@ Thumb instruction
>> ?#if __LINUX_ARM_ARCH__ >= 7
>> + ? ? ? sub ? ? r4, r2, #2 ? ? ? ? ? ? ? ? ? ? ?@ Thumb instr at LR - 2
>> ?2:
>> ?ARM( ?ldrht ? r5, [r4], #2 ? ?)
>> ?THUMB( ? ? ? ?ldrht ? r5, [r4] ? ? ? ?)
>> @@ -492,18 +500,19 @@ __und_usr:
>> ?3: ? ? ldrht ? r0, [r4]
>> ? ? ? ?add ? ? r2, r2, #2 ? ? ? ? ? ? ? ? ? ? ?@ r2 is PC + 2, make it PC + 4
>> ? ? ? ?orr ? ? r0, r0, r5, lsl #16
>> + ? ? ? @
>> + ? ? ? @ r0 = the two 16-bit Thumb instructions which caused the exception
>> + ? ? ? @ r2 = PC value for the following Thumb instruction (:= regs->ARM_pc+2)
>> + ? ? ? @ r4 = PC value for the first 16-bit Thumb instruction
>> + ? ? ? @
>> ?#else
>> ? ? ? ?b ? ? ? __und_usr_unknown
>> ?#endif
>> - UNWIND(.fnend ? ? ? ? )
>> + UNWIND(.fnend)
>> ?ENDPROC(__und_usr)
>>
>> - ? ? ? @
>> - ? ? ? @ fallthrough to call_fpe
>> - ? ? ? @
>> -
>> ?/*
>> - * The out of line fixup for the ldrt above.
>> + * The out of line fixup for the ldrt instructions above.
>> ?*/
>> ? ? ? ?.pushsection .fixup, "ax"
>> ?4: ? ? mov ? ? pc, r9
>> @@ -534,11 +543,12 @@ ENDPROC(__und_usr)
>> ?* NEON handler code.
>> ?*
>> ?* Emulators may wish to make use of the following registers:
>> - * ?r0 ?= instruction opcode.
>> - * ?r2 ?= PC+4
>> + * ?r0 ?= instruction opcode (32-bit ARM or two 16-bit Thumb)
>> + * ?r2 ?= PC value to resume execution after successful emulation
>> ?* ?r9 ?= normal "successful" return address
>> - * ?r10 = this threads thread_info structure.
>> + * ?r10 = this threads thread_info structure
>> ?* ?lr ?= unrecognised instruction return address
>> + * IRQs disabled, FIQs enabled.
>> ?*/
>> ? ? ? ?@
>> ? ? ? ?@ Fall-through from Thumb-2 __und_usr
>> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
>> index ee57640..eeb9250 100644
>> --- a/arch/arm/kernel/traps.c
>> +++ b/arch/arm/kernel/traps.c
>> @@ -347,9 +347,9 @@ asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
>> ? ? ? ?void __user *pc;
>>
>> ? ? ? ?/*
>> - ? ? ? ?* According to the ARM ARM, PC is 2 or 4 bytes ahead,
>> - ? ? ? ?* depending whether we're in Thumb mode or not.
>> - ? ? ? ?* Correct this offset.
>> + ? ? ? ?* According to the ARM ARM, the PC is 2 or 4 bytes ahead
>> + ? ? ? ?* depending on Thumb mode. ?Correct this offset so that
>> + ? ? ? ?* regs->ARM_pc points at the faulting instruction.
>> ? ? ? ? */
>> ? ? ? ?regs->ARM_pc -= correction;
>>
>> diff --git a/arch/arm/vfp/entry.S b/arch/arm/vfp/entry.S
>> index 4fa9903..2bf6089 100644
>> --- a/arch/arm/vfp/entry.S
>> +++ b/arch/arm/vfp/entry.S
>> @@ -19,6 +19,15 @@
>> ?#include <asm/vfpmacros.h>
>> ?#include "../kernel/entry-header.S"
>>
>> +@ VFP entry point.
>> +@
>> +@ ?r0 ?= instruction opcode (32-bit ARM or two 16-bit Thumb)
>> +@ ?r2 ?= PC value to resume execution after successful emulation
>> +@ ?r9 ?= normal "successful" return address
>> +@ ?r10 = this threads thread_info structure
>> +@ ?lr ?= unrecognised instruction return address
>> +@ ?IRQs disabled.
>> +@
>> ?ENTRY(do_vfp)
>> ?#ifdef CONFIG_PREEMPT
>> ? ? ? ?ldr ? ? r4, [r10, #TI_PREEMPT] ?@ get preempt count
>> diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
>> index 9897dcf..7292921 100644
>> --- a/arch/arm/vfp/vfphw.S
>> +++ b/arch/arm/vfp/vfphw.S
>> @@ -61,13 +61,13 @@
>>
>> ?@ VFP hardware support entry point.
>> ?@
>> -@ ?r0 ?= faulted instruction
>> -@ ?r2 ?= faulted PC+4
>> -@ ?r9 ?= successful return
>> +@ ?r0 ?= instruction opcode (32-bit ARM or two 16-bit Thumb)
>> +@ ?r2 ?= PC value to resume execution after successful emulation
>> +@ ?r9 ?= normal "successful" return address
>> ?@ ?r10 = vfp_state union
>> ?@ ?r11 = CPU number
>> -@ ?lr ?= failure return
>> -
>> +@ ?lr ?= unrecognised instruction return address
>> +@ ?IRQs enabled.
>> ?ENTRY(vfp_support_entry)
>> ? ? ? ?DBGSTR3 "instr %08x pc %08x state %p", r0, r2, r10
>
> I tested copying r2 to regs->ARM_pc like this patch does, and it fixes
> my test case. ?Could this second patch go first so it can be applied
> to stable?
>
Also, both patches together Tested-by: Colin Cross <ccross@android.com>
^ permalink raw reply
* [GIT PULL] omap-fixes and minor board updates
From: Tony Lindgren @ 2011-01-14 19:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
Please pull omap fixes and some minor board updates from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus
This is mostly to deal with the build and boot issues after merging
with the arm and usb trees. The series also fixes some sparse issues.
It would be nice to get these in before -rc1.
Regards,
Tony
The following changes since commit 891cc2283216bf76f387546f0e220caf8ce9fbf9:
Merge branch 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel (2011-01-14 10:30:09 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus
Aaro Koskinen (1):
arm: mach-omap2: mux: fix buffer overrun
Anand Gadiyar (1):
arm: omap4: pandaboard: turn on PHY reference clock at init
Catalin Marinas (1):
ARM: Do not enable SWP emulation if CPU_V6 && CPU_V7
Enric Balletbo i Serra (4):
omap3: igep3: Add USB EHCI support for IGEP module
omap3: igep3: Fix IGEP module second MMC channel power supply
omap3: igep2: Add keypad support
omap3: igep3: Add omap_reserve functionality
Felipe Balbi (1):
arm: omap: gpio: don't access irq_desc array directly
Koen Kooi (3):
omap3: beaglexm: fix EHCI power up GPIO dir
omap3: beaglexm: fix DVI reset GPIO
omap3: beaglexm: fix power on of DVI
Mika Westerberg (1):
OMAP: GPIO: fix _set_gpio_triggering() for OMAP2+
Nishanth Menon (8):
omap3|4: mux: make local structures static
omap3: zoom: use static for pointer passing
omap3: igep3: make igep3_flash_init static
omap2+: wdt: trivial sparse fixes
OMAP3+: sr_device: include pm header
OMAP2+: TWL: make conversion routines static
OMAP2+: TWL: include pm header for init protos
omap2+: pm_bus: make functions used as pointers as static
Santosh Shilimkar (6):
omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask
omap2plus: voltage: Trivial warning fix 'no return statement'
omap2plus: voltage: Trivial linking fix 'undefined reference'
omap2plus: voltage: Trivial linking fix for 'EINVAL' undeclared
omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg'
omap3: clocks: Fix build error 'CK_3430ES2' undeclared here
Tony Lindgren (2):
Merge branch 'ehci-omap-clock' into omap-fixes
omap4: Fix ULPI PHY init for ES1.0 SDP
arch/arm/mach-omap2/board-4430sdp.c | 10 ++-
arch/arm/mach-omap2/board-igep0020.c | 33 ++++++++++
arch/arm/mach-omap2/board-igep0030.c | 85 ++++++++++++++++++++++----
arch/arm/mach-omap2/board-omap3beagle.c | 60 ++++++++++++++++--
arch/arm/mach-omap2/board-omap4panda.c | 10 +++
arch/arm/mach-omap2/board-zoom-peripherals.c | 4 +-
arch/arm/mach-omap2/clock3xxx_data.c | 2 +-
arch/arm/mach-omap2/clockdomain.h | 2 -
arch/arm/mach-omap2/devices.c | 2 +-
arch/arm/mach-omap2/mux.c | 2 +-
arch/arm/mach-omap2/mux34xx.c | 4 +-
arch/arm/mach-omap2/mux44xx.c | 6 +-
arch/arm/mach-omap2/omap_twl.c | 10 ++-
arch/arm/mach-omap2/pm_bus.c | 4 +-
arch/arm/mach-omap2/prm2xxx_3xxx.h | 63 +++++++++++++++++++-
arch/arm/mach-omap2/sr_device.c | 1 +
arch/arm/mach-omap2/wd_timer.c | 2 +
arch/arm/mm/Kconfig | 2 +-
arch/arm/plat-omap/gpio.c | 12 +++-
arch/arm/plat-omap/include/plat/voltage.h | 17 ++++-
20 files changed, 280 insertions(+), 51 deletions(-)
^ permalink raw reply
* [PATCH] Introduce VPR200 board.
From: Sascha Hauer @ 2011-01-14 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=KbD2FWnW2U7EG0gO8q2knVGL4uo0orbjf7y8c@mail.gmail.com>
On Fri, Jan 14, 2011 at 12:59:51PM -0200, Fabio Estevam wrote:
> Hi Marc,
>
> On Thu, Jan 13, 2011 at 9:48 PM, Marc Reilly <marc@cpdesign.com.au> wrote:
> ....
> >
> > +config MACH_VPR200
> > + ? ? ? bool "Support VPR200 platform"
> > + ? ? ? select SOC_IMX35
> > + ? ? ? select IMX_HAVE_PLATFORM_FSL_USB2_UDC
> > + ? ? ? select IMX_HAVE_PLATFORM_IMX2_WDT
> > + ? ? ? select IMX_HAVE_PLATFORM_IMX_UART
> > + ? ? ? select IMX_HAVE_PLATFORM_IMX_I2C
> > + ? ? ? select IMX_HAVE_PLATFORM_MXC_EHCI
> > + ? ? ? select IMX_HAVE_PLATFORM_MXC_NAND
>
> NAND seems to be unused on you board currently.
>
> > + ? ? ? select IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
> > + ? ? ? select IMX_HAVE_PLATFORM_MXC_PWM
>
> PWM seems to be unused on you board currently.
>
> I think you also need:
> select MXC_ULPI if USB_ULPI
Nope, ulpi is unused on this board.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH] ARM: vfp: Fix up exception location in Thumb mode
From: Colin Cross @ 2011-01-14 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114184759.GN15996@n2100.arm.linux.org.uk>
On Fri, Jan 14, 2011 at 10:47 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> So... this incrementally on top of the previous patch (which I've
> reproduced below as there's a subtle comment change in there wrt IRQ
> state.)
>
> This means we have consistent state - both r2 and regs->ARM_pc always
> point to the next instruction to be executed in every case, which means
> its easy to understand and remember while reading through the code.
>
> diff -u b/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> --- b/arch/arm/kernel/entry-armv.S
> +++ b/arch/arm/kernel/entry-armv.S
> @@ -499,10 +499,11 @@
> ? ? ? ?blo ? ? __und_usr_unknown
> ?3: ? ? ldrht ? r0, [r4]
> ? ? ? ?add ? ? r2, r2, #2 ? ? ? ? ? ? ? ? ? ? ?@ r2 is PC + 2, make it PC + 4
> - ? ? ? orr ? ? r0, r0, r5, lsl #16
> + ? ? ? str ? ? r2, [sp, #S_PC] ? ? ? ? ? ? ? ? @ it's a 2x16bit instr, update
> + ? ? ? orr ? ? r0, r0, r5, lsl #16 ? ? ? ? ? ? @ ?regs->ARM_pc
> ? ? ? ?@
> ? ? ? ?@ r0 = the two 16-bit Thumb instructions which caused the exception
> - ? ? ? @ r2 = PC value for the following Thumb instruction (:= regs->ARM_pc+2)
> + ? ? ? @ r2 = PC value for the following Thumb instruction (:= regs->ARM_pc)
> ? ? ? ?@ r4 = PC value for the first 16-bit Thumb instruction
> ? ? ? ?@
> ?#else
>
> 8<-x-x-
>
> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> index 2b46fea..5876eec 100644
> --- a/arch/arm/kernel/entry-armv.S
> +++ b/arch/arm/kernel/entry-armv.S
> @@ -461,27 +461,35 @@ ENDPROC(__irq_usr)
> ? ? ? ?.align ?5
> ?__und_usr:
> ? ? ? ?usr_entry
> -
> - ? ? ? @
> - ? ? ? @ fall through to the emulation code, which returns using r9 if
> - ? ? ? @ it has emulated the instruction, or the more conventional lr
> - ? ? ? @ if we are to treat this as a real undefined instruction
> ? ? ? ?@
> - ? ? ? @ ?r0 - instruction
> + ? ? ? @ The emulation code returns using r9 if it has emulated the
> + ? ? ? @ instruction, or the more conventional lr if we are to treat
> + ? ? ? @ this as a real undefined instruction
> ? ? ? ?@
> ? ? ? ?adr ? ? r9, BSYM(ret_from_exception)
> ? ? ? ?adr ? ? lr, BSYM(__und_usr_unknown)
> + ? ? ? @
> + ? ? ? @ r2 = regs->ARM_pc, which is either 2 or 4 bytes ahead of the
> + ? ? ? @ faulting instruction depending on Thumb mode.
> + ? ? ? @ r3 = regs->ARM_cpsr
> + ? ? ? @
> ? ? ? ?tst ? ? r3, #PSR_T_BIT ? ? ? ? ? ? ? ? ?@ Thumb mode?
> - ? ? ? itet ? ?eq ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?@ explicit IT needed for the 1f label
> + ? ? ? itttt ? eq ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?@ explicit IT needed for the 1f label
> ? ? ? ?subeq ? r4, r2, #4 ? ? ? ? ? ? ? ? ? ? ?@ ARM instr at LR - 4
> - ? ? ? subne ? r4, r2, #2 ? ? ? ? ? ? ? ? ? ? ?@ Thumb instr at LR - 2
> ?1: ? ? ldreqt ?r0, [r4]
> ?#ifdef CONFIG_CPU_ENDIAN_BE8
> ? ? ? ?reveq ? r0, r0 ? ? ? ? ? ? ? ? ? ? ? ? ?@ little endian instruction
> ?#endif
> + ? ? ? @
> + ? ? ? @ r0 = 32-bit ARM instruction which caused the exception
> + ? ? ? @ r2 = PC value for the following instruction (:= regs->ARM_pc)
> + ? ? ? @ r4 = PC value for the faulting instruction
> + ? ? ? @
> ? ? ? ?beq ? ? call_fpe
> +
> ? ? ? ?@ Thumb instruction
> ?#if __LINUX_ARM_ARCH__ >= 7
> + ? ? ? sub ? ? r4, r2, #2 ? ? ? ? ? ? ? ? ? ? ?@ Thumb instr at LR - 2
> ?2:
> ?ARM( ?ldrht ? r5, [r4], #2 ? ?)
> ?THUMB( ? ? ? ?ldrht ? r5, [r4] ? ? ? ?)
> @@ -492,18 +500,19 @@ __und_usr:
> ?3: ? ? ldrht ? r0, [r4]
> ? ? ? ?add ? ? r2, r2, #2 ? ? ? ? ? ? ? ? ? ? ?@ r2 is PC + 2, make it PC + 4
> ? ? ? ?orr ? ? r0, r0, r5, lsl #16
> + ? ? ? @
> + ? ? ? @ r0 = the two 16-bit Thumb instructions which caused the exception
> + ? ? ? @ r2 = PC value for the following Thumb instruction (:= regs->ARM_pc+2)
> + ? ? ? @ r4 = PC value for the first 16-bit Thumb instruction
> + ? ? ? @
> ?#else
> ? ? ? ?b ? ? ? __und_usr_unknown
> ?#endif
> - UNWIND(.fnend ? ? ? ? )
> + UNWIND(.fnend)
> ?ENDPROC(__und_usr)
>
> - ? ? ? @
> - ? ? ? @ fallthrough to call_fpe
> - ? ? ? @
> -
> ?/*
> - * The out of line fixup for the ldrt above.
> + * The out of line fixup for the ldrt instructions above.
> ?*/
> ? ? ? ?.pushsection .fixup, "ax"
> ?4: ? ? mov ? ? pc, r9
> @@ -534,11 +543,12 @@ ENDPROC(__und_usr)
> ?* NEON handler code.
> ?*
> ?* Emulators may wish to make use of the following registers:
> - * ?r0 ?= instruction opcode.
> - * ?r2 ?= PC+4
> + * ?r0 ?= instruction opcode (32-bit ARM or two 16-bit Thumb)
> + * ?r2 ?= PC value to resume execution after successful emulation
> ?* ?r9 ?= normal "successful" return address
> - * ?r10 = this threads thread_info structure.
> + * ?r10 = this threads thread_info structure
> ?* ?lr ?= unrecognised instruction return address
> + * IRQs disabled, FIQs enabled.
> ?*/
> ? ? ? ?@
> ? ? ? ?@ Fall-through from Thumb-2 __und_usr
> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> index ee57640..eeb9250 100644
> --- a/arch/arm/kernel/traps.c
> +++ b/arch/arm/kernel/traps.c
> @@ -347,9 +347,9 @@ asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
> ? ? ? ?void __user *pc;
>
> ? ? ? ?/*
> - ? ? ? ?* According to the ARM ARM, PC is 2 or 4 bytes ahead,
> - ? ? ? ?* depending whether we're in Thumb mode or not.
> - ? ? ? ?* Correct this offset.
> + ? ? ? ?* According to the ARM ARM, the PC is 2 or 4 bytes ahead
> + ? ? ? ?* depending on Thumb mode. ?Correct this offset so that
> + ? ? ? ?* regs->ARM_pc points at the faulting instruction.
> ? ? ? ? */
> ? ? ? ?regs->ARM_pc -= correction;
>
> diff --git a/arch/arm/vfp/entry.S b/arch/arm/vfp/entry.S
> index 4fa9903..2bf6089 100644
> --- a/arch/arm/vfp/entry.S
> +++ b/arch/arm/vfp/entry.S
> @@ -19,6 +19,15 @@
> ?#include <asm/vfpmacros.h>
> ?#include "../kernel/entry-header.S"
>
> +@ VFP entry point.
> +@
> +@ ?r0 ?= instruction opcode (32-bit ARM or two 16-bit Thumb)
> +@ ?r2 ?= PC value to resume execution after successful emulation
> +@ ?r9 ?= normal "successful" return address
> +@ ?r10 = this threads thread_info structure
> +@ ?lr ?= unrecognised instruction return address
> +@ ?IRQs disabled.
> +@
> ?ENTRY(do_vfp)
> ?#ifdef CONFIG_PREEMPT
> ? ? ? ?ldr ? ? r4, [r10, #TI_PREEMPT] ?@ get preempt count
> diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
> index 9897dcf..7292921 100644
> --- a/arch/arm/vfp/vfphw.S
> +++ b/arch/arm/vfp/vfphw.S
> @@ -61,13 +61,13 @@
>
> ?@ VFP hardware support entry point.
> ?@
> -@ ?r0 ?= faulted instruction
> -@ ?r2 ?= faulted PC+4
> -@ ?r9 ?= successful return
> +@ ?r0 ?= instruction opcode (32-bit ARM or two 16-bit Thumb)
> +@ ?r2 ?= PC value to resume execution after successful emulation
> +@ ?r9 ?= normal "successful" return address
> ?@ ?r10 = vfp_state union
> ?@ ?r11 = CPU number
> -@ ?lr ?= failure return
> -
> +@ ?lr ?= unrecognised instruction return address
> +@ ?IRQs enabled.
> ?ENTRY(vfp_support_entry)
> ? ? ? ?DBGSTR3 "instr %08x pc %08x state %p", r0, r2, r10
I tested copying r2 to regs->ARM_pc like this patch does, and it fixes
my test case. Could this second patch go first so it can be applied
to stable?
^ permalink raw reply
* [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
From: Paul Walmsley @ 2011-01-14 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110113164957.GA28040@n2100.arm.linux.org.uk>
On Thu, 13 Jan 2011, Russell King - ARM Linux wrote:
> On Thu, Jan 13, 2011 at 07:51:53AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110113 01:15]:
> > > Given the very sorry state of OMAP in mainline at present, I'm surprised
> > > that this kind of stuff is still going on...
> >
> > At least I boot test the patches I send..
>
> Which is why OMAP3 and OMAP4 can't be built in mainline because they
> spit out lots of compile errors in the OMAP code... As they won't
> even compile they couldn't have been boot tested.
Current mainline != the patches that Tony sent to Linus[1].
The patches that Tony sent to Linus, which Linus merged, build fine
with omap2plus_defconfig[2].
- Paul
1. Lindgren, Tony. _[GIT PULL] omap changes for v2.6.38_.
Posted to the linux-kernel mailing list on 6 January 2011.
http://www.gossamer-threads.com/lists/linux/kernel/1324357 (among
others)
2. Compilation log of the patches that Tony submitted for the 2.6.38 merge
window (included below)
---
$ git log mainline/master --pretty=oneline | fgrep omap-for-linus |head -1
01539ba2a706ab7d35fc0667dff919ade7f87d63 Merge branch 'omap-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6
$ git show 01539ba2a706ab7d35fc0667dff919ade7f87d63 |head -5
commit 01539ba2a706ab7d35fc0667dff919ade7f87d63
Merge: 9e9bc97 dc69d1a
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu Jan 6 19:13:58 2011 -0800
$ git checkout dc69d1a
HEAD is now at dc69d1a... omap2: Make OMAP2PLUS select OMAP_DM_TIMER
$ make mrproper
$ make omap2plus_defconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/docproc
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/kxgettext.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/lex.zconf.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
#
# configuration written to .config
#
$ make -j2
scripts/kconfig/conf --silentoldconfig Kconfig
CHK include/linux/version.h
UPD include/linux/version.h
CHK include/generated/utsrelease.h
UPD include/generated/utsrelease.h
HOSTCC scripts/genksyms/genksyms.o
Generating include/generated/mach-types.h
CC kernel/bounds.s
GEN include/generated/bounds.h
CC arch/arm/kernel/asm-offsets.s
SHIPPED scripts/genksyms/lex.c
SHIPPED scripts/genksyms/parse.h
SHIPPED scripts/genksyms/keywords.c
SHIPPED scripts/genksyms/parse.c
HOSTCC scripts/genksyms/lex.o
GEN include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
HOSTCC scripts/genksyms/parse.o
CC scripts/mod/empty.o
HOSTCC scripts/mod/mk_elfconfig
MKELF scripts/mod/elfconfig.h
HOSTCC scripts/mod/file2alias.o
HOSTLD scripts/genksyms/genksyms
HOSTCC scripts/kallsyms
HOSTCC scripts/pnmtologo
HOSTCC scripts/mod/modpost.o
HOSTCC scripts/conmakehash
HOSTCC scripts/bin2c
HOSTCC scripts/mod/sumversion.o
HOSTLD scripts/mod/modpost
CC init/main.o
HOSTCC usr/gen_init_cpio
GEN usr/initramfs_data.cpio
AS usr/initramfs_data.o
LD usr/built-in.o
CC arch/arm/nwfpe/fpa11.o
CC arch/arm/nwfpe/fpa11_cpdo.o
CC arch/arm/nwfpe/fpa11_cpdt.o
CC arch/arm/nwfpe/fpa11_cprt.o
CC arch/arm/nwfpe/fpmodule.o
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/do_mounts.o
CC arch/arm/nwfpe/fpopcode.o
CC arch/arm/nwfpe/softfloat.o
CC init/do_mounts_rd.o
CC arch/arm/nwfpe/single_cpdo.o
CC init/do_mounts_initrd.o
CC arch/arm/nwfpe/double_cpdo.o
AS arch/arm/nwfpe/entry.o
LD arch/arm/nwfpe/nwfpe.o
LD arch/arm/nwfpe/built-in.o
CC init/initramfs.o
CC init/calibrate.o
CC init/version.o
LD init/mounts.o
CC arch/arm/vfp/vfpmodule.o
LD init/built-in.o
CC arch/arm/kernel/elf.o
AS arch/arm/vfp/entry.o
AS arch/arm/vfp/vfphw.o
CC arch/arm/vfp/vfpsingle.o
AS arch/arm/kernel/entry-armv.o
AS arch/arm/kernel/entry-common.o
CC arch/arm/kernel/irq.o
CC arch/arm/vfp/vfpdouble.o
CC arch/arm/kernel/process.o
LD arch/arm/vfp/vfp.o
LD arch/arm/vfp/built-in.o
CC arch/arm/mm/dma-mapping.o
CC arch/arm/kernel/ptrace.o
CC arch/arm/mm/extable.o
CC arch/arm/mm/fault.o
CC arch/arm/kernel/return_address.o
arch/arm/kernel/return_address.c:61:2: warning: #warning "TODO: return_address should use unwind tables"
arch/arm/kernel/return_address.c:61:2: warning: #warning "TODO: return_address should use unwind tables"
CC arch/arm/kernel/setup.o
CC arch/arm/mm/init.o
CC arch/arm/mm/iomap.o
CC arch/arm/kernel/signal.o
CC arch/arm/mm/fault-armv.o
CC arch/arm/kernel/sys_arm.o
CC arch/arm/mm/flush.o
CC arch/arm/kernel/stacktrace.o
CC arch/arm/mm/ioremap.o
CC arch/arm/kernel/time.o
CC arch/arm/mm/mmap.o
CC arch/arm/kernel/traps.o
CC arch/arm/mm/pgd.o
CC arch/arm/mm/mmu.o
CC arch/arm/kernel/leds.o
CC arch/arm/kernel/armksyms.o
CC arch/arm/mm/vmregion.o
CC arch/arm/mm/proc-syms.o
CC arch/arm/kernel/module.o
CC arch/arm/mm/alignment.o
CC arch/arm/kernel/smp.o
AS arch/arm/mm/abort-ev6.o
AS arch/arm/mm/abort-ev7.o
AS arch/arm/mm/pabort-v6.o
AS arch/arm/mm/pabort-v7.o
AS arch/arm/mm/cache-v6.o
AS arch/arm/mm/cache-v7.o
CC arch/arm/mm/copypage-v6.o
CC arch/arm/mm/context.o
CC a2/powerdomains44xx_data.o
CC arch/arm/mach-omap2/clockdomain.o
CC arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.o
CC arch/arm/mach-omap2/clockdomains44xx_data.o
CC arch/arm/mach-omap2/clock.o
CC arch/arm/mach-omap2/clock_common_data.o
CC arch/arm/mach-omap2/clkt_dpll.o
CC kernel/exec_domain.o
CC arch/arm/mach-omap2/clkt_clksel.o
CC arch/arm/mach-omap2/clock2xxx.o
CC arch/arm/mach-omap2/clkt2xxx_sys.o
CC arch/arm/mach-omap2/clkt2xxx_dpllcore.o
CC kernel/panic.o
CC arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.o
CC arch/arm/mach-omap2/clkt2xxx_apll.o
CC arch/arm/mach-omap2/clkt2xxx_osc.o
CC kernel/printk.o
CC arch/arm/mach-omap2/clock2420_data.o
CC arch/arm/mach-omap2/clock2430.o
CC arch/arm/mach-omch/arm/mach-omap2/usb-musb.o
CC arch/arm/mach-omap2/usb-tusb6010.o
CC kernel/nsproxy.o
CC arch/arm/mach-omap2/usb-ehci.o
CC kernel/srcu.o
CC arch/arm/mach-omap2/gpmc-onenand.o
CC kernel/semaphore.o
CC arch/arm/mach-omap2/gpmc-nand.o
CC arch/arm/mach-omap2/gpmc-smc91x.o
CC kernel/notifier.o
CC arch/arm/mach-omap2/gpmc-smsc911x.o
CC kernel/ksysfs.o
LD arch/arm/mach-omap2/built-in.o
CC kernel/pm_qos_params.o
CC mm/bootmem.o
CC kernel/sched_clock.o
CC mm/filemap.o
CC kernel/cred.o
CC kernel/async.o
CC kernel/range.o
CC kernel/jump_label.o
CC mm/mempool.o
CC kernel/groups.o
CC mm/oom_kill.o
CC kernel/freezer.o
CC kernel/profile.o
CC mm/fadvise.o
CC mm/maccess.o
CC kernel/stacktrace.o
CC mm/page_alloc.o
CC kernel/irq/irqdesc.o
CC kernel/irq/handle.o
CC kernel/irq/manage.o
CC kernel/irq/spurious.o
CC kernel/irq/resend.o
CC mm/page-writeback.o
CC kernel/irq/chip.o
CC kernel/irq/dummychip.o
CC kernel/irq/devres.o
CC kernel/irq/autoprobe.o
CC mm/readahead.o
CC kernel/irq/proc.o
CC kernel/irq/pm.o
LD kernel/irq/built-in.o
CC kernel/power/main.o
CC mm/swap.o
CC kernel/power/console.o
CC kernel/power/process.o
CC mm/truncate.o
CC kernel/power/suspend.o
CC mm/vmscan.o
CC kernel/power/nvs.o
CC kernel/power/poweroff.o
LD kernel/power/built-in.o
CC kernel/time/timekeeping.o
CC kernel/time/ntp.o
CC kernel/time/clocksource.o
CC mm/shmem.o
CC kernel/time/jiffies.o
CC kernel/time/timer_list.o
CC kernel/time/timecompare.o
CC kernel/time/timeconv.o
CC kernel/time/clockevents.o
CC mm/prio_tree.o
CC mm/util.o
CC kernel/time/tick-common.o
CC kernel/time/tick-broadcast.o
CC mm/mmzone.o
CC kernel/time/tick-oneshot.o
CC mm/vmstat.o
CC kernel/time/tick-sched.o
CC kernel/time/timer_stats.o
CC mm/backing-dev.o
LD kernel/time/built-in.o
CC kernel/trace/trace_clock.o
CC kernel/trace/ring_buffer.o
CC mm/page_isolation.o
CC mm/mm_init.o
CC mm/mmu_context.o
CC mm/percpu.o
CC kernel/trace/trace.o
CC mm/fremap.o
CC mm/highmem.o
CC mm/madvise.o
CC mm/memory.o
CC kernel/trace/trace_output.o
CC kernel/trace/trace_stat.o
CC mm/mincore.o
CC kernel/trace/trace_printk.o
CC mm/mlock.o
CC kernel/trace/trace_sched_switch.o
CC mm/mmap.o
CC kernel/trace/trace_nop.o
CC kernel/trace/blktrace.o
CC mm/mprotect.o
CC kernel/trace/trace_events.o
CC mm/mremap.o
CC mm/msync.o
CC kernel/trace/trace_export.o
CC mm/rmap.o
CC kernel/trace/trace_event_perf.o
CC kernel/trace/trace_events_filter.o
CC mm/vmalloc.o
CC kernel/trace/trace_kprobe.o
CC mm/pagewalk.o
CC mm/init-mm.o
CC mm/memblock.o
CC kernel/trace/power-traces.o
CC mm/page_io.o
CC mm/swap_state.o
LD kernel/trace/built-in.o
CC kernel/mutex-debug.o
CC mm/swapfile.o
CC kernel/lockdep.o
CC mm/thrash.o
CC mm/dmapool.o
CC mm/slab.o
CC kernel/lockdep_proc.o
CC kernel/futex.o
CC kernel/rtmutex.o
LD mm/built-in.o
CC fs/open.o
CC kernel/smp.o
CC kernel/spinlock.o
CC kernel/uid16.o
CC fs/read_write.o
CC kernel/module.o
CC fs/file_table.o
CC fs/super.o
CC kernel/kallsyms.o
CC fs/char_dev.o
CC kernel/acct.o
CC fs/stat.o
CC kernel/kexec.o
CC fs/exec.o
GZIP kernel/config_data.gz
CC kernel/stop_machine.o
CC kernel/kprobes.o
CC fs/pipe.o
CC kernel/rcutree.o
CC fs/namei.o
CC kernel/utsname_sysctl.o
CC kernel/tracepoint.o
CC kernel/elfcore.o
CC kernel/sched_cpupri.o
CC kernel/irq_work.o
CC fs/fcntl.o
CC kernel/perf_event.o
CC fs/ioctl.o
CC fs/readdir.o
CC fs/select.o
CC fs/fifo.o
CC kernel/hw_breakpoint.o
CC fs/dcache.o
CC kernel/time.o
IKCFG kernel/config_data.h
CC kernel/configs.o
CC fs/inode.o
LD kernel/built-in.o
CC ipc/util.o
CC ipc/msgutil.o
CC fs/attr.o
CC ipc/msg.o
CC fs/bad_inode.o
CC ipc/sem.o
CC fs/file.o
CC fs/filesystems.o
CC ipc/shm.o
CC fs/namespace.o
CC ipc/ipcns_notifier.o
CC ipc/syscall.o
CC ipc/ipc_sysctl.o
CC ipc/mqueue.o
CC fs/seq_file.o
CC ipc/mq_sysctl.o
CC fs/xattr.o
LD ipc/built-in.o
CC fs/libfs.o
CC fs/fs-writeback.o
CC security/keys/gc.o
CC security/keys/key.o
CC security/keys/keyring.o
CC fs/pnode.o
CC fs/drop_caches.o
CC fs/splice.o
CC security/keys/keyctl.o
CC security/keys/permission.o
CC fs/sync.o
CC security/keys/process_keys.o
CC fs/utimes.o
CC security/keys/request_key.o
CC fs/stack.o
CC security/keys/request_key_auth.o
CC fs/fs_struct.o
CC security/keys/user_defined.o
CC fs/statfs.o
rs/mtd/onenand/built-in.o
LD drivers/mtd/tests/built-in.o
CC drivers/mtd/ubi/vtbl.o
CC drivers/mtd/ubi/vmt.o
CC fs/ubifs/sb.o
CC drivers/mtd/ubi/upd.o
CC drivers/mtd/ubi/build.o
CC fs/ubifs/io.o
CC drivers/mtd/ubi/cdev.o
CC fs/ubifs/tnc.o
CC drivers/mtd/ubi/kapi.o
CC drivers/mtd/ubi/eba.o
CC fs/ubifs/master.o
CC fs/ubifs/scan.o
CC drivers/mtd/ubi/io.o
CC fs/ubifs/replay.o
CC drivers/mtd/ubi/wl.o
CC fs/ubifs/log.o
CC drivers/mtd/ubi/scan.o
CC fs/ubifs/commit.o
CC fs/ubifs/gc.o
CC drivers/mtd/ubi/misc.o
LD drivers/mtd/ubi/ubi.o
LD drivers/mtd/ubi/built-in.o
LD drivers/mtd/mtd.o
LD drivers/mtd/built-in.o
CC drivers/net/mii.o
CC fs/ubifs/orphan.o
CC fs/ubifs/budget.o
LD drivers/net/arm/built-in.o
CC drivers/net/phy/phy.o
CC fs/ubifs/find.o
CC drivers/net/phy/phy_device.o
CC fs/ubifs/tnc_commit.o
CC fs/ubifs/compress.o
CC drivers/net/phy/mdio_bus.o
CC fs/ubifs/lpt.o
CC drivers/net/phy/smsc.o
LD drivers/net/phy/libphy.o
LD drivers/net/phy/built-in.o
CC drivers/net/usb/asix.o
CC fs/ubifs/lprops.o
CC fs/ubifs/recovery.o
CC drivers/net/usb/cdc_ether.o
CC drivers/net/usb/net1080.o
CC fs/ubifs/ioctl.o
CC fs/ubifs/lpt_commit.o
CC drivers/net/usb/cdc_subset.o
CC drivers/net/usb/zaurus.o
CC fs/ubifs/tnc_misc.o
CC drivers/net/usb/usbnet.o
LD fs/ubifs/ubifs.o
LD fs/ubifs/built-in.o
CC fs/eventpoll.o
CC fs/anon_inodes.o
LD drivers/net/usb/built-in.o
CC fs/signalfd.o
LD drivers/net/wireless/built-in.o
LD drivers/net/wireless/libertas/built-in.o
CC [M] drivers/net/wireless/libertas/cfg.o
CC fs/timerfd.o
CC fs/eventfd.o
CC [M] drivers/net/wireless/libertas/cmd.o
CC fs/aio.o
CC fs/locks.o
CC [M] drivers/net/wireless/libertas/cmdresp.o
CC [M] drivers/net/wireless/libertas/debugfs.o
CC fs/binfmt_misc.o
CC [M] drivers/net/wireless/libertas/ethtool.o
CC fs/binfmt_script.o
CC fs/binfmt_elf.o
CC [M] drivers/net/wireless/libertas/main.o
CC fs/posix_acl.o
CC [M] drivers/net/wireless/libertas/rx.o
CC fs/xattr_acl.o
CC fs/dcookies.o
CC [M] drivers/net/wireless/libertas/tx.o
LD fs/built-in.o
CC [M] drivers/net/wireless/libertas/if_sdio.o
LD drivers/platform/built-in.o
CC drivers/power/power_supply_core.o
CC drivers/power/power_supply_sysfs.o
LD drivers/power/power_supply.o
LD drivers/power/built-in.o
CC [M] drivers/net/wireless/libertas/if_usb.o
LD sound/built-in.o
CC [M] sound/sound_core.o
LD sound/arm/built-in.o
LD sound/atmel/built-in.o
LD sound/core/oss/built-in.o
CC [M] sound/core/oss/mixer_oss.o
LD [M] drivers/net/wireless/libertas/libertas.o
LD [M] drivers/net/wireless/libertas/usb8xxx.o
LD [M] drivers/net/wireless/libertas/libertas_sdio.o
CC drivers/net/ks8851.o
CC [M] sound/core/oss/pcm_oss.o
CC drivers/net/ks8851_mll.o
CC drivers/net/Space.o
CC drivers/net/loopback.o
CC [M] sound/core/oss/pcm_plugin.o
CC drivers/net/smc91x.o
CC [M] sound/core/oss/io.o
CC [M] sound/core/oss/copy.o
CC [M] sound/core/oss/linear.o
CC drivers/net/smsc911x.o
CC [M] sound/core/oss/mulaw.o
CC [M] sound/core/oss/route.o
CC [M] sound/core/oss/rate.o
LD [M] sound/core/oss/snd-mixer-oss.o
LD [M] sound/core/oss/snd-pcm-oss.o
CC [M] sound/core/hwdep.o
LD drivers/net/built-in.o
CC drivers/regulator/core.o
CC [M] sound/core/memalloc.o
CC [M] sound/core/pcm.o
CC drivers/regulator/dummy.o
CC drivers/regulator/fixed.o
CC [M] sound/core/pcm_native.o
CC drivers/regulator/twl-regulator.o
CC drivers/regulator/tps65023-regulator.o
CC drivers/regulator/tps6507x-regulator.ooc/blackfin/built-in.o
LD sound/soc/codecs/built-in.o
CC [M] sound/soc/codecs/twl4030.o
LD [M] sound/soc/codecs/snd-soc-twl4030.o
LD sound/soc/davinci/built-in.o
LD sound/soc/ep93xx/built-in.o
LD sound/soc/fsl/built-in.o
LD sound/soc/imx/built-in.o
LD sound/soc/jz4740/built-in.o
LD sound/soc/kirkwood/built-in.o
LD sound/soc/nuc900/built-in.o
LD sound/soc/omap/built-in.o
CC [M] sound/soc/omap/omap-mcbsp.o
CC drivers/serial/8250_early.o
CC drivers/serial/omap-serial.o
CC [M] sound/soc/omap/omap-pcm.o
CC [M] sound/soc/omap/omap3pandora.o
LD drivers/serial/built-in.o
CC drivers/spi/spi.o
CC drivers/spi/omap2_mcspi.o
LD [M] sound/soc/omap/snd-soc-omap.o
LD [M] sound/soc/omap/snd-soc-omap-mcbsp.o
LD [M] sound/soc/omap/snd-soc-omap3pandora.o
LD sound/soc/pxa/built-in.o
LD sound/soc/s3c24xx/built-in.o
LD sound/soc/s6000/built-in.o
LD sound/soc/sh/built-in.o
LD sound/soc/txx9/built-in.o
LD [M] sound/soc/snd-soc-core.o
LD sound/sparc/built-in.o
LD sound/spi/built-in.o
LD sound/synth/built-in.o
LD sound/usb/built-in.o
CC [M] sound/usb/card.o
LD drivers/video/logo/logo_superh_vga16.c
LOGO drivers/video/logo/logo_blackfin_clut224.c
LOGO drivers/video/logo/logo_dec_clut224.c
LOGO drivers/video/logo/logo_m32r_clut224.c
LOGO drivers/video/logo/logo_mac_clut224.c
LOGO drivers/video/logo/logo_parisc_clut224.c
LOGO drivers/video/logo/logo_sgi_clut224.c
LOGO drivers/video/logo/logo_spe_clut224.c
LOGO drivers/video/logo/logo_sun_clut224.c
LOGO drivers/video/logo/logo_superh_clut224.c
CC drivers/video/logo/logo_linux_mono.o
CC drivers/video/logo/logo_linux_vga16.o
CC drivers/video/logo/logo_linux_cock.o
CC net/ipv4/ip_input.o
CC lib/bitrev.o
CC lib/crc-ccitt.o
CC net/ipv4/ip_fragment.o
CC lib/crc16.o
CC lib/crc-t10dif.o
CC lib/crc-itu-t.o
HOSTCC lib/gen_crc32table
CC lib/crc7.o
CC net/ipv4/ip_forward.o
CC lib/libcrc32c.o
CC lib/lzo/lzo1x_compress.o
CC lib/lzo/lzo1x_decompress.o
CC net/ipv4/ip_options.o
LD lib/lzo/lzo_compress.o
LD lib/lzo/lzo_decompress.o
LD lib/lzo/built-in.o
CC lib/zlib_deflate/deflate.o
CC lib/zlib_deflate/deftree.o
CC net/ipv4/ip_output.o
CC lib/zlib_deflate/deflate_syms.o
LD lib/zlib_deflate/zlib_deflate.o
LD lib/zlib_deflate/built-in.o
CC lib/zlib_inflate/inffast.o
CC lib/zlib_inflate/inflate.o
CC lib/zlib_inflate/infutil.o
CC lib/zlib_inflate/inftrees.o
CC lib/zlib_inflate/inflate_syms.o
LD lib/zlib_inflate/zlib_inflate.o
LD lib/zlib_inflate/built-in.o
CC lib/percpu_counter.o
CC net/ipv4/ip_sockglue.o
CC lib/nlattr.o
CC lib/atomic64.o
CC lib/argv_split.o
CC net/ipv4/inet_hashtables.o
CC lib/cmdline.o
CC lib/cpumask.o
CC lib/ctype.o
CC lib/dec_and_lock.o
CC lib/decompress.o
CC lib/decompress_inflate.o
CC net/ipv4/inet_timewait_sock.o
CC lib/dump_stack.o
CC lib/extable.o
CC lib/flex_array.o
CC lib/idr.o
CC net/ipv4/inet_connection_sock.o
CC lib/int_sqrt.o
CC lib/ioremap.o
CC lib/irq_regs.o
CC lib/is_single_threaded.o
CC net/ipv4/tcp.o
CC lib/klist.o
CC lib/kobject.o
CC lib/kobject_uevent.o
CC lib/kref.o
CC net/ipv4/tcp_input.o
CC lib/plist.o
CC lib/prio_heap.o
CC lib/prio_tree.o
CC lib/proportions.o
CC lib/radix-tree.o
CC lib/ratelimit.o
CC lib/rbtree.o
CC lib/reciprocal_div.o
CC lib/rwsem-spinlock.o
CC lib/sha1.o
CC lib/show_mem.o
CC lib/string.o
CC net/ipv4/tcp_output.o
CC lib/vsprintf.o
GEN lib/crc32table.h
AR lib/lib.a
CC lib/crc32.o
CC net/ipv4/tcp_timer.o
LD lib/built-in.o
CC net/ipv4/tcp_ipv4.o
CC net/ipv4/tcp_minisocks.o
CC net/ipv4/tcp_cong.o
CC net/ipv4/datagram.o
CC net/key/af_key.o
CC net/ipv4/raw.o
CC net/ipv4/udp.o
LD net/key/built-in.o
CC net/ipv4/udplite.o
CC net/ipv4/arp.o
CC net/ipv4/icmp.o
CC net/ipv4/devinet.o
CC net/ipv4/af_inet.o
LD net/mac80211/built-in.o
CC [M] net/mac80211/main.o
CC net/ipv4/igmp.o
CC [M] net/mac80211/status.o
CC [M] net/mac80211/sta_info.o
CC [M] net/mac80211/wep.o
CC net/ipv4/fib_frontend.o
CC [M] net/mac80211/wpa.o
CC [M] net/mac80211/scan.o
CC net/ipv4/fib_semantics.o
CC net/ipv4/inet_fragment.o
CC [M] net/mac80211/offchannel.o
CC net/ipv4/sysctl_net_ipv4.o
CC [M] net/mac80211/ht.o
CC net/ipv4/fib_hash.o
CC [M] net/mac80211/agg-tx.o
CC net/ipv4/proc.o
CC net/ipv4/xfrm4_mode_beet.o
CC [M] net/mac80211/agg-rx.o
CC net/ipv4/xfrm4_mode_transport.o
CC [M] net/mac80211/ibss.o
CC net/ipv4/xfrm4_mode_tunnel.o
CC [M] net/mac80211/mlme.o
CC net/ipv4/ipconfig.o
CC [M] net/mac80211/work.o
CC net/ipv4/netfilter.o
CC [M] net/mac80211/iface.o
LD net/ipv4/netfilter/built-in.o
CC net/ipv4/inet_diag.o
CC [M] net/mac80211/rate.o
CC net/ipv4/tcp_diag.o
CC net/ipv4/tcp_cubic.o
CC [M] net/mac80211/michael.o
CC [M] net/mac80211/tkip.o
CC net/ipv4/xfrm4_policy.o
CC [M] net/mac80211/aes_ccm.o
CC net/ipv4/xfrm4_state.o
CC [M] net/mac80211/aes_cmac.o
CC net/ipv4/xfrm4_input.o
CC [M] net/mac80211/cfg.o
CC net/ipv4/xfrm4_output.o
CC [M] net/mac80211/rx.o
LD net/ipv4/built-in.o
CC [M] net/mac80211/spectmgmt.o
CC [M] net/mac80211/tx.o
CC net/netfilter/core.o
CC net/netfilter/nf_log.o
CC [M] net/mac80211/key.o
CC net/netfilter/nf_queue.o
CC [M] net/mac80211/util.o
CC net/netfilter/nf_sockopt.o
CC [M] net/mac80211/wme.o
LD net/netfilter/netfilter.o
LD net/netfilter/built-in.o
CC [M] net/mac80211/event.o
CC [M] net/mac80211/chan.o
CC [M] net/mac80211/pm.o
CC [M] net/mac80211/rc80211_pid_algo.o
CC [M] net/mac80211/rc80211_minstrel.o
CC [M] net/mac80211/rc80211_minstrel_ht.o
CC net/netlink/af_netlink.o
LD [M] net/mac80211/mac80211.o
CC net/packet/af_packet.o
CC net/netlink/genetlink.o
LD net/packet/built-in.o
CC net/sched/sch_generic.o
CC net/sched/sch_mq.o
LD net/netlink/built-in.o
CC net/sunrpc/clnt.o
LD net/sched/built-in.o
CC net/unix/af_unix.o
CC net/sunrpc/xprt.o
CC net/unix/garbage.o
CC net/unix/sysctl_net_unix.o
CC net/sunrpc/socklib.o
LD net/unix/unix.o
LD net/unix/built-in.o
CC net/sunrpc/xprtsock.o
CC net/sunrpc/sched.o
CC net/sunrpc/auth.o
CC net/sunrpc/auth_null.o
CC net/sunrpc/auth_unix.o
CC net/wireless/wext-core.o
CC net/sunrpc/auth_generic.o
CC net/wireless/wext-proc.o
CC net/sunrpc/svc.o
CC net/wireless/wext-spy.o
CC [M] net/wireless/core.o
CC net/sunrpc/svcsock.o
CC [M] net/wireless/sysfs.o
CC [M] net/wireless/radiotap.o
CC net/sunrpc/svcauth.o
CC [M] net/wireless/util.o
CC net/sunrpc/svcauth_unix.o
CC [M] net/wireless/reg.o
CC net/sunrpc/addr.o
CC net/sunrpc/rpcb_clnt.o
CC [M] net/wireless/scan.o
CC net/sunrpc/timer.o
CC [M] net/wireless/nl80211.o
CC net/sunrpc/xdr.o
CC net/sunrpc/sunrpc_syms.o
CC net/sunrpc/cache.o
CC net/sunrpc/rpc_pipe.o
CC [M] net/wireless/mlme.o
CC net/sunrpc/svc_xprt.o
CC [M] net/wireless/ibss.o
CC [M] net/wireless/sme.o
CC net/sunrpc/stats.o
CC [M] net/wireless/chan.o
CC net/sunrpc/sysctl.o
CC [M] net/wireless/ethtool.o
CC net/sunrpc/auth_gss/auth_gss.o
CC [M] net/wireless/wext-compat.o
CC net/sunrpc/auth_gss/gss_generic_token.o
CC [M] net/wireless/wext-sme.o
CC net/sunrpc/auth_gss/gss_mech_switch.o
CC [M] net/wireless/lib80211.o
CC net/sunrpc/auth_gss/svcauth_gss.o
LD net/wireless/built-in.o
LD [M] net/wireless/cfg80211.o
CC net/xfrm/xfrm_policy.o
CC net/sunrpc/auth_gss/gss_krb5_mech.o
CC net/sunrpc/auth_gss/gss_krb5_seal.o
CC net/sunrpc/auth_gss/gss_krb5_unseal.o
CC net/sunrpc/auth_gss/gss_krb5_seqnum.o
CC net/xfrm/xfrm_state.o
CC net/sunrpc/auth_gss/gss_krb5_wrap.o
CC net/sunrpc/auth_gss/gss_krb5_crypto.o
CC net/sunrpc/auth_gss/gss_krb5_keys.o
CC net/xfrm/xfrm_hash.o
LD net/sunrpc/auth_gss/auth_rpcgss.o
LD net/sunrpc/auth_gss/rpcsec_gss_krb5.o
LD net/sunrpc/auth_gss/built-in.o
LD net/sunrpc/sunrpc.o
LD net/sunrpc/built-in.o
CC net/sysctl_net.o
CC net/xfrm/xfrm_input.o
CC net/xfrm/xfrm_output.o
CC net/xfrm/xfrm_algo.o
CC net/xfrm/xfrm_sysctl.o
CC net/xfrm/xfrm_user.o
LD net/xfrm/built-in.o
LD net/built-in.o
LD vmlinux.o
MODPOST vmlinux.o
WARNING: modpost: Found 1 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
GEN .version
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
KSYM .tmp_kallsyms1.S
AS .tmp_kallsyms1.o
LD .tmp_vmlinux2
KSYM .tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD .tmp_vmlinux3
KSYM .tmp_kallsyms3.S
AS .tmp_kallsyms3.o
LD vmlinux
SYSMAP System.map
SYSMAP .tmp_System.map
OBJCOPY arch/arm/boot/Image
Kernel: arch/arm/boot/Image is ready
AS arch/arm/boot/compressed/head.o
Building modules, stage 2.
GZIP arch/arm/boot/compressed/piggy.gzip
MODPOST 36 modules
CC crypto/aes_generic.mod.o
CC crypto/arc4.mod.o
CC crypto/ecb.mod.o
CC drivers/bluetooth/bcm203x.mod.o
CC drivers/bluetooth/bpa10x.mod.o
CC drivers/bluetooth/hci_uart.mod.o
CC drivers/net/wireless/libertas/libertas.mod.o
CC drivers/net/wireless/libertas/libertas_sdio.mod.o
CC drivers/net/wireless/libertas/usb8xxx.mod.o
CC drivers/scsi/scsi_wait_scan.mod.o
CC drivers/usb/gadget/g_zero.mod.o
CC net/bluetooth/bluetooth.mod.o
CC net/bluetooth/bnep/bnep.mod.o
CC net/bluetooth/hidp/hidp.mod.o
CC arch/arm/boot/compressed/misc.o
CC net/bluetooth/l2cap.mod.o
CC net/bluetooth/rfcomm/rfcomm.mod.o
CC net/bluetooth/sco.mod.o
CC arch/arm/boot/compressed/decompress.o
CC net/mac80211/mac80211.mod.o
CC net/wireless/cfg80211.mod.o
CC net/wireless/lib80211.mod.o
CC sound/core/oss/snd-mixer-oss.mod.o
CC sound/core/oss/snd-pcm-oss.mod.o
CC sound/core/snd-hwdep.mod.o
SHIPPED arch/arm/boot/compressed/lib1funcs.S
AS arch/arm/boot/compressed/piggy.gzip.o
AS arch/arm/boot/compressed/lib1funcs.o
LD arch/arm/boot/compressed/vmlinux
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
CC sound/core/snd-page-alloc.mod.o
CC sound/core/snd-pcm.mod.o
CC sound/core/snd-rawmidi.mod.o
CC sound/core/snd-timer.mod.o
CC sound/core/snd.mod.o
CC sound/soc/codecs/snd-soc-twl4030.mod.o
CC sound/soc/omap/snd-soc-omap-mcbsp.mod.o
CC sound/soc/omap/snd-soc-omap.mod.o
CC sound/soc/omap/snd-soc-omap3pandora.mod.o
CC sound/soc/snd-soc-core.mod.o
CC sound/soundcore.mod.o
CC sound/usb/snd-usb-audio.mod.o
CC sound/usb/snd-usbmidi-lib.mod.o
LD [M] crypto/aes_generic.ko
LD [M] crypto/arc4.ko
LD [M] crypto/ecb.ko
LD [M] drivers/bluetooth/bcm203x.ko
LD [M] drivers/bluetooth/bpa10x.ko
LD [M] drivers/bluetooth/hci_uart.ko
LD [M] drivers/net/wireless/libertas/libertas.ko
LD [M] drivers/net/wireless/libertas/libertas_sdio.ko
LD [M] drivers/net/wireless/libertas/usb8xxx.ko
LD [M] drivers/scsi/scsi_wait_scan.ko
LD [M] drivers/usb/gadget/g_zero.ko
LD [M] net/bluetooth/bluetooth.ko
LD [M] net/bluetooth/bnep/bnep.ko
LD [M] net/bluetooth/hidp/hidp.ko
LD [M] net/bluetooth/l2cap.ko
LD [M] net/bluetooth/rfcomm/rfcomm.ko
LD [M] net/bluetooth/sco.ko
LD [M] net/mac80211/mac80211.ko
LD [M] net/wireless/cfg80211.ko
LD [M] net/wireless/lib80211.ko
LD [M] sound/core/oss/snd-mixer-oss.ko
LD [M] sound/core/oss/snd-pcm-oss.ko
LD [M] sound/core/snd-hwdep.ko
LD [M] sound/core/snd-page-alloc.ko
LD [M] sound/core/snd-pcm.ko
LD [M] sound/core/snd-rawmidi.ko
LD [M] sound/core/snd-timer.ko
LD [M] sound/core/snd.ko
LD [M] sound/soc/codecs/snd-soc-twl4030.ko
LD [M] sound/soc/omap/snd-soc-omap-mcbsp.ko
LD [M] sound/soc/omap/snd-soc-omap.ko
LD [M] sound/soc/omap/snd-soc-omap3pandora.ko
LD [M] sound/soc/snd-soc-core.ko
LD [M] sound/soundcore.ko
LD [M] sound/usb/snd-usb-audio.ko
LD [M] sound/usb/snd-usbmidi-lib.ko
$
^ permalink raw reply
* [PATCH] ARM: msm: 7x30: don't force a gpiomux table for the whole arch
From: Dima Zavin @ 2011-01-14 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8yalj2nfj11.fsf@huya.qualcomm.com>
Thanks!
--Dima
On Fri, Jan 14, 2011 at 10:16 AM, David Brown <davidb@codeaurora.org> wrote:
> On Mon, Jan 10 2011, Dima Zavin wrote:
>
>> This is completely board specific and therefore must be provided
>> on a per-board basis.
>>
>> Change-Id: I96f922ad9bb9cbce7874c5ae6ac0d7479b7a2124
>> Signed-off-by: Dima Zavin <dima@android.com>
>
> I'll pull this into msm-next once rc8-rc1 comes out.
>
> I'll take out the Change-Id line, though.
>
> David
>
^ permalink raw reply
* [PATCH 01/54] ARM: core irq_data conversion.
From: Lennert Buytenhek @ 2011-01-14 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114162417.GA23154@n2100.arm.linux.org.uk>
On Fri, Jan 14, 2011 at 04:24:17PM +0000, Russell King - ARM Linux wrote:
> > static void route_irq(struct irq_desc *desc, unsigned int irq, unsigned int cpu)
> > {
> > - pr_debug("IRQ%u: moving from cpu%u to cpu%u\n", irq, desc->node, cpu);
> > + pr_debug("IRQ%u: moving from cpu%u to cpu%u\n", irq, desc->irq_data.node, cpu);
> >
> > raw_spin_lock_irq(&desc->lock);
> > - desc->chip->set_affinity(irq, cpumask_of(cpu));
> > + desc->irq_data.chip->irq_set_affinity(&desc->irq_data,
> > + cpumask_of(cpu), false);
>
> Shouldn't this be 'true' to force the IRQ to move? The old CPU is
> going down so it's not really optional.
Right, that makes sense. Can you make that change?
^ permalink raw reply
* [PATCHv2] hwrng: add support for picoxcell TRNG
From: Matt Mackall @ 2011-01-14 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295030661-16364-1-git-send-email-jamie@jamieiles.com>
On Fri, 2011-01-14 at 18:44 +0000, Jamie Iles wrote:
> This driver adds support for the True Random Number Generator in
> the Picochip PC3X3 and later devices.
>
> v2: fix indentation and cleanup read function to remove single use
> variables and to take advantage of the rng buffer being aligned.
>
> Cc: Matt Mackall <mpm@selenic.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Matt Mackall <mpm@selenic.com>
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* [PATCH] ARM: vfp: Fix up exception location in Thumb mode
From: Russell King - ARM Linux @ 2011-01-14 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114173050.GJ15996@n2100.arm.linux.org.uk>
On Fri, Jan 14, 2011 at 05:30:50PM +0000, Russell King - ARM Linux wrote:
> On Fri, Jan 14, 2011 at 04:58:47PM +0000, Catalin Marinas wrote:
> > I agree, this code needs some clean-up. Maybe for Undef we could unify
> > the ARM and Thumb-2 offsets so that they are both 4 (it may confuse the
> > breakpoint code, I haven't checked).
> >
> > Otherwise just let the code handling the undef deal with the ARM/Thumb
> > difference. For SVC, it makes sense to have different offsets as we
> > always return to the next instruction.
>
> I think it just needs better documentation.
>
> Having been through all this, there _are_ bugs lurking in the code exactly
> because of this randomness with what PC value is means what.
>
> When the VFP support code tests the state of the VFP hardware during boot,
> it sets the VFP handler to point at vfp_testing_entry, bypassing the normal
> VFP handling code, and executes a VFP instruction.
>
> If this VFP instruction faults (eg, because there is no VFP hardware
> present or we're not permitted to use it), it could end up resuming
> execution in the middle of the 16-bit paired instruction because
> regs->ARM_pc points in the middle of it.
>
> So vfp_testing_entry should at least store r2 into regs->ARM_pc to
> guarantee resuming at the following instruction.
>
> So maybe the right answer is to store r2 into regs->ARM_pc in
> process_exception in the VFP assembly code too?
>
> Or maybe we should just make it unconditional that whenever we have an
> undefined instruction exception, the regs->ARM_pc value will always be
> set for resuming execution after the faulted instruction. That makes
> it consistent with r2 throughout the code in every case.
So... this incrementally on top of the previous patch (which I've
reproduced below as there's a subtle comment change in there wrt IRQ
state.)
This means we have consistent state - both r2 and regs->ARM_pc always
point to the next instruction to be executed in every case, which means
its easy to understand and remember while reading through the code.
diff -u b/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
--- b/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -499,10 +499,11 @@
blo __und_usr_unknown
3: ldrht r0, [r4]
add r2, r2, #2 @ r2 is PC + 2, make it PC + 4
- orr r0, r0, r5, lsl #16
+ str r2, [sp, #S_PC] @ it's a 2x16bit instr, update
+ orr r0, r0, r5, lsl #16 @ regs->ARM_pc
@
@ r0 = the two 16-bit Thumb instructions which caused the exception
- @ r2 = PC value for the following Thumb instruction (:= regs->ARM_pc+2)
+ @ r2 = PC value for the following Thumb instruction (:= regs->ARM_pc)
@ r4 = PC value for the first 16-bit Thumb instruction
@
#else
8<-x-x-
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 2b46fea..5876eec 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -461,27 +461,35 @@ ENDPROC(__irq_usr)
.align 5
__und_usr:
usr_entry
-
- @
- @ fall through to the emulation code, which returns using r9 if
- @ it has emulated the instruction, or the more conventional lr
- @ if we are to treat this as a real undefined instruction
@
- @ r0 - instruction
+ @ The emulation code returns using r9 if it has emulated the
+ @ instruction, or the more conventional lr if we are to treat
+ @ this as a real undefined instruction
@
adr r9, BSYM(ret_from_exception)
adr lr, BSYM(__und_usr_unknown)
+ @
+ @ r2 = regs->ARM_pc, which is either 2 or 4 bytes ahead of the
+ @ faulting instruction depending on Thumb mode.
+ @ r3 = regs->ARM_cpsr
+ @
tst r3, #PSR_T_BIT @ Thumb mode?
- itet eq @ explicit IT needed for the 1f label
+ itttt eq @ explicit IT needed for the 1f label
subeq r4, r2, #4 @ ARM instr at LR - 4
- subne r4, r2, #2 @ Thumb instr at LR - 2
1: ldreqt r0, [r4]
#ifdef CONFIG_CPU_ENDIAN_BE8
reveq r0, r0 @ little endian instruction
#endif
+ @
+ @ r0 = 32-bit ARM instruction which caused the exception
+ @ r2 = PC value for the following instruction (:= regs->ARM_pc)
+ @ r4 = PC value for the faulting instruction
+ @
beq call_fpe
+
@ Thumb instruction
#if __LINUX_ARM_ARCH__ >= 7
+ sub r4, r2, #2 @ Thumb instr at LR - 2
2:
ARM( ldrht r5, [r4], #2 )
THUMB( ldrht r5, [r4] )
@@ -492,18 +500,19 @@ __und_usr:
3: ldrht r0, [r4]
add r2, r2, #2 @ r2 is PC + 2, make it PC + 4
orr r0, r0, r5, lsl #16
+ @
+ @ r0 = the two 16-bit Thumb instructions which caused the exception
+ @ r2 = PC value for the following Thumb instruction (:= regs->ARM_pc+2)
+ @ r4 = PC value for the first 16-bit Thumb instruction
+ @
#else
b __und_usr_unknown
#endif
- UNWIND(.fnend )
+ UNWIND(.fnend)
ENDPROC(__und_usr)
- @
- @ fallthrough to call_fpe
- @
-
/*
- * The out of line fixup for the ldrt above.
+ * The out of line fixup for the ldrt instructions above.
*/
.pushsection .fixup, "ax"
4: mov pc, r9
@@ -534,11 +543,12 @@ ENDPROC(__und_usr)
* NEON handler code.
*
* Emulators may wish to make use of the following registers:
- * r0 = instruction opcode.
- * r2 = PC+4
+ * r0 = instruction opcode (32-bit ARM or two 16-bit Thumb)
+ * r2 = PC value to resume execution after successful emulation
* r9 = normal "successful" return address
- * r10 = this threads thread_info structure.
+ * r10 = this threads thread_info structure
* lr = unrecognised instruction return address
+ * IRQs disabled, FIQs enabled.
*/
@
@ Fall-through from Thumb-2 __und_usr
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index ee57640..eeb9250 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -347,9 +347,9 @@ asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
void __user *pc;
/*
- * According to the ARM ARM, PC is 2 or 4 bytes ahead,
- * depending whether we're in Thumb mode or not.
- * Correct this offset.
+ * According to the ARM ARM, the PC is 2 or 4 bytes ahead
+ * depending on Thumb mode. Correct this offset so that
+ * regs->ARM_pc points at the faulting instruction.
*/
regs->ARM_pc -= correction;
diff --git a/arch/arm/vfp/entry.S b/arch/arm/vfp/entry.S
index 4fa9903..2bf6089 100644
--- a/arch/arm/vfp/entry.S
+++ b/arch/arm/vfp/entry.S
@@ -19,6 +19,15 @@
#include <asm/vfpmacros.h>
#include "../kernel/entry-header.S"
+@ VFP entry point.
+@
+@ r0 = instruction opcode (32-bit ARM or two 16-bit Thumb)
+@ r2 = PC value to resume execution after successful emulation
+@ r9 = normal "successful" return address
+@ r10 = this threads thread_info structure
+@ lr = unrecognised instruction return address
+@ IRQs disabled.
+@
ENTRY(do_vfp)
#ifdef CONFIG_PREEMPT
ldr r4, [r10, #TI_PREEMPT] @ get preempt count
diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
index 9897dcf..7292921 100644
--- a/arch/arm/vfp/vfphw.S
+++ b/arch/arm/vfp/vfphw.S
@@ -61,13 +61,13 @@
@ VFP hardware support entry point.
@
-@ r0 = faulted instruction
-@ r2 = faulted PC+4
-@ r9 = successful return
+@ r0 = instruction opcode (32-bit ARM or two 16-bit Thumb)
+@ r2 = PC value to resume execution after successful emulation
+@ r9 = normal "successful" return address
@ r10 = vfp_state union
@ r11 = CPU number
-@ lr = failure return
-
+@ lr = unrecognised instruction return address
+@ IRQs enabled.
ENTRY(vfp_support_entry)
DBGSTR3 "instr %08x pc %08x state %p", r0, r2, r10
@@ -138,9 +138,12 @@ check_for_exception:
@ exception before retrying branch
@ out before setting an FPEXC that
@ stops us reading stuff
- VFPFMXR FPEXC, r1 @ restore FPEXC last
- sub r2, r2, #4
- str r2, [sp, #S_PC] @ retry the instruction
+ VFPFMXR FPEXC, r1 @ Restore FPEXC last
+ sub r2, r2, #4 @ Retry current instruction - if Thumb
+ str r2, [sp, #S_PC] @ mode it's two 16-bit instructions,
+ @ else it's one 32-bit instruction, so
+ @ always subtract 4 from the following
+ @ instruction address.
#ifdef CONFIG_PREEMPT
get_thread_info r10
ldr r4, [r10, #TI_PREEMPT] @ get preempt count
^ permalink raw reply related
* [PATCH] TWD: enable one-shot mode
From: Stephen Boyd @ 2011-01-14 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111115209.GA12781@n2100.arm.linux.org.uk>
On 01/11/2011 03:52 AM, Russell King - ARM Linux wrote:
> On Mon, Jan 10, 2011 at 09:12:36PM -0800, Stephen Boyd wrote:
>>
>> I see this patch was already tested and merged but can you elaborate on
>> why this was done? From what I understand, NOHZ selects one-shot (like
>> is done in this patch), so why don't the machines with a TWD choose NOHZ
>> or high res timers?
>
> You're right - so it's not actually required. It should probably be
> reverted, though it does no damage...
Now I'm wondering why there are other 'select TICK_ONESHOT' lines in
arch/arm/Kconfig. Can we just remove them all? Otherwise it feels like
we're making it confusing for others later on.
----->8---[cut here]----8<-----
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e2f8011..7750a78 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -532,7 +532,6 @@ config ARCH_MMP
select CLKDEV_LOOKUP
select GENERIC_CLOCKEVENTS
select HAVE_SCHED_CLOCK
- select TICK_ONESHOT
select PLAT_PXA
select SPARSE_IRQ
help
@@ -613,7 +612,6 @@ config ARCH_PXA
select ARCH_REQUIRE_GPIOLIB
select GENERIC_CLOCKEVENTS
select HAVE_SCHED_CLOCK
- select TICK_ONESHOT
select PLAT_PXA
select SPARSE_IRQ
help
@@ -668,7 +666,6 @@ config ARCH_SA1100
select GENERIC_CLOCKEVENTS
select HAVE_CLK
select HAVE_SCHED_CLOCK
- select TICK_ONESHOT
select ARCH_REQUIRE_GPIOLIB
help
Support for StrongARM 11x0 based boards.
@@ -1300,7 +1297,6 @@ config HAVE_ARM_SCU
config HAVE_ARM_TWD
bool
depends on SMP
- select TICK_ONESHOT
help
This options enables support for the ARM timer and watchdog unit
--
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
* [PATCHv2] hwrng: add support for picoxcell TRNG
From: Jamie Iles @ 2011-01-14 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114181609.GN2822@pulham.picochip.com>
This driver adds support for the True Random Number Generator in
the Picochip PC3X3 and later devices.
v2: fix indentation and cleanup read function to remove single use
variables and to take advantage of the rng buffer being aligned.
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
---
drivers/char/hw_random/Kconfig | 12 +++
drivers/char/hw_random/Makefile | 1 +
drivers/char/hw_random/picoxcell-rng.c | 169 ++++++++++++++++++++++++++++++++
3 files changed, 182 insertions(+), 0 deletions(-)
create mode 100644 drivers/char/hw_random/picoxcell-rng.c
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index d31483c..beecd1c 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -198,3 +198,15 @@ config HW_RANDOM_NOMADIK
module will be called nomadik-rng.
If unsure, say Y.
+
+config HW_RANDOM_PICOXCELL
+ tristate "Picochip picoXcell true random number generator support"
+ depends on HW_RANDOM && ARCH_PICOXCELL && PICOXCELL_PC3X3
+ ---help---
+ This driver provides kernel-side support for the Random Number
+ Generator hardware found on Picochip PC3x3 and later devices.
+
+ To compile this driver as a module, choose M here: the
+ module will be called picoxcell-rng.
+
+ If unsure, say Y.
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 4273308..3db4eb8 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -19,3 +19,4 @@ obj-$(CONFIG_HW_RANDOM_TX4939) += tx4939-rng.o
obj-$(CONFIG_HW_RANDOM_MXC_RNGA) += mxc-rnga.o
obj-$(CONFIG_HW_RANDOM_OCTEON) += octeon-rng.o
obj-$(CONFIG_HW_RANDOM_NOMADIK) += nomadik-rng.o
+obj-$(CONFIG_HW_RANDOM_PICOXCELL) += picoxcell-rng.o
diff --git a/drivers/char/hw_random/picoxcell-rng.c b/drivers/char/hw_random/picoxcell-rng.c
new file mode 100644
index 0000000..9f32760
--- /dev/null
+++ b/drivers/char/hw_random/picoxcell-rng.c
@@ -0,0 +1,169 @@
+/*
+ * Copyright (c) 2010-2011 Picochip Ltd., Jamie Iles
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * All enquiries to support at picochip.com
+ */
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/hw_random.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+
+#define DATA_REG_OFFSET 0x0200
+#define CSR_REG_OFFSET 0x0278
+#define CSR_OUT_EMPTY_MASK (1 << 24)
+#define TAI_REG_OFFSET 0x0380
+
+static void __iomem *rng_base;
+static struct clk *rng_clk;
+
+/*
+ * Get some random data from the random number generator. The hw_random core
+ * layer provides us with locking.
+ */
+static int picoxcell_trng_read(struct hwrng *rng, void *buf, size_t max,
+ bool wait)
+{
+ u32 __iomem *csr = rng_base + CSR_REG_OFFSET;
+
+ /* Wait for some data to become available. */
+ while (__raw_readl(csr) & CSR_OUT_EMPTY_MASK) {
+ if (!wait)
+ return 0;
+ cpu_relax();
+ }
+
+ *(u32 *)buf = __raw_readl(rng_base + DATA_REG_OFFSET);
+
+ return sizeof(u32);
+}
+
+static struct hwrng picoxcell_trng = {
+ .name = "picoxcell",
+ .read = picoxcell_trng_read,
+};
+
+/*
+ * Take the random number generator out of reset and make sure the interrupts
+ * are masked. We shouldn't need to get large amounts of random bytes so just
+ * poll the status register. The hardware generates 32 bits every 320ns so we
+ * shouldn't have to wait long enough to warrant waiting for an IRQ.
+ */
+static void picoxcell_trng_start(void)
+{
+ __raw_writel(0, rng_base + TAI_REG_OFFSET);
+ __raw_writel(0, rng_base + CSR_REG_OFFSET);
+}
+
+static int picoxcell_trng_probe(struct platform_device *pdev)
+{
+ int ret;
+ struct resource *mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+ if (!mem) {
+ dev_warn(&pdev->dev, "no memory resource\n");
+ return -ENOMEM;
+ }
+
+ if (!devm_request_mem_region(&pdev->dev, mem->start, resource_size(mem),
+ "picoxcell_trng")) {
+ dev_warn(&pdev->dev, "unable to request io mem\n");
+ return -EBUSY;
+ }
+
+ rng_base = devm_ioremap(&pdev->dev, mem->start, resource_size(mem));
+ if (!rng_base) {
+ dev_warn(&pdev->dev, "unable to remap io mem\n");
+ return -ENOMEM;
+ }
+
+ rng_clk = clk_get(&pdev->dev, NULL);
+ if (IS_ERR(rng_clk)) {
+ dev_warn(&pdev->dev, "no clk\n");
+ return PTR_ERR(rng_clk);
+ }
+
+ ret = clk_enable(rng_clk);
+ if (ret) {
+ dev_warn(&pdev->dev, "unable to enable clk\n");
+ goto err_enable;
+ }
+
+ picoxcell_trng_start();
+ ret = hwrng_register(&picoxcell_trng);
+ if (ret)
+ goto err_register;
+
+ dev_info(&pdev->dev, "pixoxcell random number generator active\n");
+
+ return 0;
+
+err_register:
+ clk_disable(rng_clk);
+err_enable:
+ clk_put(rng_clk);
+
+ return ret;
+}
+
+static int __devexit picoxcell_trng_remove(struct platform_device *pdev)
+{
+ hwrng_unregister(&picoxcell_trng);
+ clk_disable(rng_clk);
+ clk_put(rng_clk);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM
+static int picoxcell_trng_suspend(struct device *dev)
+{
+ clk_disable(rng_clk);
+
+ return 0;
+}
+
+static int picoxcell_trng_resume(struct device *dev)
+{
+ return clk_enable(rng_clk);
+}
+
+static const struct dev_pm_ops picoxcell_trng_pm_ops = {
+ .suspend = picoxcell_trng_suspend,
+ .resume = picoxcell_trng_resume,
+};
+#endif /* CONFIG_PM */
+
+static struct platform_driver picoxcell_trng_driver = {
+ .probe = picoxcell_trng_probe,
+ .remove = __devexit_p(picoxcell_trng_remove),
+ .driver = {
+ .name = "picoxcell-trng",
+ .owner = THIS_MODULE,
+#ifdef CONFIG_PM
+ .pm = &picoxcell_trng_pm_ops,
+#endif /* CONFIG_PM */
+ },
+};
+
+static int __init picoxcell_trng_init(void)
+{
+ return platform_driver_register(&picoxcell_trng_driver);
+}
+module_init(picoxcell_trng_init);
+
+static void __exit picoxcell_trng_exit(void)
+{
+ platform_driver_unregister(&picoxcell_trng_driver);
+}
+module_exit(picoxcell_trng_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jamie Iles");
+MODULE_DESCRIPTION("Picochip picoXcell TRNG driver");
--
1.7.3.4
^ permalink raw reply related
* ARM: CPU hotplug: fix hard-coded control register constants
From: Stephen Warren @ 2011-01-14 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114120437.GB15996@n2100.arm.linux.org.uk>
Russell King wrote:
> Sent: Friday, January 14, 2011 5:05 AM
>
> On Fri, Jan 14, 2011 at 05:20:03PM +0530, viresh kumar wrote:
> ...
> In any case, this code is probably doing the wrong thing - if s5pv310
> is not an ARMv6 MPCore the its fiddling with the auxillary control
> register is already broken.
>
> > > diff --git a/arch/arm/mach-tegra/hotplug.c b/arch/arm/mach-tegra/hotplug.c
> > > index 17faf77..a5cb1ce 100644
> > > --- a/arch/arm/mach-tegra/hotplug.c
> > > +++ b/arch/arm/mach-tegra/hotplug.c
> > > @@ -26,13 +26,13 @@ static inline void cpu_enter_lowpower(void)
> > > * Turn off coherency
> > > */
> > > " mrc p15, 0, %0, c1, c0, 1\n"
> > > - " bic %0, %0, #0x20\n"
> > > + " bic %0, %0, %2\n"
> >
> > here also.
>
> Same comment.
Just as an FYI, in various downstream trees, that file (for mach-tegra) has
been removed and replaced with completely different code. However, the
replacement isn't in the process of being upstreamed right yet. Specifically:
git://android.git.kernel.org/kernel/tegra.git
linux-tegra-2.6.37
cb8e70bd4fa41ea7ac66f01f7425943db99ac7d3
ARM: tegra: Add suspend and hotplug support
Hope this helps.
--
nvpublic
^ permalink raw reply
* [GIT PULL] AT91: patches for v2.6.38-rc1
From: Russell King - ARM Linux @ 2011-01-14 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D309278.5010603@atmel.com>
On Fri, Jan 14, 2011 at 07:14:16PM +0100, Nicolas Ferre wrote:
> Le 14/01/2011 19:04, Russell King - ARM Linux :
> > On Fri, Jan 14, 2011 at 07:00:16PM +0100, Nicolas Ferre wrote:
> >> Hi Russell,
> >>
> >> Can you please pull those little changes for AT91? They add two
> >> new boards already discussed on the mailing list and a little
> >> cleanup patch:
> >
> > Has this already been in linux-next?
>
> I must admit that... no.
>
> > We should only be merging new code during a merge window which has
> > already had visibility in linux-next, with the exception of bug fixes
> > and regression fixes.
>
> I understand your point but those are only *board* files that are lying
> around for one or two months.
> I was really wishing to see them included in mainline during merge
> window as they are not core ARM nor AT91 files...
Okay for this time, but please ensure that stuff like this is in
linux-next before the merge window next time so that it can have
some exposure.
^ permalink raw reply
* [PATCH] ARM: msm: 7x30: don't force a gpiomux table for the whole arch
From: David Brown @ 2011-01-14 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294686030-9817-1-git-send-email-dima@android.com>
On Mon, Jan 10 2011, Dima Zavin wrote:
> This is completely board specific and therefore must be provided
> on a per-board basis.
>
> Change-Id: I96f922ad9bb9cbce7874c5ae6ac0d7479b7a2124
> Signed-off-by: Dima Zavin <dima@android.com>
I'll pull this into msm-next once rc8-rc1 comes out.
I'll take out the Change-Id line, though.
David
^ 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