* Question about "Inconsistent kallsyms data"
From: Eric Miao @ 2011-10-08 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E382602.6050308@grupopie.com>
On Wed, Aug 3, 2011 at 12:29 AM, Paulo Marques <pmarques@grupopie.com> wrote:
> Tomasz Figa wrote:
>> On Friday 29 of July 2011 at 12:58:32, Tomasz Figa wrote:
>>>[...]
>>> I will try to bisect the case with s3c6400 defconfig.
>>
>> I have no idea why, but I cannot reproduce the issue anymore, even after make
>> distclean or starting with a clean tree. A build system bug?
>>
>> I do not know much technical details about the kernel build system, but might
>> it be a concurrency issue (I use make -j5 for building with 5 jobs)?
>
> Usually this is caused by symbols moving slightly between kernel compiles.
>
> This is an explanation of the process I wrote a while ago in a different
> thread at LKML:
>
>> Now as for CONFIG_KALLSYMS_EXTRA_PASS: to build the kallsyms table, the
>> build process first links a kernel image with an empty kallsyms table
>> and use that to fetch information for all the symbols.
>>
>> It then uses that information to build the table with the right size,
>> and links it again. If everything goes ok, this new version as all the
>> symbols in the correct places and the final table can be built with the
>> correct addresses.
>>
>> The final linking should produce the same result as only the data on the
>> kallsyms table changed, but not its size.
>>
>> However, there have been bugs in the past with section alignments and
>> symbol reordering for symbols with the same address, etc., etc. that
>> make this final table not have the exact same size, and the build fails
>> with an inconsistent kallsyms data message. At this point, the user can
>> turn on the CONFIG_KALLSYMS_EXTRA_PASS and temporarily solve the problem
>> while the developers find the correct fix. Without this option, in this
>> situation the kernel would simply fail the compilation.
>>
>> All this has been stable for a while and this option hasn't been needed
>> recently (AFAIK), but if there is some bug in some new binutils or
>> something, the option might be needed again.
>
> To check inconsistencies, the Makefile compares ".tmp_System.map" and
> "System.map" for differences.
>
> On a normal build they should be identical, but if this fails with
> "Inconsistent kallsyms data" you could try comparing the two files to
> check which symbols are causing trouble.
I met this issue today as well. Didn't have a chance to compare the
files, as I did a 'rm -fr ../build' and reconfigured/re-built everything,
and 'make O=../build clean' didn't work for me.
I'm using a toolchain with version info as below:
$ arm-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.5.2/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.5.2-8ubuntu3'
--with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --enable-shared --enable-multiarch
--with-multiarch-defaults=i386-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix
--with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.5.2
--libdir=/usr/lib --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-gold --enable-ld=default --with-plugin-ld=ld.gold
--enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a
--with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb
--disable-werror --enable-checking=release
--program-prefix=arm-linux-gnueabi-
--includedir=/usr/arm-linux-gnueabi/include --build=i686-linux-gnu
--host=i686-linux-gnu --target=arm-linux-gnueabi
--with-headers=/usr/arm-linux-gnueabi/include
--with-libs=/usr/arm-linux-gnueabi/lib
Thread model: posix
gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3)
>
> --
> Paulo Marques - www.grupopie.com
>
> "All generalizations are false."
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH 24/26] ARM: pxa: centro and treo680 need palm27x
From: Eric Miao @ 2011-10-08 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317499438-14058-25-git-send-email-arnd@arndb.de>
On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The two platforms are part of the palm27x family and use the same
> code. Select the palm27x symbol to make sure they can be built
> standalone.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
> ---
> ?arch/arm/mach-pxa/Kconfig | ? ?2 ++
> ?1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
> index 568b7f6..da6fca0 100644
> --- a/arch/arm/mach-pxa/Kconfig
> +++ b/arch/arm/mach-pxa/Kconfig
> @@ -431,6 +431,7 @@ config MACH_CENTRO
> ? ? ? ?bool "Palm Centro 685 (GSM)"
> ? ? ? ?default y
> ? ? ? ?depends on ARCH_PXA_PALM
> + ? ? ? select MACH_PALM27X
> ? ? ? ?select PXA27x
> ? ? ? ?select IWMMXT
> ? ? ? ?select PALM_TREO
> @@ -442,6 +443,7 @@ config MACH_TREO680
> ? ? ? ?bool "Palm Treo 680"
> ? ? ? ?default y
> ? ? ? ?depends on ARCH_PXA_PALM
> + ? ? ? select MACH_PALM27X
> ? ? ? ?select PXA27x
> ? ? ? ?select IWMMXT
> ? ? ? ?select PALM_TREO
> --
> 1.7.5.4
>
>
^ permalink raw reply
* [PATCH 26/26] ARM: pxa: sharpsl pm needs SPI
From: Eric Miao @ 2011-10-08 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317499438-14058-27-git-send-email-arnd@arndb.de>
On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The sharpsl code selects the max1111 spi driver, so it must also
> ensure that SPI itself is enabled. The platform does not work
> without max1111.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
> ---
> ?arch/arm/mach-pxa/Kconfig | ? ?2 ++
> ?1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
> index 3733971..6dee18e 100644
> --- a/arch/arm/mach-pxa/Kconfig
> +++ b/arch/arm/mach-pxa/Kconfig
> @@ -710,6 +710,8 @@ config SHARPSL_PM
> ?config SHARPSL_PM_MAX1111
> ? ? ? ?bool
> ? ? ? ?select HWMON
> + ? ? ? select SPI
> + ? ? ? select SPI_MASTER
> ? ? ? ?select SENSORS_MAX1111
>
> ?config PXA_HAVE_ISA_IRQS
> --
> 1.7.5.4
>
>
^ permalink raw reply
* [PATCH 06/26] ARM: pxa: add missing header inclusions
From: Jamie Iles @ 2011-10-08 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111008080309.GD25689@n2100.arm.linux.org.uk>
On Sat, Oct 08, 2011 at 09:03:09AM +0100, Russell King - ARM Linux wrote:
> On Fri, Oct 07, 2011 at 01:08:23PM +0800, Eric Miao wrote:
> > On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > These resulted in build breakage in some configurations:
> > >
> > > arch/arm/mach-pxa/irq.c:132:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'icip_handle_irq'
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > ---
> > > ?arch/arm/mach-pxa/irq.c | ? ?1 +
> > > ?1 files changed, 1 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-pxa/irq.c b/arch/arm/mach-pxa/irq.c
> > > index b09e848..848e96d 100644
> > > --- a/arch/arm/mach-pxa/irq.c
> > > +++ b/arch/arm/mach-pxa/irq.c
> > > @@ -16,6 +16,7 @@
> > > ?#include <linux/module.h>
> > > ?#include <linux/interrupt.h>
> > > ?#include <linux/syscore_ops.h>
> > > +#include <linux/ftrace.h>
> >
> > It's actually __irq_entry being defined in <linux/ftrace.h> and in turn
> > __exception_irq_entry being conditionally defined to that.
> >
> > I think it's better to fix this in <asm/system.h> instead of in the
> > cases where this macro is referenced?
> >
> > Russell?
>
> There's a patch in the patch system which fixes this (7115/3) but I
> can't apply it because it doesn't apply to anything in my for-next
> tree (it applies to the obsolete 'devel' branch which is rather old
> now.)
OK, I wasn't aware that devel was obsolete (though I guess if I'd paid
closer attention to the commit dates I'd have suspected something).
Anyhow, new patch in the tracker as 7115/4 rebased onto for-next.
Jamie
^ permalink raw reply
* [PATCH 06/26] ARM: pxa: add missing header inclusions
From: Eric Miao @ 2011-10-08 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111008102313.GA4464@gallagher>
On Sat, Oct 8, 2011 at 6:23 PM, Jamie Iles <jamie@jamieiles.com> wrote:
> On Sat, Oct 08, 2011 at 09:03:09AM +0100, Russell King - ARM Linux wrote:
>> On Fri, Oct 07, 2011 at 01:08:23PM +0800, Eric Miao wrote:
>> > On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > > These resulted in build breakage in some configurations:
>> > >
>> > > arch/arm/mach-pxa/irq.c:132:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'icip_handle_irq'
>> > >
>> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> > > ---
>> > > ?arch/arm/mach-pxa/irq.c | ? ?1 +
>> > > ?1 files changed, 1 insertions(+), 0 deletions(-)
>> > >
>> > > diff --git a/arch/arm/mach-pxa/irq.c b/arch/arm/mach-pxa/irq.c
>> > > index b09e848..848e96d 100644
>> > > --- a/arch/arm/mach-pxa/irq.c
>> > > +++ b/arch/arm/mach-pxa/irq.c
>> > > @@ -16,6 +16,7 @@
>> > > ?#include <linux/module.h>
>> > > ?#include <linux/interrupt.h>
>> > > ?#include <linux/syscore_ops.h>
>> > > +#include <linux/ftrace.h>
>> >
>> > It's actually __irq_entry being defined in <linux/ftrace.h> and in turn
>> > __exception_irq_entry being conditionally defined to that.
>> >
>> > I think it's better to fix this in <asm/system.h> instead of in the
>> > cases where this macro is referenced?
>> >
>> > Russell?
>>
>> There's a patch in the patch system which fixes this (7115/3) but I
>> can't apply it because it doesn't apply to anything in my for-next
>> tree (it applies to the obsolete 'devel' branch which is rather old
>> now.)
>
> OK, I wasn't aware that devel was obsolete (though I guess if I'd paid
> closer attention to the commit dates I'd have suspected something).
>
> Anyhow, new patch in the tracker as 7115/4 rebased onto for-next.
Thanks, Jamie.
^ permalink raw reply
* Question about "Inconsistent kallsyms data"
From: Arnd Bergmann @ 2011-10-08 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMPhdO80ua0WphKnx3nyBLN7LsUDnDKPX1QbzWEjjfO5t3Uz5Q@mail.gmail.com>
On Saturday 08 October 2011 18:17:49 Eric Miao wrote:
> >
> > To check inconsistencies, the Makefile compares ".tmp_System.map" and
> > "System.map" for differences.
> >
> > On a normal build they should be identical, but if this fails with
> > "Inconsistent kallsyms data" you could try comparing the two files to
> > check which symbols are causing trouble.
>
> I met this issue today as well. Didn't have a chance to compare the
> files, as I did a 'rm -fr ../build' and reconfigured/re-built everything,
> and 'make O=../build clean' didn't work for me.
I can easily reproduce it here, but it's extremely hard to nail
down what is actually going on.
For all I know, this depends on the specific configuration, source
version and gcc version. If you change any of these in any meaningful
way, the problem can go away or reappear. In one case, I've been
able to get to the point where inserting a single 'nop' instruction
in one (any) source file triggered the problem. This happens to be
the point when one of the linker sections grows beyond some power-of-two
boundary.
If anyone wants to reproduce it, I can recommend taking a fast machine
and the for-next+randconfig branch of git://git.linaro.org/people/arnd/arm-soc.git
There is a script called randconfig.sh in it. Remove the KALLSYMS_EXTRA_PASS=1
line from it and run it for some time. After a few hours you will get
multiple configurations for your compiler that show the problem.
I've had one case where even with KALLSYMS_EXTRA_PASS=1 I was still getting
inconsistent kallsyms data. Manually changing the Makefile to do a fourth
run fixed it.
Arnd
^ permalink raw reply
* [PATCH 24/26] ARM: pxa: centro and treo680 need palm27x
From: Marek Vasut @ 2011-10-08 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMPhdO9hTC0_30Oxc+ndn5EstOEMQKa7E_MEf4jn7ipTBbhBfw@mail.gmail.com>
On Saturday, October 08, 2011 12:20:57 PM Eric Miao wrote:
> On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > The two platforms are part of the palm27x family and use the same
> > code. Select the palm27x symbol to make sure they can be built
> > standalone.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Applied.
Thanks Eric.
^ permalink raw reply
* [PATCH v2] pinmux: add a driver for the CSR SiRFprimaII pinmux
From: Barry Song @ 2011-10-08 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbb_5EZHT3=SNePbW-=NYjLSLzJgjEdEaBV7X=s6gxydw@mail.gmail.com>
2011/9/1, Linus Walleij <linus.walleij@linaro.org>:
> On Thu, Sep 1, 2011 at 4:22 AM, Barry Song <Baohua.Song@csr.com> wrote:
>
>> -v2:
>> rebase to Linus W's v5 patch(v5 is still in discussion);
>> add complete pinmux list table;
>> add gpio ranges;
>> replace mask magic number by bitops;
>> rename upmx to spmx
>
> No further comments on this, but now I went in and rewrote
> pinmuxing a bit so that pin groups are a separate concept from
> pinmux (which just refers to a group). Please have a look at
> the U300 driver and see if you can accomodate the changes.
>
> Sorry for the flow of respins but I'm really liking the stuff that
> has come out as a result of Stephen's feedback. Having
> separate groups and functions may look a bit crufty on
> simple pinmuxes but I'm pretty convinced it'll be a win
> for the subsystem when moving to more complex drivers.
>
>> +static const struct sirfsoc_pinmux_func sirfsoc_pinmux_funcs[] = {
>> + {
>> + .name = "lcd_16bits",
>> + .pins = lcd_16bits_pins,
>> + .num_pins = ARRAY_SIZE(lcd_16bits_pins),
>> + .padmux = &lcd_16bits_padmux,
>> + }, {
>> + .name = "lcd_18bits",
>> + .pins = lcd_18bits_pins,
>> + .num_pins = ARRAY_SIZE(lcd_18bits_pins),
>> + .padmux = &lcd_18bits_padmux,
>> + }, {
>
> You can probably simplify this and other things with
> preprocessor macros if you want to, like:
>
> #define SIRF_FUNC_ENTRY(a) \
> { .name = "##a##", .pins = ##a##_pins, .num_pins =
> ARRAY_SIZE(##a##_pins), .padmux = &##a##_padmux }
>
> Then just:
>
> static const struct sirfsoc_pinmux_func sirfsoc_pinmux_funcs[] = {
> SIRF_FUNC_ENTRY(lcd_16bits),
>
>
> The macro syntax is probably wrong, the preprocessor always
> craze me out, but you get the idea.
:-) .name = "##a##" should be changed to .name = #a
#name will convert name into a string "name"
for example,
#define PRINT( n ) printf( #n )
main()
{
PRINT(100);
}
will output 100.
-barry
^ permalink raw reply
* [PATCH 08/26] ARM: pxa: move z2 to generic cpu_suspend
From: Eric Miao @ 2011-10-08 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201110071156.38283.arnd@arndb.de>
On Fri, Oct 7, 2011 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 07 October 2011, Eric Miao wrote:
>> commit 3f7961cbd3428c8639d42d1a51870466e4cbb0eb
>> Author: Eric Miao <eric.y.miao@gmail.com>
>> Date: ? Sun Sep 11 17:19:11 2011 +0800
>>
>> ? ? ARM: pxa/z2: fix building error of pxa27x_cpu_suspend() no longer available
>>
>> ? ? Cc: Vasily Khoruzhick <anarsoul@gmail.com>
>> ? ? Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
>>
>> diff --git a/arch/arm/mach-pxa/z2.c b/arch/arm/mach-pxa/z2.c
>> index 6c9275a..6fa4e74 100644
>> --- a/arch/arm/mach-pxa/z2.c
>> +++ b/arch/arm/mach-pxa/z2.c
>> @@ -679,6 +679,8 @@ static inline void z2_pmic_init(void) {}
>> ?#endif
>>
>> ?#ifdef CONFIG_PM
>> +extern void pxa27x_cpu_pm_enter(suspend_state_t state);
>> +
>> ?static void z2_power_off(void)
>> ?{
>> ? ? ? ? /* We're using deep sleep as poweroff, so clear PSPR to ensure that
>
> You really shouldn't have an extern declaration in a .c file. Otherwise
> looks good to me.
How about this one?
diff --git a/arch/arm/mach-pxa/include/mach/pxa27x.h
b/arch/arm/mach-pxa/include/mach/pxa27x.h
index b9b1bdc..7cff640 100644
--- a/arch/arm/mach-pxa/include/mach/pxa27x.h
+++ b/arch/arm/mach-pxa/include/mach/pxa27x.h
@@ -1,6 +1,7 @@
#ifndef __MACH_PXA27x_H
#define __MACH_PXA27x_H
+#include <linux/suspend.h>
#include <mach/hardware.h>
#include <mach/pxa2xx-regs.h>
#include <mach/mfp-pxa27x.h>
@@ -21,6 +22,7 @@
extern void __init pxa27x_map_io(void);
extern void __init pxa27x_init_irq(void);
extern int __init pxa27x_set_pwrmode(unsigned int mode);
+extern void pxa27x_cpu_pm_enter(suspend_state_t state);
#define pxa27x_handle_irq ichp_handle_irq
diff --git a/arch/arm/mach-pxa/z2.c b/arch/arm/mach-pxa/z2.c
index 6c9275a..a82d420 100644
--- a/arch/arm/mach-pxa/z2.c
+++ b/arch/arm/mach-pxa/z2.c
@@ -686,7 +686,8 @@ static void z2_power_off(void)
*/
PSPR = 0x0;
local_irq_disable();
- pxa27x_cpu_suspend(PWRMODE_DEEPSLEEP, PLAT_PHYS_OFFSET - PAGE_OFFSET);
+ pxa27x_set_pwrmode(PWRMODE_DEEPSLEEP);
+ pxa27x_cpu_pm_enter(PM_SUSPEND_MEM);
}
#else
#define z2_power_off NULL
^ permalink raw reply related
* [PATCH 13/26] ARM: pxa: use correct __iomem annotations
From: Eric Miao @ 2011-10-08 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201110071216.50783.arnd@arndb.de>
On Fri, Oct 7, 2011 at 6:16 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 07 October 2011, Eric Miao wrote:
>> > @@ -18,11 +24,11 @@
>> > ?* peripherals on APB, let's count it into the ABP mapping area.
>> > ?*/
>> > ?#define APB_PHYS_BASE ? ? ? ? ?0xd4000000
>> > -#define APB_VIRT_BASE ? ? ? ? ?0xfe000000
>> > +#define APB_VIRT_BASE ? ? ? ? ?IOMEM(0xfe000000)
>>
>> To be honest, I'd really like to keep the *_VIRT_BASE definitions to be
>> type independent.
>>
>> And have the actual register definitions to be casted to void __iomem *
>> when being defined, e.g.
>>
>> #define APBC_REG(x) ? ? IOMEM(APBC_VIRT_BASE + (x))
>>
>> #define APBC_UART1 ? ? ?APBC_REG(0x000)
>>
>> Arnd, do we have some standard guidelines on this for all SoCs
>> to follow? As I know, it's currently still being a mess.
>
> We don't have any formal guidelines yet, but I'd really love to get
> rid of all the arbitrary type casts to make use of the built-in
> type checking of the compiler and sparse. A virtual base address
> for registers is conventionally an __iomem pointer, so defining it
> as something else is completely bogus. I have started making patches
> for a number of platforms for this.
>
> Ideally we should have very little code directly using, but the fact
> is that they are there and we won't remove them all anytime soon, so
> we should at least use the correct types here.
>
> Another issue that goes together with this is that right now our
> readl/writel macros accept any input type (pointer, __iomem pointer,
> unsigned long, unsigned int), and I have a patch to make that stricter
> but that requires fixing up all the places where we do a
> readl(APBC_VIRT_BASE + x) that Russell mentioned.
>
> The only place where this requires adding extra type casts right now is
> the iotable setup, which I hope we can also fix eventually by splitting
> the static I/O mapping setup from other static mappings (MT_MEMORY,
> MT_MEMORY_NONCACHED, ...).
Sounds fair enough. Applied.
^ permalink raw reply
* [PATCH 08/26] ARM: pxa: move z2 to generic cpu_suspend
From: Arnd Bergmann @ 2011-10-08 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMPhdO97bJZ1FRHUq_VHQ8oHyY7U4ay-jv5Ft+gunRwtBvz8qw@mail.gmail.com>
On Saturday 08 October 2011 20:37:53 Eric Miao wrote:
> >>
> >> #ifdef CONFIG_PM
> >> +extern void pxa27x_cpu_pm_enter(suspend_state_t state);
> >> +
> >> static void z2_power_off(void)
> >> {
> >> /* We're using deep sleep as poweroff, so clear PSPR to ensure that
> >
> > You really shouldn't have an extern declaration in a .c file. Otherwise
> > looks good to me.
>
> How about this one?
Yes, looks good as far as I can tell (I still don't quite understand how the
cpu power management all fits together, but I don't see anything wrong with
it either.
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH 08/26] ARM: pxa: move z2 to generic cpu_suspend
From: Eric Miao @ 2011-10-08 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <14032344.tng7XWeaFg@wuerfel>
On Sat, Oct 8, 2011 at 9:00 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Saturday 08 October 2011 20:37:53 Eric Miao wrote:
>> >>
>> >> ?#ifdef CONFIG_PM
>> >> +extern void pxa27x_cpu_pm_enter(suspend_state_t state);
>> >> +
>> >> ?static void z2_power_off(void)
>> >> ?{
>> >> ? ? ? ? /* We're using deep sleep as poweroff, so clear PSPR to ensure that
>> >
>> > You really shouldn't have an extern declaration in a .c file. Otherwise
>> > looks good to me.
>>
>> How about this one?
>
> Yes, looks good as far as I can tell (I still don't quite understand how the
> cpu power management all fits together, but I don't see anything wrong with
> it either.
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks.
^ permalink raw reply
* [PATCH v2] pinmux: add a driver for the CSR SiRFprimaII pinmux
From: Arnd Bergmann @ 2011-10-08 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4xpYMzHGi09jt2Y9xCocYJ0iHYRfdvwCzcH65uaF2sP0g@mail.gmail.com>
On Saturday 08 October 2011 19:58:23 Barry Song wrote:
> > You can probably simplify this and other things with
> > preprocessor macros if you want to, like:
> >
> > #define SIRF_FUNC_ENTRY(a) \
> > { .name = "##a##", .pins = ##a##_pins, .num_pins =
> > ARRAY_SIZE(##a##_pins), .padmux = &##a##_padmux }
> >
> > Then just:
> >
> > static const struct sirfsoc_pinmux_func sirfsoc_pinmux_funcs[] = {
> > SIRF_FUNC_ENTRY(lcd_16bits),
> >
> >
> > The macro syntax is probably wrong, the preprocessor always
> > craze me out, but you get the idea.
>
> :-) .name = "##a##" should be changed to .name = #a
>
> #name will convert name into a string "name"
>
Better don't use string concatenation at all if you can avoid it.
A generic macro like
#define SIRF_PINMUX(_name, _pins, _padmux) \
{ .name = (_name), .pins = (_pins), \
.num_pins = ARRAY_SIZE(_pins), padmux = (_padmux), }
is both very easy to understand for someone reading it casually and
lets you actually grep for where the identifiers are being used.
> static const struct sirfsoc_pinmux_func sirfsoc_pinmux_funcs[] = {
> SIRF_FUNC_ENTRY(lcd_16bits),
for the first time, you have no clue what that does, but
static const struct sirfsoc_pinmux_func sirfsoc_pinmux_funcs[] = {
SIRF_PINMUX("lcd_16bits", lcd_16bits_pins, &lcd_16bits_padmux),
...
};
Makes it very clear what you are referencing here and needs no extra lines.
Arnd
^ permalink raw reply
* [PATCH 17/26] ARM: pxa: pxa95x is incompatible with earlier pxa
From: Arnd Bergmann @ 2011-10-08 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAN1soZy3_9Trycti8SCbnO75N6NE31tFqrKMpZtiJPgwNc2cbg@mail.gmail.com>
On Saturday 08 October 2011 11:32:14 Haojian Zhuang wrote:
>
> Eric,
>
> At first, a new macro (ARCH_PXA_V7) is defined in
> arch/arm/mach-pxa/Kconfig in this patch.
> I prefer to move this macro to arch/arm/Kconfig.
If we move it to arch/arm/Kconfig, I would prefer making it a global option,
not a pxa specific one. If we introduce a top-level CONFIG_CPU_V6PLUS
option, we can make a number of decisions inside of Kconfig depend on that,
especially as we move to allow building multiple v6/v7 platforms together,
or multiple v5 platforms for that matter. I believe we don't need to
worry about v5+v7 at this point and can instead assume that won't ever
happen.
> Secondly, pxa95x is both used in saarb and tavorevb3.
The patch makes that very explicit, doesn't it?
> Thirdly, PXA_V7_MACH_AUTO is unnecessary. We just need to select those
> machines in defconfig or define a new DT machine type to select all
> machines.
Enabling them in defconfig will not help here, it still allows creating
an invalid configuration by disabling both saarb and tavorevb3.
I agree that it would be best to have a single DT machine type that can
handle both saarb and tavorevb3 as well as any future pxa95x based machines,
but nobody has implemented that yet. In the meantime, I think we should
have the PXA_V7_MACH_AUTO or an equivalent mechanism to enforce that at
least one of the two board files gets built into any kernel. This is mostly
important to help the 'make randconfig' builds succeed, not for actual
users getting it wrong accidentally.
Arnd
^ permalink raw reply
* [PATCH v3 RE-SEND 2/2] iommu/exynos: Add iommu driver for Exynos Platforms
From: KyongHo Cho @ 2011-10-08 13:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E8F6532.9060609@gmail.com>
On Sat, Oct 8, 2011 at 5:46 AM, Sylwester Nawrocki
<sylvester.nawrocki@gmail.com> wrote:
>> -
>> -config S5P_SLEEP
>> - ? ? bool
>> - ? ? help
>> - ? ? ? Internal config node to apply common S5P sleep management code.
>> - ? ? ? Can be selected by S5P and newer SoCs with similar sleep procedure.
>> -
>
> Is S5P_SLEEP being removed intentionally ? It doesn't seem to belong here.
No, it is a mistake while rebasing the patches.
Thank you for pointing that.
^ permalink raw reply
* Serieal console on Samsung S3C6410 ARM11 CPU (Was [ANNOUNCE] 3.0.6-rt17)
From: Thomas Abraham @ 2011-10-08 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201110081326.58731.jbe@pengutronix.de>
Hi Juergen,
On 8 October 2011 16:56, Juergen Beisert <jbe@pengutronix.de> wrote:
> Thomas Gleixner wrote:
>> I'm pleased to announce the 3.0.6-rt17 release.
>
> I have no idea where to search, but when I'm using the 3.0.6-rt17 on my
> Samsung S3C6410 ARM based system, the UART (serial console) does not work as
> expected. Typing only one char at a time is okay. Typing two chars
> immediately makes the system using 100 % CPU load and takes about 2 seconds
> to respond. It seems the interrupt handling is broken in the UART driver, but
> I don't know how to fix it.
>
> This with a simple cursor up (one char to get the last command) and a small
> pause to the next "ENTER" char:
>
> root at mini6410:~ cat /proc/interrupts | grep 18:
> ?18: ? ?5739107 ?s3c-uart ?s3c6400-uart
>
> Same again:
>
> root at mini6410:~ cat /proc/interrupts | grep 18:
> ?18: ? ?5739113 ?s3c-uart ?s3c6400-uart
>
> 6 interrupts seems reasonable.
>
> Now with cursor up and SPACE immediately, then a pause for ENTER:
>
> root at mini6410:~ cat /proc/interrupts | grep 18:
> ?18: ? ?5923815 ?s3c-uart ?s3c6400-uart
>
> 184702 interrupts looks strange.
Just curious, do you have the following two commits?
serial: samsung: Add unified interrupt handler for s3c64xx and later SoC's
ARM: SAMSUNG: Remove uart irq handling from platform code
Thanks,
Thomas.
^ permalink raw reply
* [PATCH 0/3] GIC OF bindings
From: Thomas Abraham @ 2011-10-08 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317410880-24828-1-git-send-email-robherring2@gmail.com>
On 1 October 2011 00:57, Rob Herring <robherring2@gmail.com> wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> Another round of GIC devicetree support.
>
> This moves the tracking of the starting hwirq number into the irq domain
> code. Doing this makes hwirq == GIC interrupt ID and simplifies the GIC
> code removing irq_offset.
>
> The full series is available here. This includes Russell's devel-stable and
> for-next branches and Nico's vmalloc branch:
>
> git://git.jdl.com/software/linux-3.0.git gic-v2
>
> Tested on highbank and Realview 11MPCore qemu (2 GICs).
>
> Rob
>
> Rob Herring (3):
> ?irq: support domains with non-zero hwirq base
> ?ARM: gic: add irq_domain support
> ?ARM: gic: add OF based initialization
For Exynos4 GIC and Interrupt Combiner Controllers:
Tested-by: Thomas Abraham <thomas.abraham@linaro.org>
>
> ?Documentation/devicetree/bindings/arm/gic.txt | ? 55 ++++++++++
> ?arch/arm/common/Kconfig ? ? ? ? ? ? ? ? ? ? ? | ? ?1 +
> ?arch/arm/common/gic.c ? ? ? ? ? ? ? ? ? ? ? ? | ?142 +++++++++++++++++++------
> ?arch/arm/include/asm/hardware/gic.h ? ? ? ? ? | ? ?5 +-
> ?include/linux/irqdomain.h ? ? ? ? ? ? ? ? ? ? | ? 16 +++-
> ?kernel/irq/irqdomain.c ? ? ? ? ? ? ? ? ? ? ? ?| ? 12 +-
> ?6 files changed, 189 insertions(+), 42 deletions(-)
> ?create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>
> --
> 1.7.5.4
>
>
^ permalink raw reply
* [PATCH V2 1/2] ARM: S3C2410: Add __init attribute to usb_simtec_init()
From: Sergei Shtylyov @ 2011-10-08 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317988513-20800-2-git-send-email-tushar.behera@linaro.org>
Hello.
On 07-10-2011 15:55, Tushar Behera wrote:
> usb_simtec_init() references s3c_ohci_set_platdata() which is defined
> with __init attribute. Hence to remove section mismatch warning, __init
> attribute is added to usb_simtec_init().
> It removes following two warnigs.
> WARNING: vmlinux.o(.text+0x1460c): Section mismatch in reference from
> the function usb_simtec_init() to the function
> .init.text:s3c_ohci_set_platdata()
> The function usb_simtec_init() references the function
> __init s3c_ohci_set_platdata().
> WARNING: vmlinux.o(.text+0x14650): Section mismatch in reference from
> the function usb_simtec_init() to the (unknown reference)
> .init.data:(unknown)
> The function usb_simtec_init() references the (unknown reference)
> __initdata (unknown).
> Signed-off-by: Tushar Behera<tushar.behera@linaro.org>
[...]
> diff --git a/arch/arm/mach-s3c2410/usb-simtec.h b/arch/arm/mach-s3c2410/usb-simtec.h
> index 03842ed..43cc88f 100644
> --- a/arch/arm/mach-s3c2410/usb-simtec.h
> +++ b/arch/arm/mach-s3c2410/usb-simtec.h
> @@ -12,5 +12,5 @@
> * published by the Free Software Foundation.
> */
>
> -extern int usb_simtec_init(void);
> +extern int __init usb_simtec_init(void);
Function prototypes don't need to be annotated with __init.
WBR, Sergei
^ permalink raw reply
* [PATCH] ARM: kprobes: work around build errors
From: Arnd Bergmann @ 2011-10-08 15:07 UTC (permalink / raw)
To: linux-arm-kernel
I got a few build errors for kprobes playing with randconfig on the
latest kernel. While this patch manages to avoid these errors, I'm
pretty sure that it is not the ideal solution.
The errors I got in arm are while building for ARMv6 with
the arm-linux-gnueabihf-gcc-4.6 provided by Linaro, which
results in these messages:
/tmp/ccGpftnj.s: Assembler messages:
/tmp/ccGpftnj.s:22066: Error: selected processor does not support ARM mode `mls r0,r1,r2,r3'
/tmp/ccGpftnj.s:22099: Error: selected processor does not support ARM mode `mlshi r7,r8,r9,r10'
/tmp/ccGpftnj.s:22128: Error: selected processor does not support ARM mode `mls lr,r1,r2,r13'
/tmp/ccGpftnj.s:23781: Error: selected processor does not support ARM mode `strexd r0,r2,r3,[sp]'
/tmp/ccGpftnj.s:23802: Error: selected processor does not support ARM mode `ldrexd r2,r3,[sp]'
/tmp/ccGpftnj.s:23823: Error: selected processor does not support ARM mode `strexb r0,r2,[sp]'
/tmp/ccGpftnj.s:23844: Error: selected processor does not support ARM mode `ldrexb r2,[sp]'
/tmp/ccGpftnj.s:23865: Error: selected processor does not support ARM mode `strexh r0,r2,[sp]'
/tmp/ccGpftnj.s:23886: Error: selected processor does not support ARM mode `ldrexh r2,[sp]'
/tmp/ccGpftnj.s:25836: Warning: base register written back, and overlaps second transfer register
The errors for the thumb variant are using the same tool
chain, but obviously in v7 thumb2 mode. The error I got
is
/tmp/cczp95OW.s:18721: Error: offset out of range
Reducing the amount of padding in the "TEST_BF_X("bpl.w 2f",0x1000)"
test case resolves this, and I experimentally found 0xe20 to be the
maximum value in this location, but that is different if I change the
surrounding code. This one is much harder to reproduce and I can
provide the configuration file I used if that helps.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/arch/arm/kernel/kprobes-test-arm.c b/arch/arm/kernel/kprobes-test-arm.c
index fc82de8..ba9c600 100644
--- a/arch/arm/kernel/kprobes-test-arm.c
+++ b/arch/arm/kernel/kprobes-test-arm.c
@@ -367,9 +367,11 @@ void kprobe_arm_test_cases(void)
TEST_UNSUPPORTED(".word 0xe0500090 @ undef")
TEST_UNSUPPORTED(".word 0xe05fff9f @ undef")
+#if __LINUX_ARM_ARCH__ >= 7
TEST_RRR( "mls r0, r",1, VAL1,", r",2, VAL2,", r",3, VAL3,"")
TEST_RRR( "mlshi r7, r",8, VAL3,", r",9, VAL1,", r",10, VAL2,"")
TEST_RR( "mls lr, r",1, VAL2,", r",2, VAL3,", r13")
+#endif
TEST_UNSUPPORTED(".word 0xe06f3291 @ mls pc, r1, r2, r3")
TEST_UNSUPPORTED(".word 0xe060329f @ mls r0, pc, r2, r3")
TEST_UNSUPPORTED(".word 0xe0603f91 @ mls r0, r1, pc, r3")
@@ -447,7 +449,7 @@ void kprobe_arm_test_cases(void)
TEST_UNSUPPORTED(".word 0xe1500090") /* Unallocated space */
TEST_UNSUPPORTED(".word 0xe1600090") /* Unallocated space */
TEST_UNSUPPORTED(".word 0xe1700090") /* Unallocated space */
-#if __LINUX_ARM_ARCH__ >= 6
+#if __LINUX_ARM_ARCH__ >= 7
TEST_UNSUPPORTED("ldrex r2, [sp]")
TEST_UNSUPPORTED("strexd r0, r2, r3, [sp]")
TEST_UNSUPPORTED("ldrexd r2, r3, [sp]")
diff --git a/arch/arm/kernel/kprobes-test-thumb.c b/arch/arm/kernel/kprobes-test-thumb.c
index 5e726c3..bcf5e6b 100644
--- a/arch/arm/kernel/kprobes-test-thumb.c
+++ b/arch/arm/kernel/kprobes-test-thumb.c
@@ -746,7 +746,7 @@ CONDITION_INSTRUCTIONS(22,
TEST_BB("bne.w 2b")
TEST_BF("bgt.w 2f")
TEST_BB("blt.w 2b")
- TEST_BF_X("bpl.w 2f",0x1000)
+ TEST_BF_X("bpl.w 2f",0xe20)
)
TEST_UNSUPPORTED("msr cpsr, r0")
^ permalink raw reply related
* [PULL] i.MX
From: Arnd Bergmann @ 2011-10-08 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111008101322.GH31404@pengutronix.de>
Hi Sascha,
I've found a few new build errors using randconfig after pulling the
i.MX tree, here are the patches I did to resolve them. If you agree
with the patches, just send me an Ack and I'll add them on top.
If you have a better solution for any of them, please send me another
pull request.
Arnd
^ permalink raw reply
* [PATCH 1/3] ARM: imx: always select CACHE_L2X0 on i.MX3
From: Arnd Bergmann @ 2011-10-08 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <109850802.HMOqKGRdrl@wuerfel>
The i.MX3 and i.MX35 files unconditionally call the l2x0_init
function, so we should make sure that this is built into the
kernel.
arch/arm/mach-imx/built-in.o: In function `imx3_init_l2x0':
mm-imx3.c:(.text+0x154): undefined reference to `l2x0_init'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mach-imx/Kconfig | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 6c12836..3de9ac9 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -64,6 +64,7 @@ config SOC_IMX31
select ARCH_MXC_AUDMUX_V2
select ARCH_MX31
select MXC_AVIC
+ select CACHE_L2X0
config SOC_IMX35
bool
@@ -73,7 +74,7 @@ config SOC_IMX35
select HAVE_EPIT
select ARCH_MX35
select MXC_AVIC
-
+ select CACHE_L2X0
if ARCH_IMX_V4_V5
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/3] ARM: imx: add missing include of linux/ftrace.h
From: Arnd Bergmann @ 2011-10-08 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <109850802.HMOqKGRdrl@wuerfel>
Using the __exception_irq_entry symbol requires including
this header file:
arch/arm/plat-mxc/avic.c:154:39: error: expected '=', ',', ';', 'asm'
or '__attribute__' before 'avic_handle_irq'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/plat-mxc/avic.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-mxc/avic.c b/arch/arm/plat-mxc/avic.c
index 8875fb4..9bab263 100644
--- a/arch/arm/plat-mxc/avic.c
+++ b/arch/arm/plat-mxc/avic.c
@@ -20,6 +20,7 @@
#include <linux/module.h>
#include <linux/irq.h>
#include <linux/io.h>
+#include <linux/ftrace.h>
#include <mach/common.h>
#include <asm/mach/irq.h>
#include <mach/hardware.h>
--
1.7.5.4
^ permalink raw reply related
* [PATCH 3/7] ARM: imx: export imx_ioremap
From: Arnd Bergmann @ 2011-10-08 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <109850802.HMOqKGRdrl@wuerfel>
The arch_ioremap function on i.MX is now an indirect function pointer.
In order to use it from any loadable module, the pointer itself
has to be exported.
ERROR: "imx_ioremap" [drivers/video/tmiofb.ko] undefined!
ERROR: "imx_ioremap" [drivers/usb/host/sl811-hcd.ko] undefined!
ERROR: "imx_ioremap" [drivers/usb/host/r8a66597-hcd.ko] undefined!
ERROR: "imx_ioremap" [drivers/usb/host/oxu210hp-hcd.ko] undefined!
ERROR: "imx_ioremap" [drivers/usb/gadget/r8a66597-udc.ko] undefined!
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/plat-mxc/system.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-mxc/system.c b/arch/arm/plat-mxc/system.c
index 9dad8dc..45e1b5f 100644
--- a/arch/arm/plat-mxc/system.c
+++ b/arch/arm/plat-mxc/system.c
@@ -21,6 +21,7 @@
#include <linux/io.h>
#include <linux/err.h>
#include <linux/delay.h>
+#include <linux/module.h>
#include <mach/hardware.h>
#include <mach/common.h>
@@ -30,6 +31,7 @@
void (*imx_idle)(void) = NULL;
void __iomem *(*imx_ioremap)(unsigned long, size_t, unsigned int) = NULL;
+EXPORT_SYMBOL_GPL(imx_ioremap);
static void __iomem *wdog_base;
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/2] [ARM] mach-types: Re-add apf9328
From: Gwenhael Goavec-Merou @ 2011-10-08 15:19 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com>
---
arch/arm/tools/mach-types | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/tools/mach-types b/arch/arm/tools/mach-types
index fff68d0..07811a7 100644
--- a/arch/arm/tools/mach-types
+++ b/arch/arm/tools/mach-types
@@ -188,6 +188,7 @@ omap_2430sdp MACH_OMAP_2430SDP OMAP_2430SDP 900
davinci_evm MACH_DAVINCI_EVM DAVINCI_EVM 901
palmz72 MACH_PALMZ72 PALMZ72 904
nxdb500 MACH_NXDB500 NXDB500 905
+apf9328 MACH_APF9328 APF9328 906
palmt5 MACH_PALMT5 PALMT5 917
palmtc MACH_PALMTC PALMTC 918
omap_apollon MACH_OMAP_APOLLON OMAP_APOLLON 919
--
1.7.3.4
^ permalink raw reply related
* [PATCH 2/2] [ARM] MX1:apf9328: Add i2c support
From: Gwenhael Goavec-Merou @ 2011-10-08 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318087189-22977-1-git-send-email-gwenhael.goavec-merou@armadeus.com>
Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com>
---
arch/arm/mach-imx/Kconfig | 1 +
arch/arm/mach-imx/mach-apf9328.c | 10 ++++++++++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 4792fd5..0e89395 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -99,6 +99,7 @@ config MACH_SCB9328
config MACH_APF9328
bool "APF9328"
select SOC_IMX1
+ select IMX_HAVE_PLATFORM_IMX_I2C
select IMX_HAVE_PLATFORM_IMX_UART
help
Say Yes here if you are using the Armadeus APF9328 development board
diff --git a/arch/arm/mach-imx/mach-apf9328.c b/arch/arm/mach-imx/mach-apf9328.c
index a404c89..f60e2b4 100644
--- a/arch/arm/mach-imx/mach-apf9328.c
+++ b/arch/arm/mach-imx/mach-apf9328.c
@@ -18,6 +18,7 @@
#include <linux/platform_device.h>
#include <linux/mtd/physmap.h>
#include <linux/dm9000.h>
+#include <linux/i2c.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -41,6 +42,9 @@ static const int apf9328_pins[] __initconst = {
PB29_PF_UART2_RTS,
PB30_PF_UART2_TXD,
PB31_PF_UART2_RXD,
+ /* I2C */
+ PA15_PF_I2C_SDA,
+ PA16_PF_I2C_SCL,
};
/*
@@ -103,6 +107,10 @@ static const struct imxuart_platform_data uart1_pdata __initconst = {
.flags = IMXUART_HAVE_RTSCTS,
};
+static const struct imxi2c_platform_data apf9328_i2c_data __initconst = {
+ .bitrate = 100000,
+};
+
static struct platform_device *devices[] __initdata = {
&apf9328_flash_device,
&dm9000x_device,
@@ -119,6 +127,8 @@ static void __init apf9328_init(void)
imx1_add_imx_uart0(NULL);
imx1_add_imx_uart1(&uart1_pdata);
+ imx1_add_imx_i2c(&apf9328_i2c_data);
+
platform_add_devices(devices, ARRAY_SIZE(devices));
}
--
1.7.3.4
^ 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