* [PATCH v2 00/14] OMAP-GPMC related cleanup for common zImage
From: Tony Lindgren @ 2012-10-16 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121010163840.GA13585@parrot.com>
* Ivan Djelic <ivan.djelic@parrot.com> [121010 09:40]:
>
> I ran several mtd regression tests on a Beagle Board on your gpmc-czimage-v2 tag.
> All BCH error correcting tests passed successfully.
>
> I occasionally had weird read errors though, especially when reading blank pages:
> the omap driver returned 512-byte sectors containing something like:
>
> 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff
> 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff
> 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff
> 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff
> 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff
> 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>
> instead of:
>
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>
> I was able to reproduce the problem also on l2-mtd tip, albeit less often.
> The problem seems to occur quite randomly, it may be a hardware issue on
> my board...
Things like this typically happen in the GPMC timings are not correct.
Maybe add #define DEBUG to top of gpmc.c and compare the timings
before and after Afzal's patches?
> Anyway, the ECC handling part looks OK to me.
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: OMAP: resolve sparse warning concerning debug_card_init()
From: Tony Lindgren @ 2012-10-16 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50751D36.9020001@compulab.co.il>
* Igor Grinberg <grinberg@compulab.co.il> [121010 00:02]:
> On 10/09/12 22:29, Paul Walmsley wrote:
> >
> > Commit 801475ccb2b2c1928b22aec4b9e5285d9e347602 ("ARM: OMAP: move
> > debug_card_init() function") results in the following new sparse
> > warning:
> >
> > arch/arm/plat-omap/debug-devices.c:71:12: warning: symbol 'debug_card_init' was not declared. Should it be static?
> >
> > Fix by implementing Tony's suggestion to add a "sideways include" to the
> > new location of the debug-devices.h file in arch/arm/mach-omap2/.
> >
> > Signed-off-by: Paul Walmsley <paul@pwsan.com>
> > Cc: Igor Grinberg <grinberg@compulab.co.il>
> > Cc: Tony Lindgren <tony@atomide.com>
>
> Acked-by: Igor Grinberg <grinberg@compulab.co.il>
Thanks, applying into omap-for-v3.7-rc1/fixes-part2.
Regards,
Tony
> > ---
> > arch/arm/plat-omap/debug-devices.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/plat-omap/debug-devices.c b/arch/arm/plat-omap/debug-devices.c
> > index c7a4c09..5a4678e 100644
> > --- a/arch/arm/plat-omap/debug-devices.c
> > +++ b/arch/arm/plat-omap/debug-devices.c
> > @@ -16,6 +16,7 @@
> > #include <linux/smc91x.h>
> >
> > #include <mach/hardware.h>
> > +#include "../mach-omap2/debug-devices.h"
> >
> > /* Many OMAP development platforms reuse the same "debug board"; these
> > * platforms include H2, H3, H4, and Perseus2.
>
> --
> Regards,
> Igor.
^ permalink raw reply
* [GIT PULL] imx multi-platform support
From: Olof Johansson @ 2012-10-16 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121015034047.GB24393@S2101-09.ap.freescale.net>
Hi,
On Sun, Oct 14, 2012 at 8:40 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> Arnd, Olof,
>
> Here is the imx multi-platform support [1] that missed 3.7 merge window.
> Please pull it for 3.8 and exposing on linux-next. As it touches a lot
> of files, I send it early, so that people can base their works off it
> to avoid conflicts.
Thanks! I've pulled this into arm-soc under the next/cleanup branch,
since all but the last commit really is cleanup (moving around header
files) and I didn't see a need to split out the last commit in a
separate branch.
> Sascha, please base your 3.8 branches off this one.
>
> Subsystem maintainers,
>
> We will keep this topic branch stable (non-rebase), so you are free
> to merge it to solve conflicts or dependency if necessary.
As a note and reminder to others: please base your changes on the
imx/multiplatform branch in arm-soc, or on Shawn's own branch, not on
next/cleanup or the for-next branch of arm-soc.
Thanks!
-Olof
^ permalink raw reply
* [PATCH] ARM: OMAP4: hwmod data: gpmc main clk
From: Tony Lindgren @ 2012-10-16 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507BDECA.20101@ti.com>
* Benoit Cousson <b-cousson@ti.com> [121015 03:02]:
> Hi Afzal,
>
> On 10/15/2012 07:47 AM, Afzal Mohammed wrote:
> > gpmc has been converted to a driver. It requests clock with
> > con-id "fck", if not available, probe fails. Clock for gpmc
> > device with con-id "fck" is created (aliased) along with
> > hwmod device, and for that to happen, main_clk needs to be
> > specified in hwmod entry, add it for OMAP4.
>
> Well, in this case, this is not the preferred way. The hwmod data are supposed to reflect the real HW capabilities.
> We'd better add the alias in the already existing dummy clock node.
>
> Here is the patch to do that.
>
> Thanks,
> Benoit
>
> ---
> From: Benoit Cousson <b-cousson@ti.com>
> Date: Mon, 15 Oct 2012 11:41:42 +0200
> Subject: [PATCH] ARM: OMAP2+: clock data: Add dev-id for the omap-gpmc dummy fck
>
> The GPMC code has been converted to a driver by the following commit:
>
> commit da496873970c57c4b31e186d967933da0ffa0d7c
> Author: Afzal Mohammed <afzal@ti.com>
> Date: Sun Sep 23 17:28:25 2012 -0600
>
> ARM: OMAP2+: gpmc: minimal driver support
>
> It now requests a clock with con-id "fck" otherwise the probe will fails.
>
> [ 0.342010] omap-gpmc omap-gpmc: error: clk_get
> [ 0.346771] omap-gpmc: probe of omap-gpmc failed with error -2
>
> Add the "omap-gmpc" dev-id and fck con-id to the already existing
> gmpc-fck dummy clock.
>
> Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
> Cc: Afzal Mohammed <afzal@ti.com>
Thanks applying into omap-for-v3.7-rc1/fixes-part2.
Regards,
Tony
> ---
> arch/arm/mach-omap2/clock44xx_data.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
> index d661d13..6efc30c 100644
> --- a/arch/arm/mach-omap2/clock44xx_data.c
> +++ b/arch/arm/mach-omap2/clock44xx_data.c
> @@ -3294,7 +3294,7 @@ static struct omap_clk omap44xx_clks[] = {
> CLK(NULL, "auxclk5_src_ck", &auxclk5_src_ck, CK_443X),
> CLK(NULL, "auxclk5_ck", &auxclk5_ck, CK_443X),
> CLK(NULL, "auxclkreq5_ck", &auxclkreq5_ck, CK_443X),
> - CLK(NULL, "gpmc_ck", &dummy_ck, CK_443X),
> + CLK("omap-gpmc", "fck", &dummy_ck, CK_443X),
> CLK("omap_i2c.1", "ick", &dummy_ck, CK_443X),
> CLK("omap_i2c.2", "ick", &dummy_ck, CK_443X),
> CLK("omap_i2c.3", "ick", &dummy_ck, CK_443X),
> --
> 1.7.0.4
>
^ permalink raw reply
* [PATCH] ARM: kirkwood: fix LEDs names for lsxl boards
From: Jason Cooper @ 2012-10-16 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210161921.01657.michael@walle.cc>
On Tue, Oct 16, 2012 at 07:21:01PM +0200, Michael Walle wrote:
>
> Hi Andrew,
>
> Can you pick this patch?
Michael,
I have it in my queue.
thx,
Jason.
^ permalink raw reply
* [PATCH] ARM: kirkwood: fix buttons on lsxl boards
From: Jason Cooper @ 2012-10-16 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210161921.27831.michael@walle.cc>
On Tue, Oct 16, 2012 at 07:21:27PM +0200, Michael Walle wrote:
>
> Hi Andrew,
>
> Can you pick this patch?
Michael,
Already in my queue.
thx,
Jason.
^ permalink raw reply
* [PATCH] ARM: kexec: fix segment memory addresses check
From: Will Deacon @ 2012-10-16 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350410244-12240-1-git-send-email-aaro.koskinen@iki.fi>
On Tue, Oct 16, 2012 at 06:57:24PM +0100, Aaro Koskinen wrote:
> Commit c564df4db85aac8d1d65a56176a0a25f46138064 (ARM: 7540/1: kexec:
> Check segment memory addresses) added a safety check with accidentally
> reversed condition, and broke kexec functionality on ARM. Fix this.
>
> Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
> ---
> arch/arm/kernel/machine_kexec.c | 7 +++----
> 1 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
> index e29c333..8ef8c93 100644
> --- a/arch/arm/kernel/machine_kexec.c
> +++ b/arch/arm/kernel/machine_kexec.c
> @@ -45,10 +45,9 @@ int machine_kexec_prepare(struct kimage *image)
> for (i = 0; i < image->nr_segments; i++) {
> current_segment = &image->segment[i];
>
> - err = memblock_is_region_memory(current_segment->mem,
> - current_segment->memsz);
> - if (err)
> - return - EINVAL;
> + if (!memblock_is_region_memory(current_segment->mem,
> + current_segment->memsz))
> + return -EINVAL;
>
> err = get_user(header, (__be32*)current_segment->buf);
> if (err)
> --
> 1.7.2.5
Thanks for this Aaro:
Acked-by: Will Deacon <will.deacon@arm.com>
Please stick it in the patch system.
Will
^ permalink raw reply
* [RFC PATCHv2] ARM: vt8500: Convert arch-vt8500 to multiplatform
From: Olof Johansson @ 2012-10-16 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349942353-14972-1-git-send-email-linux@prisktech.co.nz>
On Thu, Oct 11, 2012 at 08:59:13PM +1300, Tony Prisk wrote:
> This patch completes the conversion to ARCH_MULTI_V5 for arch-vt8500.
> Removed /mach/include/ and remaining unneeded files.
>
> Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
Acked-by: Olof Johansson <olof@lixom.net>
I think it's time to add a defconfig for vt8500 so we get build coverage. Can
you please do so for 3.8, maybe as a part of the branch this patch goes in?
Thanks!
-Olof
^ permalink raw reply
* [PULL REQUEST] ARM: vt8500: Cleanup for 3.8
From: Olof Johansson @ 2012-10-16 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350263941.3458.1.camel@gitbox>
On Mon, Oct 15, 2012 at 02:19:01PM +1300, Tony Prisk wrote:
> The following changes since commit
> ddffeb8c4d0331609ef2581d84de4d763607bd37:
>
> Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
>
> are available in the git repository at:
>
> git://server.prisktech.co.nz/git/linuxwmt.git/ tags/cleanup-for-3.8
Thanks, pulled into next/cleanup.
-Olof
^ permalink raw reply
* [Celinux-dev] PDF documentation
From: Tim Bird @ 2012-10-16 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016143522.086F2204292@gemini.denx.de>
On 10/16/2012 07:35 AM, Wolfgang Denk wrote:
> Dear Constantine Shulyupin,
>
> In message <CAE7jHC83biZy7TNYSr+-X85tpenqtAHuwSO47Q-6+XRF0fUxLA@mail.gmail.com> you wrote:
>>
>> I have some questions and ideas about documentation in PDF format.
>> During embedded SW development I often work with documentation,
>> especially datasheets in PDF format. I have some issues with such
>> documentation. It is not so easy to manage a lot of PDF documents
>> sometimes with strange code in file names. It is not easy to store
>> and share links to documentation.
>
> PDF has a lot of advantages in many situations, but I agree that it is
> also non-perfect for many other use cases.
>
>> Questions:
>> - have same issues with PDF documentation and datasheets?
>> - do you think documentation and datasheets in HTML format on a site
>> can be more useful than PDF?
>
> HTML is really useful in a web browser only.
I agree. This has already been covered by others, but HTML
consists of multiple files, and so is not convenient to store
or transmit atomically. Also, HTML is often difficult to print
(you have to explicitly remove the page decorations added by
the site (or find the 'print' option on the page).
> For documentation of the U-Boot boot loader we use a very different
> approach: documentation is created, stored and edited in a wiki
> (using FosWiki, see http://foswiki.org/). This has the advantage that
> you can make it either easily editable to the community, or put
> arbitrary access restrictions to it by using wiki user / group access
> permissions. In combination with some plugins (like TocPlugin,
> BookmakerPlugin and PublishPlugin) we can then "linearize" the entries
> in the wiki to generate a "book" which can be read both online (as
> HTML) or offline (by publishing the content as a linerarized, single
> HTLP, plain text, PDF and/or PostScript document).
>
> To give you a feeling how this works, please see for example
> http://www.denx.de/wiki/view/DULG/Manual?stickboard=m28
> http://www.denx.de/wiki/publish/DULG/DULG-m28.html
> http://www.denx.de/wiki/publish/DULG/DULG-m28.ps
> and http://www.denx.de/wiki/publish/DULG/DULG-m28.pdf
...
> And the nice thing is: all this is based on free software only...
This is really interesting.
Several years ago, CELF tried to add a similar capability to
MoinMoin (the ability to take arbitrary page lists, and
automatically publish them to PDF). Unfortunately, it didn't
work very well. The tools to produce PDF were pretty bad back then.
I think the wiki approach is very good for collecting the
information, and having a way to snapshot and publish the items
solves some of the problems wikis have (uneven editing across
multiple pages over time can lead to inconsistent pages).
It sounds like the tools have improved since we did this, and
maybe we should look again and see if there's something similar
we could add to the elinux wiki.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
^ permalink raw reply
* [GIT PULL] Versatile Express updates for v3.8
From: Olof Johansson @ 2012-10-16 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350404650.1242.20.camel@hornet>
On Tue, Oct 16, 2012 at 05:24:10PM +0100, Pawel Moll wrote:
> Hi Arnd, Olof,
>
> Would you be so kind to pull the updates for Versatile Express? It's the
> same stuff as discussed last month (I've just added a couple of fixes
> for bugs reported by Tixy) plus the hwmon driver (the maintainer acked
> it and chosen to get it merged through the arm-soc tree).
Hi Pawel,
The branch contents looks good, but I wonder if you would mind splitting it up
across the same kind of topics that we tend to organize arm-soc in?
Suggestions below.
> Pawel Moll (8):
> hwmon: Versatile Express hwmon driver
> mfd: Versatile Express config infrastructure
> mfd: Versatile Express system registers driver
> ARM: vexpress: Reset driver
The above would go in a drivers branch
> ARM: vexpress: Add config bus components and clocks to DTs
> ARM: vexpress: Start using new Versatile Express infrastructure
> ARM: vexpress: Remove motherboard dependencies in the DTS files
> ARM: vexpress: Make the debug UART detection more specific
I would suggest taking the two DT patches (#1 and #3 in the list) and splitting
them off in a dt branch, and the rest in a boards or soc branch.
So, total of three branches:
drivers
dt
soc
If these are the only vexpress patches you expect at all for 3.8, we can
just take it as it is in one more broad branch. But since we're early in
the cycle I'm guessing you might end up having more patches coming in,
so starting to sort them in topics is a good idea.
Thanks!
-Olof
^ permalink raw reply
* [RFC PATCHv2] ARM: vt8500: Convert arch-vt8500 to multiplatform
From: Arnd Bergmann @ 2012-10-16 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016181758.GA1801@quad.lixom.net>
On Tuesday 16 October 2012, Olof Johansson wrote:
> On Thu, Oct 11, 2012 at 08:59:13PM +1300, Tony Prisk wrote:
> > This patch completes the conversion to ARCH_MULTI_V5 for arch-vt8500.
> > Removed /mach/include/ and remaining unneeded files.
> >
> > Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
>
> Acked-by: Olof Johansson <olof@lixom.net>
>
> I think it's time to add a defconfig for vt8500 so we get build coverage. Can
> you please do so for 3.8, maybe as a part of the branch this patch goes in?
Wouldn't this just be part of a new multi_v5_defconfig?
I don't object to having a vt8500-only defconfig, but I think we should
also enable it in the normal one.
Arnd
^ permalink raw reply
* [RFC PATCHv2] ARM: vt8500: Convert arch-vt8500 to multiplatform
From: Olof Johansson @ 2012-10-16 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210161837.03651.arnd@arndb.de>
On Tue, Oct 16, 2012 at 11:37 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 16 October 2012, Olof Johansson wrote:
>> On Thu, Oct 11, 2012 at 08:59:13PM +1300, Tony Prisk wrote:
>> > This patch completes the conversion to ARCH_MULTI_V5 for arch-vt8500.
>> > Removed /mach/include/ and remaining unneeded files.
>> >
>> > Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
>>
>> Acked-by: Olof Johansson <olof@lixom.net>
>>
>> I think it's time to add a defconfig for vt8500 so we get build coverage. Can
>> you please do so for 3.8, maybe as a part of the branch this patch goes in?
>
> Wouldn't this just be part of a new multi_v5_defconfig?
Yeah, as long as it contains the needed drivers, etc.
> I don't object to having a vt8500-only defconfig, but I think we should
> also enable it in the normal one.
Agreed.
-Olof
^ permalink raw reply
* [RFC PATCHv2] ARM: vt8500: Convert arch-vt8500 to multiplatform
From: Tony Prisk @ 2012-10-16 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016181758.GA1801@quad.lixom.net>
On Tue, 2012-10-16 at 11:17 -0700, Olof Johansson wrote:
> On Thu, Oct 11, 2012 at 08:59:13PM +1300, Tony Prisk wrote:
> > This patch completes the conversion to ARCH_MULTI_V5 for arch-vt8500.
> > Removed /mach/include/ and remaining unneeded files.
> >
> > Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
>
> Acked-by: Olof Johansson <olof@lixom.net>
>
> I think it's time to add a defconfig for vt8500 so we get build coverage. Can
> you please do so for 3.8, maybe as a part of the branch this patch goes in?
>
>
> Thanks!
>
>
> -Olof
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
I thought the ARCH_MULTI def_configs would cover it from 3.8?
Or would you like a vt8500_defconfig to help build the ARCH_MULTI
configs?
Either way, I will get it done and included in this branch.
Regards
Tony P
^ permalink raw reply
* [RFC PATCHv2] ARM: vt8500: Convert arch-vt8500 to multiplatform
From: Olof Johansson @ 2012-10-16 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350412901.16703.1.camel@gitbox>
On Tue, Oct 16, 2012 at 11:41 AM, Tony Prisk <linux@prisktech.co.nz> wrote:
> On Tue, 2012-10-16 at 11:17 -0700, Olof Johansson wrote:
>> On Thu, Oct 11, 2012 at 08:59:13PM +1300, Tony Prisk wrote:
>> > This patch completes the conversion to ARCH_MULTI_V5 for arch-vt8500.
>> > Removed /mach/include/ and remaining unneeded files.
>> >
>> > Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
>>
>> Acked-by: Olof Johansson <olof@lixom.net>
>>
>> I think it's time to add a defconfig for vt8500 so we get build coverage. Can
>> you please do so for 3.8, maybe as a part of the branch this patch goes in?
>>
>>
>> Thanks!
>>
>>
>> -Olof
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> I thought the ARCH_MULTI def_configs would cover it from 3.8?
>
> Or would you like a vt8500_defconfig to help build the ARCH_MULTI
> configs?
>
> Either way, I will get it done and included in this branch.
Yeah, as mentioned in my reply to Arnd, the multiconfig would be
sufficient, just make sure it contains the drivers you need for your
platform(s) to work well.
-Olof
^ permalink raw reply
* [RFC PATCHv2] ARM: vt8500: Convert arch-vt8500 to multiplatform
From: Tony Prisk @ 2012-10-16 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMg7P602xerMjm3KjSh59Qt26URDQK-boVjnPB2v9kdCLg@mail.gmail.com>
On Tue, 2012-10-16 at 11:42 -0700, Olof Johansson wrote:
> On Tue, Oct 16, 2012 at 11:41 AM, Tony Prisk <linux@prisktech.co.nz> wrote:
> > On Tue, 2012-10-16 at 11:17 -0700, Olof Johansson wrote:
> >> On Thu, Oct 11, 2012 at 08:59:13PM +1300, Tony Prisk wrote:
> >> > This patch completes the conversion to ARCH_MULTI_V5 for arch-vt8500.
> >> > Removed /mach/include/ and remaining unneeded files.
> >> >
> >> > Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
> >>
> >> Acked-by: Olof Johansson <olof@lixom.net>
> >>
> >> I think it's time to add a defconfig for vt8500 so we get build coverage. Can
> >> you please do so for 3.8, maybe as a part of the branch this patch goes in?
> >>
> >>
> >> Thanks!
> >>
> >>
> >> -Olof
> >>
> >> _______________________________________________
> >> linux-arm-kernel mailing list
> >> linux-arm-kernel at lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
> > I thought the ARCH_MULTI def_configs would cover it from 3.8?
> >
> > Or would you like a vt8500_defconfig to help build the ARCH_MULTI
> > configs?
> >
> > Either way, I will get it done and included in this branch.
>
> Yeah, as mentioned in my reply to Arnd, the multiconfig would be
> sufficient, just make sure it contains the drivers you need for your
> platform(s) to work well.
>
>
> -Olof
Actually, now that I think about it - I have reverted some of the
multiplatform changes locally to allow us to keep earlyprintk, so I
guess a vt8500_single defconfig wouldn't hurt at the moment.
Regards
Tony P
^ permalink raw reply
* [PATCH 1/4] leds: leds-ns2: add device tree binding
From: Arnd Bergmann @ 2012-10-16 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016135153.GE28384@kw.sim.vm.gnt>
On Tuesday 16 October 2012, Simon Guinot wrote:
> On Tue, Oct 16, 2012 at 01:02:39PM +0000, Arnd Bergmann wrote:
> >
> > I'm not overly familiar with the LED subsystem, but isn't this something
> > that could be done with the generic gpio-led driver?
>
> Basically, the leds-gpio driver allows to associate one pin to one LED.
> It is simple and efficient. The LED can be turned on or off. And using a
> platform callback (gpio_blink_set), some hardware timer blink can be
> enabled. A very few platforms are using this last callback.
>
> On the ns2 (and other lacie machines), there is three different modes
> for the front blue LED: on, off and SATA activity blink. Three different
> pins are used to configure the LED. Definitively it is not compatible
> with the leds-gpio driver.
Ok, thanks for the explantion. I think your approach is fine then.
Arnd
^ permalink raw reply
* [PATCH 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
From: Jon Hunter @ 2012-10-16 19:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <41d66042625157d089e9c9532030a6831e79c641.1350327324.git.richardcochran@gmail.com>
On 10/15/2012 02:16 PM, Richard Cochran wrote:
> From: hvaibhav at ti.com <hvaibhav@ti.com>
>
> With recent changes in omap gpmc driver code, in case of DT
> boot mode, where bootloader does not configure gpmc cs space
> will result into kernel BUG() inside gpmc_mem_init() function,
> as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and
> gpmc_config7[0].baseaddress is set to '0' on reset.
I am not sure I completely follow the logic here.
Won't this problem occur if the bootloader does not configure the gpmc
cs space AND we are not using DT?
Is the csvalid bit set because we are booting from the internal ROM?
I guess I don't see why csvalid bit being set and a base-address of 0x0
should not be allowed. That should be a valid combination.
One problem I see with gpmc_mem_init() is that it assumes that
BOOT_ROM_SPACE is 1MB for all devices starting at 0x0 apart from the
apollon board. For newer devices such as OMAP4, there is only 48KB of
internal ROM and only mapped to 0x0 when booting from internal ROM. So
this needs to be fixed.
How much internal ROM does the AM335x have and where is it mapped?
> This use-case is applicable for any board/EVM which doesn't have
> any peripheral connected to gpmc cs0, for example BeagleXM and
> BeagleBone, so DT boot mode fails.
>
> This patch adds of_have_populated_dt() check before creating
> device, so that for DT boot mode, gpmc probe will not be called
> which is expected behavior, as gpmc is not supported yet from DT.
Yes, but we do actually still allow some platform devices to be probed
(such as dmtimers) when booting with DT that don't support DT yet. So
this change prevents us from using the gpmc on boards when booting with DT.
I am not convinced that this is addressing the underlying problem with
gpmc_mem_init().
Cheers
Jon
^ permalink raw reply
* [PATCH 3/9] uprobes: allow ignoring of probe hits
From: Rabin Vincent @ 2012-10-16 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121015165218.GA10239@redhat.com>
2012/10/15 Oleg Nesterov <oleg@redhat.com>:
> On 10/14, Rabin Vincent wrote:
>> Allow arches to decided to ignore a probe hit. ARM will use this to
>> only call handlers if the conditions to execute a conditionally executed
>> instruction are satisfied.
>
> Not sure I understand why we shouldn't call handlers in this case,
> but OK, I know nothing about arm.
This old discussion about kprobes should be useful:
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-March/045755.html
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-March/046544.html
> This conflicts with other changes in
>
> git://git.kernel.org/pub/scm/linux/kernel/git/oleg/misc uprobes/core
>
> Could you re-diff?
OK, I will rebase them.
^ permalink raw reply
* [PATCH] ARM: mach-kirkwood: add documentation for device tree bindings
From: Simon Guinot @ 2012-10-16 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507C6AE4.1020406@gmail.com>
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
---
Documentation/devicetree/bindings/arm/kirkwood.txt | 37 ++++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/kirkwood.txt
diff --git a/Documentation/devicetree/bindings/arm/kirkwood.txt b/Documentation/devicetree/bindings/arm/kirkwood.txt
new file mode 100644
index 0000000..14fb6b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/kirkwood.txt
@@ -0,0 +1,37 @@
+Marvell Kirkwood Platforms Device Tree Bindings
+-----------------------------------------------
+
+Boards with a SoC of the Marvell Kirkwood family shall have the
+following property:
+Required root node property:
+compatible: must contain "marvell,kirkwood"
+
+In addition, boards with a Kirkwood SoC 88F6192 shall have the
+following property:
+Required root node property:
+compatible: must contain "marvell,kirkwood-88f6192"
+
+In addition, boards with a Kirkwood SoC 88F6281 shall have the
+following property:
+Required root node property:
+compatible: must contain "marvell,kirkwood-88f6281"
+
+In addition, boards with a Kirkwood SoC 88F6702 shall have the
+following property:
+Required root node property:
+compatible: must contain "marvell,kirkwood-88f6702"
+
+Board with a SoC of the Marvell Armada 300 family (Kirkwood compatible)
+shall have the following property:
+Required root node property:
+compatible: must contain "marvell,armada300", "marvell,kirkwood"
+
+In addition, boards with an Armada 300 SoC 88F6282 shall have the
+following property:
+Required root node property:
+compatible: must contain "marvell,armada300-88f6282"
+
+In addition, boards with an Armada 300 SoC 88F6283 shall have the
+following property:
+Required root node property:
+compatible: must contain "marvell,armada300-88f6283"
--
1.7.10
^ permalink raw reply related
* [PATCH 6/9] uprobes: flush cache after xol write
From: Rabin Vincent @ 2012-10-16 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121015165756.GA11737@redhat.com>
2012/10/15 Oleg Nesterov <oleg@redhat.com>:
> On 10/14, Rabin Vincent wrote:
>> Flush the cache so that the instructions written to the XOL area are
>> visible.
>>
>> Signed-off-by: Rabin Vincent <rabin@rab.in>
>> ---
>> kernel/events/uprobes.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
>> index ca000a9..8c52f93 100644
>> --- a/kernel/events/uprobes.c
>> +++ b/kernel/events/uprobes.c
>> @@ -1246,6 +1246,7 @@ static unsigned long xol_get_insn_slot(struct uprobe *uprobe, unsigned long slot
>> offset = current->utask->xol_vaddr & ~PAGE_MASK;
>> vaddr = kmap_atomic(area->page);
>> arch_uprobe_xol_copy(&uprobe->arch, vaddr + offset);
>> + flush_dcache_page(area->page);
>> kunmap_atomic(vaddr);
>
> I agree... but why under kmap_atomic?
No real reason; I'll move it to after the unmap.
^ permalink raw reply
* [PATCH 1/9] uprobes: move function declarations out of arch
From: Rabin Vincent @ 2012-10-16 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121015171932.GA28723@linux.vnet.ibm.com>
2012/10/15 Srikar Dronamraju <srikar@linux.vnet.ibm.com>:
> You need to take care of the powerpc port
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=8b7b80b9ebb46dd88fbb94e918297295cf312b59
>
> Also as Oleg pointed out, He has already posted changes on top of -tip.
> So it probably makes sense to redo these patches on top of those
> patches.
OK, will look into it.
^ permalink raw reply
* [PATCH 2/4] ARM: kirkwood: DT board setup for Network Space v2 and parents
From: Simon Guinot @ 2012-10-16 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507C6AE4.1020406@gmail.com>
On Mon, Oct 15, 2012 at 02:58:28PM -0500, Rob Herring wrote:
> On 10/15/2012 10:34 AM, Simon Guinot wrote:
> > This patch adds DT board setup for LaCie Network Space v2 and parents,
> > based on the Marvell Kirkwood 6281 SoC. This includes Network Space v2
> > (Max) and Internet Space v2.
> >
> > Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
> > ---
> > arch/arm/boot/dts/Makefile | 3 +
> > arch/arm/boot/dts/kirkwood-is2.dts | 30 ++++++++++
> > arch/arm/boot/dts/kirkwood-ns2-common.dtsi | 63 +++++++++++++++++++++
> > arch/arm/boot/dts/kirkwood-ns2.dts | 30 ++++++++++
> > arch/arm/boot/dts/kirkwood-ns2max.dts | 49 ++++++++++++++++
> > arch/arm/mach-kirkwood/Kconfig | 21 +++++++
> > arch/arm/mach-kirkwood/Makefile | 3 +
> > arch/arm/mach-kirkwood/board-dt.c | 8 +++
> > arch/arm/mach-kirkwood/board-ns2.c | 83 ++++++++++++++++++++++++++++
> > arch/arm/mach-kirkwood/common.h | 8 +++
> > drivers/leds/Kconfig | 4 +-
> > 11 files changed, 301 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm/boot/dts/kirkwood-is2.dts
> > create mode 100644 arch/arm/boot/dts/kirkwood-ns2-common.dtsi
> > create mode 100644 arch/arm/boot/dts/kirkwood-ns2.dts
> > create mode 100644 arch/arm/boot/dts/kirkwood-ns2max.dts
> > create mode 100644 arch/arm/mach-kirkwood/board-ns2.c
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index c1ce813..e6201b6 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -34,9 +34,12 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
> > kirkwood-ib62x0.dtb \
> > kirkwood-iconnect.dtb \
> > kirkwood-iomega_ix2_200.dtb \
> > + kirkwood-is2.dtb \
> > kirkwood-km_kirkwood.dtb \
> > kirkwood-lschlv2.dtb \
> > kirkwood-lsxhl.dtb \
> > + kirkwood-ns2.dtb \
> > + kirkwood-ns2max.dtb \
> > kirkwood-ts219-6281.dtb \
> > kirkwood-ts219-6282.dtb
> > dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
> > diff --git a/arch/arm/boot/dts/kirkwood-is2.dts b/arch/arm/boot/dts/kirkwood-is2.dts
> > new file mode 100644
> > index 0000000..7bc4677
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/kirkwood-is2.dts
> > @@ -0,0 +1,30 @@
> > +/dts-v1/;
> > +
> > +/include/ "kirkwood-ns2-common.dtsi"
> > +
> > +/ {
> > + model = "LaCie Internet Space v2";
> > + compatible = "lacie,inetspace_v2", "marvell,kirkwood-88f6281", "marvell,kirkwood";
>
> Compatible strings must be documented.
Hi Rob,
I have sent a patch to document the compatible strings used with the
Marvell Kirkwood SoCs. Do you also want me to document the compatible
strings for the LaCie machines ? Looking at the devicetree/bindings/arm
directory, it doesn't seems to be a common practice.
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121016/0c50619b/attachment.sig>
^ permalink raw reply
* [RFC PATCH 1/4] ARM: kernel: add device tree init map function
From: Rob Herring @ 2012-10-16 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350393709-23546-2-git-send-email-lorenzo.pieralisi@arm.com>
On 10/16/2012 08:21 AM, Lorenzo Pieralisi wrote:
> When booting through a device tree, the kernel cpu logical id map can be
> initialized using device tree data passed by FW or through an embedded blob.
>
> This patch adds a function that parses device tree "cpu" nodes and
> retrieves the corresponding CPUs hardware identifiers (MPIDR).
> It sets the possible cpus and the cpu logical map values according to
> the number of CPUs defined in the device tree and respective properties.
>
> The primary CPU is assigned cpu logical number 0 to keep the current
> convention valid.
>
> Current bindings documentation is included in the patch:
>
> Documentation/devicetree/bindings/arm/cpus.txt
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> ---
> Documentation/devicetree/bindings/arm/cpus.txt | 42 +++++++++++++++++++++++
> arch/arm/include/asm/prom.h | 2 ++
> arch/arm/kernel/devtree.c | 47 ++++++++++++++++++++++++++
> 3 files changed, 91 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/cpus.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> new file mode 100644
> index 0000000..897f3b4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -0,0 +1,42 @@
> +* ARM CPUs binding description
> +
> +The device tree allows to describe the layout of CPUs in a system through
> +the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
> +defining properties for every cpu.
> +
> +Bindings for CPU nodes follow the ePAPR standard, available from:
> +
> +http://devicetree.org
> +
> +For the ARM architecture every CPU node must contain the following property:
> +
> +- reg : property defining the CPU MPIDR[23:0] register bits
defining or matching the MPIDR?
> +
> +Every cpu node is required to set its device_type to "cpu".
This is a bit questionable as device_type is deprecated for FDT.
However, since the ePAPR defines using it
You should add a compatible property for the cpu model.
> +
> +Example:
> +
> + cpus {
> + #size-cells = <0>;
> + #address-cells = <1>;
> +
> + CPU0: cpu at 0 {
> + device_type = "cpu";
> + reg = <0x0>;
> + };
> +
> + CPU1: cpu at 1 {
> + device_type = "cpu";
> + reg = <0x1>;
> + };
> +
> + CPU2: cpu at 100 {
> + device_type = "cpu";
> + reg = <0x100>;
> + };
> +
> + CPU3: cpu at 101 {
> + device_type = "cpu";
> + reg = <0x101>;
> + };
> + };
> diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
> index aeae9c6..8dd51dc 100644
> --- a/arch/arm/include/asm/prom.h
> +++ b/arch/arm/include/asm/prom.h
> @@ -15,6 +15,7 @@
>
> extern struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
> extern void arm_dt_memblock_reserve(void);
> +extern void __init arm_dt_init_cpu_maps(void);
>
> #else /* CONFIG_OF */
>
> @@ -24,6 +25,7 @@ static inline struct machine_desc *setup_machine_fdt(unsigned int dt_phys)
> }
>
> static inline void arm_dt_memblock_reserve(void) { }
> +static inline void arm_dt_init_cpu_maps(void) { }
>
> #endif /* CONFIG_OF */
> #endif /* ASMARM_PROM_H */
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index bee7f9d..c86e414 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -19,8 +19,10 @@
> #include <linux/of_irq.h>
> #include <linux/of_platform.h>
>
> +#include <asm/cputype.h>
> #include <asm/setup.h>
> #include <asm/page.h>
> +#include <asm/smp_plat.h>
> #include <asm/mach/arch.h>
> #include <asm/mach-types.h>
>
> @@ -61,6 +63,51 @@ void __init arm_dt_memblock_reserve(void)
> }
> }
>
> +/*
> + * arm_dt_init_cpu_maps - Function retrieves cpu nodes from the device tree
> + * and builds the cpu logical map array containing MPIDR values related to
> + * logical cpus
> + *
> + * Updates the cpu possible mask with the number of parsed cpu nodes
> + */
> +void __init arm_dt_init_cpu_maps(void)
> +{
> + struct device_node *dn = NULL;
> + int i, cpu = 1;
> +
> + while ((dn = of_find_node_by_type(dn, "cpu")) && cpu <= nr_cpu_ids) {
I think all /cpu nodes would have the right type. You could use
for_each_child_of_node here.
> + const u32 *hwid;
> + int len;
> +
> + pr_debug(" * %s...\n", dn->full_name);
> +
> + hwid = of_get_property(dn, "reg", &len);
> +
Use of_property_read_u32.
> + if (!hwid || len != 4) {
> + pr_err(" * %s missing reg property\n", dn->full_name);
> + continue;
> + }
> + /*
> + * We want to assign the boot CPU logical id 0.
> + * Boot CPU checks its own MPIDR and if matches the current
> + * cpu node "reg" value it sets the logical cpu index to 0
> + * and stores the physical id accordingly.
> + * If MPIDR does not match, assign sequential cpu logical
> + * id (starting from 1) and increments it.
> + */
> + i = (be32_to_cpup(hwid) == (read_cpuid_mpidr() & 0xffffff))
> + ? 0 : cpu++;
> +
> + if (!i)
> + printk(KERN_INFO "Booting Linux on CPU HWID 0x%x\n",
> + be32_to_cpup(hwid));
> +
> + cpu_logical_map(i) = be32_to_cpup(hwid);
> +
> + set_cpu_possible(i, true);
> + }
> +}
> +
> /**
> * setup_machine_fdt - Machine setup when an dtb was passed to the kernel
> * @dt_phys: physical address of dt blob
>
^ permalink raw reply
* [PATCH 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
From: Jon Hunter @ 2012-10-16 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016174835.GV15569@atomide.com>
Hi Tony,
On 10/16/2012 12:48 PM, Tony Lindgren wrote:
> * Richard Cochran <richardcochran@gmail.com> [121015 12:18]:
>> From: hvaibhav at ti.com <hvaibhav@ti.com>
>>
>> With recent changes in omap gpmc driver code, in case of DT
>> boot mode, where bootloader does not configure gpmc cs space
>> will result into kernel BUG() inside gpmc_mem_init() function,
>> as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and
>> gpmc_config7[0].baseaddress is set to '0' on reset.
>>
>> This use-case is applicable for any board/EVM which doesn't have
>> any peripheral connected to gpmc cs0, for example BeagleXM and
>> BeagleBone, so DT boot mode fails.
>>
>> This patch adds of_have_populated_dt() check before creating
>> device, so that for DT boot mode, gpmc probe will not be called
>> which is expected behavior, as gpmc is not supported yet from DT.
>
> I'm applying this one into omap-for-v3.7-rc1/fixes-part2.
>
> Next time, please also cc linux-omap at vger.kernel.org for series
> like this. I'm sure the people reading the omap list are interested
> in these.
This patch appears to be masking an underlying issue. How about
something like the following ...
Cheers
Jon
>From 753a4928bf6f7baa4c001bdca3d15a85e999db4c Mon Sep 17 00:00:00 2001
From: Jon Hunter <jon-hunter@ti.com>
Date: Tue, 16 Oct 2012 15:22:58 -0500
Subject: [PATCH] ARM: OMAP2+: Allow kernel to boot even if GPMC fails to
reserve memory
Currently, if the GPMC driver fails to reserve memory when probed we will
call BUG() and the kernel will not boot. Instead of calling BUG(), return
an error from probe and allow kernel to boot.
Tested on AM335x beagle bone board.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/mach-omap2/gpmc.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5ac5cf3..8f0d3c8 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -868,9 +868,9 @@ static void __devexit gpmc_mem_exit(void)
}
-static void __devinit gpmc_mem_init(void)
+static int __devinit gpmc_mem_init(void)
{
- int cs;
+ int cs, rc;
unsigned long boot_rom_space = 0;
/* never allocate the first page, to facilitate bug detection;
@@ -890,13 +890,17 @@ static void __devinit gpmc_mem_init(void)
if (!gpmc_cs_mem_enabled(cs))
continue;
gpmc_cs_get_memconf(cs, &base, &size);
- if (gpmc_cs_insert_mem(cs, base, size) < 0)
- BUG();
+ rc = gpmc_cs_insert_mem(cs, base, size);
+ if (IS_ERR_VALUE(rc))
+ return rc;
}
+
+ return 0;
}
static __devinit int gpmc_probe(struct platform_device *pdev)
{
+ int rc;
u32 l;
struct resource *res;
@@ -936,7 +940,11 @@ static __devinit int gpmc_probe(struct platform_device *pdev)
dev_info(gpmc_dev, "GPMC revision %d.%d\n", GPMC_REVISION_MAJOR(l),
GPMC_REVISION_MINOR(l));
- gpmc_mem_init();
+ rc = gpmc_mem_init();
+ if (IS_ERR_VALUE(rc)) {
+ dev_err(gpmc_dev, "failed to reserve memory\n");
+ return rc;
+ }
if (IS_ERR_VALUE(gpmc_setup_irq()))
dev_warn(gpmc_dev, "gpmc_setup_irq failed\n");
--
1.7.9.5
^ permalink raw reply related
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