* [PATCH 01/51] ARM: reset: introduce arm_arch_reset function pointer
From: Rabin Vincent @ 2011-10-31 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111031141322.GK19187@n2100.arm.linux.org.uk>
On Mon, Oct 31, 2011 at 19:43, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> $ spatch -sp_file arch_reset-1.cocci arch/arm/*/include/*/system.h > arch_reset-1.diff
>
> The diff it created contains:
>
> --- arch/arm/mach-ep93xx/include/mach/system.h ?2011-03-04 19:52:46.419272878 +0000
> +++ /tmp/cocci-output-380-f841cc-system.h ? ? ? 2011-10-31 13:54:52.066705107 +0000
> ...
> --- arch/arm/mach-iop32x/include/mach/system.h ?2011-03-04 19:52:46.445272534 +0000
> +++ /tmp/cocci-output-380-c0e3f4-system.h ? ? ? 2011-10-31 13:54:52.072705051 +0000
> ...
> --- arch/arm/mach-ixp2000/include/mach/system.h 2011-03-04 19:52:46.449272482 +0000
> +++ /tmp/cocci-output-380-467f17-system.h ? ? ? 2011-10-31 13:54:52.079704984 +0000
> ...
>
> which in total deletes 6 lines. ?However, the patch is rejected by
> git apply and gnu patch as it stands - it needs the filenames to be
> edited to something more reasonable. ?So that also takes six edits.
The above patch will apply with gnu patch if you use -p0.
^ permalink raw reply
* [PATCH 01/51] ARM: reset: introduce arm_arch_reset function pointer
From: Jamie Iles @ 2011-10-31 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111031141322.GK19187@n2100.arm.linux.org.uk>
Hi Russell,
On Mon, Oct 31, 2011 at 02:13:22PM +0000, Russell King - ARM Linux wrote:
> On Sat, Oct 29, 2011 at 02:56:53PM +0100, Will Deacon wrote:
> > The only downside is that I have to go over all of the platforms again
> > unless I can polish up my Coccinelle-fu. Ho-hum.
>
> Well, I've just given coccinelle a go, and having read all the hype about
> it, I'm completely disappointed with it to the extent that I'm going to
> uninstall the tool from my system (unless someone can point out what I'm
> doing wrong.)
>
> I thought I'd give it a spin on a nice simple change - deleting the
> local_irq_disable() calls inside arch_reset() (irqs have already been
> disabled by this time):
>
> @@
> identifier mode, cmd;
> @@
>
> arch_reset(char mode, const char *cmd)
> {
> ...
> - local_irq_disable();
> ...
> }
>
> $ spatch -sp_file arch_reset-1.cocci arch/arm/*/include/*/system.h > arch_reset-1.diff
>
> The diff it created contains:
>
> --- arch/arm/mach-ep93xx/include/mach/system.h 2011-03-04 19:52:46.419272878 +0000
> +++ /tmp/cocci-output-380-f841cc-system.h 2011-10-31 13:54:52.066705107 +0000
> ...
> --- arch/arm/mach-iop32x/include/mach/system.h 2011-03-04 19:52:46.445272534 +0000
> +++ /tmp/cocci-output-380-c0e3f4-system.h 2011-10-31 13:54:52.072705051 +0000
> ...
> --- arch/arm/mach-ixp2000/include/mach/system.h 2011-03-04 19:52:46.449272482 +0000
> +++ /tmp/cocci-output-380-467f17-system.h 2011-10-31 13:54:52.079704984 +0000
> ...
>
> which in total deletes 6 lines. However, the patch is rejected by
> git apply and gnu patch as it stands - it needs the filenames to be
> edited to something more reasonable. So that also takes six edits.
I think you need:
spatch -sp_file arch_reset-1.cocci -patch . arch/arm/*/include/*/system.h > \
arch_reset-1.diff
I've also used -in_place in the past then use git to generate the diff,
but I guess it is nicer to have the patch self-contained.
Jamie
^ permalink raw reply
* [PATCH 01/51] ARM: reset: introduce arm_arch_reset function pointer
From: Russell King - ARM Linux @ 2011-10-31 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111029135653.GA25057@mudshark.cambridge.arm.com>
On Sat, Oct 29, 2011 at 02:56:53PM +0100, Will Deacon wrote:
> The only downside is that I have to go over all of the platforms again
> unless I can polish up my Coccinelle-fu. Ho-hum.
Well, I've just given coccinelle a go, and having read all the hype about
it, I'm completely disappointed with it to the extent that I'm going to
uninstall the tool from my system (unless someone can point out what I'm
doing wrong.)
I thought I'd give it a spin on a nice simple change - deleting the
local_irq_disable() calls inside arch_reset() (irqs have already been
disabled by this time):
@@
identifier mode, cmd;
@@
arch_reset(char mode, const char *cmd)
{
...
- local_irq_disable();
...
}
$ spatch -sp_file arch_reset-1.cocci arch/arm/*/include/*/system.h > arch_reset-1.diff
The diff it created contains:
--- arch/arm/mach-ep93xx/include/mach/system.h 2011-03-04 19:52:46.419272878 +0000
+++ /tmp/cocci-output-380-f841cc-system.h 2011-10-31 13:54:52.066705107 +0000
...
--- arch/arm/mach-iop32x/include/mach/system.h 2011-03-04 19:52:46.445272534 +0000
+++ /tmp/cocci-output-380-c0e3f4-system.h 2011-10-31 13:54:52.072705051 +0000
...
--- arch/arm/mach-ixp2000/include/mach/system.h 2011-03-04 19:52:46.449272482 +0000
+++ /tmp/cocci-output-380-467f17-system.h 2011-10-31 13:54:52.079704984 +0000
...
which in total deletes 6 lines. However, the patch is rejected by
git apply and gnu patch as it stands - it needs the filenames to be
edited to something more reasonable. So that also takes six edits.
I might as well have used grep and an editor to do the job:
$ files=$(grep -l local_irq_disable arch/arm/*/include/*/system.h)
$ uemacs $files
$ git add $files
$ git commit
And for a more complex task, you're still going to have to mess about
editing filenames. This seems (to me) to make the tool rather awkward
to use. On the plus side, for complex changes it does help to make
you look at the generated patch rather than just believing it to be
correct.
^ permalink raw reply
* [PATCH 01/51] ARM: reset: introduce arm_arch_reset function pointer
From: Will Deacon @ 2011-10-31 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111031120603.GJ19187@n2100.arm.linux.org.uk>
On Mon, Oct 31, 2011 at 12:06:03PM +0000, Russell King - ARM Linux wrote:
> On Sat, Oct 29, 2011 at 02:56:53PM +0100, Will Deacon wrote:
> > Hi Russell,
> >
> > On Sat, Oct 29, 2011 at 11:21:08AM +0100, Russell King - ARM Linux wrote:
> > > This would then allow everyone to hook into the restart via the same
> > > method irrespective of what they want, and if they want the old
> > > 'arch_reset' way, call setup_restart() themselves.
> >
> > Yup, it's a fantastic idea because it allows us to put all of the identity
> > mapping bits into setup_restart as well. So then platforms make the choice
> > about the mapping they want, rather than being told via the reboot mode.
>
> I've now committed my patch, so if you'd like to give it an acked by,
> and preferably a tested-by, I'll publish it out in a stable branch.
I gave it a spin on my Versatile Express and it reboots as expected.
Acked-and-tested-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* config ARCH_AT91SAM9X5
From: Marc Kleine-Budde @ 2011-10-31 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1320062362.14409.58.camel@x61.thuisdomein>
On 10/31/2011 12:59 PM, Paul Bolle wrote:
> 0) Since the commits
> 9baeb7e4 ("at91: Add ARCH_ID and basic cpu macros [...]"),
> b9e379bc ("net/can: allow CAN_AT91 on AT91SAM9X5"), and
> 8c3583b6 ("at91: use structure to store the current soc")
>
> the mainline kernel tree uses the Kconfig symbol ARCH_AT91SAM9X5 and the
> preprocessor macro CONFIG_ARCH_AT91SAM9X5.
>
> 1) But there's currently no Kconfig entry ARCH_AT91SAM9X5. (Neither is
> there a direct definition of the macro CONFIG_ARCH_AT91SAM9X5.)
> Shouldn't a Kconfig entry for ARCH_AT91SAM9X5 be added (to
> arch/arm/mach-at91/Kconfig)?
Talking for the at91_can driver (which has been done by me):
The driver and Kconfig have been prepared for the upcoming 5series AT91
SOCs.
Basically the same applies to the commit 9baeb7e4 ("at91: Add ARCH_ID
and basic cpu macros [...]").
But the 5series hasn't bee merged yet. Nicolas and Jean-Christophe can
probably tell you more.
regards, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111031/7e70a2cc/attachment.sig>
^ permalink raw reply
* [PATCH 01/51] ARM: reset: introduce arm_arch_reset function pointer
From: Russell King - ARM Linux @ 2011-10-31 12:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111029135653.GA25057@mudshark.cambridge.arm.com>
On Sat, Oct 29, 2011 at 02:56:53PM +0100, Will Deacon wrote:
> Hi Russell,
>
> On Sat, Oct 29, 2011 at 11:21:08AM +0100, Russell King - ARM Linux wrote:
> > This would then allow everyone to hook into the restart via the same
> > method irrespective of what they want, and if they want the old
> > 'arch_reset' way, call setup_restart() themselves.
>
> Yup, it's a fantastic idea because it allows us to put all of the identity
> mapping bits into setup_restart as well. So then platforms make the choice
> about the mapping they want, rather than being told via the reboot mode.
I've now committed my patch, so if you'd like to give it an acked by,
and preferably a tested-by, I'll publish it out in a stable branch.
^ permalink raw reply
* config ARCH_AT91SAM9X5
From: Paul Bolle @ 2011-10-31 11:59 UTC (permalink / raw)
To: linux-arm-kernel
0) Since the commits
9baeb7e4 ("at91: Add ARCH_ID and basic cpu macros [...]"),
b9e379bc ("net/can: allow CAN_AT91 on AT91SAM9X5"), and
8c3583b6 ("at91: use structure to store the current soc")
the mainline kernel tree uses the Kconfig symbol ARCH_AT91SAM9X5 and the
preprocessor macro CONFIG_ARCH_AT91SAM9X5.
1) But there's currently no Kconfig entry ARCH_AT91SAM9X5. (Neither is
there a direct definition of the macro CONFIG_ARCH_AT91SAM9X5.)
Shouldn't a Kconfig entry for ARCH_AT91SAM9X5 be added (to
arch/arm/mach-at91/Kconfig)?
Paul Bolle
^ permalink raw reply
* [PATCH] mach-ixp4xx: made gpio functions atomic
From: Russell King - ARM Linux @ 2011-10-31 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACW_hTY_CCSMWK1tYK_or5g5-2NQUbfLiJxLhKvT=V8BPuODMg@mail.gmail.com>
On Mon, Oct 31, 2011 at 09:32:55AM +0100, Frans Meulenbroeks wrote:
> May I consider the patch accepted or is some rework needed?
Neither, I was just commenting on it. MAINTAINERS says:
ARM/INTEL IXP4XX ARM ARCHITECTURE
M: Imre Kaloz <kaloz@openwrt.org>
M: Krzysztof Halasa <khc@pm.waw.pl>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-ixp4xx/
It would be a good idea to have acks from Imre and/or Krzysztof, even
better if they can apply it themselves.
^ permalink raw reply
* [PATCH] iomux-mx25: configuration to support CSPI3 on CSI pins
From: Paul Fertser @ 2011-10-31 11:04 UTC (permalink / raw)
To: linux-arm-kernel
This adds necessary defines for the CSPI3 module (activated with
imx25_add_spi_imx2()) to work on the CSI pins (alternative mode 7).
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
---
Tested on real hardware
arch/arm/plat-mxc/include/mach/iomux-mx25.h | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-mxc/include/mach/iomux-mx25.h b/arch/arm/plat-mxc/include/mach/iomux-mx25.h
index bf64e1e..f0726d4 100644
--- a/arch/arm/plat-mxc/include/mach/iomux-mx25.h
+++ b/arch/arm/plat-mxc/include/mach/iomux-mx25.h
@@ -265,16 +265,20 @@
#define MX25_PAD_CSI_D2__CSI_D2 IOMUX_PAD(0x318, 0x120, 0x10, 0, 0, NO_PAD_CTRL)
#define MX25_PAD_CSI_D2__UART5_RXD_MUX IOMUX_PAD(0x318, 0x120, 0x11, 0x578, 1, NO_PAD_CTRL)
#define MX25_PAD_CSI_D2__GPIO_1_27 IOMUX_PAD(0x318, 0x120, 0x15, 0, 0, NO_PAD_CTRL)
+#define MX25_PAD_CSI_D2__CSPI3_MOSI IOMUX_PAD(0x318, 0x120, 0x17, 0, 0, NO_PAD_CTRL)
#define MX25_PAD_CSI_D3__CSI_D3 IOMUX_PAD(0x31c, 0x124, 0x10, 0, 0, NO_PAD_CTRL)
#define MX25_PAD_CSI_D3__GPIO_1_28 IOMUX_PAD(0x31c, 0x124, 0x15, 0, 0, NO_PAD_CTRL)
+#define MX25_PAD_CSI_D3__CSPI3_MISO IOMUX_PAD(0x31c, 0x124, 0x17, 0x4b4, 1, NO_PAD_CTRL)
#define MX25_PAD_CSI_D4__CSI_D4 IOMUX_PAD(0x320, 0x128, 0x10, 0, 0, NO_PAD_CTRL)
#define MX25_PAD_CSI_D4__UART5_RTS IOMUX_PAD(0x320, 0x128, 0x11, 0x574, 1, NO_PAD_CTRL)
#define MX25_PAD_CSI_D4__GPIO_1_29 IOMUX_PAD(0x320, 0x128, 0x15, 0, 0, NO_PAD_CTRL)
+#define MX25_PAD_CSI_D4__CSPI3_SCLK IOMUX_PAD(0x320, 0x128, 0x17, 0, 0, NO_PAD_CTRL)
#define MX25_PAD_CSI_D5__CSI_D5 IOMUX_PAD(0x324, 0x12c, 0x10, 0, 0, NO_PAD_CTRL)
#define MX25_PAD_CSI_D5__GPIO_1_30 IOMUX_PAD(0x324, 0x12c, 0x15, 0, 0, NO_PAD_CTRL)
+#define MX25_PAD_CSI_D5__CSPI3_RDY IOMUX_PAD(0x324, 0x12c, 0x17, 0, 0, NO_PAD_CTRL)
#define MX25_PAD_CSI_D6__CSI_D6 IOMUX_PAD(0x328, 0x130, 0x10, 0, 0, NO_PAD_CTRL)
#define MX25_PAD_CSI_D6__GPIO_1_31 IOMUX_PAD(0x328, 0x130, 0x15, 0, 0, NO_PAD_CTRL)
--
1.7.2.3
^ permalink raw reply related
* [RFC PATCH] arm: dma: Drop GFP_COMP for DMA memory allocations
From: Russell King - ARM Linux @ 2011-10-31 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319836732-31687-1-git-send-email-swarren@nvidia.com>
On Fri, Oct 28, 2011 at 03:18:52PM -0600, Stephen Warren wrote:
> I believe the patch below was once posted to solve this for ARM, but never
> got picked up. Evidently, AVR32 did pick it up. I'm wondering if we should
> pick this up for ARM now, or if there's some other solution?
Well, Nick did talk about a solution using GFP_USERMAP in one of those
threads, which doesn't seem to have gone anywhere. So I guess we need
this patch.
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 82a093c..93b86e6 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -308,6 +308,13 @@ __dma_alloc(struct device *dev, size_t size, dma_addr_t *handle, gfp_t gfp,
> struct page *page;
> void *addr;
>
> + /* Following is a work-around (a.k.a. hack) to prevent pages
> + * with __GFP_COMP being passed to split_page() which cannot
> + * handle them. The real problem is that this flag probably
> + * should be 0 on ARM as it is not supported on this
> + * platform--see CONFIG_HUGETLB_PAGE. */
I don't think this comment makes sense anymore - HUGETLB_PAGE doesn't
have any help text.
> + gfp &= ~(__GFP_COMP);
> +
> *handle = ~0;
> size = PAGE_ALIGN(size);
>
> --
> 1.7.0.4
>
>
^ permalink raw reply
* Serious question: How long does it take to get 64bit into ARM?
From: Russell King - ARM Linux @ 2011-10-31 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111030001654.GX4267@michelle1>
On Sun, Oct 30, 2011 at 02:16:54AM +0200, Michelle Konzack wrote:
> Hello Arm Developers,
>
> Applied Micro Circuits (AMCC) has now presented its new 64bit ARM ?C:
>
> <http://www.pcmag.com/article2/0,2817,2395449,00.asp>
>
> and I like to know, how long it take, to get 64bit support into the
> Kernel.
It won't happen until there's some concrete technical documentation or
example implementation publically released, so at the moment it really
depends on the marketing schedule.
^ permalink raw reply
* [PATCH] [TRIVIAL] ARM: imx: Fix typo 'MACH_MX31_3DS_MXC_NAND_USE_BBT'
From: Jiri Kosina @ 2011-10-31 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318421062.2336.4.camel@x61.thuisdomein>
On Wed, 12 Oct 2011, Paul Bolle wrote:
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> This is trivial because this is what apparently was intended. On the
> other hand this should open code paths that were hidden until now. So
> perhaps this needs the maintainer's approval. (I cannot meaningfully
> test this.)
I'd like to have this tested by some relevant people before taking it
myself (added some CCs).
>
> arch/arm/mach-imx/mach-mx31_3ds.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-imx/mach-mx31_3ds.c b/arch/arm/mach-imx/mach-mx31_3ds.c
> index c20be75..5750ca5 100644
> --- a/arch/arm/mach-imx/mach-mx31_3ds.c
> +++ b/arch/arm/mach-imx/mach-mx31_3ds.c
> @@ -542,7 +542,7 @@ static const struct mxc_nand_platform_data
> mx31_3ds_nand_board_info __initconst = {
> .width = 1,
> .hw_ecc = 1,
> -#ifdef MACH_MX31_3DS_MXC_NAND_USE_BBT
> +#ifdef CONFIG_MACH_MX31_3DS_MXC_NAND_USE_BBT
> .flash_bbt = 1,
> #endif
> };
> --
> 1.7.4.4
>
>
>
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH] s3c2410: remove __ioaddrc()
From: Russell King - ARM Linux @ 2011-10-31 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319916749-14899-1-git-send-email-cesarb@cesarb.net>
On Sat, Oct 29, 2011 at 05:32:29PM -0200, Cesar Eduardo Barros wrote:
> While looking at s3c2410's mach/io.h, I noticed the #define for
> __ioaddr() looked wrong. While the #defines above it called the "c"
> suffixed variant when __builtin_constant_p() was true, the one for
> __ioaddr() called the "c" suffixed variant (__ioaddrc()) when
> __builtin_constant_p() was *false*.
>
> Looking further, I noticed that __ioaddr() and __ioaddrc() were
> identical, the only difference being that __ioaddr() is an inline
> function and __ioaddrc() is a macro.
>
> __ioaddrc() is not used anywhere else. There were similar constructs,
> also reversed from what I'd expect, in both mach-clps7500 (removed from
> the kernel in 2.6.29) and mach-rpc. The copy in mach-rpc was removed in
> commit 6de2c31d3dad7384b3efa03674bd6ed479d58cb2 (rpc: remove obsolete IO
> accessors).
>
> Since __ioaddrc() is both redundant and useless, has no other uses, and
> has already been removed in mach-rpc, remove it also in mach-s3c2410.
Good. Now, what about that horrible fudge in the inb/outb etc accessors.
Can that be killed off as well?
^ permalink raw reply
* [PATCH 2/6] arm/tegra: prepare pinmux code for multiple tegra variants
From: Peter De Schrijver @ 2011-10-31 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF173EDAB4A4@HQMAIL01.nvidia.com>
On Fri, Oct 28, 2011 at 06:18:27PM +0200, Stephen Warren wrote:
> Peter De Schrijver wrote at Friday, October 28, 2011 2:18 AM:
> > On Thu, Oct 27, 2011 at 09:59:49PM +0200, Stephen Warren wrote:
> > > Peter De Schrijver wrote at Tuesday, October 25, 2011 10:54 AM:
> > > > This patch modifies the pinmux code to be useable for multiple tegra variants.
> > > > Some tegra20 specific constants will be replaced by variables which will be
> > > > initialized to the appropriate value at runtime.
> ...
> > > > @@ -668,11 +668,24 @@ void tegra_pinmux_config_pullupdown_table(const struct tegra_pingroup_config *co
> > > > }
> > > > }
> > > >
> > > > +static struct of_device_id tegra_pinmux_of_match[] __devinitdata = {
> > > > + { .compatible = "nvidia,tegra20-pinmux", tegra20_pinmux_init },
> > > > + { },
> > > > +};
> > > > +
> > > > static int __devinit tegra_pinmux_probe(struct platform_device *pdev)
> > > > {
> > > > struct resource *res;
> > > > int i;
> > > > int config_bad = 0;
> > > > + const struct of_device_id *match;
> > > > +
> > > > +#ifdef CONFIG_OF
> > > > + match = of_match_device(tegra_pinmux_of_match, &pdev->dev);
> > >
> > > What if match==NULL? I suppose that "can't" happen with DT, since the
> > > device wouldn't have been probed unless there was a matching entry...
> >
> > Exactly. That was my reasoning as well. We can't get here unless there is a
> > match.
> >
> > > Does this work when booting without DT; IIRC the internal patches I saw
> > > fell back to hard-coding a call to tegra20_pinmux_init() when booting
> > > a static board file (i.e. not booting device-tree)? Perhaps that's in a
> >
Indeed. Something went wrong here.
> > Unfortunately I don't have a tegra20 board which is supported without
> > devicetree.
>
> Oh, that's quite unfortunate. Still, you need to write the code so it's
> expected to work for the non-DT case. Once you've fixed this, if you
> push a complete branch somewhere, I can boot-test it on a few non-DT
> boards. Hopefully I can test on Cardhu too.
I know. But alas I have to base myself on assumptions, which is suboptimal of
course. I will see if I can find a tegra20 board which doesn't require
devicetree here in finland or push a complete branch somewhere.
Cheers,
Peter.
^ permalink raw reply
* Serious question: How long does it take to get 64bit into ARM?
From: Catalin Marinas @ 2011-10-31 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111030001654.GX4267@michelle1>
Hi,
On 30 October 2011 01:16, Michelle Konzack
<linux4michelle@tamay-dogan.net> wrote:
> Applied Micro Circuits (AMCC) has now presented its new 64bit ARM ?C:
>
> ? ?<http://www.pcmag.com/article2/0,2817,2395449,00.asp>
>
> and I like to know, how long it take, to ?get ?64bit ?support ?into ?the
> Kernel.
We are working on this already and will follow the Linux community
review process to get the ARMv8 support in the mainline kernel. I
can't mention a timeline at this point as it depends on detailed
documentation being available and at least some early hardware (FPGA)
to test on but hopefully we'll complete the process before you can get
platforms with ARMv8 (even if mainline would not fully support ARMv8,
I'll make patches available on some Git tree).
--
Catalin
^ permalink raw reply
* [PATCH v9 2/4] cpuidle: Remove CPUIDLE_FLAG_IGNORE and dev->prepare()
From: Deepthi Dharwar @ 2011-10-31 7:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EAABB07.3000305@linux.intel.com>
On Friday 28 October 2011 07:54 PM, Arjan van de Ven wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/28/2011 3:50 AM, Deepthi Dharwar wrote:
>> The cpuidle_device->prepare() mechanism causes updates to the
>> cpuidle_state[].flags, setting and clearing CPUIDLE_FLAG_IGNORE
>> to tell the governor not to chose a state on a per-cpu basis at
>> run-time. State demotion is now handled by the driver and it returns
>> the actual state entered. Hence, this mechanism is not required.
>> Also this removes per-cpu flags from cpuidle_state enabling
>> it to be made global.
>>
>
> having worked on some newer platforms....
> this one is really still needed. doing this inside the actual states
> does not work,
> because if the deepest 3 states are invalid, the same (somewhat
> expensive) test would have to be done 3 times,
> and each of the states would have to fail before the 4th one gets chosen.
> that's just not going to work
>
> (in the state handler you can't know what other state to fall back to,
> and especially not how to enter such a fallback state)
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (MingW32)
>
> iQEcBAEBAgAGBQJOqrsGAAoJEEHdSxh4DVnEu7EH/i5lEJctBAIubJOcZz/tvBFp
> XYmAe/HqNtSXeHOVsJkTf8y4ppE8487exF7xxMik4GRN0CZNCtkyMezqDVu+eDim
> O/UUbScsAc5cSY6mkjOFXLFup+mi1nkRUnAbxXEyTMhWwcbfr2OvcuO7l7TmATML
> hu87P3PVEafEop3q2+uWMc57fFxnNFfEDqRx6N9V+OJKV5dHrRYL4G4E01fYGFLo
> xTR0IW7nB15L0C29zk9uk/Dqow8SoJZA83c7p7AieP5zdntb6p7noIf03qmdp19f
> fulwMwembCHivo+pLO+jAMhKD1T6VYoCyiYW0LHrQ2E07fayBhFJCxlazgKFcl0=
> =FL6o
> -----END PGP SIGNATURE-----
>
Hi Arjan,
Thanks for the review.
We retain the dev->prepare() routine and CPUIDLE_FLAG_IGNORE
but still allow the dev->enter() to return index ?
So by retaining it, transition to the idle states
would be much quicker in case one more states are invalid.
Also to note is that in the newer design, we have split the
cpuidle_state structure. One global struct, cpuidle_states[] that
contains all the state related information including flags, and
the other cpuidle_device that contain statistics and other data
that are per-cpu basis.
So the flags are not per cpu per state basis but
maintained globally as per state basis.
So if we have to enable CPUIDLE_FLAG_IGNORE flag in this
current new design, then I am thinking if we needed to have this
on a per-cpu basis. If so, then flags have to be moved into cpuidle_device
struct rather than cpuidle_state struct.
Is it a good idea to retain these flags as global (part of cpuidle_states)
or make it per-cpu basis ?
-Thanks
Deepthi
^ permalink raw reply
* [PATCH] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
From: Pandita, Vikram @ 2011-10-31 6:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315521779.2313.29.camel@deneb.redhat.com>
On Thu, Sep 8, 2011 at 3:41 PM, Mark Salter <msalter@redhat.com> wrote:
> On Wed, 2011-08-31 at 20:35 +0100, Will Deacon wrote:
>> On Wed, Aug 31, 2011 at 07:19:33PM +0100, Rob Herring wrote:
>> > On 08/31/2011 12:51 PM, Will Deacon wrote:
>> > > Another thing that Marc and I tried on OMAP4 was not bringing up the secondary
>> > > CPU during boot (by commenting out most of smp_init). In this case, I/O
>> > > performance was good until we tried to online the secondary CPU. The online
>> > > failed but after that the I/O performance was certainly degraded.
>> > >
>> >
>> > Was the SCU enabled at that point? One diff between nosmp boot and
>> > offlining the 2nd core would be that the SCU remains enabled in the
>> > latter case. I think the SCU does not get enabled for nosmp.
>>
>> Our rudimentary test (printing out the SCU control register during boot)
>> showed that it *was* enabled for nosmp. I think this is due to the secure
>> world having to do that on OMAP so it's probably not true for other
>> platforms.
>
> I've done a little test and found that turning on the MMU of the second
> core causes the problem to show up. I patched head.S so I stopped the
> second core in an infinite loop just before turning on the MMU. The
> system continues booting on core#0 and I see ~20MB/s with hdparm -t to
> an attached usb disk. Same setup but with second core being stopped with
> infinite loop just after MMU is enabled shows ~5MB/s. So whatever is
> going wrong, its not because of anything the second core is doing beyond
> turning on its MMU and doing an empty loop.
what was the final take on the optimization?
Excuse if i could not follow the whole thread - could someone
summarize for the benefit of many.
Thanks
>
> --Mark
>
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH V6] SDHCI: S3C: Use generic clock names for sdhci bus clock options
From: Rajeshwari Shinde @ 2011-10-31 5:44 UTC (permalink / raw)
To: linux-arm-kernel
This patch modifies the driver to stop depending on the clock names
being passed from the platform and switch over to bus clock lookup
using generic clock names.
V6 Changes:
Changed sprintf to snprintf as suggested by Chris Ball.
Signed-off-by: Rajeshwari Shinde <rajeshwari.s@samsung.com>
---
drivers/mmc/host/sdhci-s3c.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 82709b6..488223c 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -435,14 +435,11 @@ static int __devinit sdhci_s3c_probe(struct platform_device *pdev)
for (clks = 0, ptr = 0; ptr < MAX_BUS_CLK; ptr++) {
struct clk *clk;
- char *name = pdata->clocks[ptr];
-
- if (name == NULL)
- continue;
+ char name[14];
+ snprintf(name, 14, "mmc_busclk.%d", ptr);
clk = clk_get(dev, name);
if (IS_ERR(clk)) {
- dev_err(dev, "failed to get clock %s\n", name);
continue;
}
--
1.7.4.4
^ permalink raw reply related
* [PATCH V5 1/3] SDHCI: S3C: Use generic clock names for sdhci bus clock options
From: Rajeshwari Birje @ 2011-10-31 4:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m2obx34j81.fsf@bob.laptop.org>
Hi Chris,
Thank you for your comment will modify and resend the patches.
Regards,
Rajeshwari Shinde.
On Thu, Oct 27, 2011 at 1:29 AM, Chris Ball <cjb@laptop.org> wrote:
> Hi Rajeshwari, Kukjin,
>
> On Fri, Oct 14 2011, Rajeshwari Shinde wrote:
>> This patch modifies the driver to stop depending on the clock names
>> being passed from the platform and switch over to bus clock lookup
>> using generic clock names.
>>
>> Signed-off-by: Rajeshwari Shinde <rajeshwari.s@samsung.com>
>> ---
>> ?drivers/mmc/host/sdhci-s3c.c | ? ?6 ++----
>> ?1 files changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
>> index 82709b6..a5fde87 100644
>> --- a/drivers/mmc/host/sdhci-s3c.c
>> +++ b/drivers/mmc/host/sdhci-s3c.c
>> @@ -435,14 +435,12 @@ static int __devinit sdhci_s3c_probe(struct platform_device *pdev)
>>
>> ? ? ? for (clks = 0, ptr = 0; ptr < MAX_BUS_CLK; ptr++) {
>> ? ? ? ? ? ? ? struct clk *clk;
>> - ? ? ? ? ? ? char *name = pdata->clocks[ptr];
>> + ? ? ? ? ? ? char name[14];
>>
>> - ? ? ? ? ? ? if (name == NULL)
>> - ? ? ? ? ? ? ? ? ? ? continue;
>> + ? ? ? ? ? ? sprintf(name, "mmc_busclk.%d", ptr);
>
> Let's use snprintf() here instead -- it's better to have fewer uses of
> sprintf() to audit.
>
>> ? ? ? ? ? ? ? clk = clk_get(dev, name);
>> ? ? ? ? ? ? ? if (IS_ERR(clk)) {
>> - ? ? ? ? ? ? ? ? ? ? dev_err(dev, "failed to get clock %s\n", name);
>> ? ? ? ? ? ? ? ? ? ? ? continue;
>> ? ? ? ? ? ? ? }
>
> Thanks,
>
> - Chris.
> --
> Chris Ball ? <cjb@laptop.org> ? <http://printf.net/>
> One Laptop Per Child
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v5] dmaengine: add CSR SiRFprimaII DMAC driver
From: Vinod Koul @ 2011-10-31 3:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319768559-24200-1-git-send-email-Barry.Song@csr.com>
On Thu, 2011-10-27 at 19:22 -0700, Barry Song wrote:
> From: Rongjun Ying <Rongjun.Ying@csr.com>
>
> Cc: Jassi Brar <jaswinder.singh@linaro.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Rongjun Ying <rongjun.ying@csr.com>
> Signed-off-by: Barry Song <Baohua.Song@csr.com>
> ---
> -v5:
> fix checkpatch issues;
> fix compile warinings;
> Note: This tree
> git://gitorious.org/sirfprima2-kernel/sirfprima2-kernel.git prima2-dma-for-Vinod
> merge both slave_dma interleaved branch and prima2 defconfig.
Applied thanks.
I will merge these after merging direction fixes.
--
~Vinod
^ permalink raw reply
* [PATCH v2 2/3] arm/dt: tegra: add dts file for paz00
From: Grant Likely @ 2011-10-31 3:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4025601.AfFCiixCcK@ax5200p>
On Sun, Oct 30, 2011 at 09:39:37PM +0100, Marc Dietrich wrote:
> On Friday 28 October 2011 09:49:49 Stephen Warren wrote:
> > I also see a bunch of code to set up the memory
> > information from DT e.g. setup_machine_fdt()'s call to:
> >
> > of_scan_flat_dt(early_init_dt_scan_memory, NULL);
> >
> > ... but I assume that happens before the ATAGs are processed, and the
> > buggy ATAGs end up overriding the information in the DT file. And further,
> > I assume that specifying "mem=" on the command-line overrides that, thus
> > solving the problem.
> >
> > It'd be awesome if you could validate this; the simplest way is probably
> > to:
> >
> > a) Remove mem= from the command-line
>
> I tested several variations. Without DT, the fixup can compensate a missing
> mem entry in the kernel command line, but with a mem= from the kernel command
> line, a fixup is not needed.
>
> With DT, the command line specified from nvflash is ignored and the one from
> DT comes into the game. If it is also missing there, system detects 512 MB
> (which is physical right, but we cannot reserve memory for the gpu). The fixup
> is indeed ignored in this case.
The /memreserve/ fields are supposed to allow you to do this.
>
> > b) Modify arch/arm/kernel/setup.c:parse_tag_mem32() to do nothing;
> > comment out the call to arm_add_memory()
>
> I leave this out because the bootloader does not send memory info in the
> ATAGS.
>
> > c) Test booting, and check what RAM size the kernel thinks you have.
>
> see above. RAM detection works, but it's not what we want ...
>
> > If that works, then ATAGs are the problem. We probably need to modify the
> > core ARM code not to use memory ATAGs when there is a DT?
> >
> > I'm mainly pushing on this because adding "mem=" to the command-line in
> > the DT file isn't a great solution; when people start using bootloaders
> > that rewrite the DT to include the user-specified command-line, then every
> > user is going to have to start specifying "mem=" in their command-lines.
>
> Well, I see two options for our case:
>
> a) use the mem=448M at 0 in the DT so the gpu can get its memory
> b) upstream the chromeos changes to reserve gpu memory "on the fly" from
> the autodetected 512M (as it should be IMHO).
b) is the ideal. a) is absolutely wrong. /memreserve/ should fix the
gpu memory problem when not passing a mem= parameter. If /memreserve/
isn't working, then I'd like to know why.
g.
^ permalink raw reply
* [GIT PULL] GIC DT binding support
From: Rob Herring @ 2011-10-31 1:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201110310131.53251.arnd@arndb.de>
Arnd,
On 10/30/2011 07:31 PM, Arnd Bergmann wrote:
> On Friday 28 October 2011, Rob Herring wrote:
>> Merge branch 'for-sfr' of
>> git://openlinux.windriver.com/people/paulg/linux-next into HEAD
>> (2011-10-28 15:51:07 -0500)
>>
>
> Rob, I think there is no chance that this is working out.
>
> I've just spent a few hours trying to resolve all the dependencies from this,
> but I don't think it will work out, unless Linus pulls that tree very soon,
> which I think is very unlikely.
>
> Have you made sure that Paul even considers this branch stable?
No.
> Normally this kind of change gets pushed *last* in the merge window, to make
> it possible to fix up all the stuff that breaks. This means I cannot
> wait for the branch to get merged upstream before send a pull request for
> my next/dt and next/soc branches.
>
> Do you even depend on that branch? It seems to me that you merely have a
> conflict, not a dependency, so why do you even try fixing it up?
Sorry about this. I thought I needed to fix the linux-next build
breakage. I only depend on it when export.h gets introduced, so I can
drop that out. All the other dependencies are in Linus' master now. I
pushed out a branch without Paul's branch:
I get to Connect around 2PM tomorrow, we can discuss further then if
necessary.
The following changes since commit ce949717b559709423c1ef716a9db16d1dcadaed:
Merge git://github.com/rustyrussell/linux (2011-10-29 07:52:16 -0700)
are available in the git repository at:
git://sources.calxeda.com/kernel/linux.git gic-dt-v2
Rob Herring (5):
of/irq: introduce of_irq_init
irq: support domains with non-zero hwirq base
ARM: gic: add irq_domain support
ARM: gic: add OF based initialization
ARM: gic: fix irq_alloc_descs handling for sparse irq
Documentation/devicetree/bindings/arm/gic.txt | 55 +++++++
arch/arm/common/Kconfig | 1 +
arch/arm/common/gic.c | 187
++++++++++++++++---------
arch/arm/include/asm/hardware/gic.h | 10 +-
drivers/of/irq.c | 107 ++++++++++++++
include/linux/irqdomain.h | 16 ++-
include/linux/of_irq.h | 3 +
kernel/irq/irqdomain.c | 12 +-
8 files changed, 319 insertions(+), 72 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
Rob
^ permalink raw reply
* [GIT PULL] GIC DT binding support
From: Arnd Bergmann @ 2011-10-31 0:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EAB1BFF.3070406@gmail.com>
On Friday 28 October 2011, Rob Herring wrote:
> Merge branch 'for-sfr' of
> git://openlinux.windriver.com/people/paulg/linux-next into HEAD
> (2011-10-28 15:51:07 -0500)
>
Rob, I think there is no chance that this is working out.
I've just spent a few hours trying to resolve all the dependencies from this,
but I don't think it will work out, unless Linus pulls that tree very soon,
which I think is very unlikely.
Have you made sure that Paul even considers this branch stable?
Normally this kind of change gets pushed *last* in the merge window, to make
it possible to fix up all the stuff that breaks. This means I cannot
wait for the branch to get merged upstream before send a pull request for
my next/dt and next/soc branches.
Do you even depend on that branch? It seems to me that you merely have a
conflict, not a dependency, so why do you even try fixing it up?
Arnd
^ permalink raw reply
* [GIT PULL] pending DT patches and cleanup for map_io for v3.2 merge window
From: Arnd Bergmann @ 2011-10-30 23:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024091704.GF31337@atomide.com>
On Monday 24 October 2011, Tony Lindgren wrote:
> As discussed in the ARM kernel meeting yesterday, here's are
> the pending omap things to pull for v3.2 merge window.
Hi Tony,
I finally got to pull these.
> These would be nice to get still in as other people's work
> such as Nico's map_io changes need #2 below.
>
> 1. Initial DT support posted few weeks ago
>
> Please see the earlier pull request at:
>
> http://lkml.org/lkml/2011/10/4/441
Looks good. I've missed this initially because I had not yet managed
to go through that mail thread (randconfig patches) again and pick
up the patches that got an Ack. The pull request was right in the
middle of 100 other unread emails...
> 2. Cleanup for map_io posted few weeks ago
>
> This depends on the #1 above, and also requires
> the ioremap_exec patch. Russell said he has applied
> into devel-stable (But not pushed out yet?).
>
> When you have the ioremap_exec patch from Russell,
> please pull this from:
>
> git://github.com/tmlind/linux.git sram-map-io
>
> Pull request against #1 attached below.
This had systematic but trivial conflicts against the memory.h
series, which I fixed up. There was also a conflict with 009426a0e
"ARM: omap: Setup consistent dma size at boot time" from Tixy.
That patch added a call to omap_init_consistent_dma_size in a function
that you removed. I have resolved the conflict by adding that call to
omap1_init_early and omap_common_init_early, but I have no idea if that
is a correct resolution. Please check.
Arnd
Arnd
^ permalink raw reply
* [GIT PULL] i.MX6Q support
From: Arnd Bergmann @ 2011-10-30 22:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111022005800.GC337@S2100-06.ap.freescale.net>
On Saturday 22 October 2011, Shawn Guo wrote:
> On Fri, Oct 21, 2011 at 08:01:58PM +0200, Sascha Hauer wrote:
> >
> > Adding the following at least gives a compilable result. Works on i.MX3,
> > I couldn't test on i.MX6 though.
>
> It works for imx6q.
I had to rebase the branch after pulling the updated gic series.
Sorry to bother you again, but can you check the new branch one more time?
Arnd
^ 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