* [PATCH] Fix ep93xx-fb init/exit annotations
From: H Hartley Sweeten @ 2011-01-10 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D2A4AFD.4050008@bluewatersys.com>
Sunday, January 09, 2011 4:56 PM, Ryan Mallon wrote:
>
> Fix section mismatch errors in the ep93xx-fb driver resulting from
> incorrect init/exit annotations.
>
> Reported-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Signed-off-by: Ryan Mallon <ryan@bluewatersys.com>
That fixed it.
Tested-by: H Hartley Sweeten <hsweeten@visionengravers.com>
^ permalink raw reply
* [GIT PULL] ux500-core leftovers
From: Linus Walleij @ 2011-01-10 18:00 UTC (permalink / raw)
To: linux-arm-kernel
Linus, could you please pull:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
for-torvalds
This is based on commit 0c21e3a and contains
the following patches that couldn't be merged through
Russell's ARM tree due to cross-branch dependencies
now sorted out in your tree:
Rabin Vincent (5):
ux500: remove build-time changing macros
ux500: rename MOP board Kconfig
ux500: dynamic SOC detection
ux500: modem_irq is only for 5500
ux500: allow 5500 and 8500 to be built together
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] omap3: clocks: Fix build error 'CK_3430ES2' undeclared here
From: Paul Walmsley @ 2011-01-10 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <32cc9f4ba82187480f1e4d15d4e93dc0@mail.gmail.com>
Hello Santosh, Tony,
On Mon, 10 Jan 2011, Santosh Shilimkar wrote:
> > -----Original Message-----
> > From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> > owner at vger.kernel.org] On Behalf Of Anand Gadiyar
> > Sent: Monday, January 10, 2011 7:07 PM
> > To: Santosh Shilimkar
> > Cc: linux-omap at vger.kernel.org; tony at atomide.com; linux-arm-
> > kernel at lists.infradead.org; Paul Walmsley
> > Subject: Re: [PATCH] omap3: clocks: Fix build error 'CK_3430ES2'
> > undeclared here
> >
> > On 1/10/2011 3:46 AM, Santosh Shilimkar wrote:
> > > At latest mainline commit 0c21e3aaf6a, omap2plus build is broken.
> > This
> > > patch is trivial fix for the missed usb clock node for
> > CK_3430ES2PLUS
> > > flag update.
> > >
> > > CHK include/generated/compile.h
> > > CC arch/arm/mach-omap2/clock3xxx_data.o
> > > arch/arm/mach-omap2/clock3xxx_data.c:3289: error: 'CK_3430ES2'
> > undeclared
> > > here (not in a function)
> > > make[1]: *** [arch/arm/mach-omap2/clock3xxx_data.o] Error 1
> > > make: *** [arch/arm/mach-omap2] Error 2
> > >
> > > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > > Cc: Paul Walmsley <paul@pwsan.com>
> > > ---
> > > arch/arm/mach-omap2/clock3xxx_data.c | 2 +-
> > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-
> > omap2/clock3xxx_data.c
> > > index d3ab1c9..c54cc33 100644
> > > --- a/arch/arm/mach-omap2/clock3xxx_data.c
> > > +++ b/arch/arm/mach-omap2/clock3xxx_data.c
> > > @@ -3286,7 +3286,7 @@ static struct omap_clk omap3xxx_clks[] = {
> > > CLK(NULL, "cpefuse_fck", &cpefuse_fck, CK_3430ES2PLUS
> > | CK_AM35XX | CK_36XX),
> > > CLK(NULL, "ts_fck", &ts_fck, CK_3430ES2PLUS |
> CK_AM35XX
> > | CK_36XX),
> > > CLK(NULL, "usbtll_fck", &usbtll_fck, CK_3430ES2PLUS
> > | CK_AM35XX | CK_36XX),
> > > - CLK("ehci-omap.0", "usbtll_fck", &usbtll_fck,
> > CK_3430ES2 | CK_AM35XX),
> > > + CLK("ehci-omap.0", "usbtll_fck", &usbtll_fck,
> > CK_3430ES2PLUS | CK_AM35XX),
> >
> > Was about to post something similar.
> >
> > Can you update this line to add CK_36XX as well. Without this, we
> > won't be able to use
> > the USBHOST on 36xx/37xx platforms.
> >
> > With this, feel free to add my
> > Acked-by: Anand Gadiyar <gadiyar@ti.com>
> >
> ok. I can add CK_36XX and repost it with your ack
Looks good to me. Tony, do you want to merge this one as part of the -rc
series? If so then it is:
Acked-by: Paul Walmsley <paul@pwsan.com>
- Paul
^ permalink raw reply
* [PATCH] omap3: clocks: Fix build error 'CK_3430ES2' undeclared here
From: Paul Walmsley @ 2011-01-10 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1101101156220.5731@utopia.booyaka.com>
On Mon, 10 Jan 2011, Paul Walmsley wrote:
> Looks good to me. Tony, do you want to merge this one as part of the -rc
> series? If so then it is:
>
> Acked-by: Paul Walmsley <paul@pwsan.com>
(once Santosh reposts the updated fix, that is)
- Paul
^ permalink raw reply
* [PATCH] ARM: msm: 7x30: don't force a gpiomux table for the whole arch
From: Dima Zavin @ 2011-01-10 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294680810.12298.2.camel@c-dwalke-linux.qualcomm.com>
This is completely board specific and therefore must be provided
on a per-board basis.
Change-Id: I96f922ad9bb9cbce7874c5ae6ac0d7479b7a2124
Signed-off-by: Dima Zavin <dima@android.com>
---
arch/arm/mach-msm/Makefile | 2 +-
arch/arm/mach-msm/board-msm7x30.c | 22 +++++++++++++++++++++
arch/arm/mach-msm/gpiomux-7x30.c | 38 -------------------------------------
3 files changed, 23 insertions(+), 39 deletions(-)
delete mode 100644 arch/arm/mach-msm/gpiomux-7x30.c
diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
index b5a7b07..b5695ce 100644
--- a/arch/arm/mach-msm/Makefile
+++ b/arch/arm/mach-msm/Makefile
@@ -25,7 +25,7 @@ obj-$(CONFIG_ARCH_MSM7X30) += board-msm7x30.o devices-msm7x30.o
obj-$(CONFIG_ARCH_QSD8X50) += board-qsd8x50.o devices-qsd8x50.o
obj-$(CONFIG_ARCH_MSM8X60) += board-msm8x60.o
-obj-$(CONFIG_ARCH_MSM7X30) += gpiomux-7x30.o gpiomux-v1.o gpiomux.o
+obj-$(CONFIG_ARCH_MSM7X30) += gpiomux-v1.o gpiomux.o
obj-$(CONFIG_ARCH_QSD8X50) += gpiomux-8x50.o gpiomux-v1.o gpiomux.o
obj-$(CONFIG_ARCH_MSM8X60) += gpiomux-8x60.o gpiomux-v2.o gpiomux.o
ifndef CONFIG_MSM_V2_TLMM
diff --git a/arch/arm/mach-msm/board-msm7x30.c b/arch/arm/mach-msm/board-msm7x30.c
index 05241df..431be40 100644
--- a/arch/arm/mach-msm/board-msm7x30.c
+++ b/arch/arm/mach-msm/board-msm7x30.c
@@ -35,10 +35,32 @@
#include <mach/vreg.h>
#include "devices.h"
+#include "gpiomux.h"
#include "proc_comm.h"
extern struct sys_timer msm_timer;
+struct msm_gpiomux_config msm_gpiomux_configs[GPIOMUX_NGPIOS] = {
+#ifdef CONFIG_SERIAL_MSM_CONSOLE
+ [49] = { /* UART2 RFR */
+ .suspended = GPIOMUX_DRV_2MA | GPIOMUX_PULL_DOWN |
+ GPIOMUX_FUNC_2 | GPIOMUX_VALID,
+ },
+ [50] = { /* UART2 CTS */
+ .suspended = GPIOMUX_DRV_2MA | GPIOMUX_PULL_DOWN |
+ GPIOMUX_FUNC_2 | GPIOMUX_VALID,
+ },
+ [51] = { /* UART2 RX */
+ .suspended = GPIOMUX_DRV_2MA | GPIOMUX_PULL_DOWN |
+ GPIOMUX_FUNC_2 | GPIOMUX_VALID,
+ },
+ [52] = { /* UART2 TX */
+ .suspended = GPIOMUX_DRV_2MA | GPIOMUX_PULL_DOWN |
+ GPIOMUX_FUNC_2 | GPIOMUX_VALID,
+ },
+#endif
+};
+
static struct platform_device *devices[] __initdata = {
#if defined(CONFIG_SERIAL_MSM) || defined(CONFIG_MSM_SERIAL_DEBUGGER)
&msm_device_uart2,
diff --git a/arch/arm/mach-msm/gpiomux-7x30.c b/arch/arm/mach-msm/gpiomux-7x30.c
deleted file mode 100644
index 6ce41c5..0000000
--- a/arch/arm/mach-msm/gpiomux-7x30.c
+++ /dev/null
@@ -1,38 +0,0 @@
-/* Copyright (c) 2010, Code Aurora Forum. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
- * 02110-1301, USA.
- */
-#include "gpiomux.h"
-
-struct msm_gpiomux_config msm_gpiomux_configs[GPIOMUX_NGPIOS] = {
-#ifdef CONFIG_SERIAL_MSM_CONSOLE
- [49] = { /* UART2 RFR */
- .suspended = GPIOMUX_DRV_2MA | GPIOMUX_PULL_DOWN |
- GPIOMUX_FUNC_2 | GPIOMUX_VALID,
- },
- [50] = { /* UART2 CTS */
- .suspended = GPIOMUX_DRV_2MA | GPIOMUX_PULL_DOWN |
- GPIOMUX_FUNC_2 | GPIOMUX_VALID,
- },
- [51] = { /* UART2 RX */
- .suspended = GPIOMUX_DRV_2MA | GPIOMUX_PULL_DOWN |
- GPIOMUX_FUNC_2 | GPIOMUX_VALID,
- },
- [52] = { /* UART2 TX */
- .suspended = GPIOMUX_DRV_2MA | GPIOMUX_PULL_DOWN |
- GPIOMUX_FUNC_2 | GPIOMUX_VALID,
- },
-#endif
-};
--
1.7.3.1
^ permalink raw reply related
* [PATCH v4 0/3] OMAP3: beaglexm: GPIO fixes
From: Tony Lindgren @ 2011-01-10 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294441282-17986-1-git-send-email-nm@ti.com>
* Nishanth Menon <nm@ti.com> [110107 15:00]:
> Hi,
> As discussed in the threads:
> http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/
> http://marc.info/?t=121540030800004&r=1&w=2
>
> here is the split up series with commit message after discussion:
> http://www.beagleboard.org/irclogs/index.php?date=2011-01-06#T19:12:21
>
> Koen Kooi (3):
> omap3: beaglexm: fix EHCI power up GPIO dir
> omap3: beaglexm: fix DVI reset GPIO
> omap3: beaglexm: fix power on of DVI
Dropping the earlier versions from omap-fixes, I want to get the
build fixes in ASAP. These can wait a bit until Aaro's comments
are addressed.
Regards,
Tony
^ permalink raw reply
* [PATCH 2/3] perf: add OMAP support for the new power events
From: Paul Walmsley @ 2011-01-10 19:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=3pek3+Vv+c1TCxBH2RJcoSXq8TL8CyK9ABMeu@mail.gmail.com>
Hello Jean,
On Wed, 5 Jan 2011, Jean Pihet wrote:
> On Tue, Jan 4, 2011 at 7:48 PM, Paul Walmsley <paul@pwsan.com> wrote:
>
> > If the latter, then it might make sense to put these
> > trace points into the functions that actually change the hardware
> > registers, e.g., omap2_dflt_clk_{enable,disable}(), etc., since a
> > clk_enable() on a leaf clock may result in many internal system clocks
> > being enabled up the clock tree.
> I agree with you it is better to track the actual clock changes instead.
> I propose to move the tracepoints to omap2_clk_{enable...} which
> enables all the clocks irrespectively of the installed handler.
Yes, that is a better place.
> Note about the clock handlers: omap2_dflt_clk_enable happens to be the
> handler for all controllable clocks but could that change in the
> future?
Yes, it certainly could.
- Paul
^ permalink raw reply
* [PATCH] omap3: clocks: Fix build error 'CK_3430ES2' undeclared here
From: Tony Lindgren @ 2011-01-10 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1101101158360.5731@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [110110 10:58]:
> On Mon, 10 Jan 2011, Paul Walmsley wrote:
>
> > Looks good to me. Tony, do you want to merge this one as part of the -rc
> > series? If so then it is:
> >
> > Acked-by: Paul Walmsley <paul@pwsan.com>
>
> (once Santosh reposts the updated fix, that is)
OK thanks will queue.
Tony
^ permalink raw reply
* [PATCH v4 0/3] OMAP3: beaglexm: GPIO fixes
From: Nishanth Menon @ 2011-01-10 19:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110110190436.GE4957@atomide.com>
Tony Lindgren had written, on 01/10/2011 01:04 PM, the following:
> * Nishanth Menon <nm@ti.com> [110107 15:00]:
>> Hi,
>> As discussed in the threads:
>> http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/
>> http://marc.info/?t=121540030800004&r=1&w=2
>>
>> here is the split up series with commit message after discussion:
>> http://www.beagleboard.org/irclogs/index.php?date=2011-01-06#T19:12:21
>>
>> Koen Kooi (3):
>> omap3: beaglexm: fix EHCI power up GPIO dir
>> omap3: beaglexm: fix DVI reset GPIO
>> omap3: beaglexm: fix power on of DVI
>
> Dropping the earlier versions from omap-fixes, I want to get the
> build fixes in ASAP. These can wait a bit until Aaro's comments
> are addressed.
Ack. will post a v5 after aligning. build breakages have higher priority
ofcourse ;)
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v2 1/5] omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask
From: Paul Walmsley @ 2011-01-10 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <874o9ko25j.fsf@ti.com>
Hi Kevin
On Fri, 7 Jan 2011, Kevin Hilman wrote:
> Rajendra Nayak <rnayak@ti.com> writes:
>
> [...]
>
> > Just another trivial fix.
> >
> > From bb46b74d2b0ab3d35e72b760da7e123a891e6813 Mon Sep 17 00:00:00 2001
> > From: Rajendra Nayak <rnayak@ti.com>
> > Date: Fri, 7 Jan 2011 14:07:25 +0530
> > Subject: [PATCH] OMAP: powerdomain: remove unused func declaration
> >
> > Trivial fix to remove the unused function declaration
> > from the powerdomain header.
> >
> > Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> > ---
> > arch/arm/mach-omap2/powerdomain.h | 1 -
> > 1 files changed, 0 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/powerdomain.h
> > b/arch/arm/mach-omap2/powerdomain.h
> > index c66431e..0b7a357 100644
> > --- a/arch/arm/mach-omap2/powerdomain.h
> > +++ b/arch/arm/mach-omap2/powerdomain.h
> > @@ -165,7 +165,6 @@ struct pwrdm_ops {
> > int (*pwrdm_wait_transition)(struct powerdomain *pwrdm);
> > };
> >
> > -void pwrdm_fw_init(void);
> > void pwrdm_init(struct powerdomain **pwrdm_list, struct pwrdm_ops
> > *custom_funcs);
>
> Note this is line-wrapped.
>
> Looks like you need to get get-send-email setup so you can avoid having
> the patch sending problems.
>
> >
> > struct powerdomain *pwrdm_lookup(const char *name);
>
> In any case, with Paul's ack, I can queue this with the others.
Normally I would wait for the .39 merge window with something like this,
but you're welcome to queue it for the -rc fixes if you feel it's
appropriate:
Acked-by: Paul Walmsley <paul@pwsan.com>
- Paul
^ permalink raw reply
* AT91: Fix power-saving in idle-mode on 926T processors
From: Uwe Kleine-König @ 2011-01-10 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87fwt069ys.fsf@macbook.be.48ers.dk>
On Mon, Jan 10, 2011 at 04:43:07PM +0100, Peter Korsgaard wrote:
> >>>>> "Anders" == Anders Larsen <al@alarsen.net> writes:
>
> Hi,
>
> >> Is there a known interaction with this and the JTAG controller?
>
> Anders> indeed there is - disabling the processor clock blocks JTAG debugging.
>
> Ok - And apparently it completely blocks the JTAG controller, so you
> cannot even put it in bypass mode and access other devices on the same
> JTAG chain.
This is a quite usual violation of ieee-1949.1-2001 (i.e. the jtag
standard (don't know if there is a newer version?)). I really wonder
why it's so hard to get this right. There is the availability of
"compiliance-enable patterns" that allow to say: "My device is only
jtaggable if this input is 1." Why not power the jtag block with such an
input? Software doesn't need (and actually must not) have the ability
to disable the jtag clock. Moreover this way the chip doesn't need any
current to keep jtag on and still a developer needing jtag doesn't need
to change any source code, but only needs a jumper on his devboard.
It could be so easy when all people knew what they do.
sigh
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Uwe Kleine-König @ 2011-01-10 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294680035.3349.19.camel@heimdal.trondhjem.org>
Hello Trond,
On Mon, Jan 10, 2011 at 12:20:35PM -0500, Trond Myklebust wrote:
> On Mon, 2011-01-10 at 18:08 +0100, Marc Kleine-Budde wrote:
> > On 01/10/2011 05:25 PM, Trond Myklebust wrote:
> > > On Mon, 2011-01-10 at 11:50 +0100, Uwe Kleine-K?nig wrote:
> > >> Hi Trond,
> > >>
> > >> On Sat, Jan 08, 2011 at 06:15:51PM -0500, Trond Myklebust wrote:
> > >>> -----------------------------------------------------------------------------------
> > >> It would be great if you could add a "8<" in the line above next time.
> > >> Then git-am -c does the right thing (at least I think so).
> > >
> > > Sorry. I wasn't aware of that particular idiom. So something like
> > >
> > > 8<------------------------------------------------------------
> > > From: Trond Myklebust <Trond.Myklebust@netapp.com>
> > > Subject: .....
> >
> > Yes.
> >
> > From "man git-mailinfo":
> > "A line that mainly consists of scissors (either ">8" or "8<") and
> > perforation (dash "-")"
> >
> > BTW:
> > Is this patch a candidate for stable?
>
> Yes. I'm planning on sending it to the stable list after Linus merges it
> into mainline.
So there is another idiom for you: just put
Cc: stable at kernel.org
in the S-o-b block and Greg will pick it off "automatically". (Just in
case you don't know, and if you do, maybe someone else learned
something.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Trond Myklebust @ 2011-01-10 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110110192552.GG24920@pengutronix.de>
On Mon, 2011-01-10 at 20:25 +0100, Uwe Kleine-K?nig wrote:
> Hello Trond,
>
> On Mon, Jan 10, 2011 at 12:20:35PM -0500, Trond Myklebust wrote:
> > On Mon, 2011-01-10 at 18:08 +0100, Marc Kleine-Budde wrote:
> > > On 01/10/2011 05:25 PM, Trond Myklebust wrote:
> > > > On Mon, 2011-01-10 at 11:50 +0100, Uwe Kleine-K?nig wrote:
> > > >> Hi Trond,
> > > >>
> > > >> On Sat, Jan 08, 2011 at 06:15:51PM -0500, Trond Myklebust wrote:
> > > >>> -----------------------------------------------------------------------------------
> > > >> It would be great if you could add a "8<" in the line above next time.
> > > >> Then git-am -c does the right thing (at least I think so).
> > > >
> > > > Sorry. I wasn't aware of that particular idiom. So something like
> > > >
> > > > 8<------------------------------------------------------------
> > > > From: Trond Myklebust <Trond.Myklebust@netapp.com>
> > > > Subject: .....
> > >
> > > Yes.
> > >
> > > From "man git-mailinfo":
> > > "A line that mainly consists of scissors (either ">8" or "8<") and
> > > perforation (dash "-")"
> > >
> > > BTW:
> > > Is this patch a candidate for stable?
> >
> > Yes. I'm planning on sending it to the stable list after Linus merges it
> > into mainline.
> So there is another idiom for you: just put
>
> Cc: stable at kernel.org
>
> in the S-o-b block and Greg will pick it off "automatically". (Just in
> case you don't know, and if you do, maybe someone else learned
> something.)
I usually do this, but there is a slight problem with that approach:
Greg gets to do all the work of figuring out to which stable kernels
this particular patch applies. In this case, since we're only talking
about the 2.6.37 kernel, I prefer to use the mailing lists.
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust at netapp.com
www.netapp.com
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: James Bottomley @ 2011-01-10 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294687767.3349.28.camel@heimdal.trondhjem.org>
On Mon, 2011-01-10 at 14:29 -0500, Trond Myklebust wrote:
> I usually do this, but there is a slight problem with that approach:
> Greg gets to do all the work of figuring out to which stable kernels
> this particular patch applies. In this case, since we're only talking
> about the 2.6.37 kernel, I prefer to use the mailing lists.
So the non-standard, but accepted way of doing this is
Cc: Stable Tree <stable@kernel.org> [2.6.37]
James
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Linus Torvalds @ 2011-01-10 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294687767.3349.28.camel@heimdal.trondhjem.org>
2011/1/10 Trond Myklebust <Trond.Myklebust@netapp.com>:
>
> I usually do this, but there is a slight problem with that approach:
> Greg gets to do all the work of figuring out to which stable kernels
> this particular patch applies. In this case, since we're only talking
> about the 2.6.37 kernel, I prefer to use the mailing lists.
Just do
Cc: stable at kernel.org [2.6.37]
or similar. It's quite common.
So EVEN IF you want to email people around about the patch separately,
do add the "Cc: stable" marker. It's worthwhile information about the
patch for everybody involved.
Linus
^ permalink raw reply
* [PATCH] ARM: imx/mx27_3ds: Add debug board support
From: Uwe Kleine-König @ 2011-01-10 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294677761-11971-1-git-send-email-fabio.estevam@freescale.com>
Hello Fabio,
On Mon, Jan 10, 2011 at 02:42:41PM -0200, Fabio Estevam wrote:
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> arch/arm/mach-imx/Kconfig | 1 +
> arch/arm/mach-imx/mach-mx27_3ds.c | 7 +++++++
> 2 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 17d2e60..56684b5 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -243,6 +243,7 @@ config MACH_MX27_3DS
> select IMX_HAVE_PLATFORM_MXC_EHCI
> select IMX_HAVE_PLATFORM_MXC_MMC
> select IMX_HAVE_PLATFORM_SPI_IMX
> + select MXC_DEBUG_BOARD
> select MXC_ULPI if USB_ULPI
> help
> Include support for MX27PDK platform. This includes specific
> diff --git a/arch/arm/mach-imx/mach-mx27_3ds.c b/arch/arm/mach-imx/mach-mx27_3ds.c
> index 83f8e2b..4d72891 100644
> --- a/arch/arm/mach-imx/mach-mx27_3ds.c
> +++ b/arch/arm/mach-imx/mach-mx27_3ds.c
> @@ -37,12 +37,15 @@
> #include <mach/common.h>
> #include <mach/iomux-mx27.h>
> #include <mach/ulpi.h>
> +#include <mach/irqs.h>
> +#include <mach/3ds_debugboard.h>
>
> #include "devices-imx27.h"
>
> #define SD1_EN_GPIO (GPIO_PORTB + 25)
> #define OTG_PHY_RESET_GPIO (GPIO_PORTB + 23)
> #define SPI2_SS0 (GPIO_PORTD + 21)
> +#define EXPIO_PARENT_INT (MXC_INTERNAL_IRQS + GPIO_PORTC + 28)
>
> static const int mx27pdk_pins[] __initconst = {
> /* UART1 */
> @@ -276,6 +279,10 @@ static void __init mx27pdk_init(void)
> imx27_add_spi_imx1(&spi2_pdata);
> spi_register_board_info(mx27_3ds_spi_devs,
> ARRAY_SIZE(mx27_3ds_spi_devs));
> +
> + if (mxc_expio_init(MX27_CS5_BASE_ADDR, EXPIO_PARENT_INT))
> + pr_warn("Init of the debugboard failed, all "
> + "devices on the debugboard are unusable.\n");
You don't need to break this. In fact it's better when you don't.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Trond Myklebust @ 2011-01-10 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinFenq3BEiUQRsxDy6EKwqSM33RcwFG4fs-sXLJ@mail.gmail.com>
On Mon, 2011-01-10 at 11:34 -0800, Linus Torvalds wrote:
> 2011/1/10 Trond Myklebust <Trond.Myklebust@netapp.com>:
> >
> > I usually do this, but there is a slight problem with that approach:
> > Greg gets to do all the work of figuring out to which stable kernels
> > this particular patch applies. In this case, since we're only talking
> > about the 2.6.37 kernel, I prefer to use the mailing lists.
>
> Just do
>
> Cc: stable at kernel.org [2.6.37]
>
> or similar. It's quite common.
>
> So EVEN IF you want to email people around about the patch separately,
> do add the "Cc: stable" marker. It's worthwhile information about the
> patch for everybody involved.
OK. Patch description amended and recommitted in git. Thanks to all for
the tips...
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust at netapp.com
www.netapp.com
^ permalink raw reply
* [PATCH v2] ARM: imx/mx27_3ds: Add debug board support
From: Fabio Estevam @ 2011-01-10 20:17 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v1:
- Do not break the error message
arch/arm/mach-imx/Kconfig | 1 +
arch/arm/mach-imx/mach-mx27_3ds.c | 6 ++++++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 17d2e60..56684b5 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -243,6 +243,7 @@ config MACH_MX27_3DS
select IMX_HAVE_PLATFORM_MXC_EHCI
select IMX_HAVE_PLATFORM_MXC_MMC
select IMX_HAVE_PLATFORM_SPI_IMX
+ select MXC_DEBUG_BOARD
select MXC_ULPI if USB_ULPI
help
Include support for MX27PDK platform. This includes specific
diff --git a/arch/arm/mach-imx/mach-mx27_3ds.c b/arch/arm/mach-imx/mach-mx27_3ds.c
index 83f8e2b..1643315 100644
--- a/arch/arm/mach-imx/mach-mx27_3ds.c
+++ b/arch/arm/mach-imx/mach-mx27_3ds.c
@@ -37,12 +37,15 @@
#include <mach/common.h>
#include <mach/iomux-mx27.h>
#include <mach/ulpi.h>
+#include <mach/irqs.h>
+#include <mach/3ds_debugboard.h>
#include "devices-imx27.h"
#define SD1_EN_GPIO (GPIO_PORTB + 25)
#define OTG_PHY_RESET_GPIO (GPIO_PORTB + 23)
#define SPI2_SS0 (GPIO_PORTD + 21)
+#define EXPIO_PARENT_INT (MXC_INTERNAL_IRQS + GPIO_PORTC + 28)
static const int mx27pdk_pins[] __initconst = {
/* UART1 */
@@ -276,6 +279,9 @@ static void __init mx27pdk_init(void)
imx27_add_spi_imx1(&spi2_pdata);
spi_register_board_info(mx27_3ds_spi_devs,
ARRAY_SIZE(mx27_3ds_spi_devs));
+
+ if (mxc_expio_init(MX27_CS5_BASE_ADDR, EXPIO_PARENT_INT))
+ pr_warn("Init of the debugboard failed, all devices on the debugboard are unusable.\n");
}
static void __init mx27pdk_timer_init(void)
--
1.6.0.4
^ permalink raw reply related
* [PATCH] spi: tegra: don't treat NULL clk as an error
From: Grant Likely @ 2011-01-10 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294657506-27510-1-git-send-email-jamie@jamieiles.com>
On Mon, Jan 10, 2011 at 4:05 AM, Jamie Iles <jamie@jamieiles.com> wrote:
> Some platforms have been known to return NULL from clk_get() if they
> support only a single struct clk. ?Whilst tegra doesn't do this, make
> the drivers consistent with others.
>
> Cc: Erik Gilling <konkers@android.com>
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
Hi James,
If NULL does get returned, say due to a future change to the clock
code, then this change causes the driver to oops. I'm not going to
apply this patch.
g.
> ---
>
> ?drivers/spi/spi_tegra.c | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/spi/spi_tegra.c b/drivers/spi/spi_tegra.c
> index bb7df02..891e590 100644
> --- a/drivers/spi/spi_tegra.c
> +++ b/drivers/spi/spi_tegra.c
> @@ -513,7 +513,7 @@ static int __init spi_tegra_probe(struct platform_device *pdev)
> ? ? ? ?}
>
> ? ? ? ?tspi->clk = clk_get(&pdev->dev, NULL);
> - ? ? ? if (IS_ERR_OR_NULL(tspi->clk)) {
> + ? ? ? if (IS_ERR(tspi->clk)) {
> ? ? ? ? ? ? ? ?dev_err(&pdev->dev, "can not get clock\n");
> ? ? ? ? ? ? ? ?ret = PTR_ERR(tspi->clk);
> ? ? ? ? ? ? ? ?goto err2;
> --
> 1.7.3.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] ARM: vexpress: register platform PATA device.
From: Nick Bowler @ 2011-01-10 21:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110107224348.GZ31708@n2100.arm.linux.org.uk>
On 2011-01-07 22:43 +0000, Russell King - ARM Linux wrote:
> On Fri, Jan 07, 2011 at 04:24:05PM -0500, Nick Bowler wrote:
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index d56d21c..ee61039 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -264,6 +264,7 @@ config ARCH_VEXPRESS
> > select HAVE_CLK
> > select ICST
> > select PLAT_VERSATILE
> > + select HAVE_PATA_PLATFORM
>
> To avoid the Kconfig warning, this should be:
>
> select HAVE_PATA_PLATFORM if ATA
>
> or it needs to be moved outside of the if ATA ... endif block in
> drivers/ata/Kconfig.
The Kconfig dependency fix was merged into mainline today, so this patch
should no longer trigger the aforementioned warning.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply
* [PATCH] ARM AT91SAM9M10G45: Remove duplicate inclusion of mach/hardware.h
From: Jesper Juhl @ 2011-01-10 21:29 UTC (permalink / raw)
To: linux-arm-kernel
Remove duplicate inclusion of mach/hardware.h
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
board-sam9m10g45ek.c | 1 -
1 file changed, 1 deletion(-)
Completely untested. I don't have any way of even compiling this, but I
think it's fairly obviously correct.
diff --git a/arch/arm/mach-at91/board-sam9m10g45ek.c b/arch/arm/mach-at91/board-sam9m10g45ek.c
index 86ff4b5..6c999db 100644
--- a/arch/arm/mach-at91/board-sam9m10g45ek.c
+++ b/arch/arm/mach-at91/board-sam9m10g45ek.c
@@ -29,23 +29,22 @@
#include <mach/hardware.h>
#include <video/atmel_lcdc.h>
#include <asm/setup.h>
#include <asm/mach-types.h>
#include <asm/irq.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
#include <asm/mach/irq.h>
-#include <mach/hardware.h>
#include <mach/board.h>
#include <mach/gpio.h>
#include <mach/at91sam9_smc.h>
#include <mach/at91_shdwc.h>
#include "sam9_smc.h"
#include "generic.h"
static void __init ek_map_io(void)
{
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* [PATCH] ARM AT91SAM9M10G45: Remove duplicate inclusion of mach/hardware.h
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-01-10 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LNX.2.00.1101102225550.32164@swampdragon.chaosbits.net>
On 22:29 Mon 10 Jan , Jesper Juhl wrote:
> Remove duplicate inclusion of mach/hardware.h
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
^ permalink raw reply
* [PATCH 1/1] ARM i.MX50: Rename devices-mx50.h
From: Jason Liu @ 2011-01-10 21:44 UTC (permalink / raw)
To: linux-arm-kernel
There are devices-imx51.h and devices-imx53.h under
arch/arm/mach-mx5 directory. So, had better rename
devices-mx50.h to devices-imx50.h to follow the same
naming convention with imx51 and imx53 part.
Signed-off-by: Jason Liu <r64343@freescale.com>
---
arch/arm/mach-mx5/board-mx50_rdp.c | 2 +-
.../mach-mx5/{devices-mx50.h => devices-imx50.h} | 0
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-mx5/board-mx50_rdp.c b/arch/arm/mach-mx5/board-mx50_rdp.c
index fd32e4c..e5bb600 100644
--- a/arch/arm/mach-mx5/board-mx50_rdp.c
+++ b/arch/arm/mach-mx5/board-mx50_rdp.c
@@ -35,7 +35,7 @@
#include <asm/mach/arch.h>
#include <asm/mach/time.h>
-#include "devices-mx50.h"
+#include "devices-imx50.h"
static iomux_v3_cfg_t mx50_rdp_pads[] __initdata = {
/* SD1 */
diff --git a/arch/arm/mach-mx5/devices-mx50.h b/arch/arm/mach-mx5/devices-imx50.h
similarity index 100%
rename from arch/arm/mach-mx5/devices-mx50.h
rename to arch/arm/mach-mx5/devices-imx50.h
--
1.7.0.4
^ permalink raw reply related
* [PATCH] spi: tegra: don't treat NULL clk as an error
From: Russell King - ARM Linux @ 2011-01-10 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikd7AZv+-aVf4=jwF+xjvq+1k_kAwLPz-+yP6=Q@mail.gmail.com>
On Mon, Jan 10, 2011 at 01:58:12PM -0700, Grant Likely wrote:
> On Mon, Jan 10, 2011 at 4:05 AM, Jamie Iles <jamie@jamieiles.com> wrote:
> > Some platforms have been known to return NULL from clk_get() if they
> > support only a single struct clk. ?Whilst tegra doesn't do this, make
> > the drivers consistent with others.
> >
> > Cc: Erik Gilling <konkers@android.com>
> > Signed-off-by: Jamie Iles <jamie@jamieiles.com>
>
> Hi James,
>
> If NULL does get returned, say due to a future change to the clock
> code, then this change causes the driver to oops. I'm not going to
> apply this patch.
Please apply it - the clock API just defines struct clk as a cookie
where errors are IS_ERR/PTR_ERR. Other values must be considered by
drivers as perfectly valid, including NULL.
^ permalink raw reply
* [PATCH 4/4] ARM: support for Thumb-2 instructions with CONFIG_ARM_PATCH_PHYS_VIRT
From: Dave Martin @ 2011-01-10 22:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294129208-15201-5-git-send-email-nico@fluxnic.net>
Hi,
On Tue, Jan 4, 2011 at 2:20 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
> ---
> arch/arm/Kconfig | 3 +--
> arch/arm/include/asm/memory.h | 5 +++--
> arch/arm/kernel/head.S | 31 +++++++++++++++++++++++++++----
> 3 files changed, 31 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 136ed9b..feb374a 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -189,8 +189,7 @@ config VECTORS_BASE
>
> config ARM_PATCH_PHYS_VIRT
> bool
> - depends on EXPERIMENTAL
> - depends on !XIP && !THUMB2_KERNEL
> + depends on !XIP && EXPERIMENTAL
>
> source "init/Kconfig"
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index f83be97..80a939d 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -157,14 +157,15 @@
> #error "this machine configuration uses complex __virt_to_phys/__phys_to_virt and cannot use CONFIG_ARM_PATCH_PHYS_VIRT"
> #endif
>
> +/* the stub constant 0xff000000 is used to force the required insn encoding */
> #define __pv_stub(from,to,instr) \
> __asm__( \
> - "1: " instr "\t%0, %1, %2\n" \
> + "1: " instr "\t%0, %1, #0xff000000\n" \
> " .pushsection .pv_table,\"a\"\n" \
> " .long 1b\n" \
> " .popsection" \
> : "=r" (to) \
> - : "r" (from), "I" (1))
> + : "r" (from))
>
> static inline unsigned long __virt_to_phys(unsigned long x)
> {
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 621c792..397271d 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -447,11 +447,11 @@ __fixup_pv_table:
> adr r0, 1f
> ldmia r0, {r3-r5}
> sub r3, r0, r3 @ PHYS_OFFSET - PAGE_OFFSET
> + movs r6, r3, lsl #8 @ must be 16MiB aligned
> + bne __error
> add r4, r4, r3
> add r5, r5, r3
> - mov r6, r3, lsr #24 @ constant for add/sub instructions
> - teq r3, r6, lsl #24 @ must be 16MiB aligned
> - bne __error
> + mov r6, r3
> b __fixup_pv_table_loop
> ENDPROC(__fixup_phys_virt)
>
> @@ -462,6 +462,8 @@ ENDPROC(__fixup_phys_virt)
> .pushsection .text
>
> ENTRY(__fixup_pv_table_loop)
> +#ifndef CONFIG_THUMB2_KERNEL
> + mov r6, r6, lsr #24 @ constant for add/sub instructions
> orr r6, r6, #0x400 @ mask in rotate right 8 bits
> 2: cmp r4, r5
> ldrlo r7, [r4], #4
> @@ -471,6 +473,27 @@ ENTRY(__fixup_pv_table_loop)
> strlo ip, [r7, r3]
> blo 2b
> mov pc, lr
> +#else
> + teq r6, #0
> + beq 2f
> + clz r7, r6
> + lsr r6, #24
> + lsl r6, r7
> + bic r6, r6, #0x3080
Should bits 12-13 of r6 ever be nonzero here? The code already throws
an error of the p2v offset is not a multiple of 16 MiB; i.e., (r6 &
~0xff000000) == 0, so r6 >> (24 - clz(r6)) must be in the range
0..0xff.
Of course, clearing the extra bits again doesn't matter...
> + lsrs r7, #1
> + orrcs r6, r6, #0x80
> + orr r6, r6, r7, lsl #12
> + orr r6, r6, #0x4000
> +2: cmp r4, r5
> + bxhs lr
> + ldr r7, [r4], #4
> + add r7, r3
> + ldr ip, [r7, #2]
> + and ip, ip, #0x0f00
> + orr ip, ip, r6
> + str ip, [r7, #2]
> + b 2b
> +#endif
> ENDPROC(__fixup_phys_virt_loop)
>
> /*
> @@ -482,7 +505,7 @@ ENTRY(fixup_pv_table)
> mov r3, #0 @ offset (zero as we're in virtual space)
> mov r4, r0 @ loop start
> mov r5, r1 @ loop end
> - mov r6, r2, lsr #24 @ constant for add/sub instructions
> + mov r6, r2 @ PHYS_OFFSET - PAGE_OFFSET
> bl __fixup_pv_table_loop
> ldmfd sp!, {r4 - r7, pc}
> ENDPROC(fixup_pv_table)
I've not been able to test this code yet, but it looks to me like it
should work for the Thumb-2 case.
Cheers
---Dave
^ 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