* [GIT PULL v3] pxa: patches for v2.6.38-rc
From: Russell King - ARM Linux @ 2011-01-15 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinZUW9Xvp-Yoz_cQnVo+iGb7A1XBgzE0yuCJzvN@mail.gmail.com>
On Fri, Jan 14, 2011 at 07:26:39PM -0600, Eric Miao wrote:
> On Fri, Jan 14, 2011 at 3:49 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > 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.
>
> You are right. Do you want me to have another patch on top or I
> make the change back into the guilty commit and you re-pull? I'd
> prefer the latter.
I dropped your tree so you can fix them locally.
^ permalink raw reply
* [PATCH 27/48] ARM: PL08x: avoid duplicating registers in txd and phychan structures
From: Russell King - ARM Linux @ 2011-01-15 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=GsMaDQDSuR=Z4AT4Vk4GThx6O_0Le=pjsu9gj@mail.gmail.com>
On Fri, Jan 14, 2011 at 05:35:41PM -0800, Dan Williams wrote:
> On Mon, Jan 3, 2011 at 2:39 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > As we now have all the code accessing the phychan {csrc,cdst,clli,cctl,
> > ccfg} members in one function, there's no point storing the data into
> > the struct. ?Get rid of the struct members. ?Re-order the register dump
> > in the dev_dbg() to reflect the order we write the registers to the DMA
> > device.
> >
> > The txd {csrc,cdst,clli,cctl} values are duplicates of the lli[0]
> > values, so there's no point duplicating these either. ?Program the DMAC
> > registers directly from the lli[0] values.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
> This one caused:
> drivers/dma/amba-pl08x.c: In function 'pl08x_start_txd':
> drivers/dma/amba-pl08x.c:205: warning: dereferencing 'void *' pointer
That probably means you've got something out of order. I have them
ordered in my git tree, I'll recheck there.
^ permalink raw reply
* [PATCH] ARM: make head.S less dependent on the compile time PHYS_OFFSET define
From: Russell King - ARM Linux @ 2011-01-15 12:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1101142322580.938@xanadu.home>
On Fri, Jan 14, 2011 at 11:49:31PM -0500, Nicolas Pitre wrote:
> On Sat, 15 Jan 2011, Russell King - ARM Linux wrote:
>
> > I've pushed it out under the branch p2v. I think before this
> > goes upstream, "ARM: P2V: Use pv_fixup trick to get physical address"
> > needs merging with "ARM: P2V: make head.S use PLAT_PHYS_OFFSET" -
> > it doesn't really make sense to fix the same code twice for the same
> > underlying problem in the same patch set when it's possible to only
> > fix it once.
>
> Indeed. You probably should fold the following with it as well:
Ok, done.
One other item which has been missed: the p2v build state between kernel
and modules must match to prevent incompatible modules being loaded.
This also applies for the 16-bit p2v stuff as well - an 8-bit p2v module
can't be loaded into a 16-bit p2v kernel as it will be missing bits
16-23 of the offset.
These dependencies are actually one-way:
------- module -------
kernel fixed p2v-8 p2v-16
fixed y n* n*
p2v-8 n y y
p2v-16 n n y
The 'n*' could be 'y' if we always include the fixup code, but I'm not
sure the complexity required for expressing these dependencies (which
can't be done with the vermagic method) is worth it.
So I've added a marker to the module version string, which will require
the build configuration of P2V for the kernel and modules to match.
^ permalink raw reply
* [GIT PULL v3] pxa: patches for v2.6.38-rc
From: Eric Miao @ 2011-01-15 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114214900.GP15996@n2100.arm.linux.org.uk>
On Fri, Jan 14, 2011 at 3:49 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> 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.
>
Fixed.
> 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
>
This didn't happen on my side. Maybe it's due to some change
not yet merged into devel-stable?
> 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?
>
This is going to be tricky now. The rfkill_set_led_trigger_name() has been
removed somehow as dead code along with several others in commit 2e48928,
apparently the patch author didn't notice it's existing usage, not only in
tosa-bt.c but arch/arm/mach-s3c2410/h1940-bluetooth.c.
There are two options:
1) remove the invocation completely, and rfkill_register() will just use
the dev_name(), which is of form 'rfkill%u', as the name for the led trigger.
But this is going to change the name of user space as well, which is what
we want to avoid.
2) or revert that 'removing dead code' commit. The function is simple
enough though, but since 'struct rfkill' is declared somehow within the
net/rfkill/core.c file, there has to be some function to initialize that.
Now, my personal preference would be to postpone the proper fix for this
issue into -rc?.
> which looks like a missing dependency.
>
> Do you want to fix these and send an updated pull?
>
With the first issue solved, I've pushed the change to my tree. Please
try re-pull. Will have to be on the flight hours later, and I might be
not responsive until a bit later. Sorry for this.
^ permalink raw reply
* [GIT PULL v3] pxa: patches for v2.6.38-rc
From: Russell King - ARM Linux @ 2011-01-15 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=AtkMc90K8C9qrKaVqdLyuHE9SXyugkkX8HEeS@mail.gmail.com>
On Sat, Jan 15, 2011 at 06:20:06AM -0600, Eric Miao wrote:
> > 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
> >
>
> This didn't happen on my side. Maybe it's due to some change
> not yet merged into devel-stable?
I sent a follow-up patch to it - see "[PATCH] Fix latest regression - pgtable.h"
> > 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?
> >
>
> This is going to be tricky now. The rfkill_set_led_trigger_name() has been
> removed somehow as dead code along with several others in commit 2e48928,
> apparently the patch author didn't notice it's existing usage, not only in
> tosa-bt.c but arch/arm/mach-s3c2410/h1940-bluetooth.c.
>
> There are two options:
>
> 1) remove the invocation completely, and rfkill_register() will just use
> the dev_name(), which is of form 'rfkill%u', as the name for the led trigger.
> But this is going to change the name of user space as well, which is what
> we want to avoid.
>
> 2) or revert that 'removing dead code' commit. The function is simple
> enough though, but since 'struct rfkill' is declared somehow within the
> net/rfkill/core.c file, there has to be some function to initialize that.
>
> Now, my personal preference would be to postpone the proper fix for this
> issue into -rc?.
Okay, let's defer this until it can be discussed with Stephen Hemminger.
^ permalink raw reply
* [GIT PULL] Samsung S5P for 2.6.38 merge window
From: Russell King - ARM Linux @ 2011-01-15 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <021901cbb2e2$ef4a0630$cdde1290$%kim@samsung.com>
On Thu, Jan 13, 2011 at 02:30:01PM +0900, Kukjin Kim wrote:
> Hi Russell,
>
> Please pull Samsung S5P updates from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> for-rmk
>
> These things are for 2.6.38.
This looks very large. I really considered not merging this due to:
1. possibly conflicts with Lennert's irq_data conversion patches.
2. It's not right to push large quantities of code into mainline towards
the end of the merge window. You should have everything prepared
that you want to send before the merge window opens.
In future, please have your tree ready for merging *before* the merge
window opens and aim to get the bulk in preferably before, at the latest
during the first week.
^ permalink raw reply
* [GIT PULL] Samsung S5P for 2.6.38 merge window
From: Russell King - ARM Linux @ 2011-01-15 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110115132955.GA15996@n2100.arm.linux.org.uk>
On Sat, Jan 15, 2011 at 01:29:55PM +0000, Russell King - ARM Linux wrote:
> On Thu, Jan 13, 2011 at 02:30:01PM +0900, Kukjin Kim wrote:
> > Hi Russell,
> >
> > Please pull Samsung S5P updates from:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> > for-rmk
> >
> > These things are for 2.6.38.
>
> This looks very large. I really considered not merging this due to:
>
> 1. possibly conflicts with Lennert's irq_data conversion patches.
>
> 2. It's not right to push large quantities of code into mainline towards
> the end of the merge window. You should have everything prepared
> that you want to send before the merge window opens.
>
> In future, please have your tree ready for merging *before* the merge
> window opens and aim to get the bulk in preferably before, at the latest
> during the first week.
And... merging this kills off the ability to get a sane diffstat out
of git for my devel-stable branch due to multiple common ancestors.
We'll see what Linus says on this - but there are three outcomes:
1. Linus responds quickly, and wants his tree merged into mine before
he pulls (Linus isn't generally a fan of last minute cross-tree
merging.)
2. Linus doesn't respond before the merge window closes, and I leave the
tree as is, which means no pull request being sent and therefore it
doesn't make mainline.
3. Linus doesn't respond before the merge window closes, I decide to
drop your tree, and send a pull request which Linus actions.
Realistically, it's (1) or (3).
This is yet another reason to get your tree ready before the merge
window opens.
^ permalink raw reply
* Locking in the clk API
From: Christer Weinigel @ 2011-01-15 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110112090301.GS11039@n2100.arm.linux.org.uk>
On 01/12/2011 10:03 AM, Russell King - ARM Linux wrote:
> That never has been, and that is called for the _system_ going into
> suspend. That's not what I'm talking about. I'm talking about drivers
> doing their own power management in response to (a) their knowledge of
> how the device behaves and (b) in response to the user state they know.
>
> In the case of a UART, that means enabling the clock when the user opens
> the device and turning it off when the user closes the device - and in
> the case of the UART being used as the system console, enabled when
> printk calls it, disabled when finished outputting the message.
>
> The latter is a case where you're called in atomic context.
This feels a bit like perfect being the enemy of good.
On platforms that need to sleep to enable the UART clock, configuring
the UART as the kernel console should be equivalent to userspace opening
the UART device, i.e. enable the clock. At least to me that feels like
an acceptable tradeoff, and if I wanted to save the last bit of power
I'll have to refrain from using UART as the kernel console.
If both printk to the console and disabling the clock is really really
neccesary, add a clk_enable_busywait, but that will be a bit of a hack.
> Another case - a storage device. While you may receive open/close calls,
> these are meaningless for power management - you'll receive an open call
> when you mount a filesystem, and a close call when you finally unmount it.
> That doesn't mean it's going to be used. Your request handler will
> generally run in an atomic context, so in order to do dynamic power
> saving you need to be able to enable/disable clocks in that context.
> A touchscreen controller which you communicate with over a dedicated bus.
> The touchscreen controller doesn't require the host to be constantly
> clocked - it only needs to be clocked when communicating with the
> touchscreen. The touchscreen controller raises an interrupt for service.
> You'd want to enable the clock in the interrupt handler to communicate
> with the device and turn it off afterwards.
Both of these feel like they should use a call such as clk_get_atomic
and be able to handle EWOULDBLOCK/EAGAIN (or whatever error code is used
to indicate that it would have to sleep) and delegate to a worker thread
to enable the clock. To catch uses of plain clk_enable from atomic
contects, add a WARN_ON/BUG_ON(in_atomic()). It won't catch everything,
but would help a bit at least.
Someone suggested splitting clk_enable into a part that can sleep and a
part that can't, would that be workable? I.e. extend clk_get so that it
knows what requirements the driver has on the clock. So a driver that does:
clk_get(dev, "my_clk", CLK_CANSLEEP);
must then either use clk_enable from contexts which can sleep or use
clk_enable_atomic and be able to handle EWOULDBLOCK.
A driver which can't handle EWOULDBLOCK would do:
clk_get(dev, "my_clk", CLK_ATOMIC)
informing the clock subsystem that clk_enable_atomic must always
succeed. If the clock source driver can't do that it has to enable the
clock at clk_get time instead of at clk_enable time. If a clock
requires a potentially slow PLL setup which needs to sleep but can gate
the clock atomically, do the PLL setup from clk_get and the gating from
clk_enable. This means that a clock might be on when it strictly isn't
necessary, but at least it will be correct and assuming that Peter Mundt
is correct in saying that the sleeping clock case is a corner case this
will usually not be a problem.
For the corner cases where someone ports a driver that uses CLK_ATOMIC
to a system with sleeping clocks and wants the last bit of power saving,
the burden is on that someone to add EWOULDBLOCK support to the driver.
Regarding the other functions in the clock API, generic code in
clk_disable_atomic could check if it is a sleeping clock and based on
that call clk_disable directly or delegate the call to a worker thread.
All other functions should be able to sleep, with the possible
exception of clk_get_rate which could be useful so that a driver can
check if the clock is running at the correct rate from atomic context
and delegate to a worker thread to change the clock rate if it is not.
To avoid unnecessary code churn it might be better to say that plain
clk_enable is the atomic variant and if it is a sleeping clock it will
be enbled at the time plain clk_get is called. People who want to use
sleeping clocks can then modify a driver at a time to use
clk_get_cansleep and clk_enable_cansleep. But I must say that the name
clk_enable_atomic feels a lot cleaner.
/Christer
^ permalink raw reply
* ARM: CPU hotplug: fix hard-coded control register constants
From: viresh kumar @ 2011-01-15 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114120838.GC15996@n2100.arm.linux.org.uk>
On 1/14/11, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> Subject: [PATCH] ARM: fix wrongly patched constants
>
> e3d9c625 (ARM: CPU hotplug: fix hard-coded control register constants)
> changed the wrong constants in the hotplug assembly code. Fix this.
>
> Reported-by: viresh kumar <viresh.kumar@st.com>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> arch/arm/mach-s5pv310/hotplug.c | 4 ++--
> arch/arm/mach-tegra/hotplug.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-s5pv310/hotplug.c
> b/arch/arm/mach-s5pv310/hotplug.c
> index afa5392..c24235c 100644
> --- a/arch/arm/mach-s5pv310/hotplug.c
> +++ b/arch/arm/mach-s5pv310/hotplug.c
> @@ -30,10 +30,10 @@ static inline void cpu_enter_lowpower(void)
> * Turn off coherency
> */
> " mrc p15, 0, %0, c1, c0, 1\n"
> - " bic %0, %0, %2\n"
> + " bic %0, %0, #0x20\n"
> " mcr p15, 0, %0, c1, c0, 1\n"
> " mrc p15, 0, %0, c1, c0, 0\n"
> - " bic %0, %0, #0x04\n"
> + " bic %0, %0, %2\n"
> " mcr p15, 0, %0, c1, c0, 0\n"
> : "=&r" (v)
> : "r" (0), "Ir" (CR_C)
> diff --git a/arch/arm/mach-tegra/hotplug.c b/arch/arm/mach-tegra/hotplug.c
> index a5cb1ce..f329404 100644
> --- a/arch/arm/mach-tegra/hotplug.c
> +++ b/arch/arm/mach-tegra/hotplug.c
> @@ -26,10 +26,10 @@ static inline void cpu_enter_lowpower(void)
> * Turn off coherency
> */
> " mrc p15, 0, %0, c1, c0, 1\n"
> - " bic %0, %0, %2\n"
> + " bic %0, %0, #0x20\n"
> " mcr p15, 0, %0, c1, c0, 1\n"
> " mrc p15, 0, %0, c1, c0, 0\n"
> - " bic %0, %0, #0x04\n"
> + " bic %0, %0, %2\n"
> " mcr p15, 0, %0, c1, c0, 0\n"
> : "=&r" (v)
> : "r" (0), "Ir" (CR_C)
Acked-by: Viresh Kumar <viresh.kumar@st.com>
^ permalink raw reply
* Locking in the clk API
From: Russell King - ARM Linux @ 2011-01-15 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D31A8F1.4080301@weinigel.se>
On Sat, Jan 15, 2011 at 03:02:25PM +0100, Christer Weinigel wrote:
> This feels a bit like perfect being the enemy of good.
>
> On platforms that need to sleep to enable the UART clock, configuring
> the UART as the kernel console should be equivalent to userspace opening
> the UART device, i.e. enable the clock. At least to me that feels like
> an acceptable tradeoff, and if I wanted to save the last bit of power
> I'll have to refrain from using UART as the kernel console.
>
> If both printk to the console and disabling the clock is really really
> neccesary, add a clk_enable_busywait, but that will be a bit of a hack.
Well, we're not discussing a _new_ API here - we're discussing an API
with existing users which works completely fine on the devices its
used, with differing expectations between implementations.
> Both of these feel like they should use a call such as clk_get_atomic
> and be able to handle EWOULDBLOCK/EAGAIN (or whatever error code is used
> to indicate that it would have to sleep) and delegate to a worker thread
> to enable the clock. To catch uses of plain clk_enable from atomic
> contects, add a WARN_ON/BUG_ON(in_atomic()). It won't catch everything,
> but would help a bit at least.
We've never allowed clk_get() to be called in interruptible context,
so that's not the issue. The issue is purely about clk_enable() and
clk_disable() and whether they should be able to be called in atomic
context or not.
We've been around returning EAGAIN, WARN_ONs, BUG_ONs, having clk_enable()
vs clk_enable_atomic(), clk_enable_cansleep() vs clk_enable(), etc.
There's been a lot of talk on this issue for ages with no real progress
that I'm just going to repeat: let's unify those implementations which
use a spinlock for their clks into one consolidated solution, and
a separate consolidated solution for those which use a mutex.
This will at least allow us to have _some_ consolidation of the existing
implementations - and it doesn't add anything to the problem at hand.
It might actually help identify what can be done at code level to resolve
this issue.
^ permalink raw reply
* Locking in the clk API
From: Uwe Kleine-König @ 2011-01-15 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110115145358.GC15996@n2100.arm.linux.org.uk>
Hi Russell,
On Sat, Jan 15, 2011 at 02:53:58PM +0000, Russell King - ARM Linux wrote:
> We've been around returning EAGAIN, WARN_ONs, BUG_ONs, having clk_enable()
> vs clk_enable_atomic(), clk_enable_cansleep() vs clk_enable(), etc.
>
> There's been a lot of talk on this issue for ages with no real progress
> that I'm just going to repeat: let's unify those implementations which
> use a spinlock for their clks into one consolidated solution, and
> a separate consolidated solution for those which use a mutex.
>
> This will at least allow us to have _some_ consolidation of the existing
> implementations - and it doesn't add anything to the problem at hand.
> It might actually help identify what can be done at code level to resolve
> this issue.
Great, so how should we do it? Take Jeremy's patch and make the
differenciation between sleeping and atomic implementation a Kconfig
variable?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Locking in the clk API
From: Russell King - ARM Linux @ 2011-01-15 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110115150331.GB6917@pengutronix.de>
On Sat, Jan 15, 2011 at 04:03:31PM +0100, Uwe Kleine-K?nig wrote:
> Hi Russell,
>
> On Sat, Jan 15, 2011 at 02:53:58PM +0000, Russell King - ARM Linux wrote:
> > We've been around returning EAGAIN, WARN_ONs, BUG_ONs, having clk_enable()
> > vs clk_enable_atomic(), clk_enable_cansleep() vs clk_enable(), etc.
> >
> > There's been a lot of talk on this issue for ages with no real progress
> > that I'm just going to repeat: let's unify those implementations which
> > use a spinlock for their clks into one consolidated solution, and
> > a separate consolidated solution for those which use a mutex.
> >
> > This will at least allow us to have _some_ consolidation of the existing
> > implementations - and it doesn't add anything to the problem at hand.
> > It might actually help identify what can be done at code level to resolve
> > this issue.
> Great, so how should we do it? Take Jeremy's patch and make the
> differenciation between sleeping and atomic implementation a Kconfig
> variable?
No - I've been suggesting for about a week now about doing two entirely
separate consolidations.
I think it would be insane to do the consolidation of the two different
implementations in one patch or even one patch set. There needs to be
a consolidation of spinlock-based clks as one patch set, which is
entirely separate and independent from the consolidation of mutex-based
clks.
What if one of the consolidations turns out to be a problem? Do we want
to throw both out, or do we want to keep as much as we possibly can?
^ permalink raw reply
* [PATCH] ARM: vfp: Fix up exception location in Thumb mode
From: Catalin Marinas @ 2011-01-15 15:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114173050.GJ15996@n2100.arm.linux.org.uk>
On 14 January 2011 17:30, Russell King - ARM Linux
<linux@arm.linux.org.uk> 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.
[...]
> 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.
Yes, that's possible. We probably never tried a Thumb-2 kernel where
VFP isn't present.
> 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.
I have some comments below.
> 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]
The itttt above should just be itt. The reveq is conditionally
compiled and beq doesn't necessarily need one.
> ?#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)
Is r2 here always the PC value following instruction? If the Thumb
instruction was 32-bit, it just points in the middle of the faulting
instruction.
> + ? ? ? @ 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)
That's correct.
> + ? ? ? @ r4 = PC value for the first 16-bit Thumb instruction
I think r4 here points in the middle of tha faulting instruction for
32-bit Thumb.
> + ? ? ? @
> ?#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,14 @@
> ?#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
> +@
> ?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
That's right.
> +@ ?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.
I would say it's always a 32-bit instruction but made up of two 16-bit
values to allow half-word alignment.
--
Catalin
^ permalink raw reply
* [PATCH] ARM: vfp: Fix up exception location in Thumb mode
From: Catalin Marinas @ 2011-01-15 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114184759.GN15996@n2100.arm.linux.org.uk>
On 14 January 2011 18:47, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> 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
Do we need to modify the VFP entry code to avoit the store to ARM_pc?
--
Catalin
^ permalink raw reply
* [PATCH] ARM: vfp: Fix up exception location in Thumb mode
From: Russell King - ARM Linux @ 2011-01-15 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTin_pMzNc-ZL+rVcwaVawer0poyxhatqw5P-A2qW@mail.gmail.com>
On Sat, Jan 15, 2011 at 03:31:04PM +0000, Catalin Marinas wrote:
> On 14 January 2011 17:30, Russell King - ARM Linux
> <linux@arm.linux.org.uk> 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.
> [...]
> > 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.
>
> Yes, that's possible. We probably never tried a Thumb-2 kernel where
> VFP isn't present.
>
> > 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.
>
> I have some comments below.
>
> > 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]
>
> The itttt above should just be itt. The reveq is conditionally
> compiled and beq doesn't necessarily need one.
It's a reveq, so I thought we should cover all the instructions with
an 'eq' conditional for thumb.
>
> > ?#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)
>
> Is r2 here always the PC value following instruction? If the Thumb
> instruction was 32-bit, it just points in the middle of the faulting
> instruction.
Is the T bit ever zero in this case? The code here is:
tst r3, #PSR_T_BIT
subeq r4, r2, #4
1: ldreqt r0, [r4]
reveq r0, r0
beq call_fpe
So, if !T, then we subtract 4 and load the instruction (which was the
faulting instruction). So r2 is the following instruction.
Ah, maybe you're getting confused by the comment. Should we put
an 'eq' suffix on the end of each line? ;)
>
> > + ? ? ? @ 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)
>
> That's correct.
>
> > + ? ? ? @ r4 = PC value for the first 16-bit Thumb instruction
>
> I think r4 here points in the middle of tha faulting instruction for
> 32-bit Thumb.
You're right.
>
> > + ? ? ? @
> > ?#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,14 @@
> > ?#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
> > +@
> > ?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
>
> That's right.
>
> > +@ ?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.
>
> I would say it's always a 32-bit instruction but made up of two 16-bit
> values to allow half-word alignment.
Do you have a suggested replacement text?
^ permalink raw reply
* [PATCH] ARM: vfp: Fix up exception location in Thumb mode
From: Russell King - ARM Linux @ 2011-01-15 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=p+f7TO+_g677VXNJkt-mu+8d8c6T9qgt5MVtn@mail.gmail.com>
On Sat, Jan 15, 2011 at 03:38:16PM +0000, Catalin Marinas wrote:
> On 14 January 2011 18:47, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > 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
>
> Do we need to modify the VFP entry code to avoit the store to ARM_pc?
The one after the sub #4 instruction?
That's answered by the comments... "retry the instruction" and that
r2 = regs->ARM_pc in every case, and both r2 and regs->ARM_pc point
at the _following_ instruction...
I do hope this isn't a case that _more_ comments are making this more
confusing (which seems to be the way with documentation - the more
words you use, the more questions people have). Maybe we should get
rid of all the comments instead?
^ permalink raw reply
* Locking in the clk API
From: Uwe Kleine-König @ 2011-01-15 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110115151507.GD15996@n2100.arm.linux.org.uk>
On Sat, Jan 15, 2011 at 03:15:07PM +0000, Russell King - ARM Linux wrote:
> On Sat, Jan 15, 2011 at 04:03:31PM +0100, Uwe Kleine-K?nig wrote:
> > Hi Russell,
> >
> > On Sat, Jan 15, 2011 at 02:53:58PM +0000, Russell King - ARM Linux wrote:
> > > We've been around returning EAGAIN, WARN_ONs, BUG_ONs, having clk_enable()
> > > vs clk_enable_atomic(), clk_enable_cansleep() vs clk_enable(), etc.
> > >
> > > There's been a lot of talk on this issue for ages with no real progress
> > > that I'm just going to repeat: let's unify those implementations which
> > > use a spinlock for their clks into one consolidated solution, and
> > > a separate consolidated solution for those which use a mutex.
> > >
> > > This will at least allow us to have _some_ consolidation of the existing
> > > implementations - and it doesn't add anything to the problem at hand.
> > > It might actually help identify what can be done at code level to resolve
> > > this issue.
> > Great, so how should we do it? Take Jeremy's patch and make the
> > differenciation between sleeping and atomic implementation a Kconfig
> > variable?
>
> No - I've been suggesting for about a week now about doing two entirely
> separate consolidations.
I didn't read that out of your mails.
> I think it would be insane to do the consolidation of the two different
> implementations in one patch or even one patch set. There needs to be
> a consolidation of spinlock-based clks as one patch set, which is
> entirely separate and independent from the consolidation of mutex-based
> clks.
I think they should share most of the code. Apart from calling
different locking functions they should be pretty much identical, no?
> What if one of the consolidations turns out to be a problem? Do we want
> to throw both out, or do we want to keep as much as we possibly can?
Do you really expect fundamental problems that make it necessary to
switch all platforms that use the (say) sleeping variant back to their
original implementation? I don't think that when the general idea of
using clk_ops prooves for the atomic case it cannot happen that a
"native" implementation for a sleeping clk is better that a sleeping
clk_ops implementation.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] Remove CPU_32v6K dependencies in asm/spinlock.h
From: Russell King - ARM Linux @ 2011-01-15 16:11 UTC (permalink / raw)
To: linux-arm-kernel
SMP requires at least the ARMv6K extensions to be present, so if we're
running on SMP, the WFE and SEV instructions must be available.
However, when we run on UP, the v6K extensions may not be available,
and so we don't want WFE/SEV to be in the instruction stream. Use the
SMP alternatives infrastructure to replace these instructions with NOPs
if we build for SMP but run on UP.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
This removes one of the reasons that OMAP disables V6K on multi-omap
kernels - which subtly breaks SMP support. Build tested and verified
by examination of resulting disassembly, but not boot tested.
arch/arm/include/asm/spinlock.h | 37 +++++++++++++++++++++++++------------
1 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
index 17eb355..da1af52 100644
--- a/arch/arm/include/asm/spinlock.h
+++ b/arch/arm/include/asm/spinlock.h
@@ -5,17 +5,36 @@
#error SMP not supported on pre-ARMv6 CPUs
#endif
+/*
+ * sev and wfe are ARMv6K extensions. Uniprocessor ARMv6 may not have the K
+ * extensions, so when running on UP, we have to patch these instructions away.
+ */
+#define ALT_SMP(smp, up) \
+ "9998: " smp "\n" \
+ " .pushsection \".alt.smp.init\", \"a\"\n" \
+ " .long 9998b\n" \
+ " " up "\n" \
+ " .popsection\n"
+
+#ifdef CONFIG_THUMB2_KERNEL
+#define SEV ALT_SMP("sev.w", "nop.w")
+#define WFE(cond) ALT_SMP("wfe" cond ".w", "nop.w")
+#else
+#define SEV ALT_SMP("sev", "nop")
+#define WFE(cond) ALT_SMP("wfe" cond, "nop")
+#endif
+
static inline void dsb_sev(void)
{
#if __LINUX_ARM_ARCH__ >= 7
__asm__ __volatile__ (
"dsb\n"
- "sev"
+ SEV
);
-#elif defined(CONFIG_CPU_32v6K)
+#else
__asm__ __volatile__ (
"mcr p15, 0, %0, c7, c10, 4\n"
- "sev"
+ SEV
: : "r" (0)
);
#endif
@@ -46,9 +65,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
__asm__ __volatile__(
"1: ldrex %0, [%1]\n"
" teq %0, #0\n"
-#ifdef CONFIG_CPU_32v6K
-" wfene\n"
-#endif
+ WFE("ne")
" strexeq %0, %2, [%1]\n"
" teqeq %0, #0\n"
" bne 1b"
@@ -107,9 +124,7 @@ static inline void arch_write_lock(arch_rwlock_t *rw)
__asm__ __volatile__(
"1: ldrex %0, [%1]\n"
" teq %0, #0\n"
-#ifdef CONFIG_CPU_32v6K
-" wfene\n"
-#endif
+ WFE("ne")
" strexeq %0, %2, [%1]\n"
" teq %0, #0\n"
" bne 1b"
@@ -176,9 +191,7 @@ static inline void arch_read_lock(arch_rwlock_t *rw)
"1: ldrex %0, [%2]\n"
" adds %0, %0, #1\n"
" strexpl %1, %0, [%2]\n"
-#ifdef CONFIG_CPU_32v6K
-" wfemi\n"
-#endif
+ WFE("mi")
" rsbpls %0, %1, #0\n"
" bmi 1b"
: "=&r" (tmp), "=&r" (tmp2)
^ permalink raw reply related
* Locking in the clk API
From: Russell King - ARM Linux @ 2011-01-15 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110115160329.GD6917@pengutronix.de>
On Sat, Jan 15, 2011 at 05:03:29PM +0100, Uwe Kleine-K?nig wrote:
> On Sat, Jan 15, 2011 at 03:15:07PM +0000, Russell King - ARM Linux wrote:
> > No - I've been suggesting for about a week now about doing two entirely
> > separate consolidations.
> I didn't read that out of your mails.
It was actually four days ago:
| Maybe another approach for the time being is to unify in two steps: first
| unify the implementations which use a spinlock - and those which can use
| a spinlock, and separately those which must use a mutex.
|
| Then this issue can be revisited in the future.
> > I think it would be insane to do the consolidation of the two different
> > implementations in one patch or even one patch set. There needs to be
> > a consolidation of spinlock-based clks as one patch set, which is
> > entirely separate and independent from the consolidation of mutex-based
> > clks.
> I think they should share most of the code. Apart from calling
> different locking functions they should be pretty much identical, no?
That way you get unions of mutexes and spinlocks (which is one thing
we're trying to avoid) and conditionals controlling whether a mutex
or spinlock is taken - which we've already ascertained was strongly
objected to by folk in mainline (and quite rightfully so IMHO.)
> > What if one of the consolidations turns out to be a problem? Do we want
> > to throw both out, or do we want to keep as much as we possibly can?
> Do you really expect fundamental problems that make it necessary to
> switch all platforms that use the (say) sleeping variant back to their
> original implementation? I don't think that when the general idea of
> using clk_ops prooves for the atomic case it cannot happen that a
> "native" implementation for a sleeping clk is better that a sleeping
> clk_ops implementation.
I'm saying keep all the options open until we've got the whole thing
sorted out. If you think it's possible to do without creating a mess
in the process - and without unions of mutexes and spinlocks or
conditionals controlling whether we use mutex_lock vs spin_lock then
please show the patches.
^ permalink raw reply
* Locking in the clk API
From: Uwe Kleine-König @ 2011-01-15 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110115162121.GI15996@n2100.arm.linux.org.uk>
On Sat, Jan 15, 2011 at 04:21:21PM +0000, Russell King - ARM Linux wrote:
> On Sat, Jan 15, 2011 at 05:03:29PM +0100, Uwe Kleine-K?nig wrote:
> > On Sat, Jan 15, 2011 at 03:15:07PM +0000, Russell King - ARM Linux wrote:
> > > No - I've been suggesting for about a week now about doing two entirely
> > > separate consolidations.
> > I didn't read that out of your mails.
>
> It was actually four days ago:
> | Maybe another approach for the time being is to unify in two steps: first
> | unify the implementations which use a spinlock - and those which can use
> | a spinlock, and separately those which must use a mutex.
> |
> | Then this issue can be revisited in the future.
>
> > > I think it would be insane to do the consolidation of the two different
> > > implementations in one patch or even one patch set. There needs to be
> > > a consolidation of spinlock-based clks as one patch set, which is
> > > entirely separate and independent from the consolidation of mutex-based
> > > clks.
> > I think they should share most of the code. Apart from calling
> > different locking functions they should be pretty much identical, no?
>
> That way you get unions of mutexes and spinlocks (which is one thing
> we're trying to avoid) and conditionals controlling whether a mutex
> or spinlock is taken - which we've already ascertained was strongly
> objected to by folk in mainline (and quite rightfully so IMHO.)
If the decision is done basing on a Kconfig symbol it's an #ifdef.
That's not great but IMHO much better than a runtime decision.
> > > What if one of the consolidations turns out to be a problem? Do we want
> > > to throw both out, or do we want to keep as much as we possibly can?
> > Do you really expect fundamental problems that make it necessary to
> > switch all platforms that use the (say) sleeping variant back to their
> > original implementation? I don't think that when the general idea of
> > using clk_ops prooves for the atomic case it cannot happen that a
> > "native" implementation for a sleeping clk is better that a sleeping
> > clk_ops implementation.
>
> I'm saying keep all the options open until we've got the whole thing
> sorted out. If you think it's possible to do without creating a mess
> in the process - and without unions of mutexes and spinlocks or
> conditionals controlling whether we use mutex_lock vs spin_lock then
> please show the patches.
Jeremy: I think it would be quite easy to convert your series to use an
#ifdef instead of the flag. I don't want to do this (at least not
without asking first) because it's your series, not mine. How should we
proceed?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2] ARM: pxa: PalmZ72: Add OV9640 camera support
From: Bjørn Forsman @ 2011-01-15 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295054277-7879-1-git-send-email-marek.vasut@gmail.com>
Hi,
On 15 January 2011 02:17, Marek Vasut <marek.vasut@gmail.com> wrote:
> Rework of patch from 2009:
> PalmZ72: Add support for OV9640 camera sensor
>
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> ---
> v2: Use gpio_request_array()/gpio_free_array() array
>
> ?arch/arm/mach-pxa/include/mach/palmz72.h | ? ?5 +
> ?arch/arm/mach-pxa/palmz72.c ? ? ? ? ? ? ?| ?127 ++++++++++++++++++++++++++++++
> ?2 files changed, 132 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/include/mach/palmz72.h b/arch/arm/mach-pxa/include/mach/palmz72.h
> index 2bbcf70..0d4700a 100644
> --- a/arch/arm/mach-pxa/include/mach/palmz72.h
> +++ b/arch/arm/mach-pxa/include/mach/palmz72.h
[snip]
> +static int palmz72_camera_power(struct device *dev, int power)
> +{
> + ? ? ? gpio_set_value(GPIO_NR_PALMZ72_CAM_PWDN, !power);
> + ? ? ? mdelay(50);
> + ? ? ? return 0;
> +}
> +
> +static int palmz72_camera_reset(struct device *dev)
> +{
> + ? ? ? gpio_set_value(GPIO_NR_PALMZ72_CAM_RESET, 1);
> + ? ? ? mdelay(50);
> + ? ? ? gpio_set_value(GPIO_NR_PALMZ72_CAM_RESET, 0);
> + ? ? ? mdelay(50);
> + ? ? ? return 0;
> +}
(Sorry if these are stupid newbie-questions.)
Is the entire kernel blocked during the above mdelay()s or
just some kernel thread? (Or: will this add like 100ms or 150ms
to boot time?)
Can mdelay() be replaced with something non-blocking?
[snip]
Best regards,
Bj?rn Forsman
^ permalink raw reply
* [patch 1/2] Fix pwm-related build failure
From: Sergei Shtylyov @ 2011-01-15 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110113113006.269152863@rtp-net.org>
Hello.
On 13-01-2011 14:26, Arnaud Patard (Rtp) wrote:
> Commit 076762aa52de48688f6e1b6999fe58d736479f37 is adding a macro whis is
Please also specify the commit summary in parens.
> calling imx_add_mxc_pwm() but gives it 2 parameters while it's taking only
> one parameters.
WBR, Sergei
^ permalink raw reply
* IXP4xx current status
From: Krzysztof Halasa @ 2011-01-15 16:48 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I just compiled and booted current Linus' git tree on my Goramo
MultiLink (IXP425-based) and it seems to work.
I have two IXP4xx patches to be sent to Linus at this point, including:
- Rename FREQ macro to avoid collisions by Ben Hutchings
- Fix qmgr_release_queue() flushing unexpected queue entries (mine).
If I'm supposed to add anything to this list, please let me know.
--
Krzysztof Halasa
^ permalink raw reply
* [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
From: Russell King - ARM Linux @ 2011-01-15 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110115003734.GV4957@atomide.com>
On Fri, Jan 14, 2011 at 04:37:34PM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 16:24]:
> > On Fri, Jan 14, 2011 at 04:12:55PM -0800, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 15:58]:
> > > >
> > > > # ARMv6k
> > > > config CPU_32v6K
> > > > bool "Support ARM V6K processor extensions" if !SMP
> > > > depends on CPU_V6 || CPU_V7
> > > > default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
> > > >
> > > > OMAP2 prevents the selection of armv6k support. This is probably a very
> > > > bad idea if you want to run the resulting kernel on SMP hardware as it
> > > > removes a barrier in the spinlock code and disables the SMP-safe bitops.
> > >
> > > I have some ideas to fix this. Unfortunately it will be inefficient
> > > as spinlock.h can be included from modules too :( I was thinking we can
> > > implement dsb_sev in the proc-*.S functions for the unoptimized multi-arm
> > > builds.
> >
> > For spinlocks, the important thing is the barrier. The wfe/sev are an
> > optimization. The barrier contained with the ifdef is a valid V6
> > instruction.
>
> OK, great it's just drain WB. Then we can do the ussual iffdeffery
> on it for multi-arm builds as it does not depend on the 6K extensions.
> I can do a patch for this on Monday, gotta run now.
>
> > > > The original patch which started turning this off was from the MX3 stuff,
> > > > but without explaination.
> > > >
> > > > However, OMAP extended this to disabling the select statement for CPU_32v6K
> > > > even if CPU_V7 is set:
> > > >
> > > > config CPU_V7
> > > > bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB |- select CPU_32v6K
> > > > + select CPU_32v6K if !ARCH_OMAP2
> > > >
> > > > Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and this
> > > > patch should not have been merged.
> > >
> > > The only way we can fix that is do smp_on_up style rewriting of the assembly
> > > during init between CPUv6 and v6K. Want me to do a patch for that?
> >
> > The bitops code is quite different between the two versions, and I doubt
> > the smp_on_up rewriting will look at all pretty. I think it needs an
> > alternative idea - like not using the 'byte' operations at all.
> >
> > Whether we have any code which passes non-word aligned pointers to bitops
> > isn't particularly known - in theory they should all be unsigned long *'s,
> > so should be word-aligned. Who knows what filesystems do though... and
> > such a change could be disasterous to peoples data if the block/inode
> > bitmaps get corrupted.
>
> Hmm, how about emulation of those instructions for non-v6K ARMv6 processors?
> I guess we could do some address checking in the bitops functions too for
> multi-arm builds..
>
> > IOW, such a change needs testing on a box where a range of filesystems are
> > used, and the filesystems can be thrown away if corrupted.
>
> Or we could patch in the address checking first and only disable it
> later if now warnings.
Right, this is what I'm going to do - and it's going to *intentionally*
break omap2plus_defconfig. Please see the commit comments for the
reason why. We need to address the V6 issue properly without risking
users data.
To Sascha: this replaces the previous patch which I asked for your ack.
8<-----------
Subject: [PATCH] ARM: Do not disable CPU_32v6K based on platform selection
CPU_32v6K controls whether we use the ARMv6K extension instructions in
the kernel, and in some places whether we use SMP-safe code sequences
(eg, bitops.)
Having this configuration option disabled on a SMP supporting kernel
results in a problem: the SMP-unsafe code sequences will be used, and
as such the resulting kernel is not SMP safe.
As the atomic bitops are used by filesystems (eg, ext2 - to manipulate
the inode and block bitmaps) not having the SMP safe code sequences is
fatal for filesystem data integrity. So running an SMP kernel without
CPU_32v6K set is dangerous.
MX3 prevents the selection of this option to ensure that it is not
enabled for their CPU, which is ARMv6 only. MX3 folk need to ensure
that their kernel is properly configured.
OMAP prevents the selection of this option in an attempt to produce a
kernel which runs on architectures from ARMv6 to ARMv7 MPCore.
Balancing between oopsing on boot and filesystem corruption, it is far
more preferable to oops on boot until the code sequences are sorted out
properly.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
arch/arm/mm/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 49db8b3..d61af9c 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -405,7 +405,7 @@ config CPU_V6
config CPU_32v6K
bool "Support ARM V6K processor extensions" if !SMP
depends on CPU_V6 || CPU_V7
- default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
+ default y if SMP
help
Say Y here if your ARMv6 processor supports the 'K' extension.
This enables the kernel to use some instructions not present
--
1.6.2.5
^ permalink raw reply related
* IXP4xx current status
From: Russell King - ARM Linux @ 2011-01-15 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m3lj2mi047.fsf@intrepid.localdomain>
On Sat, Jan 15, 2011 at 05:48:40PM +0100, Krzysztof Halasa wrote:
> Hi,
>
> I just compiled and booted current Linus' git tree on my Goramo
> MultiLink (IXP425-based) and it seems to work.
>
> I have two IXP4xx patches to be sent to Linus at this point, including:
> - Rename FREQ macro to avoid collisions by Ben Hutchings
> - Fix qmgr_release_queue() flushing unexpected queue entries (mine).
>
> If I'm supposed to add anything to this list, please let me know.
It would be nice to have the patches posted here, so they end up in the
list archives (and so are searchable for "why was that done?" type
questions.)
^ 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