* [GIT PULL] GIC DT binding support
From: Rob Herring @ 2011-10-28 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EA5DADC.7030805@gmail.com>
Arnd,
On 10/24/2011 04:38 PM, Rob Herring wrote:
> Arnd,
>
> I'm not sure if you want a rebased branch to fix merge conflicts or not.
> If that's okay, please pull. I've also fixed the msm compile failure.
>
> The dependencies are v3.1-rc9 and rmk's devel-stable.
>
Here's an updated pull request to fix missing export.h include. Now it's
also dependent on module.h clean-up branch:
git://openlinux.windriver.com/people/paulg/linux-next for-sfr
The following changes since commit fa1d6d372245a160eecf5f57d64d2b21ea248e08:
Merge branch 'for-sfr' of
git://openlinux.windriver.com/people/paulg/linux-next into HEAD
(2011-10-28 15:51:07 -0500)
are available in the git repository at:
git://sources.calxeda.com/kernel/linux.git gic-dt
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 | 188
++++++++++++++++--------
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, 320 insertions(+), 72 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
Rob
^ permalink raw reply
* [RFC PATCH] arm: dma: Drop GFP_COMP for DMA memory allocations
From: Stephen Warren @ 2011-10-28 21:18 UTC (permalink / raw)
To: linux-arm-kernel
From: Sumit Bhattacharya <sumitb@nvidia.com>
dma_alloc_coherent wants to split pages after allocation in order to
reduce the memory footprint. This does not work well with GFP_COMP
pages, so drop this flag before allocation.
This patch is ported from arch/avr32
(commit 3611553ef985ef7c5863c8a94641738addd04cff).
Signed-off-by: Sumit Bhattacharya <sumitb@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
Russell, for background, please see:
http://www.spinics.net/lists/alsa-devel/msg05399.html
https://lkml.org/lkml/2006/7/8/236
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?
(note: This patch is actually based on one of our older internal kernels;
I'd need to rebase it if we do decide to go ahead with it. I also haven't
tested it in mainline, and would have difficulty doing so, since the issue
this solves only shows up when using our HD-Audio controller on Tegra30,
and that isn't upstream yet.)
arch/arm/mm/dma-mapping.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
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. */
+ gfp &= ~(__GFP_COMP);
+
*handle = ~0;
size = PAGE_ALIGN(size);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 01/51] ARM: reset: introduce arm_arch_reset function pointer
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-10-28 21:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319813059-8914-2-git-send-email-will.deacon@arm.com>
On 15:43 Fri 28 Oct , Will Deacon wrote:
> arch_reset is a static inline function defined in mach/system.h and, as
> such, is a blocker for the single zImage work.
>
> This patch introduces an arm_arch_reset function pointer to which
> platforms can assign their reset function rather than define it in the
> header file.
this is a great cleanup but I think this should be done in the soc_desc
structure as propose before
Best Regards,
J.
^ permalink raw reply
* [PATCH] ARM: SAMSUNG: Fix compile error due to kfree
From: jhbird.choi at gmail.com @ 2011-10-28 21:45 UTC (permalink / raw)
To: linux-arm-kernel
From: Jonghwan Choi <jhbird.choi@gmail.com>
Fix implicit declaration of function 'kfree'
Signed-off-by: Jonghwan Choi <jhbird.choi@gmail.com>
---
arch/arm/plat-samsung/dev-backlight.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-samsung/dev-backlight.c b/arch/arm/plat-samsung/dev-backlight.c
index 3cedd4c..2adbeae 100644
--- a/arch/arm/plat-samsung/dev-backlight.c
+++ b/arch/arm/plat-samsung/dev-backlight.c
@@ -14,6 +14,7 @@
#include <linux/platform_device.h>
#include <linux/io.h>
#include <linux/pwm_backlight.h>
+#include <linux/slab.h>
#include <plat/devs.h>
#include <plat/gpio-cfg.h>
--
1.7.0.4
^ permalink raw reply related
* [PATCH 00/51] Remove inline arch_reset definitions from system.h
From: Deepak Saxena @ 2011-10-28 22:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319813059-8914-1-git-send-email-will.deacon@arm.com>
On Oct 28 2011, at 15:43, Will Deacon was caught saying:
> Well, looks like I finally made it and I reckon I've managed to preserve
> my sanity.
>
> This patch series removes the inline arch_reset definitions from the
> mach/system.h files, which is currently a blocker for the single zImage
> work. Nicolas has some patches doing a similar thing for arch_idle. In
> cases where a new file has been introduced and it looks like arch_idle
> could co-exist in there, I've named the new file system.c but it will
> mean that Nicolas will need to rebase his stuff on top of this.
>
> I think I've compile-tested this whenever I could identify the right
> defconfig, but my brain stopped working about 25% of the way through.
>
> Thanks to Paul Walmsley for saving me from the OMAP changes.
>
> Comments / suggestions / fixups welcome.
I like the idea, I'm wondering about having stuffing a pointer to
an init function to assign the pointer into mach_desc? In the at91
case, we've got 7 board files assiging the same pointer. Instead
we could just have an at91_arch_reset_init() that only needs
to be in one .c file.
Another idea is to just stuff the pointer to the machine's arch_reset
into the mach_desc and generic init code could read it. In the case
of a some weird board version related quirk that can only be detected
by some runtime register poking (i.e. not via the DT machine
compatability), we could update the pointer in machines' fixup() function.
~Deepak
--
"People think all we need to fix our predicament is a free source of
energy, but I think we need to change out behaviour. More energy would
just deplete the Earth's lifeblood faster." - Janine Benyius
^ permalink raw reply
* [PATCH 34/51] ARM: mach-pxa: use arm_arch_reset instead of arch_reset
From: Marek Vasut @ 2011-10-28 22:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319813059-8914-35-git-send-email-will.deacon@arm.com>
> This patch updates mach-pxa to use arm_arch_reset instead of
> arch_reset.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm/mach-pxa/include/mach/system.h | 6 +++---
> arch/arm/mach-pxa/reset.c | 8 +++++++-
> 2 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/include/mach/system.h
> b/arch/arm/mach-pxa/include/mach/system.h index d1fce8b..0687110 100644
> --- a/arch/arm/mach-pxa/include/mach/system.h
> +++ b/arch/arm/mach-pxa/include/mach/system.h
> @@ -11,8 +11,6 @@
> */
>
> #include <asm/proc-fns.h>
> -#include "hardware.h"
> -#include "pxa2xx-regs.h"
>
> static inline void arch_idle(void)
> {
> @@ -20,4 +18,6 @@ static inline void arch_idle(void)
> }
>
>
> -void arch_reset(char mode, const char *cmd);
> +static inline void arch_reset(char mode, const char *cmd)
> +{
> +}
> diff --git a/arch/arm/mach-pxa/reset.c b/arch/arm/mach-pxa/reset.c
> index 01e9d64..075598a 100644
> --- a/arch/arm/mach-pxa/reset.c
> +++ b/arch/arm/mach-pxa/reset.c
> @@ -81,7 +81,7 @@ static void do_hw_reset(void)
> OSMR3 = OSCR + 368640; /* ... in 100 ms */
> }
>
> -void arch_reset(char mode, const char *cmd)
> +static void pxa_arch_reset(char mode, const char *cmd)
> {
> clear_reset_status(RESET_STATUS_ALL);
>
> @@ -100,3 +100,9 @@ void arch_reset(char mode, const char *cmd)
> }
> }
>
> +static int __init pxa_arch_reset_init(void)
> +{
> + arm_arch_reset = pxa_arch_reset;
> + return 0;
> +}
> +arch_initcall(pxa_arch_reset_init);
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
^ permalink raw reply
* [PATCH 00/51] Remove inline arch_reset definitions from system.h
From: Deepak Saxena @ 2011-10-28 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111028220821.GA27661@plexity.net>
On Sat, Oct 29, 2011 at 12:08 AM, Deepak Saxena <dsaxena@plexity.net> wrote:
> On Oct 28 2011, at 15:43, Will Deacon was caught saying:
>> Well, looks like I finally made it and I reckon I've managed to preserve
>> my sanity.
>>
>> This patch series removes the inline arch_reset definitions from the
>> mach/system.h files, which is currently a blocker for the single zImage
>> work. Nicolas has some patches doing a similar thing for arch_idle. In
>> cases where a new file has been introduced and it looks like arch_idle
>> could co-exist in there, I've named the new file system.c but it will
>> mean that Nicolas will need to rebase his stuff on top of this.
>>
>> I think I've compile-tested this whenever I could identify the right
>> defconfig, but my brain stopped working about 25% of the way through.
>>
>> Thanks to Paul Walmsley for saving me from the OMAP changes.
>>
>> Comments / suggestions / fixups welcome.
>
> I like the idea, I'm wondering about having stuffing a pointer to
> an init function to assign the pointer into mach_desc? In the at91
> case, we've got 7 board files assiging the same pointer. Instead
> we could just have an at91_arch_reset_init() that only needs
> to be in one .c file.
/ignore me. I missread the patch and though they were all being assigned
to the same function.
> Another idea is to just stuff the pointer to the machine's arch_reset
> into the mach_desc and generic init code could read it. In the case
> of a some weird board version related quirk that can only be detected
> by some runtime register poking (i.e. ?not via the DT machine
> compatability), we could update the pointer in machines' fixup() function.
~Deepak
^ permalink raw reply
* [RFC] Shrink sched_clock some more
From: Nicolas Pitre @ 2011-10-28 22:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EAAF5AE.6090300@codeaurora.org>
On Fri, 28 Oct 2011, Stephen Boyd wrote:
> On 09/23/11 01:52, Marc Zyngier wrote:
> > On 22/09/11 16:36, Russell King - ARM Linux wrote:
> >> ... by getting rid of the fixed-constant optimization, and moving the
> >> update code into arch/arm/kernel/sched_clock.c.
> >>
> >> Platforms now only have to supply a function to read the sched_clock
> >> register, and some basic information such as the number of significant
> >> bits and the tick rate.
> > This looks similar to a patch I posted a while ago:
> > http://patchwork.ozlabs.org/patch/112318/
> >
> >
>
> Can we get one of these two patches merged next merge window? I'd like
> to add sched_clock support to MSM and building on top of this patch is
> easier than the other way around.
Yes, I agree. Any optimizations I might have suggested may be added
later.
Nicolas
^ permalink raw reply
* [PATCH] max8997_charger: Fix unsigned value for less than zero
From: jhbird.choi at gmail.com @ 2011-10-28 22:56 UTC (permalink / raw)
To: linux-arm-kernel
From: Jonghwan Choi <jhbird.choi@gmail.com>
The 'val' is a 'unsigned char', so it is never less than zero.
Signed-off-by: Jonghwan Choi <jhbird.choi@gmail.com>
---
drivers/power/max8997_charger.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/power/max8997_charger.c b/drivers/power/max8997_charger.c
index ffc5033..a5eb3ed 100644
--- a/drivers/power/max8997_charger.c
+++ b/drivers/power/max8997_charger.c
@@ -97,7 +97,7 @@ static __devinit int max8997_battery_probe(struct platform_device *pdev)
return -EINVAL;
if (pdata->eoc_mA) {
- u8 val = (pdata->eoc_mA - 50) / 10;
+ int val = (pdata->eoc_mA - 50) / 10;
if (val < 0)
val = 0;
if (val > 0xf)
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/3] ARM: EXYNOS: Support ASV for Exynos4210
From: Russell King - ARM Linux @ 2011-10-29 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319677938-25732-4-git-send-email-boyko.lee@samsung.com>
On Thu, Oct 27, 2011 at 10:12:18AM +0900, Jongpill Lee wrote:
> +static int exynos4210_asv_pre_clock_init(void)
> +{
> + struct clk *clk_hpm;
> + struct clk *clk_copy;
> + struct clk *clk_parent;
> +
> + /* PWI clock setting */
> + clk_copy = clk_get(NULL, "sclk_pwi");
> + if (IS_ERR(clk_copy)) {
> + pr_info("EXYNOS4210: ASV : SCLK_PWI clock get error\n");
> + return -EINVAL;
> + } else {
> + clk_parent = clk_get(NULL, "xusbxti");
> +
> + if (IS_ERR(clk_parent)) {
> + pr_info("EXYNOS4210: ASV: MOUT_APLL clock get error\n");
> + clk_put(clk_copy);
> + return -EINVAL;
> + }
> + if (clk_set_parent(clk_copy, clk_parent))
> + pr_info("EXYNOS4210: ASV: Unable to set parent %s of clock %s.\n",
> + clk_parent->name, clk_copy->name);
> +
> + clk_put(clk_parent);
> + }
> + clk_set_rate(clk_copy, 4800000);
> +
> + clk_put(clk_copy);
This looks really weird - if something is using a clock, the reference
to the struct clk is supposed to be held all the time that the clock is
being used. Plus there's nothing to enable the clock itself (so it's
probably disabled).
^ permalink raw reply
* [PATCH] ramoops appears geared to not support ARM
From: Marco Stornelli @ 2011-10-29 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319844110-23062-1-git-send-email-bfreed@chromium.org>
(Added linux-arm)
Il 29/10/2011 01:21, Bryan Freed ha scritto:
> I had some difficulty in getting ramoops to work on our ARM systems.
> The driver maps memory with ioremap() which is supposed to map IO memory,
> not physical RAM. This happens to work on x86 and apparently some other
> architectures, but it does not work on ARM.
> Specifically, I see this comment in __arm_ioremap_pfn_caller():
> Don't allow RAM to be mapped - this causes problems with ARMv6+
>
> So here is a patch that hacks around the issue using page_is_ram() to
> differentiate between the two.
>
> Am I missing something here?
> Is ramoops working on any ARM systems yet, and I am just doing something wrong?
>
> My ARM platform reserves a section of RAM for use by ramoops, but it is still
> mapped along with the rest of main memory. This is so /dev/mem can find it
> with xlate_dev_mem_ptr().
> On x86, I see our BIOS reserves the memory so that it is not counted as main
> memory, and it is not mapped until ramoops ioremaps it.
>
> Bryan Freed (1):
> ramoops: Add support for ARM systems.
>
> drivers/char/ramoops.c | 67 +++++++++++++++++++++++++++++++++++++----------
> 1 files changed, 52 insertions(+), 15 deletions(-)
>
Can some ARM guys give an opinion about that?
Thanks.
Marco
^ permalink raw reply
* [PATCH v2 2/3] arm/dt: tegra: add dts file for paz00
From: Russell King - ARM Linux @ 2011-10-29 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF173EDAB4C7@HQMAIL01.nvidia.com>
On Fri, Oct 28, 2011 at 09:49:49AM -0700, Stephen Warren wrote:
> When boards boot from DT, there is no fixup function to override the
> bootloader's ATAGs. 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.
As far as the uncompressed kernel is concerned, there is either ATAG
or DT information, never both. If the boot loader provides ATAGs and
the zImage has a DT appended to it, the zImage decompressor merges the
ATAGs into the appended DT and passes the DT to the kernel.
So anyone who currently 'fixes' their broken boot loader via the fixup
function by directly manipulating the ATAGS is going to hit the DT
image instead.
> > I've seen patches on the chromeos tree which try to reserve the gpu
> > memory on demand. While we are at it, what is the vmalloc=192M used
> > by most other boards for?
>
> I'm not sure what vmalloc= does exactly. I somewhat doubt it's necessary
> until we have code that uses the GPU in mainline.
It defines the size of the vmalloc and ioremap area - and limits the
maximum amount of low memory (non-highmem) available to the kernel to
achieve the specified size of the vmalloc area. Any additional memory
will be discarded, or in the presence of a highmem enabled kernel, will
be turned into highmem.
^ permalink raw reply
* [PATCH] ramoops appears geared to not support ARM
From: Russell King - ARM Linux @ 2011-10-29 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EABBBD3.5030700@gmail.com>
On Sat, Oct 29, 2011 at 10:39:47AM +0200, Marco Stornelli wrote:
> (Added linux-arm)
>
> Il 29/10/2011 01:21, Bryan Freed ha scritto:
>> I had some difficulty in getting ramoops to work on our ARM systems.
>> The driver maps memory with ioremap() which is supposed to map IO memory,
>> not physical RAM. This happens to work on x86 and apparently some other
>> architectures, but it does not work on ARM.
>> Specifically, I see this comment in __arm_ioremap_pfn_caller():
>> Don't allow RAM to be mapped - this causes problems with ARMv6+
>>
>> So here is a patch that hacks around the issue using page_is_ram() to
>> differentiate between the two.
>>
>> Am I missing something here?
>> Is ramoops working on any ARM systems yet, and I am just doing something wrong?
>>
>> My ARM platform reserves a section of RAM for use by ramoops, but it is still
>> mapped along with the rest of main memory. This is so /dev/mem can find it
>> with xlate_dev_mem_ptr().
>> On x86, I see our BIOS reserves the memory so that it is not counted as main
>> memory, and it is not mapped until ramoops ioremaps it.
>>
>> Bryan Freed (1):
>> ramoops: Add support for ARM systems.
>>
>> drivers/char/ramoops.c | 67 +++++++++++++++++++++++++++++++++++++----------
>> 1 files changed, 52 insertions(+), 15 deletions(-)
>>
>
> Can some ARM guys give an opinion about that?
Opinion about the patch which isn't present in this email (so we can't
see it) or about the commentry above?
^ permalink raw reply
* [PATCH 33/51] ARM: mach-prima2: use arm_arch_reset instead of arch_reset
From: Barry Song @ 2011-10-29 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319813059-8914-34-git-send-email-will.deacon@arm.com>
2011/10/28 Will Deacon <will.deacon@arm.com>:
> This patch updates mach-prima2 to use arm_arch_reset instead of
> arch_reset.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
Hi Will, i guess you can move the arch reset of prima2 to
arch/arm/mach-prima2/rstc.c instead of creating a new file. rstc is
the reset controller driver in prima2. so that is the right file to
place your codes. and you will not need to include system.h as well.
> ---
> ?arch/arm/mach-prima2/Makefile ? ? ? ? ? ? ?| ? ?1 +
> ?arch/arm/mach-prima2/include/mach/system.h | ? ?6 ------
> ?arch/arm/mach-prima2/reset.c ? ? ? ? ? ? ? | ? 22 ++++++++++++++++++++++
> ?3 files changed, 23 insertions(+), 6 deletions(-)
> ?create mode 100644 arch/arm/mach-prima2/reset.c
>
> diff --git a/arch/arm/mach-prima2/Makefile b/arch/arm/mach-prima2/Makefile
> index 7af7fc0..75a7127 100644
> --- a/arch/arm/mach-prima2/Makefile
> +++ b/arch/arm/mach-prima2/Makefile
> @@ -2,6 +2,7 @@ obj-y := timer.o
> ?obj-y += irq.o
> ?obj-y += clock.o
> ?obj-y += rstc.o
> +obj-y += reset.o
> ?obj-y += prima2.o
> ?obj-$(CONFIG_DEBUG_LL) += lluart.o
> ?obj-$(CONFIG_CACHE_L2X0) += l2x0.o
> diff --git a/arch/arm/mach-prima2/include/mach/system.h b/arch/arm/mach-prima2/include/mach/system.h
> index 0dbd257..1d14a77 100644
> --- a/arch/arm/mach-prima2/include/mach/system.h
> +++ b/arch/arm/mach-prima2/include/mach/system.h
> @@ -9,11 +9,6 @@
> ?#ifndef __MACH_SYSTEM_H__
> ?#define __MACH_SYSTEM_H__
>
> -#include <linux/bitops.h>
> -#include <mach/hardware.h>
> -
> -#define SIRFSOC_SYS_RST_BIT ?BIT(31)
> -
> ?extern void __iomem *sirfsoc_rstc_base;
>
> ?static inline void arch_idle(void)
> @@ -23,7 +18,6 @@ static inline void arch_idle(void)
>
> ?static inline void arch_reset(char mode, const char *cmd)
> ?{
> - ? ? ? writel(SIRFSOC_SYS_RST_BIT, sirfsoc_rstc_base);
> ?}
>
> ?#endif
> diff --git a/arch/arm/mach-prima2/reset.c b/arch/arm/mach-prima2/reset.c
> new file mode 100644
> index 0000000..5473ae8
> --- /dev/null
> +++ b/arch/arm/mach-prima2/reset.c
> @@ -0,0 +1,22 @@
> +/*
> + * arch/arm/mach-prima2/reset.c
> + */
> +
> +#include <linux/init.h>
> +#include <linux/bitops.h>
> +#include <mach/hardware.h>
> +#include <asm/system.h>
> +
> +#define SIRFSOC_SYS_RST_BIT ?BIT(31)
> +
> +static void prima2_arch_reset(char mode, const char *cmd)
> +{
> + ? ? ? writel(SIRFSOC_SYS_RST_BIT, sirfsoc_rstc_base);
> +}
> +
> +static int __init prima2_arch_reset_init(void)
> +{
> + ? ? ? arm_arch_reset = prima2_arch_reset;
> + ? ? ? return 0;
> +}
> +arch_initcall(prima2_arch_reset_init);
> --
> 1.7.4.1
Thanks
barry
^ permalink raw reply
* [PATCH 01/51] ARM: reset: introduce arm_arch_reset function pointer
From: Russell King - ARM Linux @ 2011-10-29 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319813059-8914-2-git-send-email-will.deacon@arm.com>
On Fri, Oct 28, 2011 at 03:43:29PM +0100, Will Deacon wrote:
> arch_reset is a static inline function defined in mach/system.h and, as
> such, is a blocker for the single zImage work.
>
> This patch introduces an arm_arch_reset function pointer to which
> platforms can assign their reset function rather than define it in the
> header file.
I think this is slightly the wrong approach. We already have:
void (*arm_pm_restart)(char str, const char *cmd) = arm_machine_restart;
EXPORT_SYMBOL_GPL(arm_pm_restart);
so why do we need a new function pointer? We could convert the bulk of
arm_machine_restart() to a library function (setup_restart()), moving
the failure to reboot into machine_restart().
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.
IOW, something like this:
arch/arm/include/asm/system.h | 2 +-
arch/arm/kernel/process.c | 30 +++++++++++++++++-------------
2 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 984014b..62a3c3d 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -100,7 +100,7 @@ extern void __show_regs(struct pt_regs *);
extern int __pure cpu_architecture(void);
extern void cpu_init(void);
-void arm_machine_restart(char mode, const char *cmd);
+void setup_restart(char mode);
extern void (*arm_pm_restart)(char str, const char *cmd);
#define UDBG_UNDEFINED (1 << 0)
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index fd08140..ba91ec4 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -92,7 +92,7 @@ static int __init hlt_setup(char *__unused)
__setup("nohlt", nohlt_setup);
__setup("hlt", hlt_setup);
-void arm_machine_restart(char mode, const char *cmd)
+void setup_restart(char mode)
{
/* Disable interrupts first */
local_irq_disable();
@@ -113,19 +113,15 @@ void arm_machine_restart(char mode, const char *cmd)
/* Push out any further dirty data, and ensure cache is empty */
flush_cache_all();
+}
+EXPORT_SYMBOL_GPL(setup_restart);
- /*
- * Now call the architecture specific reboot code.
- */
- arch_reset(mode, cmd);
+static void default_restart(char mode, const char *cmd)
+{
+ setup_restart(mode);
- /*
- * Whoops - the architecture was unable to reboot.
- * Tell the user!
- */
- mdelay(1000);
- printk("Reboot failed -- System halted\n");
- while (1);
+ /* Now call the architecture specific reboot code. */
+ arch_reset(mode, cmd);
}
/*
@@ -134,7 +130,7 @@ void arm_machine_restart(char mode, const char *cmd)
void (*pm_power_off)(void);
EXPORT_SYMBOL(pm_power_off);
-void (*arm_pm_restart)(char str, const char *cmd) = arm_machine_restart;
+void (*arm_pm_restart)(char mode, const char *cmd) = default_restart;
EXPORT_SYMBOL_GPL(arm_pm_restart);
static void do_nothing(void *unused)
@@ -250,7 +246,15 @@ void machine_power_off(void)
void machine_restart(char *cmd)
{
machine_shutdown();
+
arm_pm_restart(reboot_mode, cmd);
+
+ /* Give a grace period for failure to restart of 1s */
+ mdelay(1000);
+
+ /* Whoops - the platform was unable to reboot. Tell the user! */
+ printk("Reboot failed -- System halted\n");
+ while (1);
}
void __show_regs(struct pt_regs *regs)
^ permalink raw reply related
* [git pull] trivial gpio build failure fixups
From: Grant Likely @ 2011-10-29 10:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
nothing to say here, subject says it all.
g.
The following changes since commit ec7ae517537ae5c7b0b2cd7f562dfa3e7a05b954:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6
(2011-10-28 16:44:18 -0700)
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6 devicetree/merge
Grant Likely (1):
gpio: Fix ARM versatile-express build failure
Kalle Valo (1):
of: include errno.h
arch/arm/mach-vexpress/include/mach/gpio.h | 1 +
include/linux/of.h | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-vexpress/include/mach/gpio.h
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH v2 2/3] arm/dt: tegra: add dts file for paz00
From: Grant Likely @ 2011-10-29 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111029084330.GW19187@n2100.arm.linux.org.uk>
On Sat, Oct 29, 2011 at 09:43:30AM +0100, Russell King - ARM Linux wrote:
> On Fri, Oct 28, 2011 at 09:49:49AM -0700, Stephen Warren wrote:
> > When boards boot from DT, there is no fixup function to override the
> > bootloader's ATAGs. 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.
>
> As far as the uncompressed kernel is concerned, there is either ATAG
> or DT information, never both. If the boot loader provides ATAGs and
> the zImage has a DT appended to it, the zImage decompressor merges the
> ATAGs into the appended DT and passes the DT to the kernel.
>
> So anyone who currently 'fixes' their broken boot loader via the fixup
> function by directly manipulating the ATAGS is going to hit the DT
> image instead.
Ugh. Not pretty. A platform could still have board specific fixup
code that matches on the compatible string that deals with broken
firmware ATAGs, but I don't think that is what we want to do.
We could handle it by filling the .dts file with an empty 'reg'
property for memory, and only push in the legacy ATAG data if reg is
indeed empty. That gives the option of overriding ATAGs if the DT
already specifies memory. Need to think about this more.
g.
^ permalink raw reply
* [PATCH] ramoops appears geared to not support ARM
From: Marco Stornelli @ 2011-10-29 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111029093458.GX19187@n2100.arm.linux.org.uk>
Il 29/10/2011 11:34, Russell King - ARM Linux ha scritto:
> On Sat, Oct 29, 2011 at 10:39:47AM +0200, Marco Stornelli wrote:
>> (Added linux-arm)
>>
>> Il 29/10/2011 01:21, Bryan Freed ha scritto:
>>> I had some difficulty in getting ramoops to work on our ARM systems.
>>> The driver maps memory with ioremap() which is supposed to map IO memory,
>>> not physical RAM. This happens to work on x86 and apparently some other
>>> architectures, but it does not work on ARM.
>>> Specifically, I see this comment in __arm_ioremap_pfn_caller():
>>> Don't allow RAM to be mapped - this causes problems with ARMv6+
>>>
>>> So here is a patch that hacks around the issue using page_is_ram() to
>>> differentiate between the two.
>>>
>>> Am I missing something here?
>>> Is ramoops working on any ARM systems yet, and I am just doing something wrong?
>>>
>>> My ARM platform reserves a section of RAM for use by ramoops, but it is still
>>> mapped along with the rest of main memory. This is so /dev/mem can find it
>>> with xlate_dev_mem_ptr().
>>> On x86, I see our BIOS reserves the memory so that it is not counted as main
>>> memory, and it is not mapped until ramoops ioremaps it.
>>>
>>> Bryan Freed (1):
>>> ramoops: Add support for ARM systems.
>>>
>>> drivers/char/ramoops.c | 67 +++++++++++++++++++++++++++++++++++++----------
>>> 1 files changed, 52 insertions(+), 15 deletions(-)
>>>
>>
>> Can some ARM guys give an opinion about that?
>
> Opinion about the patch which isn't present in this email (so we can't
> see it) or about the commentry above?
>
About the ioremap problem. It seems there is a problem on some ARM arch
to use ioremap (ramoops driver) to remap a piece of RAM even if it's not
used by kernel (reserved at boot with mem option, Bryan can you
confirm?). It has been suggested by Bryan to use xlate_dev_mem_ptr(),
but I'm not sure if the problem is how to reserve the memory on these
ARM archs. I believe ioremap is a general way to do it, of course not
using kernel already used by kernel, am I right? Or to be compliant with
all archs (in this particular case with ARMv6+) we should use
xlate_dev_mem_ptr()?
Marco
^ permalink raw reply
* [PATCH] ARM: mark empty gpio.h files empty
From: Grant Likely @ 2011-10-29 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319833142-4764-1-git-send-email-linus.walleij@linaro.org>
On Fri, Oct 28, 2011 at 10:19:02PM +0200, Linus Walleij wrote:
> It is generally a better idea to make intentionally empty files
> contain the human-readable /* empty */ comment, also it makes
> the files play nice with "make distclean".
>
> Reported-by: Jeff Garzik <jeff@garzik.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Applied, thanks.
g.
> ---
> arch/arm/mach-lpc32xx/include/mach/gpio.h | 1 +
> arch/arm/mach-tegra/include/mach/gpio.h | 1 +
> arch/arm/mach-u300/include/mach/gpio.h | 1 +
> 3 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-lpc32xx/include/mach/gpio.h b/arch/arm/mach-lpc32xx/include/mach/gpio.h
> index e69de29..40a8c17 100644
> --- a/arch/arm/mach-lpc32xx/include/mach/gpio.h
> +++ b/arch/arm/mach-lpc32xx/include/mach/gpio.h
> @@ -0,0 +1 @@
> +/* empty */
> diff --git a/arch/arm/mach-tegra/include/mach/gpio.h b/arch/arm/mach-tegra/include/mach/gpio.h
> index e69de29..40a8c17 100644
> --- a/arch/arm/mach-tegra/include/mach/gpio.h
> +++ b/arch/arm/mach-tegra/include/mach/gpio.h
> @@ -0,0 +1 @@
> +/* empty */
> diff --git a/arch/arm/mach-u300/include/mach/gpio.h b/arch/arm/mach-u300/include/mach/gpio.h
> index e69de29..40a8c17 100644
> --- a/arch/arm/mach-u300/include/mach/gpio.h
> +++ b/arch/arm/mach-u300/include/mach/gpio.h
> @@ -0,0 +1 @@
> +/* empty */
> --
> 1.7.3.2
>
^ permalink raw reply
* [git pull] trivial gpio build failure fixups
From: Grant Likely @ 2011-10-29 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACxGe6sNC0FseUj2pSL0y4yEJaFg=gNAP=54Ow6n8jXe2mBapA@mail.gmail.com>
Oops, one more...
g.
The following changes since commit ec7ae517537ae5c7b0b2cd7f562dfa3e7a05b954:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6
(2011-10-28 16:44:18 -0700)
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6 devicetree/merge
Grant Likely (1):
gpio: Fix ARM versatile-express build failure
Kalle Valo (1):
of: include errno.h
Linus Walleij (1):
ARM: mark empty gpio.h files empty
arch/arm/mach-lpc32xx/include/mach/gpio.h | 1 +
arch/arm/mach-tegra/include/mach/gpio.h | 1 +
arch/arm/mach-u300/include/mach/gpio.h | 1 +
arch/arm/mach-vexpress/include/mach/gpio.h | 1 +
include/linux/of.h | 1 +
5 files changed, 5 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-vexpress/include/mach/gpio.h
On Sat, Oct 29, 2011 at 12:57 PM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> Hi Linus,
>
> nothing to say here, subject says it all.
>
> g.
>
> The following changes since commit ec7ae517537ae5c7b0b2cd7f562dfa3e7a05b954:
>
> ?Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6
> (2011-10-28 16:44:18 -0700)
>
> are available in the git repository at:
>
> ?git://git.secretlab.ca/git/linux-2.6 devicetree/merge
>
> Grant Likely (1):
> ? ? ?gpio: Fix ARM versatile-express build failure
>
> Kalle Valo (1):
> ? ? ?of: include errno.h
>
> ?arch/arm/mach-vexpress/include/mach/gpio.h | ? ?1 +
> ?include/linux/of.h ? ? ? ? ? ? ? ? ? ? ? ? | ? ?1 +
> ?2 files changed, 2 insertions(+), 0 deletions(-)
> ?create mode 100644 arch/arm/mach-vexpress/include/mach/gpio.h
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH v2 2/3] arm/dt: tegra: add dts file for paz00
From: Russell King - ARM Linux @ 2011-10-29 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111029110320.GD20132@ponder.secretlab.ca>
On Sat, Oct 29, 2011 at 01:03:20PM +0200, Grant Likely wrote:
> On Sat, Oct 29, 2011 at 09:43:30AM +0100, Russell King - ARM Linux wrote:
> > On Fri, Oct 28, 2011 at 09:49:49AM -0700, Stephen Warren wrote:
> > > When boards boot from DT, there is no fixup function to override the
> > > bootloader's ATAGs. 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.
> >
> > As far as the uncompressed kernel is concerned, there is either ATAG
> > or DT information, never both. If the boot loader provides ATAGs and
> > the zImage has a DT appended to it, the zImage decompressor merges the
> > ATAGs into the appended DT and passes the DT to the kernel.
> >
> > So anyone who currently 'fixes' their broken boot loader via the fixup
> > function by directly manipulating the ATAGS is going to hit the DT
> > image instead.
>
> Ugh. Not pretty. A platform could still have board specific fixup
> code that matches on the compatible string that deals with broken
> firmware ATAGs, but I don't think that is what we want to do.
No. The point I was making is that by the time you get to the fixup
function with a DT or even into the uncompressed kernel, even if the
boot loader provided ATAGs, your ATAGs have long since been obliterated
and are no longer available.
^ permalink raw reply
* [PATCH] dt: add empty of_alias_get_id() for non-dt builds
From: Grant Likely @ 2011-10-29 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EAAABF6.50803@gmail.com>
On Fri, Oct 28, 2011 at 08:19:50AM -0500, Rob Herring wrote:
> On 10/27/2011 04:07 AM, Nicolas Ferre wrote:
> > Add function of_alias_get_id() reporting -ENOSYS
> > for non-dt builds, so that drivers migrating to dt
> > can save some '#ifdef CONFIG_OF'.
> >
> > Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>
> Acked-by: Rob Herring <rob.herring@calxeda.com>
Merged, thanks
Rob, for stuff like this, please do pick it up into your git tree and
reply saying that you've done so. Then I know I can ignore it because
I'll be receiving a pull req from you in short order.
Similarly, I reply whenever I pick up a patch, so you'll know if I've
already delt with it.
g.
>
> > ---
> > Hi Grant,
> >
> > Another empty function for non-dt builds. Can we consider
> > queuing it for 3.1?
> >
> > Best regards,
> >
> > include/linux/of.h | 5 +++++
> > 1 files changed, 5 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/linux/of.h b/include/linux/of.h
> > index 92c40a1..34d8338 100644
> > --- a/include/linux/of.h
> > +++ b/include/linux/of.h
> > @@ -302,6 +302,11 @@ static inline struct device_node *of_parse_phandle(struct device_node *np,
> > return NULL;
> > }
> >
> > +static inline int of_alias_get_id(struct device_node *np, const char *stem)
> > +{
> > + return -ENOSYS;
> > +}
> > +
> > #define of_match_ptr(_ptr) NULL
> > #define of_match_node(_matches, _node) NULL
> > #endif /* CONFIG_OF */
>
^ permalink raw reply
* [PATCH] ramoops appears geared to not support ARM
From: Russell King - ARM Linux @ 2011-10-29 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EABDDBE.5080407@gmail.com>
On Sat, Oct 29, 2011 at 01:04:30PM +0200, Marco Stornelli wrote:
> About the ioremap problem. It seems there is a problem on some ARM arch
> to use ioremap (ramoops driver) to remap a piece of RAM even if it's not
> used by kernel (reserved at boot with mem option, Bryan can you
> confirm?).
It's all very simple.
We have three major 'memory types' - 'normal memory' which must be used
for things like RAM that we execute code from and use atomic operations
within. This can be prefetched and reordered at will.
'device memory' is for devices, which tighter restrictions on reordering
and guarantees concerning reads and writes.
'strongly ordered memory' is much like device memory.
It is absolutely not permitted to map the same physical addresses with
different types - this is a stronger requirement than getting the cache
attributes the same.
System memory is mapped using 'normal memory' - obviously because we need
to be able to execute code and have working atomic operations throughout
kernel memory.
Now, ioremap creates device memory - because its main function is to
dynamically map memory regions in devices.
Now think: if we have system memory mapped as 'normal memory', and then
we try to use ioremap() to remap some of that memory, that will create
a new 'device memory' mapping with the existing 'normal memory' mapping
still present. Now look at the paragraph 'It is absolutely not permitted'
and realise that the requirements for the architecture are being violated
if we permitted this to occur.
Also realise that if that condition is violated, 'unpredictable behaviour'
will occur - not to the extent that the CPU will hang, but it could cause
data errors which could influence overall system stability.
So, the whole idea of using plain ioremap() with system memory is one
that is just completely unsupportable on ARM without _first_ removing
memory from the system mapping, which in turn means updating the page
tables for every task in the system.
^ permalink raw reply
* [PATCH] ramoops appears geared to not support ARM
From: Marco Stornelli @ 2011-10-29 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111029115507.GA19187@n2100.arm.linux.org.uk>
Il 29/10/2011 13:55, Russell King - ARM Linux ha scritto:
> On Sat, Oct 29, 2011 at 01:04:30PM +0200, Marco Stornelli wrote:
>> About the ioremap problem. It seems there is a problem on some ARM arch
>> to use ioremap (ramoops driver) to remap a piece of RAM even if it's not
>> used by kernel (reserved at boot with mem option, Bryan can you
>> confirm?).
>
> It's all very simple.
>
> We have three major 'memory types' - 'normal memory' which must be used
> for things like RAM that we execute code from and use atomic operations
> within. This can be prefetched and reordered at will.
>
> 'device memory' is for devices, which tighter restrictions on reordering
> and guarantees concerning reads and writes.
>
> 'strongly ordered memory' is much like device memory.
>
> It is absolutely not permitted to map the same physical addresses with
> different types - this is a stronger requirement than getting the cache
> attributes the same.
>
> System memory is mapped using 'normal memory' - obviously because we need
> to be able to execute code and have working atomic operations throughout
> kernel memory.
>
> Now, ioremap creates device memory - because its main function is to
> dynamically map memory regions in devices.
>
> Now think: if we have system memory mapped as 'normal memory', and then
> we try to use ioremap() to remap some of that memory, that will create
> a new 'device memory' mapping with the existing 'normal memory' mapping
> still present. Now look at the paragraph 'It is absolutely not permitted'
> and realise that the requirements for the architecture are being violated
> if we permitted this to occur.
>
> Also realise that if that condition is violated, 'unpredictable behaviour'
> will occur - not to the extent that the CPU will hang, but it could cause
> data errors which could influence overall system stability.
>
> So, the whole idea of using plain ioremap() with system memory is one
> that is just completely unsupportable on ARM without _first_ removing
> memory from the system mapping, which in turn means updating the page
> tables for every task in the system.
>
Ok, I understand, but other question: isn't there any way to reserve
normal memory? Or at least, hasn't the mem kernel option any effect from
that point of view?
^ permalink raw reply
* [PATCH] ramoops appears geared to not support ARM
From: Russell King - ARM Linux @ 2011-10-29 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EABF4C2.7000104@gmail.com>
On Sat, Oct 29, 2011 at 02:42:42PM +0200, Marco Stornelli wrote:
> Ok, I understand, but other question: isn't there any way to reserve
> normal memory? Or at least, hasn't the mem kernel option any effect from
> that point of view?
mem= can be used to redefine the available memory to the kernel, but
then you have to have some way to define a region of the memory you've
excluded to the kernel to use for ramoops.
A platform can also use the memblock stuff to extract some memory
dynamically from the information passed from the firmware - by using
memblock_alloc + memblock_remove + memblock_free. The memblock_remove
call will take the memory out of the available memory to the kernel,
and thus will prevent it being mapped.
This must be done via the ->reserve callback in the ARM board/SoC
record (it can't be done later because the memory will have already
been mapped.)
^ 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