* alignment faults in 3.6
From: Nicolas Pitre @ 2012-10-06 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAG5Tg6Ut9Q_Sn4xT+owr=ZxCc36NERhg=eATceQKQ=mKj7G-gg@mail.gmail.com>
On Sat, 6 Oct 2012, Mans Rullgard wrote:
> On 5 October 2012 23:42, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Oct 05, 2012 at 11:37:40PM +0100, Mans Rullgard wrote:
> >> The problem is the (__be32 *) casts. This is a normal pointer to a 32-bit,
> >> which is assumed to be aligned, and the cast overrides the packed attribute
> >> from the struct. Dereferencing these cast expressions must be done with the
> >> macros from asm/unaligned.h
> >
> > Again, not going to happen.
>
> There are only two options for fixing this:
>
> 1. Ensure the struct is always aligned.
> 2. Declare it packed (and fix casts).
>
> Refusing to do either leaves us with a broken kernel. Is that what you want?
Once again, please bring this up with davem and also CC
netdev at vger.kernel.org as he's the point of contention here.
Nicolas
^ permalink raw reply
* pm: add suspend_mem and suspend_standby support
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-06 16:14 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
The following changes since commit 5f3d2f2e1a63679cf1c4a4210f2f1cc2f335bef6:
Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2012-10-06 03:16:12 +0900)
are available in the git repository at:
git://git.jcrosoft.org/linux-2.6.git tags/pm_suspend_standby_mem
for you to fetch changes up to b73c8f97aa8e720bd3b921159687d00626c99d63:
arm: at91: drop at91_suspend_entering_slow_clock (2012-10-06 18:06:25 +0800)
----------------------------------------------------------------
pm: add suspend_mem and suspend_standby support
Today when we go to suspend we can not knwon at drivers level if we go in
STANDBY or MEM. Fix this by introducing two new callback suspend_mem and
suspend_standby.
If a bus or drivers does not need to care about this distinction we fallback to
suspend. This will allow to do not update the current bus or drivers.
This is needed as example by at91 OHCI, UDC and atmel serial
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
----------------------------------------------------------------
Jean-Christophe PLAGNIOL-VILLARD (6):
pm: add suspend_mem and suspend_standby support
platform: pm: add suspend_mem and suspend_standby support
tty: atmel_serial: switch pm ops
usb: ohci-at91: switch pm ops
usb: at91_ude: switch pm ops
arm: at91: drop at91_suspend_entering_slow_clock
arch/arm/mach-at91/include/mach/board.h | 3 ---
arch/arm/mach-at91/pm.c | 24 ------------------------
drivers/base/platform.c | 40 ++++++++++++++++++++++++++++++++++++++++
drivers/base/power/main.c | 12 ++++++++++++
drivers/tty/serial/atmel_serial.c | 52 +++++++++++++++++++++++++++-------------------------
drivers/usb/gadget/at91_udc.c | 34 +++++++++++++++++++++++-----------
drivers/usb/host/ohci-at91.c | 38 ++++++++++++++++++++++++--------------
include/linux/platform_device.h | 6 ++++++
include/linux/pm.h | 9 +++++++++
kernel/power/suspend.c | 16 ++++++++++++++--
10 files changed, 155 insertions(+), 79 deletions(-)
Best Regards,
J.
^ permalink raw reply
* [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
From: Marc Zyngier @ 2012-10-06 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121006154052.GB3874@atomide.com>
On Sat, 6 Oct 2012 08:40:52 -0700, Tony Lindgren <tony@atomide.com> wrote:
> * Nicolas Pitre <nicolas.pitre@linaro.org> [121006 08:33]:
>> On Sat, 6 Oct 2012, Tony Lindgren wrote:
>>
>> > * Marc Zyngier <marc.zyngier@arm.com> [121006 03:19]:
>> >
>> > > If so, that indicates some side effect of the safe_svcmode_maskall
>> > > macro,
>> > > and I suspect the "movs pc, lr" bit.
>> > >
>> > > Can you try the attached patch? It basically falls back to the
>> > > previous
>> > > behaviour if not entered in HYP mode.
>> >
>> > Yes, with this it boots OK.
>>
>> OK. In that case, I suggest this patch be sent to Russell to fix this
>> issue so he could push the ARM stuff to Linus ASAP.
>>
>> Acked-by: Nicolas Pitre <nico@linaro.org>
>
> Yes we can come back to this:
>
> Tested-by: Tony Lindgren <tony@atomide.com>
Now in Russell's patch system as #7549/1.
Thanks a lot for your help on this both of you.
M.
--
Fast, cheap, reliable. Pick two.
^ permalink raw reply
* alignment faults in 3.6
From: Mans Rullgard @ 2012-10-06 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121005224235.GR4625@n2100.arm.linux.org.uk>
On 5 October 2012 23:42, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Oct 05, 2012 at 11:37:40PM +0100, Mans Rullgard wrote:
>> The problem is the (__be32 *) casts. This is a normal pointer to a 32-bit,
>> which is assumed to be aligned, and the cast overrides the packed attribute
>> from the struct. Dereferencing these cast expressions must be done with the
>> macros from asm/unaligned.h
>
> Again, not going to happen.
There are only two options for fixing this:
1. Ensure the struct is always aligned.
2. Declare it packed (and fix casts).
Refusing to do either leaves us with a broken kernel. Is that what you want?
--
Mans Rullgard / mru
^ permalink raw reply
* [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
From: Tony Lindgren @ 2012-10-06 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6d3553bfe8a2d1ac88cab852100616a7@localhost>
* Marc Zyngier <marc.zyngier@arm.com> [121006 03:19]:
>
> If so, that indicates some side effect of the safe_svcmode_maskall macro,
> and I suspect the "movs pc, lr" bit.
>
> Can you try the attached patch? It basically falls back to the previous
> behaviour if not entered in HYP mode.
...
> diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
> index 658a15d..b21b97f 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -254,16 +254,17 @@
> mov lr , \reg
> and lr , lr , #MODE_MASK
> cmp lr , #HYP_MODE
> - orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT
> + orr \reg , \reg , #PSR_I_BIT | PSR_F_BIT
> bic \reg , \reg , #MODE_MASK
> orr \reg , \reg , #SVC_MODE
> THUMB( orr \reg , \reg , #PSR_T_BIT )
> - msr spsr_cxsf, \reg
> - adr lr, BSYM(2f)
> bne 1f
> + orr \reg, \reg, #PSR_A_BIT
> + adr lr, BSYM(2f)
> + msr spsr_cxsf, \reg
> __MSR_ELR_HYP(14)
> __ERET
> -1: movs pc, lr
> +1: msr cpsr_c, \reg
> 2:
> .endm
>
The minimal version of this that still boots on my n800 is just
the last change of the above patch:
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -263,7 +263,7 @@ THUMB( orr \reg , \reg , #PSR_T_BIT )
bne 1f
__MSR_ELR_HYP(14)
__ERET
-1: movs pc, lr
+1: msr cpsr_c, \reg
2:
.endm
^ permalink raw reply
* [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
From: Alan Cox @ 2012-10-06 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121006123803.GD15246@n2100.arm.linux.org.uk>
On Sat, 6 Oct 2012 13:38:03 +0100
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> Hi,
>
> This series of patches fixes multiple flow control issues with the OMAP
> serial driver, and prepares the driver for DMA engine conversion. We
> require hardware assisted flow control to work properly for DMA support
> otherwise we have no way to properly pause the transmitter.
All the generic parts
Acked-by: Alan Cox <alan@linux.intel.com>
^ permalink raw reply
* [RFC 20/24] SERIAL: core: add xmit buffer allocation callbacks
From: Alan Cox @ 2012-10-06 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1TKTlL-0002ni-MB@rmk-PC.arm.linux.org.uk>
On Sat, 06 Oct 2012 13:45:47 +0100
Russell King <rmk+kernel@arm.linux.org.uk> wrote:
> This allows drivers (such as OMAP serial) to allocate and free their
> transmit buffers in a sane manner, rather than working around the
> buffer allocation provided by serial_core.
I think this just illustrates how broken the serial_core layering is in
that drivers can't treat it as a library but get constrained by it.
Fine for now and actually probably a useful hook to begin removing the
circ buffers for the kernel generic kfifo and other work that needs doing
eventually.
Alan
^ permalink raw reply
* [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
From: Russell King - ARM Linux @ 2012-10-06 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1210061129080.16518@xanadu.home>
On Sat, Oct 06, 2012 at 11:32:16AM -0400, Nicolas Pitre wrote:
> On Sat, 6 Oct 2012, Tony Lindgren wrote:
> > * Marc Zyngier <marc.zyngier@arm.com> [121006 03:19]:
> >
> > > If so, that indicates some side effect of the safe_svcmode_maskall macro,
> > > and I suspect the "movs pc, lr" bit.
> > >
> > > Can you try the attached patch? It basically falls back to the previous
> > > behaviour if not entered in HYP mode.
> >
> > Yes, with this it boots OK.
>
> OK. In that case, I suggest this patch be sent to Russell to fix this
> issue so he could push the ARM stuff to Linus ASAP.
>
> Acked-by: Nicolas Pitre <nico@linaro.org>
I've already sent the pull request (it's late enough already for the
first bunch of stuff... Linus' truely brilliant timing for the N'th
time sees the merge window open when I'm away - why does he keep doing
that to me?) for everything _except_ stuff in my 'devel-stable' branch,
which includes the opcodes, virt, and new cache maintanence stuff.
I won't be sending Linus another pull request until at least three
days after he merges the current request, so we'll just have to hope
that this doesn't turn out to be a short merge window...
^ permalink raw reply
* [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
From: Tony Lindgren @ 2012-10-06 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1210061129080.16518@xanadu.home>
* Nicolas Pitre <nicolas.pitre@linaro.org> [121006 08:33]:
> On Sat, 6 Oct 2012, Tony Lindgren wrote:
>
> > * Marc Zyngier <marc.zyngier@arm.com> [121006 03:19]:
> >
> > > If so, that indicates some side effect of the safe_svcmode_maskall macro,
> > > and I suspect the "movs pc, lr" bit.
> > >
> > > Can you try the attached patch? It basically falls back to the previous
> > > behaviour if not entered in HYP mode.
> >
> > Yes, with this it boots OK.
>
> OK. In that case, I suggest this patch be sent to Russell to fix this
> issue so he could push the ARM stuff to Linus ASAP.
>
> Acked-by: Nicolas Pitre <nico@linaro.org>
Yes we can come back to this:
Tested-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
From: Russell King - ARM Linux @ 2012-10-06 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121006123803.GD15246@n2100.arm.linux.org.uk>
Another issue:
serial_omap_set_termios()
{
...
/* FIFOs and DMA Settings */
/* FCR can be changed only when the
* baud clock is not running
* DLL_REG and DLH_REG set to 0.
*/
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
serial_out(up, UART_DLL, 0);
serial_out(up, UART_DLM, 0);
serial_out(up, UART_LCR, 0);
...
serial_out(up, UART_FCR, up->fcr);
...
}
serial_omap_restore_context()
{
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B); /* Config B mode */
serial_out(up, UART_DLL, up->dll);
serial_out(up, UART_DLM, up->dlh);
serial_out(up, UART_LCR, 0x0); /* Operational mode */
serial_out(up, UART_IER, up->ier);
serial_out(up, UART_FCR, up->fcr);
}
Either the comment is wrong, or the code in serial_omap_restore_context()
is wrong; they can't both be right. Please can someone let me know which
is the right version so we can fix that inconsistency.
Thanks.
^ permalink raw reply
* [PATCH 1/3] ARM: dts: imx53-qsb: Use pinctrl for gpio-led
From: Shawn Guo @ 2012-10-06 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348702057-2351-1-git-send-email-festevam@gmail.com>
On Wed, Sep 26, 2012 at 08:27:35PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> Since commit 8fe4554f (leds: leds-gpio: adopt pinctrl support) gpio-led driver
> has pinctrl support, so setup the gpio led pin via pinctrl and avoid the
> following warning:
>
> leds-gpio leds.2: pins are not configured from the driver
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Queued first 2 patches for 3.8, and leave patch #3 to Sascha.
Shawn
^ permalink raw reply
* [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
From: Nicolas Pitre @ 2012-10-06 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121006144252.GY3874@atomide.com>
On Sat, 6 Oct 2012, Tony Lindgren wrote:
> * Marc Zyngier <marc.zyngier@arm.com> [121006 03:19]:
>
> > If so, that indicates some side effect of the safe_svcmode_maskall macro,
> > and I suspect the "movs pc, lr" bit.
> >
> > Can you try the attached patch? It basically falls back to the previous
> > behaviour if not entered in HYP mode.
>
> Yes, with this it boots OK.
OK. In that case, I suggest this patch be sent to Russell to fix this
issue so he could push the ARM stuff to Linus ASAP.
Acked-by: Nicolas Pitre <nico@linaro.org>
Nicolas
^ permalink raw reply
* [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
From: Marc Zyngier @ 2012-10-06 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1210060955230.16518@xanadu.home>
On Sat, 6 Oct 2012 10:06:00 -0400 (EDT), Nicolas Pitre
<nicolas.pitre@linaro.org> wrote:
> On Sat, 6 Oct 2012, Marc Zyngier wrote:
>
>> Hi Tony,
>>
>> On Fri, 5 Oct 2012 13:08:22 -0700, Tony Lindgren <tony@atomide.com>
>> wrote:
>> > Hi,
>> >
>> > * Marc Zyngier <marc.zyngier@arm.com> [120907 10:04]:
>> >> From: Dave Martin <dave.martin@linaro.org>
>> >>
>> >> This patch does two things:
>> >>
>> >> * Ensure that asynchronous aborts are masked at kernel entry.
>> >> The bootloader should be masking these anyway, but this reduces
>> >> the damage window just in case it doesn't.
>> >>
>> >> * Enter svc mode via exception return to ensure that CPU state is
>> >> properly serialised. This does not matter when switching from
>> >> an ordinary privileged mode ("PL1" modes in ARMv7-AR rev C
>> >> parlance), but it potentially does matter when switching from a
>> >> another privileged mode such as hyp mode.
>> >>
>> >> This should allow the kernel to boot safely either from svc mode or
>> >> hyp mode, even if no support for use of the ARM Virtualization
>> >> Extensions is built into the kernel.
>> >>
>> >> Signed-off-by: Dave Martin <dave.martin@linaro.org>
>> >> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> >
>> > Just bisected this down in linux-next for breaking booting of
>> > my omap2420 ARMv6 based n8x0..
>> >
>> >> --- a/arch/arm/kernel/head.S
>> >> +++ b/arch/arm/kernel/head.S
>> >> @@ -83,8 +83,12 @@ ENTRY(stext)
>> >> THUMB( .thumb ) @ switch to Thumb now.
>> >> THUMB(1: )
>> >>
>> >> - setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode
>> >> - @ and irqs disabled
>> >> +#ifdef CONFIG_ARM_VIRT_EXT
>> >> + bl __hyp_stub_install
>> >> +#endif
>> >> + @ ensure svc mode and all interrupts masked
>> >> + safe_svcmode_maskall r9
>> >> +
>> >> mrc p15, 0, r9, c0, c0 @ get processor id
>> >> bl __lookup_processor_type @ r5=procinfo r9=cpuid
>> >> movs r10, r5 @ invalid processor (r5=0)?
>> >
>> > ..and looks like undoing this part fixes it. Any ideas?
>> >
>> > I quickly tried disabling ARCH_OMAP3 and ARCH_OMAP4 so it's
>> > ARMv6 but that does not help.
>>
>> If you compiled for v6 only, we can safely exclude __hyp_stub_install,
>> and
>> I assume that you get past the decompressor.
>>
>> If so, that indicates some side effect of the safe_svcmode_maskall
macro,
>> and I suspect the "movs pc, lr" bit.
>
> That would be surprizing if the "movs pc, lr" was to blame. This should
> work on all architectures.
>
> However the A bit might be to blame.
>
>> Can you try the attached patch? It basically falls back to the previous
>> behaviour if not entered in HYP mode.
>
> This is likely to work of course. However I think we should try to
> pinpoint the exact problem i.e. whether it is the A bit or the "movs pc,
> lr" which makes a difference (it is unlikely to be both).
Agreed. We need to get to the bottom of this. Also, finding out which
revisions of the 1136 are present on both of Tony's platforms could help
understanding why this works on OMAP 2430 and not 2420.
> So I was about to suggest to test this patch as well:
>
> diff --git a/arch/arm/include/asm/assembler.h
> b/arch/arm/include/asm/assembler.h
> index 683a1e6b60..118e22ee46 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -254,8 +254,7 @@
> mov lr , \reg
> and lr , lr , #MODE_MASK
> cmp lr , #HYP_MODE
> - orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT
> - bic \reg , \reg , #MODE_MASK
> + mov \reg , #PSR_I_BIT | PSR_F_BIT
> orr \reg , \reg , #SVC_MODE
> THUMB( orr \reg , \reg , #PSR_T_BIT )
> msr spsr_cxsf, \reg
Yup, that should give us all the information we need.
Thanks Nico.
M.
--
Fast, cheap, reliable. Pick two.
^ permalink raw reply
* [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
From: Tony Lindgren @ 2012-10-06 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1210060955230.16518@xanadu.home>
* Nicolas Pitre <nicolas.pitre@linaro.org> [121006 07:07]:
> On Sat, 6 Oct 2012, Marc Zyngier wrote:
> >
> > If so, that indicates some side effect of the safe_svcmode_maskall macro,
> > and I suspect the "movs pc, lr" bit.
>
> That would be surprizing if the "movs pc, lr" was to blame. This should
> work on all architectures.
>
> However the A bit might be to blame.
>
> > Can you try the attached patch? It basically falls back to the previous
> > behaviour if not entered in HYP mode.
>
> This is likely to work of course. However I think we should try to
> pinpoint the exact problem i.e. whether it is the A bit or the "movs pc,
> lr" which makes a difference (it is unlikely to be both).
>
> So I was about to suggest to test this patch as well:
No luck with this patch alone.
Regards,
Tony
> diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
> index 683a1e6b60..118e22ee46 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -254,8 +254,7 @@
> mov lr , \reg
> and lr , lr , #MODE_MASK
> cmp lr , #HYP_MODE
> - orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT
> - bic \reg , \reg , #MODE_MASK
> + mov \reg , #PSR_I_BIT | PSR_F_BIT
> orr \reg , \reg , #SVC_MODE
> THUMB( orr \reg , \reg , #PSR_T_BIT )
> msr spsr_cxsf, \reg
>
>
> Nicolas
^ permalink raw reply
* [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
From: Tony Lindgren @ 2012-10-06 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6d3553bfe8a2d1ac88cab852100616a7@localhost>
Hi,
* Marc Zyngier <marc.zyngier@arm.com> [121006 03:19]:
>
> If you compiled for v6 only, we can safely exclude __hyp_stub_install, and
> I assume that you get past the decompressor.
Yes, by default it's v6 + v7, but making it v6 only did not help.
> If so, that indicates some side effect of the safe_svcmode_maskall macro,
> and I suspect the "movs pc, lr" bit.
>
> Can you try the attached patch? It basically falls back to the previous
> behaviour if not entered in HYP mode.
Yes, with this it boots OK.
Regards,
Tony
> diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
> index 658a15d..b21b97f 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -254,16 +254,17 @@
> mov lr , \reg
> and lr , lr , #MODE_MASK
> cmp lr , #HYP_MODE
> - orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT
> + orr \reg , \reg , #PSR_I_BIT | PSR_F_BIT
> bic \reg , \reg , #MODE_MASK
> orr \reg , \reg , #SVC_MODE
> THUMB( orr \reg , \reg , #PSR_T_BIT )
> - msr spsr_cxsf, \reg
> - adr lr, BSYM(2f)
> bne 1f
> + orr \reg, \reg, #PSR_A_BIT
> + adr lr, BSYM(2f)
> + msr spsr_cxsf, \reg
> __MSR_ELR_HYP(14)
> __ERET
> -1: movs pc, lr
> +1: msr cpsr_c, \reg
> 2:
> .endm
>
^ permalink raw reply
* [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
From: Russell King - ARM Linux @ 2012-10-06 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121006123803.GD15246@n2100.arm.linux.org.uk>
Another potential bug - in serial_omap_set_termios() there is this:
if (up->use_dma) {
serial_out(up, UART_TI752_TLR, 0);
up->scr |= UART_FCR_TRIGGER_4;
} else {
/* Set receive FIFO threshold to 1 byte */
up->fcr &= ~OMAP_UART_FCR_RX_FIFO_TRIG_MASK;
up->fcr |= (0x1 << OMAP_UART_FCR_RX_FIFO_TRIG_SHIFT);
}
Is that:
up->scr |= UART_FCR_TRIGGER_4;
line really correct? It looks wrong to be using a FCR register mask with
something that ends up in the OMAP SCR register...
I'm beginning to wonder how many of the "workarounds" which have been
applied to this driver, particularly those to do with FIFO triggers and
idle stuff are actually down to the horribly broken and buggy set_termios
code. I'm coming to the conclusion that all those workarounds should be
removed, and we start again from a clean slate with a properly written
driver which observes the register access rules - thereby ensuring that
the correct values get written to the registers that we expect them to.
^ permalink raw reply
* [PATCH v2 27/34] media: mx2_camera: remove cpu_is_xxx by using platform_device_id
From: Mauro Carvalho Chehab @ 2012-10-06 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121006082638.GB20231@S2101-09.ap.freescale.net>
Em Sat, 6 Oct 2012 16:26:40 +0800
Shawn Guo <shawn.guo@linaro.org> escreveu:
> On Thu, Sep 27, 2012 at 04:03:21PM -0300, Mauro Carvalho Chehab wrote:
> > It seems that it depends on some stuff that got merged via the arm tree.
> >
> > Not sure what would the better way to handle that, as applying it via -arm
> > will likely generate conflicts when merging from both trees upstream.
> >
> > If this change is not urgent, maybe it would be better to apply it after
> > the end of the merge window, via either one of the trees.
> >
> That's the original plan, having it merged via arm-soc tree at the end
> of 3.7 merge window. But I was told by arm-soc folks that we already
> have enough conflicts to sort out for this window, and we do not want
> any more. And we have to postpone it to 3.8.
>
> I will publish a topic branch for this series after 3.7-rc1 comes out.
Ok. Btw, as expected, the patch doesn't apply cleanly anymore, due to the
file renames. Waiting for 3.7-rc1 seems to be the right thing to do here.
--
Regards,
Mauro
^ permalink raw reply
* [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
From: Russell King - ARM Linux @ 2012-10-06 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121006123803.GD15246@n2100.arm.linux.org.uk>
On Sat, Oct 06, 2012 at 01:38:03PM +0100, Russell King - ARM Linux wrote:
> Hi,
>
> This series of patches fixes multiple flow control issues with the OMAP
> serial driver, and prepares the driver for DMA engine conversion. We
> require hardware assisted flow control to work properly for DMA support
> otherwise we have no way to properly pause the transmitter.
>
> This is generated against v3.6, and has been developed mainly by testing
> on the OMAP4430 SDP platform.
>
> Flow control seems to be really broken in the OMAP serial driver as things
> stand today. It just about works with software flow control because the
> generic serial core layer is inserting those characters, but only when the
> legacy DMA support is not being used. Otherwise, flow control is
> completely non-functional.
>
> Issues identified in the OMAP serial driver are:
> - set_mctrl() can only assert modem control lines, once asserted it
> is not possible to deassert them.
> - IXOFF controls sending of XON/XOFF characters, not the reception of
> these sequences.
> - IXON controls the recognition of XON/XOFF characters, not the transmission
> of the same.
> - Wrong bitmasks for hardware assisted software flow control. Bit 2
> in EFR enables sending of XON2/XOFF2 which are never set.
> - No point comparing received characters against XOFF2 ('special character
> detect') as XOFF2 is not set.
> - Fix multiple places where bits 6 and 5 of MCR are attempted to be
> altered, but because EFR ECB is unset, these bits remain unaffected.
> This effectively prevents us accessing the right XON/XOFF/TCR/TLR
> registers.
> - Remove unnecessary read-backs of EFR/MCR/LCR registers - these registers
> don't change beneath us, they are configuration registers which hold their
> values. Not only does this simplify the code, but it makes it more
> readable, and more importantly ensures that we work from a consistent
> state where ->efr never has ECB set, and ->mcr never has the TCRTLR
> bit set.
> - Fix disablement of hardware flow control and IXANY modes; once enabled
> these could never be disabled because nothing in the code ever clears
> these configuration bits.
>
> Once that lot is fixed, these patches expand serial_core to permit hardware
> assisted flow control by:
> - adding throttle/unthrottle callbacks into low level serial drivers,
> which allow them to take whatever action is necessary with hardware
> assisted flow control to throttle the remote end. In the case of
> OMAP serial, this means disabling the RX interrupts so that the FIFO
> fills to the watermark.
>
> We then have a number of cleanups to the OMAP serial code to make the
> set_termios() function clearer and less prone to the kinds of mistakes
> identified above. This results in a great simplification of the flow
> control configuration code.
>
> The OMAP serial driver hacks around with the transmit buffer allocation;
> lets clean that up so that drivers can cleanly allocate their transmitter
> buffer using coherent memory if that's what they desire.
>
> Finally, the last few patches clean up the plat/omap-serial.h header file,
> moving most of its contents into the OMAP serial driver itself. Most of
> this is private to the OMAP serial driver and should never have been
> shared with anything else.
>
> I have omitted to include the conversion of the transmit paths to DMA
> engine. Even with all the above fixed, it has issues when DMA transmit
> is in progress, and a program issues a TCSETS call (as `less' does after
> it has written its prompt.) At the moment, this causes lots of junk to
> be emitted from the serial port when issuing `dmesg | less' which sometimes
> brings the port to a complete halt.
>
> As the OMAP DMA hardware does not have a clean pause when performing a
> MEM->DEV transfer (it discards its FIFO) I do not see a solution to this,
> which probably means that we can _not_ ever support transmit DMA on OMAP
> platforms.
>
> This means the xmit buffer allocation patches are not that useful unless
> a solution to that can be found.
>
> Now, the remaining question is, how much of this patch set do we think
> about merging, and when. Given that flow control in this driver has been
> broken for a very long time, and no one has apparantly noticed, I don't
> think there's any urgency to this, so given its size, my preference would
> be to queue it up for the next merge window. The thing that would worry
> me about applying some of the initial patches is that they may change
> the behaviour today and make any problems here more visible.
I'll add another point to this: serial_omap_restore_context() makes no
attempt to restore neither the protected bits in the MCR register nor
the contents of the TCR and TLR registers. So, hardware assisted flow
control probably won't work at all well after a context loss event.
When I work out how to test this, I'll see about cooking up yet another
fix to this driver.
^ permalink raw reply
* [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
From: Nicolas Pitre @ 2012-10-06 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6d3553bfe8a2d1ac88cab852100616a7@localhost>
On Sat, 6 Oct 2012, Marc Zyngier wrote:
> Hi Tony,
>
> On Fri, 5 Oct 2012 13:08:22 -0700, Tony Lindgren <tony@atomide.com> wrote:
> > Hi,
> >
> > * Marc Zyngier <marc.zyngier@arm.com> [120907 10:04]:
> >> From: Dave Martin <dave.martin@linaro.org>
> >>
> >> This patch does two things:
> >>
> >> * Ensure that asynchronous aborts are masked at kernel entry.
> >> The bootloader should be masking these anyway, but this reduces
> >> the damage window just in case it doesn't.
> >>
> >> * Enter svc mode via exception return to ensure that CPU state is
> >> properly serialised. This does not matter when switching from
> >> an ordinary privileged mode ("PL1" modes in ARMv7-AR rev C
> >> parlance), but it potentially does matter when switching from a
> >> another privileged mode such as hyp mode.
> >>
> >> This should allow the kernel to boot safely either from svc mode or
> >> hyp mode, even if no support for use of the ARM Virtualization
> >> Extensions is built into the kernel.
> >>
> >> Signed-off-by: Dave Martin <dave.martin@linaro.org>
> >> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> >
> > Just bisected this down in linux-next for breaking booting of
> > my omap2420 ARMv6 based n8x0..
> >
> >> --- a/arch/arm/kernel/head.S
> >> +++ b/arch/arm/kernel/head.S
> >> @@ -83,8 +83,12 @@ ENTRY(stext)
> >> THUMB( .thumb ) @ switch to Thumb now.
> >> THUMB(1: )
> >>
> >> - setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode
> >> - @ and irqs disabled
> >> +#ifdef CONFIG_ARM_VIRT_EXT
> >> + bl __hyp_stub_install
> >> +#endif
> >> + @ ensure svc mode and all interrupts masked
> >> + safe_svcmode_maskall r9
> >> +
> >> mrc p15, 0, r9, c0, c0 @ get processor id
> >> bl __lookup_processor_type @ r5=procinfo r9=cpuid
> >> movs r10, r5 @ invalid processor (r5=0)?
> >
> > ..and looks like undoing this part fixes it. Any ideas?
> >
> > I quickly tried disabling ARCH_OMAP3 and ARCH_OMAP4 so it's
> > ARMv6 but that does not help.
>
> If you compiled for v6 only, we can safely exclude __hyp_stub_install, and
> I assume that you get past the decompressor.
>
> If so, that indicates some side effect of the safe_svcmode_maskall macro,
> and I suspect the "movs pc, lr" bit.
That would be surprizing if the "movs pc, lr" was to blame. This should
work on all architectures.
However the A bit might be to blame.
> Can you try the attached patch? It basically falls back to the previous
> behaviour if not entered in HYP mode.
This is likely to work of course. However I think we should try to
pinpoint the exact problem i.e. whether it is the A bit or the "movs pc,
lr" which makes a difference (it is unlikely to be both).
So I was about to suggest to test this patch as well:
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 683a1e6b60..118e22ee46 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -254,8 +254,7 @@
mov lr , \reg
and lr , lr , #MODE_MASK
cmp lr , #HYP_MODE
- orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT
- bic \reg , \reg , #MODE_MASK
+ mov \reg , #PSR_I_BIT | PSR_F_BIT
orr \reg , \reg , #SVC_MODE
THUMB( orr \reg , \reg , #PSR_T_BIT )
msr spsr_cxsf, \reg
Nicolas
^ permalink raw reply related
* [PATCH 1/4] mfd: ab8500: add devicetree support for fuelgauge
From: Francesco Lavra @ 2012-10-06 14:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349064513-31301-2-git-send-email-rajanikanth.hv@stericsson.com>
Hi,
On 10/01/2012 06:08 AM, Rajanikanth H.V wrote:
> From: "Rajanikanth H.V" <rajanikanth.hv@stericsson.com>
>
> - This patch adds device tree support for fuelguage driver
> - optimize bm devices platform_data usage and of_probe(...)
> Note: of_probe() routine for battery managed devices is made
> common across all bm drivers.
[...]
> +int __devinit
> +bmdevs_of_probe(struct device *dev,
> + struct device_node *np,
> + struct abx500_bm_plat_data *pdata)
> +{
> + int i, ret = 0, thermistor = NTC_INTERNAL;
> + const __be32 *ph;
> + const char *bat_tech;
> + struct abx500_bm_data *bat;
> + struct abx500_battery_type *btype;
> + struct device_node *np_bat_supply;
> + struct abx500_bmdevs_plat_data *plat_data = pdata->bmdev_pdata;
> +
> + /* get phandle to 'supplied-to' node */
> + ph = of_get_property(np, "supplied-to", &plat_data->num_supplicants);
> + if (ph == NULL) {
> + dev_err(dev, "no supplied_to property specified\n");
> + return -EINVAL;
> + }
> + plat_data->num_supplicants /= sizeof(int);
> + plat_data->supplied_to =
> + devm_kzalloc(dev, plat_data->num_supplicants *
> + sizeof(const char *), GFP_KERNEL);
> + if (plat_data->supplied_to == NULL) {
> + dev_err(dev, "%s no mem for supplied-to\n", __func__);
> + return -ENOMEM;
> + }
> + for (i = 0; i < plat_data->num_supplicants; ++i) {
> + np_bat_supply = of_find_node_by_phandle(be32_to_cpup(ph) + i);
> + if (np_bat_supply == NULL) {
> + dev_err(dev, "invalid supplied_to property\n");
> + return -EINVAL;
> + }
> + ret = of_property_read_string(np_bat_supply, "interface-name",
> + (const char **)(plat_data->supplied_to + i));
> + if (ret < 0) {
> + of_node_put(np_bat_supply);
> + dev_err(dev, "supply/interface name not found\n");
> + return ret;
> + }
If an error is encountered here, of_node_put() should be called for all
nodes previously referenced with of_find_node_by_phandle (or
of_parse_phandle, as Lee suggested).
Also, if I'm not mistaken we have a leak here, because the refcount of
these nodes is never decremented, not even in the driver remove routine.
[...]
> @@ -2446,18 +2444,47 @@ static int __devinit ab8500_fg_probe(struct platform_device *pdev)
> {
> int i, irq;
> int ret = 0;
> - struct abx500_bm_plat_data *plat_data = pdev->dev.platform_data;
> + struct abx500_bm_plat_data *plat_data
> + = pdev->dev.platform_data;
> + struct device_node *np = pdev->dev.of_node;
> struct ab8500_fg *di;
>
> + di = devm_kzalloc(&pdev->dev, sizeof(*di), GFP_KERNEL);
> + if (!di) {
> + dev_err(&pdev->dev, "%s no mem for ab8500_fg\n", __func__);
> + return -ENOMEM;
> + }
> + if (np) {
> + if (!plat_data) {
> + plat_data =
> + devm_kzalloc(&pdev->dev, sizeof(*plat_data),
> + GFP_KERNEL);
> + if (!plat_data) {
> + dev_err(&pdev->dev,
> + "%s no mem for plat_data\n", __func__);
> + return -ENOMEM;
> + }
> + plat_data->bmdev_pdata = devm_kzalloc(&pdev->dev,
> + sizeof(*plat_data->bmdev_pdata), GFP_KERNEL);
> + if (!plat_data->bmdev_pdata) {
> + dev_err(&pdev->dev,
> + "%s no mem for pdata->fg\n",
> + __func__);
> + return -ENOMEM;
> + }
> + }
> + ret = bmdevs_of_probe(&pdev->dev, np, plat_data);
I think it's better to move allocation of bmdev_pdata and corresponding
error check to bmdevs_of_probe(), because this code is shared by all
battery management drivers.
--
Francesco
^ permalink raw reply
* [PATCH] ARM: dts: imx6q-sabreauto: Add basic support
From: Shawn Guo @ 2012-10-06 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5Dk2YKS=RTMKe5jejvtPqw1rNFt2G0EPvYo3uM2rFZYEw@mail.gmail.com>
On Sat, Oct 06, 2012 at 10:16:10AM -0300, Fabio Estevam wrote:
> On Sat, Oct 6, 2012 at 10:03 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
>
> >> Documentation/devicetree/bindings/arm/fsl.txt | 4 ++
> >> arch/arm/boot/dts/imx6q-sabreauto.dts | 65 +++++++++++++++++++++++++
> >
> > Add imx6q-sabreauto.dtb into arch/arm/boot/dts/Makefile.
>
> Ok, looking at arch/arm/boot/dts/Makefile I see that
> imx6q-sabrelite.dtb, for example appears
> under dtb-$(CONFIG_ARCH_MXC) and dtb-$(CONFIG_SOC_IMX6Q)
>
I also noticed the problem. It's a merge issue, and we intend to use
CONFIG_ARCH_MXC cover all imx dtb targets.
> Would you like a patch to remove this duplicate entry?
>
Just sent a fix to Olof.
Shawn
^ permalink raw reply
* [PATCH] ARM: dts: remove redundant imx dtb targets from Makefile
From: Shawn Guo @ 2012-10-06 13:49 UTC (permalink / raw)
To: linux-arm-kernel
We already have CONFIG_ARCH_MXC cover imx5 and imx6 dtb targets.
Remove the redundant ones with CONFIG_ARCH_IMX5 and CONFIG_SOC_IMX6Q.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
Olof,
Most likely, it's a merge problem eventually showing on manline.
Please send the fix for 3.7-rc.
Shawn
arch/arm/boot/dts/Makefile | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 43c084c..fe39ac1 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -22,14 +22,6 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos4210-trats.dtb \
exynos5250-smdk5250.dtb
dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb
-dtb-$(CONFIG_ARCH_IMX5) += imx51-babbage.dtb \
- imx53-ard.dtb \
- imx53-evk.dtb \
- imx53-qsb.dtb \
- imx53-smd.dtb
-dtb-$(CONFIG_SOC_IMX6Q) += imx6q-arm2.dtb \
- imx6q-sabrelite.dtb \
- imx6q-sabresd.dtb
dtb-$(CONFIG_ARCH_LPC32XX) += ea3250.dtb phy3250.dtb
dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
kirkwood-dns325.dtb \
--
1.7.9.5
^ permalink raw reply related
* redirecting console output to display
From: Russell King - ARM Linux @ 2012-10-06 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349109542.85942.YahooMailNeo@web133201.mail.ir2.yahoo.com>
On Mon, Oct 01, 2012 at 05:39:02PM +0100, Ellis Andrew wrote:
> The kernel shows a message "disabling irom" and then the screen is disabled.
No idea what that message is.
> How can I set up my kernel so that it enables the display and outputs a
> console on tty0?
The default (without any console= arguments) and with fbcon enabled is to
output to the framebuffer console. There is no difference in this regard
between running Linux on ARM and running Linux on a PC with a framebuffer
console.
^ permalink raw reply
* [PATCH] ARM: dts: imx6q-sabreauto: Add basic support
From: Fabio Estevam @ 2012-10-06 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121006130344.GE20231@S2101-09.ap.freescale.net>
On Sat, Oct 6, 2012 at 10:03 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
>> Documentation/devicetree/bindings/arm/fsl.txt | 4 ++
>> arch/arm/boot/dts/imx6q-sabreauto.dts | 65 +++++++++++++++++++++++++
>
> Add imx6q-sabreauto.dtb into arch/arm/boot/dts/Makefile.
Ok, looking at arch/arm/boot/dts/Makefile I see that
imx6q-sabrelite.dtb, for example appears
under dtb-$(CONFIG_ARCH_MXC) and dtb-$(CONFIG_SOC_IMX6Q)
Would you like a patch to remove this duplicate entry?
Should we use only CONFIG_SOC?
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH 1/3] i2c: i2c-mux-gpio: Use devm_kzalloc instead of kzalloc
From: Jean Delvare @ 2012-10-06 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348758784-15245-2-git-send-email-maxime.ripard@free-electrons.com>
On Thu, 27 Sep 2012 17:13:02 +0200, Maxime Ripard wrote:
> Use the devm_kzalloc managed function to stripdown the error and remove
> code.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Acked-by: Jean Delvare <khali@linux-fr.org>
> Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
> ---
> drivers/i2c/muxes/i2c-mux-gpio.c | 14 +++++---------
> 1 file changed, 5 insertions(+), 9 deletions(-)
> (...)
Note: I ended up applying this patch (it's on its way to Linus already)
because it did conflict with another patch in my tree. So only patches
2/3 and 3/3 in this series are left for Wolfram to handle.
--
Jean Delvare
^ 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