* [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
* [GIT PULL] GIC DT binding support
From: Arnd Bergmann @ 2011-10-30 22:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EAB1BFF.3070406@gmail.com>
On Friday 28 October 2011, Rob Herring wrote:
> 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
I've pulled it and am now trying to clean up the mess resulting from
having the previous version in a number of branches already.
Can you check that the highbank/soc branch is ok this time?
Arnd
^ permalink raw reply
* [PATCH 01/51] ARM: reset: introduce arm_arch_reset function pointer
From: Will Deacon @ 2011-10-30 21:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111029200548.GC19187@n2100.arm.linux.org.uk>
On Sat, Oct 29, 2011 at 09:05:48PM +0100, Russell King - ARM Linux wrote:
> On Sat, Oct 29, 2011 at 02:56:53PM +0100, Will Deacon wrote:
> > I initially observed this in the idle code, where it looks to me like all
> > the pm_idle overrides could actually be done in the arch_idle hook (the only
> > slightly fiddly one is OMAP). Maybe Nicolas could use the same sort of
> > approach for that?
>
> Beware about changing the semantics of pm_idle - it's a cross-arch thing,
> and we really shouldn't change those semantics without changing the other
> architectures as well.
Indeed. I'm not suggesting making any changes to pm_idle, I'm just pointing
out that all of the pm_idle overrides for ARM can be written as:
if (!need_resched())
do_magic_soc_specific_idle();
local_irq_enable();
so the platform magic may as well just be implemented using arch_idle and we
can remove the ability to reassign pm_idle, therefore consolidating the
platform idle code into one function pointer.
Will
^ permalink raw reply
* [PATCH v2 2/3] arm/dt: tegra: add dts file for paz00
From: Marc Dietrich @ 2011-10-30 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF173EDAB4C7@HQMAIL01.nvidia.com>
On Friday 28 October 2011 09:49:49 Stephen Warren wrote:
> Marc Dietrich wrote at Friday, October 28, 2011 4:30 AM:
> > Am Donnerstag, 27. Oktober 2011, 09:50:03 schrieb Stephen Warren:
> > > Marc Dietrich wrote at Wednesday, October 26, 2011 1:59 PM:
> > > > This adds a dts file for paz00. As a side effect, this also
> > > > enables
> > > > the embedded controller which controls the keyboard, touchpad,
> > > > power,
> > > > leds, and some other functions.
> > >
> > > ...
> > >
> > > > +++ b/arch/arm/boot/dts/tegra-paz00.dts
> > > > @@ -0,0 +1,70 @@
> > > > +/dts-v1/;
> > > > +
> > > > +/memreserve/ 0x1c000000 0x04000000;
> > > > +/include/ "tegra20.dtsi"
> > > > +
> > > > +/ {
> > > > + model = "Toshiba AC100 / Dynabook AZ";
> > > > + compatible = "compal,paz00", "nvidia,tegra20";
> > > > +
> > > > + chosen {
> > > > + bootargs = "mem=448 at 0 console=ttyS0,115200n8
> > > > root=/dev/mmcblk1p1";
> > >
> > > You shouldn't need the mem= parameter here; it wasn't in your first
> > > patch set.>
> > that's because I forgot it. Sorry, I didn't mentioned it in the
> > changelog. I wonder why mem= is still needed.
>
> I wonder if this is some conflict between ATAGs and the DT-specified
> memory node.
>
> As far as I can tell, the kernel's memory information typically comes
> from ATAGs. Some boards override what's in the ATAGs in their machine
> descriptor's fixup routine, e.g. see tegra_paz00_fixup(). Presumably,
> this is because of buggy bootloaders sending incorrect memory information
> in the ATAGs. Do you have any way to check the ATAGs that the bootloader
> is sending? Probably, you could enable DEBUG_LL and using the low-level
> debugging functions to dump some of that information to the UART early
> during boot.
I got the ATAGS from /proc/atags and there is no memory entry there, only
initrd and cmdline (which is the one from nvflash).
The machine also has a fixup routine, but it also boots without (I'm sure it
was necessary in the past),
> When boards boot from DT, there is no fixup function to override the
> bootloader's ATAGs.
... so I guess this is why it also works with DT.
> 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.
> 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).
> > 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. The same goes for the
> /memreserve/ DT entries. I've been thinking of submitting a patch to
> remove this cruft, but haven't gotten around to it yet.
^ permalink raw reply
* [GIT PULL] pxa: fixes for next
From: Arnd Bergmann @ 2011-10-30 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMPhdO-SM88yeaQMG27MODCHCxDM3U=7=JDP0uphb_w-nfWAkQ@mail.gmail.com>
On Tuesday 25 October 2011, Eric Miao wrote:
> With that specific patch queued, see the updated request as below:
>
> The following changes since commit c3b92c8787367a8bb53d57d9789b558f1295cc96:
>
> Linux 3.1 (2011-10-24 09:10:05 +0200)
>
> are available in the git repository at:
> git://github.com/ycmiao/pxa-linux.git fix
Merged into next/fixes.
Thanks a lot!
Arnd
^ permalink raw reply
* [GIT PULL] pxa: feature patches for next
From: Arnd Bergmann @ 2011-10-30 20:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMPhdO8A3OgzdKB_1t5ddY_JBtGvPUjphYYBs7zob0ik9he=Lw@mail.gmail.com>
On Tuesday 25 October 2011, Eric Miao wrote:
> The following changes since commit c3b92c8787367a8bb53d57d9789b558f1295cc96:
>
> Linux 3.1 (2011-10-24 09:10:05 +0200)
>
> are available in the git repository at:
> git://github.com/ycmiao/pxa-linux.git feature
Hi Eric,
The code looks reasonable, but you sent the patches after the merge window
has already been opened. Please don't do that, you had enough time during the
3.1-rc cycle to send them. I'll take the patches this time because there
is just one functional change, but try to improve this next time.
See you tomorrow in Orlando,
Arnd
^ permalink raw reply
* [GIT PULL] hwspinlock changes for 3.2
From: Ohad Ben-Cohen @ 2011-10-30 20:06 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git for-linus
To receive hwspinlock updates for 3.2.
The only noticeable change is a new hwspinlock driver for
ST-Ericsson's u8500 platform by Mathieu; the rest of the changes are
either cleanups or trivial fixes (one of the fixes also trivially
changes a mach-omap2 file, and is Acked by Tony).
All of the patches have been tested in linux-next and currently there
are no merge conflicts, though I expect one to happen with the arm-sco
tree, as reported (and fixed) by Stephen earlier this month (see
http://www.spinics.net/lists/linux-next/msg16931.html).
I've flagged one of the fixes as stable material (the one from Juan).
Normally I would only send you stable-worthy patches during the rc
cycle and not wait until the merge window, but since the hwspinlock
tree and its upstream path have only materialized quite late in the
cycle (see https://lkml.org/lkml/2011/9/21/249), I've decided this
time to wait for the merge window.
Hope it's ok; please tell me if there are any issues.
Thanks,
Ohad.
The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb:
Linux 3.1-rc6 (2011-09-12 14:02:02 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git for-linus
Juan Gutierrez (1):
hwspinlock/core: use a mutex to protect the radix tree
Mathieu J. Poirier (1):
hwspinlock/u8500: add hwspinlock driver
Ohad Ben-Cohen (8):
hwspinlock/core: simplify Kconfig
hwspinlock/core: simplify 'owner' handling
hwspinlock/omap: simplify allocation scheme
hwspinlock/core/omap: fix id issues on multiple hwspinlock devices
hwspinlock/core: remove stubs for register/unregister
hwspinlock/core: register a bank of hwspinlocks in a single API call
hwspinlock/omap: omap_hwspinlock_remove should be __devexit
hwspinlock: add MAINTAINERS entries
Documentation/hwspinlock.txt | 74 +++++++-----
MAINTAINERS | 14 ++
arch/arm/mach-omap2/hwspinlock.c | 8 +-
drivers/hwspinlock/Kconfig | 27 +++--
drivers/hwspinlock/Makefile | 1 +
drivers/hwspinlock/hwspinlock_core.c | 204 +++++++++++++++++++-----------
drivers/hwspinlock/hwspinlock_internal.h | 40 ++++--
drivers/hwspinlock/omap_hwspinlock.c | 127 +++++++------------
drivers/hwspinlock/u8500_hsem.c | 198 +++++++++++++++++++++++++++++
include/linux/hwspinlock.h | 46 +++++--
10 files changed, 514 insertions(+), 225 deletions(-)
create mode 100644 drivers/hwspinlock/u8500_hsem.c
^ permalink raw reply
* [GIT PULL] at91 device tree basics
From: Arnd Bergmann @ 2011-10-30 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EA69BC9.8040402@atmel.com>
On Tuesday 25 October 2011, Nicolas Ferre wrote:
> The following changes since commit c3b92c8787367a8bb53d57d9789b558f1295cc96:
>
> Linux 3.1 (2011-10-24 09:10:05 +0200)
>
> are available in the git repository at:
> git://github.com/at91linux/linux-at91.git for-arnd/at91-dt
>
> They cover the basic device tree work done during the last moths around both
> at91sam9g45 and at91sam9g20 based board. They have been review by Grant and
> Rob. More device tree related stuff is comming ;-)
Hi Nicolas,
I've pulled it into the next/dt branch, it looks all good but please try to
send stuff like this before the merge window next time, ideally much before
the merge window.
Arnd
^ permalink raw reply
* [GIT PULL] assorted i.MX fixes
From: Arnd Bergmann @ 2011-10-30 19:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111025092344.GU23421@pengutronix.de>
On Tuesday 25 October 2011, Sascha Hauer wrote:
> Please pull the following assorted i.MX fixes. Should have send this
> earlier, I promise to do this next time.
>
> Sascha
>
> The following changes since commit fcb8ce5cfe30ca9ca5c9a79cdfe26d1993e65e0c:
>
> Linux 3.1-rc3 (2011-08-22 11:42:53 -0700)
>
> are available in the git repository at:
> git://git.pengutronix.de/git/imx/linux-2.6.git imx-fixes-for-arnd
Pulled, thanks!
Is it intentional that only one of these commits is tagged stable?
The desciptions seem to suggest that they should all apply to 3.1 or possibly earlier
as well.
Arnd
^ permalink raw reply
* [GIT PULL] i.MX5 devicetree support
From: Arnd Bergmann @ 2011-10-30 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111025091032.GT23421@pengutronix.de>
On Tuesday 25 October 2011, Sascha Hauer wrote:
> Please pull the following. It contains devicetree support for i.MX5
> based systems. You can use the following to resolve the merge conflicts
> against your for-next branch:
>
> git://git.pengutronix.de/git/imx/linux-2.6.git imx-dt-merge
My merge looked slightly different, but equivalent. Having the merge commit
as you did was indeed very useful.
Thanks!
Arnd
^ permalink raw reply
* [GIT PULL] ARM: CSR: l2x0 init cleanup for 3.2
From: Arnd Bergmann @ 2011-10-30 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4xu_m7umoohrKSdL2v8reHi9ZdkU7RWo+6a_fCA33e9Eg@mail.gmail.com>
On Monday 24 October 2011, Barry Song wrote:
> The following changes since commit 1e11bec9b09a28f81dd3173fec6b1c6c56b5e299:
> Barry Song (1):
> Merge branch 'l2x0' of rmk tree into prima2-l2x0
>
> are available in the git repository at:
>
> git://gitorious.org/sirfprima2-kernel/sirfprima2-kernel.git prima2-l2x0
>
I've now pulled it into the next/pm branch that had your previous pm
changes.
Thanks,
Arnd
^ permalink raw reply
* [PATCH] mach-ixp4xx: made gpio functions atomic
From: Russell King - ARM Linux @ 2011-10-30 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319973693-19063-1-git-send-email-fransmeulenbroeks@gmail.com>
On Sun, Oct 30, 2011 at 12:21:33PM +0100, Frans Meulenbroeks wrote:
> gpio_line_set and gpio_line config on ixp4xx were not atomic
> This patch fixes this by surrounding them with local_irq_save and
> local_irq_restore calls, similar to the way Lennert Buytenhek
> implemented this for iop. (see arch/arm/plat-iop/gpio.c)
>
> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
> ---
>
> Note: an alternative solution would be to use the set_bit and
> clear_bit atomic functions, but I felt it better to do things
> the same way as Lennert did. Also it could be that this is a few
> bytes smaller. Didn't check that.
set_bit and clear_bit should not be used on IO memory - on ARMv6 and
later these use the load exclusive/store exclusive operations which
are only valid on 'normal memory' mappings and not 'device' mappings.
Plus of course, IO memory is supposed to be __iomem and accessed using
the proper accessors, and using set_bit and clear_bit on such pointers
will issue sparse warnings.
^ permalink raw reply
* [PATCH] [RESEND] [TRIVIAL] ARM: imx: Fix typo 'MACH_MX31_3DS_MXC_NAND_USE_BBT'
From: Paul Bolle @ 2011-10-30 11:56 UTC (permalink / raw)
To: linux-arm-kernel
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.)
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
^ permalink raw reply related
* [PATCH] mach-ixp4xx: made gpio functions atomic
From: Frans Meulenbroeks @ 2011-10-30 11:21 UTC (permalink / raw)
To: linux-arm-kernel
gpio_line_set and gpio_line config on ixp4xx were not atomic
This patch fixes this by surrounding them with local_irq_save and
local_irq_restore calls, similar to the way Lennert Buytenhek
implemented this for iop. (see arch/arm/plat-iop/gpio.c)
Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
---
Note: an alternative solution would be to use the set_bit and
clear_bit atomic functions, but I felt it better to do things
the same way as Lennert did. Also it could be that this is a few
bytes smaller. Didn't check that.
--- git/arch/arm/mach-ixp4xx/include/mach/platform.h.orig 2011-08-09 19:16:52.645482269 +0200
+++ git/arch/arm/mach-ixp4xx/include/mach/platform.h 2011-08-09 19:17:39.915482235 +0200
@@ -14,6 +14,8 @@
#ifndef __ASSEMBLY__
#include <asm/types.h>
+#include <asm/system.h>
+#include <linux/kernel.h>
#ifndef __ARMEB__
#define REG_OFFSET 0
@@ -150,10 +152,14 @@
static inline void gpio_line_config(u8 line, u32 direction)
{
+ unsigned long flags;
+
+ local_irq_save(flags);
if (direction == IXP4XX_GPIO_IN)
*IXP4XX_GPIO_GPOER |= (1 << line);
else
*IXP4XX_GPIO_GPOER &= ~(1 << line);
+ local_irq_restore(flags);
}
static inline void gpio_line_get(u8 line, int *value)
@@ -163,10 +169,14 @@
static inline void gpio_line_set(u8 line, int value)
{
+ unsigned long flags;
+
+ local_irq_save(flags);
if (value == IXP4XX_GPIO_HIGH)
*IXP4XX_GPIO_GPOUTR |= (1 << line);
else if (value == IXP4XX_GPIO_LOW)
*IXP4XX_GPIO_GPOUTR &= ~(1 << line);
+ local_irq_restore(flags);
}
#endif // __ASSEMBLY__
^ permalink raw reply
* [PATCH] [TRIVIAL] ARM: pxa: Fix typo 'CONFIG_BACKLIGHT_PWM__MODULE'
From: Nicolas Kaiser @ 2011-10-30 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201110300035.27985.marek.vasut@gmail.com>
* Marek Vasut <marek.vasut@gmail.com>:
> > On Tue, 11 Oct 2011, Paul Bolle wrote:
> > > Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> > > ---
> > > Untested (I don't think I've got the hardware, nor have I got the
> > > toolchain at hand, etc.).
> > >
> > > arch/arm/mach-pxa/colibri-pxa270-income.c | 2 +-
> > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-pxa/colibri-pxa270-income.c
> > > b/arch/arm/mach-pxa/colibri-pxa270-income.c index 80538b8..248804b
> > > 100644
> > > --- a/arch/arm/mach-pxa/colibri-pxa270-income.c
> > > +++ b/arch/arm/mach-pxa/colibri-pxa270-income.c
> > > @@ -183,7 +183,7 @@ static inline void income_lcd_init(void) {}
> > >
> > > /***********************************************************************
> > > *******
> > >
> > > * Backlight
> > > ***********************************************************************
> > > *******/
> > >
> > > -#if defined(CONFIG_BACKLIGHT_PWM) ||
> > > defined(CONFIG_BACKLIGHT_PWM__MODULE) +#if defined(CONFIG_BACKLIGHT_PWM)
> > > || defined(CONFIG_BACKLIGHT_PWM_MODULE)
> > >
> > > static struct platform_pwm_backlight_data income_backlight_data = {
> > >
> > > .pwm_id = 0,
> > > .max_brightness = 0x3ff,
> >
> > I'd like to have this at least compile-tested, adding some CCs.
>
> The change is visually ok, add my:
>
> Acked-by: Marek Vasut <marek.vasut@gmail.com>
I now remember you already acked this change last year:
https://lkml.org/lkml/2010/12/4/41
Sorry that I forgot to resend the patch.
Best regards,
Nicolas Kaiser
^ permalink raw reply
* Serious question: How long does it take to get 64bit into ARM?
From: Michelle Konzack @ 2011-10-30 0:16 UTC (permalink / raw)
To: linux-arm-kernel
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.
Currently I build servers based on Marvel ?C like the Kirkwood 88F6281,
Discovery MV78100/MV78200 and Armada 300.
Thanks, Greetings and nice Day/Evening
Michelle Konzack
--
##################### Debian GNU/Linux Consultant ######################
Development of Intranet and Embedded Systems with Debian GNU/Linux
Internet Service Provider, Cloud Computing
<http://www.itsystems.tamay-dogan.net/>
itsystems at tdnet Jabber linux4michelle at jabber.ccc.de
Owner Michelle Konzack
Gewerbe Strasse 3 Tel office: +49-176-86004575
77694 Kehl Tel mobil: +49-177-9351947
Germany Tel mobil: +33-6-61925193 (France)
USt-ID: DE 278 049 239
Linux-User #280138 with the Linux Counter, http://counter.li.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111030/108d77ee/attachment.sig>
^ permalink raw reply
* [PATCH] [TRIVIAL] ARM: pxa: Fix typo 'CONFIG_BACKLIGHT_PWM__MODULE'
From: Marek Vasut @ 2011-10-29 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LNX.2.00.1110292127320.3541@pobox.suse.cz>
> On Tue, 11 Oct 2011, Paul Bolle wrote:
> > Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> > ---
> > Untested (I don't think I've got the hardware, nor have I got the
> > toolchain at hand, etc.).
> >
> > arch/arm/mach-pxa/colibri-pxa270-income.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-pxa/colibri-pxa270-income.c
> > b/arch/arm/mach-pxa/colibri-pxa270-income.c index 80538b8..248804b
> > 100644
> > --- a/arch/arm/mach-pxa/colibri-pxa270-income.c
> > +++ b/arch/arm/mach-pxa/colibri-pxa270-income.c
> > @@ -183,7 +183,7 @@ static inline void income_lcd_init(void) {}
> >
> > /***********************************************************************
> > *******
> >
> > * Backlight
> > ***********************************************************************
> > *******/
> >
> > -#if defined(CONFIG_BACKLIGHT_PWM) ||
> > defined(CONFIG_BACKLIGHT_PWM__MODULE) +#if defined(CONFIG_BACKLIGHT_PWM)
> > || defined(CONFIG_BACKLIGHT_PWM_MODULE)
> >
> > static struct platform_pwm_backlight_data income_backlight_data = {
> >
> > .pwm_id = 0,
> > .max_brightness = 0x3ff,
>
> I'd like to have this at least compile-tested, adding some CCs.
The change is visually ok, add my:
Acked-by: Marek Vasut <marek.vasut@gmail.com>
^ permalink raw reply
* [PATCH 01/51] ARM: reset: introduce arm_arch_reset function pointer
From: Russell King - ARM Linux @ 2011-10-29 20:05 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:
> > 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().
>
> Funny you should mention this approach. I've been toying with something
> similar for the kexec reset path but I hadn't managed to join the dots
> between that and the arch_reset code.
>
> I initially observed this in the idle code, where it looks to me like all
> the pm_idle overrides could actually be done in the arch_idle hook (the only
> slightly fiddly one is OMAP). Maybe Nicolas could use the same sort of
> approach for that?
Beware about changing the semantics of pm_idle - it's a cross-arch thing,
and we really shouldn't change those semantics without changing the other
architectures as well.
> I'll give this a go for v2, thanks. Once this is sorted out I'll do a second
> pass to clean up the reboot modes since I've already got some patches for
> that.
Great.
^ permalink raw reply
* [PATCH] s3c2410: remove __ioaddrc()
From: Cesar Eduardo Barros @ 2011-10-29 19:32 UTC (permalink / raw)
To: linux-arm-kernel
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.
Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.net>
---
arch/arm/mach-s3c2410/include/mach/io.h | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-s3c2410/include/mach/io.h b/arch/arm/mach-s3c2410/include/mach/io.h
index 118749f..5843974 100644
--- a/arch/arm/mach-s3c2410/include/mach/io.h
+++ b/arch/arm/mach-s3c2410/include/mach/io.h
@@ -190,15 +190,12 @@ DECLARE_IO(int,l,"")
result; \
})
-#define __ioaddrc(port) ((__PORT_PCIO(port) ? PCIO_BASE + (port) : (void __iomem *)(port)))
-
#define inb(p) (__builtin_constant_p((p)) ? __inbc(p) : __inb(p))
#define inw(p) (__builtin_constant_p((p)) ? __inwc(p) : __inw(p))
#define inl(p) (__builtin_constant_p((p)) ? __inlc(p) : __inl(p))
#define outb(v,p) (__builtin_constant_p((p)) ? __outbc(v,p) : __outb(v,p))
#define outw(v,p) (__builtin_constant_p((p)) ? __outwc(v,p) : __outw(v,p))
#define outl(v,p) (__builtin_constant_p((p)) ? __outlc(v,p) : __outl(v,p))
-#define __ioaddr(p) (__builtin_constant_p((p)) ? __ioaddr(p) : __ioaddrc(p))
#define insb(p,d,l) __raw_readsb(__ioaddr(p),d,l)
#define insw(p,d,l) __raw_readsw(__ioaddr(p),d,l)
--
1.7.6.4
^ permalink raw reply related
* [PATCH] [TRIVIAL] ARM: pxa: Fix typo 'CONFIG_BACKLIGHT_PWM__MODULE'
From: Jiri Kosina @ 2011-10-29 19:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318347115.5754.3.camel@x61.thuisdomein>
On Tue, 11 Oct 2011, Paul Bolle wrote:
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> Untested (I don't think I've got the hardware, nor have I got the
> toolchain at hand, etc.).
>
> arch/arm/mach-pxa/colibri-pxa270-income.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/colibri-pxa270-income.c b/arch/arm/mach-pxa/colibri-pxa270-income.c
> index 80538b8..248804b 100644
> --- a/arch/arm/mach-pxa/colibri-pxa270-income.c
> +++ b/arch/arm/mach-pxa/colibri-pxa270-income.c
> @@ -183,7 +183,7 @@ static inline void income_lcd_init(void) {}
> /******************************************************************************
> * Backlight
> ******************************************************************************/
> -#if defined(CONFIG_BACKLIGHT_PWM) || defined(CONFIG_BACKLIGHT_PWM__MODULE)
> +#if defined(CONFIG_BACKLIGHT_PWM) || defined(CONFIG_BACKLIGHT_PWM_MODULE)
> static struct platform_pwm_backlight_data income_backlight_data = {
> .pwm_id = 0,
> .max_brightness = 0x3ff,
I'd like to have this at least compile-tested, adding some CCs.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH v4] dmaengine: add CSR SiRFprimaII DMAC driver
From: Vinod Koul @ 2011-10-29 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5EB3BFCD089AD643B9BB63439F5FD5E98419FAC0@SHAASIEXM01.ASIA.ROOT.PRI>
On Fri, 2011-10-28 at 08:08 +0000, Barry Song wrote:
> Vinod, as I have acked interleaved dma API explicitly before, could
> you pls add:
> Acked-by: Barry Song <Baohua.Song@csr.com>
> in the commit of " DMAEngine: Define interleaved transfer request api"
> in your tree too. I didn't find it after I fetch your tree :-)
Sorry I must have missed that.
Fixed now :)
--
~Vinod
^ permalink raw reply
* [PATCH 01/51] ARM: reset: introduce arm_arch_reset function pointer
From: Will Deacon @ 2011-10-29 13:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111028213850.GB7961@game.jcrosoft.org>
On Fri, Oct 28, 2011 at 10:38:50PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> 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
Right, but that's not in mainline. Given that it looks like arm_pm_restart
is the hook we're going to go with then we can always move it into the SoC
descriptor later on.
Will
^ permalink raw reply
* [PATCH 33/51] ARM: mach-prima2: use arm_arch_reset instead of arch_reset
From: Will Deacon @ 2011-10-29 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4xvOTKwd-A83arN7anNNrdN9NQoaur76izUsa0GCmd=xQ@mail.gmail.com>
On Sat, Oct 29, 2011 at 10:41:09AM +0100, Barry Song wrote:
> 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.
Aha! rstc is a reset controller rather than a dyslexic realtime clock. Thanks,
I'll used that file for v2 if needed.
Will
^ permalink raw reply
* [PATCH 01/51] ARM: reset: introduce arm_arch_reset function pointer
From: Will Deacon @ 2011-10-29 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111029102108.GY19187@n2100.arm.linux.org.uk>
Hi Russell,
On Sat, Oct 29, 2011 at 11:21:08AM +0100, Russell King - ARM Linux wrote:
> 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().
Funny you should mention this approach. I've been toying with something
similar for the kexec reset path but I hadn't managed to join the dots
between that and the arch_reset code.
I initially observed this in the idle code, where it looks to me like all
the pm_idle overrides could actually be done in the arch_idle hook (the only
slightly fiddly one is OMAP). Maybe Nicolas could use the same sort of
approach for that?
> 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.
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.
> IOW, something like this:
>
> arch/arm/include/asm/system.h | 2 +-
> arch/arm/kernel/process.c | 30 +++++++++++++++++-------------
> 2 files changed, 18 insertions(+), 14 deletions(-)
[...]
I'll give this a go for v2, thanks. Once this is sorted out I'll do a second
pass to clean up the reboot modes since I've already got some patches for
that.
Cheers,
Will
^ 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