* Re: Patches added to powerpc.git master and powerpc-next branches
From: Kumar Gala @ 2008-04-21 17:51 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18441.58154.608911.337978@cargo.ozlabs.ibm.com>
On Apr 19, 2008, at 7:18 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> [POWERPC] 85xx: Add support for relocatble kernel (and booting at
>> non-
>> zero)
>
> Should be OK to go though probably not in the first batch. I want to
> look through it carefully again since it's touching code that is
> common to a lot of platforms. The patch description looks reasonable
> as to what it explains but the english could use a touch-up here or
> there (e.g. "a physical address that is module 256M" doesn't actually
> mean anything; "a physical address that is 0 modulo 256M" would be
> correct).
Ok. I'll have my grammar police review it and repost.
>> [POWERPC] Port fixmap from x86 and use for kmap_atomic
>
> Once again I want to go through it carefully and understand how it all
> works, and in particular understand things like the way it ensures
> that the base address for the kmap region is aligned to a 4M boundary
> so all the kmap ptes are in a single page (assuming it does :).
I'm not clear on why this is needed. I can see value in having the
PGD entry in place but the pte PAs would be changing all the time so I
don't see what benefit there is in keeping them in one page.
For normal kmap ptes we cover things in one PGD via:
#define PKMAP_BASE ((FIXADDR_BOOT_START - PAGE_SIZE*(LAST_PKMAP +
1)) & PMD_MASK)
The kmap_atomic ptes do NOT have a similar guarantee as they are
controlled via fixmap. However we do "pre-allocate" the PGD via
calling map_page() on all fixmap addresses.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] Port fixmap from x86 and use for kmap_atomic
From: Kumar Gala @ 2008-04-21 17:44 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20080419110740.107700@gmx.net>
On Apr 19, 2008, at 6:07 AM, Gerhard Pircher wrote:
>
> -------- Original-Nachricht --------
>> Datum: Thu, 17 Apr 2008 21:57:05 -0500 (CDT)
>> Von: Kumar Gala <galak@kernel.crashing.org>
>> An: Paul Mackerras <paulus@samba.org>
>> CC: linuxppc-dev@ozlabs.org
>> Betreff: [PATCH] [POWERPC] Port fixmap from x86 and use for
>> kmap_atomic
>
>> The fixmap code from x86 allows us to have compile time virtual
>> addresses
>> that we change the physical addresses of at run time.
> ...
>> +/*
>> + * Here we define all the compile-time 'special' virtual
>> + * addresses. The point is to have a constant address at
>> + * compile time, but to set the physical address only
>> + * in the boot process. We allocate these special addresses
>> + * from the end of virtual memory (0xfffff000) backwards.
>> + * Also this lets us do fail-safe vmalloc(), we
>> + * can guarantee that these special addresses and
>> + * vmalloc()-ed addresses never overlap.
> I don't understand how highmem works, but I'm just interested to
> know, if
> this implementation could conflict somehow with the non coherent DMA
> implementation in dma-noncoherent.c (which uses address space from
> 0xff100000 to 0xff300000 for DMA memory).
if the size is fixed we can easily change it so the Kconfig options
aren't needed anymore.
> On the other side could dma-noncoherent.c benefit from fixmaps so
> that it
> isn't necessary to configure a start address for DMA allocations?
Its possible however the fixmap is all about keeping the VA the same
while changing the PA. I think some work that is being done for the SW
IOMMU might be more useful to your needs.
- k
^ permalink raw reply
* [PATCH 2/2 v2] sysdev,mv64x60: initialization of mv64x60 ethernet, serial and I2C
From: Remi Machet @ 2008-04-21 17:37 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
If one of the devices of the mv64x60 init fails, the remaining
devices are not initialized => This patch change the code to
display an error and continue the initialization.
Signed-off-by: Remi Machet (rmachet@slac.stanford.edu)
---
This is the second part of the re-submission of my patch of 4/17/2008
titled "[PATCH] sysdev,mv64x60: initialization of mv64x60 ethernet,
serial and I2C"
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -431,9 +431,14 @@ static int __init mv64x60_device_setup(void)
int err;
id = 0;
- for_each_compatible_node(np, "serial", "marvell,mv64360-mpsc")
- if ((err = mv64x60_mpsc_device_setup(np, id++)))
- goto error;
+ for_each_compatible_node(np, "serial", "marvell,mv64360-mpsc") {
+ err = mv64x60_mpsc_device_setup(np, id++);
+ if (err) {
+ printk(KERN_ERR "Failed to initialize MV64x60 " \
+ "serial device %s: error %d.\n",
+ np->full_name, err);
+ };
+ };
id = 0;
id2 = 0;
@@ -441,38 +446,46 @@ static int __init mv64x60_device_setup(void)
pdev = mv64x60_eth_register_shared_pdev(np, id++);
if (IS_ERR(pdev)) {
err = PTR_ERR(pdev);
- goto error;
- }
+ printk(KERN_ERR "Failed to initialize MV64x60 " \
+ "network block %s: error %d.\n",
+ np->full_name, err);
+ continue;
+ };
for_each_child_of_node(np, np2) {
if (!of_device_is_compatible(np2,
"marvell,mv64360-eth"))
continue;
err = mv64x60_eth_device_setup(np2, id2++, pdev);
if (err) {
- of_node_put(np2);
- goto error;
+ printk(KERN_ERR "Failed to initialize " \
+ "MV64x60 network device %s: " \
+ "error %d.\n",
+ np2->full_name, err);
}
}
}
id = 0;
- for_each_compatible_node(np, "i2c", "marvell,mv64360-i2c")
- if ((err = mv64x60_i2c_device_setup(np, id++)))
- goto error;
+ for_each_compatible_node(np, "i2c", "marvell,mv64360-i2c") {
+ err = mv64x60_i2c_device_setup(np, id++);
+ if (err) {
+ printk(KERN_ERR "Failed to initialize MV64x60 I2C " \
+ "bus %s: error %d.\n",
+ np->full_name, err);
+ };
+ };
/* support up to one watchdog timer */
np = of_find_compatible_node(np, NULL, "marvell,mv64360-wdt");
if (np) {
if ((err = mv64x60_wdt_device_setup(np, id)))
- goto error;
+ printk(KERN_ERR "Failed to initialize MV64x60 " \
+ "Watchdog %s: error %d.\n",
+ np->full_name, err);
of_node_put(np);
}
return 0;
-
-error:
- of_node_put(np);
- return err;
}
arch_initcall(mv64x60_device_setup);
^ permalink raw reply
* [PATCH 1/2 v2] sysdev,mv64x60: I2C defaults
From: Remi Machet @ 2008-04-21 17:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
I2C parameters freq_m and freq_n are assigned default in the code
but if those properties are not found in the open firmware description
the init returns an error => the code now uses the default
values if the properties are not found.
Signed-off-by: Remi Machet (rmachet@slac.stanford.edu)
---
This is the first part of the re-submission of my patch of 4/17/2008
titled "[PATCH] sysdev,mv64x60: initialization of mv64x60 ethernet,
serial and I2C"
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -338,15 +338,13 @@ static int __init mv64x60_i2c_device_setup(struct device_node *np, int id)
pdata.freq_m = 8; /* default */
prop = of_get_property(np, "freq_m", NULL);
- if (!prop)
- return -ENODEV;
- pdata.freq_m = *prop;
+ if (prop)
+ pdata.freq_m = *prop;
pdata.freq_m = 3; /* default */
prop = of_get_property(np, "freq_n", NULL);
- if (!prop)
- return -ENODEV;
- pdata.freq_n = *prop;
+ if (prop)
+ pdata.freq_n = *prop;
pdata.timeout = 1000; /* default: 1 second */
^ permalink raw reply
* Re: Help! mpc8247 porting kernel 2.6.25 problem.
From: Scott Wood @ 2008-04-21 17:34 UTC (permalink / raw)
To: 张世乐; +Cc: Linuxppc-embedded
In-Reply-To: <8d59c9040804202006m607fe15bre29288240b73081d@mail.gmail.com>
On Mon, Apr 21, 2008 at 11:06:28AM +0800, 张世乐 wrote:
> Uncompressing Kernel Image ... OK
> Booting using the fdt at 0x600000
>
> [nothing output and hanging here]
>
> I use the led on the board to trace the kernel fund it stop in the function
>
> setup_common_caches in arch/powerpc/kernel/cpu_setup_6xx.S
>
> Can you give me some ideas?
That's probably not where it's actually stopping, but rather where caches
are enabled without the MMU, thus making it difficult to access devices.
You can try placing a dcbf after each write to the LED register, though
this may perturb nearby registers.
Have you tried enabling early debug printk?
-Scott
^ permalink raw reply
* Re: RFC: Possible section mismatch problem in ibm_newemac?
From: Josh Boyer @ 2008-04-21 17:05 UTC (permalink / raw)
To: Steven A. Falco; +Cc: linuxppc-dev
In-Reply-To: <480CBA91.5050003@harris.com>
On Mon, 21 Apr 2008 12:02:25 -0400
"Steven A. Falco" <sfalco@harris.com> wrote:
> I am using a recent DENX git tree. I want to enable debugging in prom_parse.c.
> When I do that, I see link warnings like:
I already sent a patch a month and a half ago to clean all these
warnings up. It never got pushed upstream.
josh
^ permalink raw reply
* Re: RFC: MPC5200 PSC AC97 driver
From: Matt Sealey @ 2008-04-21 17:04 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-dev
In-Reply-To: <200804211002.07452.jbe@pengutronix.de>
Juergen Beisert wrote:
> Please don't forget what Sylvian said about this driver: "I also completely
> skipped the 5200 (not B) support ..." and your own "I think it should be left
> noted here that the CCR size changed from 16 bits to 32 bits from 5200 to
> 5200B in order to reduce confusion.". Its not solved yet. So any user of an
> old MPC5200 will be surprised...
+static struct of_device_id mpc52xx_ac97_of_match[] = {
+ {
+ .type = "sound",
+ .compatible = "mpc5200b-psc-ac97", /* B only for now */
+ },
+};
It shouldn't even load, the matchlist is 5200b only..? No alarms and no surprises.. :)
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH] [POWERPC] 52xx: defconfigs for CM5200, Lite5200B, Motion-PRO and TQM5200
From: Grant Likely @ 2008-04-21 16:58 UTC (permalink / raw)
To: Bartlomiej Sieka; +Cc: linuxppc-dev
In-Reply-To: <480CC6F9.3050700@semihalf.com>
On Mon, Apr 21, 2008 at 10:55 AM, Bartlomiej Sieka <tur@semihalf.com> wrote:
> Grant Likely wrote:
>
> > On Mon, Apr 21, 2008 at 7:57 AM, Bartlomiej Sieka <tur@semihalf.com>
> wrote:
> >
> > > Bartlomiej Sieka wrote:
> > >
> > >
> > > > Board-specific defconfigs based on current mpc5200_defconfig, archival
> > > > lite5200_defconfig, and [cm5200|motionpro|tqm5200]_defconfig from the
> > > > linux-2.6-denx tree. Kernels build using these defconfigs were
> verified
> > > > to boot with root filesystem mounted over NFS on Motion-PRO, TQM5200
> > > > and Lite5200B boards. CM5200 target was not tested due to hardware
> > > > unavailability.
> > > >
> > > >
> > > Hello Grant,
> > >
> > > There hasn't been any negitve comments on the above patch -- will you
> > > push it upstream via your tree?
> > >
> >
> > Yes, of course.
> >
>
> Thanks -- is it safe to assume that the patch will make it into 2.6.26
> then?
Yes; defconfigs are easy to get merged.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] [POWERPC] 52xx: defconfigs for CM5200, Lite5200B, Motion-PRO and TQM5200
From: Bartlomiej Sieka @ 2008-04-21 16:55 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40804210726w3e8f4647mbc3dad8e48a124c0@mail.gmail.com>
Grant Likely wrote:
> On Mon, Apr 21, 2008 at 7:57 AM, Bartlomiej Sieka <tur@semihalf.com> wrote:
>> Bartlomiej Sieka wrote:
>>
>>> Board-specific defconfigs based on current mpc5200_defconfig, archival
>>> lite5200_defconfig, and [cm5200|motionpro|tqm5200]_defconfig from the
>>> linux-2.6-denx tree. Kernels build using these defconfigs were verified
>>> to boot with root filesystem mounted over NFS on Motion-PRO, TQM5200
>>> and Lite5200B boards. CM5200 target was not tested due to hardware
>>> unavailability.
>>>
>> Hello Grant,
>>
>> There hasn't been any negitve comments on the above patch -- will you
>> push it upstream via your tree?
>
> Yes, of course.
Thanks -- is it safe to assume that the patch will make it into 2.6.26 then?
Regards,
Bartlomiej
^ permalink raw reply
* [PATCH] Added device tree for media5200 evaluation board
From: Steven Cavanagh @ 2008-04-21 15:14 UTC (permalink / raw)
To: linuxppc-embedded
Added the media5200 device tree to support the
Freescale media5200. Added board configuration
under PPC_LITE5200
Signed-off-by: Steven Cavanagh <scavanagh@secretlab.ca>
---
arch/powerpc/boot/Makefile | 1
arch/powerpc/boot/dts/media5200.dts | 277 ++++++++++++++++++++++++++
arch/powerpc/platforms/52xx/Kconfig | 3
arch/powerpc/platforms/52xx/mpc5200_simple.c | 1
4 files changed, 281 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index f2e9abe..22cb470 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -227,6 +227,7 @@ image-$(CONFIG_PPC_ADDER875) += cuImage.adder875-uboot \
# Board ports in arch/powerpc/platform/52xx/Kconfig
image-$(CONFIG_PPC_LITE5200) += cuImage.lite5200 cuImage.lite5200b
image-$(CONFIG_PPC_GDC_CSB) += cuImage.gdc-csb gdc-csb.dtb
+image-$(CONFIG_PPC_MPC5200_SIMPLE) += cuImage.media5200
# Board ports in arch/powerpc/platform/82xx/Kconfig
image-$(CONFIG_MPC8272_ADS) += cuImage.mpc8272ads
diff --git a/arch/powerpc/boot/dts/media5200.dts b/arch/powerpc/boot/dts/media5200.dts
new file mode 100644
index 0000000..59207e1
--- /dev/null
+++ b/arch/powerpc/boot/dts/media5200.dts
@@ -0,0 +1,277 @@
+/*
+ * Freescale Media5200 board Device Tree Source
+ *
+ * Copyright 2008 Secret Lab Technologies Ltd.
+ * Grant Likely <grant.likely@secretlab.ca>
+ * Steven Cavanagh <scavanagh@secretlab.ca>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+ model = "fsl,media5200";
+ compatible = "fsl,media5200";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ aliases {
+ console = &console;
+ ethernet0 = ð0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,5200@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <32>;
+ i-cache-line-size = <32>;
+ d-cache-size = <0x4000>; // L1, 16K
+ i-cache-size = <0x4000>; // L1, 16K
+ timebase-frequency = <0x1f78a40>; // 33 MHz
+ bus-frequency = <0x7de2900>; // 132 MHz
+ clock-frequency = <0x179a7b00>; // 396 MHz
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0x8000000>; // 128MB
+ };
+
+ soc@f0000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc5200b-immr";
+ ranges = <0 0xf0000000 0xc000>;
+ reg = <0xf0000000 0x100>;
+ bus-frequency = <0x7de2900>;// 132 MHz
+ system-frequency = <0>; // from bootloader
+
+ cdm@200 {
+ compatible = "fsl,mpc5200b-cdm","fsl,mpc5200-cdm";
+ reg = <0x200 0x38>;
+ };
+
+ mpc5200_pic: interrupt-controller@500 {
+ // 5200 interrupts are encoded into two levels;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ device_type = "interrupt-controller";
+ compatible = "fsl,mpc5200b-pic","fsl,mpc5200-pic";
+ reg = <0x500 0x80>;
+ };
+
+ timer@600 { // General Purpose Timer
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
+ cell-index = <0>;
+ reg = <0x600 0x10>;
+ interrupts = <1 9 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ fsl,has-wdt;
+ };
+
+ timer@610 { // General Purpose Timer
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
+ cell-index = <1>;
+ reg = <0x610 0x10>;
+ interrupts = <1 10 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ };
+
+ timer@620 { // General Purpose Timer
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
+ cell-index = <2>;
+ reg = <0x620 0x10>;
+ interrupts = <1 11 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ };
+
+ timer@630 { // General Purpose Timer
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
+ cell-index = <3>;
+ reg = <0x630 0x10>;
+ interrupts = <1 12 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ };
+
+ timer@640 { // General Purpose Timer
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
+ cell-index = <4>;
+ reg = <0x640 0x10>;
+ interrupts = <1 13 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ };
+
+ timer@650 { // General Purpose Timer
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
+ cell-index = <5>;
+ reg = <0x650 0x10>;
+ interrupts = <1 14 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ };
+
+ timer@660 { // General Purpose Timer
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
+ cell-index = <6>;
+ reg = <0x660 0x10>;
+ interrupts = <1 15 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ };
+
+ timer@670 { // General Purpose Timer
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
+ cell-index = <7>;
+ reg = <0x670 0x10>;
+ interrupts = <1 16 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ };
+
+ rtc@800 { // Real time clock
+ compatible = "fsl,mpc5200b-rtc","fsl,mpc5200-rtc";
+ device_type = "rtc";
+ reg = <0x800 0x100>;
+ interrupts = <1 5 0 1 6 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ };
+
+ can@900 {
+ compatible = "fsl,mpc5200b-mscan","fsl,mpc5200-mscan";
+ cell-index = <0>;
+ interrupts = <2 17 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ reg = <0x900 0x80>;
+ };
+
+ can@980 {
+ compatible = "fsl,mpc5200b-mscan","fsl,mpc5200-mscan";
+ cell-index = <1>;
+ interrupts = <2 18 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ reg = <0x980 0x80>;
+ };
+
+ gpio@b00 {
+ compatible = "fsl,mpc5200b-gpio","fsl,mpc5200-gpio";
+ reg = <0xb00 0x40>;
+ interrupts = <1 7 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ };
+
+ gpio@c00 {
+ compatible = "fsl,mpc5200b-gpio-wkup","fsl,mpc5200-gpio-wkup";
+ reg = <0xc00 0x40>;
+ interrupts = <1 8 0 0 3 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ };
+
+ spi@f00 {
+ compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
+ reg = <0xf00 0x20>;
+ interrupts = <2 13 0 2 14 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ };
+
+ usb@1000 {
+ compatible = "fsl,mpc5200b-ohci","fsl,mpc5200-ohci","ohci-be";
+ reg = <0x1000 0x100>;
+ interrupts = <2 6 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ };
+
+ dma-controller@1200 {
+ device_type = "dma-controller";
+ compatible = "fsl,mpc5200b-bestcomm","fsl,mpc5200-bestcomm";
+ reg = <0x1200 0x80>;
+ interrupts = <3 0 0 3 1 0 3 2 0 3 3 0
+ 3 4 0 3 5 0 3 6 0 3 7 0
+ 3 8 0 3 9 0 3 10 0 3 11 0
+ 3 12 0 3 13 0 3 14 0 3 15 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ };
+
+ xlb@1f00 {
+ compatible = "fsl,mpc5200b-xlb","fsl,mpc5200-xlb";
+ reg = <0x1f00 0x100>;
+ };
+
+ // PSC6 in uart mode
+ console: serial@2c00 { // PSC6
+ device_type = "serial";
+ compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
+ cell-index = <5>;
+ port-number = <0>; // Logical port assignment
+ reg = <0x2c00 0x100>;
+ interrupts = <2 4 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ };
+
+ eth0: ethernet@3000 {
+ device_type = "network";
+ compatible = "fsl,mpc5200b-fec","fsl,mpc5200-fec";
+ reg = <0x3000 0x400>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <2 5 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ phy-handle = <&phy0>;
+ };
+
+ mdio@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5200b-mdio", "fsl,mpc5200-mdio";
+ reg = <0x3000 0x400>; // fec range, since we need to setup fec interrupts
+ interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
+ interrupt-parent = <&mpc5200_pic>;
+
+ phy0:ethernet-phy@0 {
+ device_type = "ethernet-phy";
+ reg = <0>;
+ };
+ };
+
+ ata@3a00 {
+ device_type = "ata";
+ compatible = "fsl,mpc5200b-ata","fsl,mpc5200-ata";
+ reg = <0x3a00 0x100>;
+ interrupts = <2 7 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ };
+
+ i2c@3d00 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
+ cell-index = <0>;
+ reg = <0x3d00 0x40>;
+ interrupts = <2 15 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ fsl5200-clocking;
+ };
+
+ i2c@3d40 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
+ cell-index = <1>;
+ reg = <0x3d40 0x40>;
+ interrupts = <2 16 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ fsl5200-clocking;
+ };
+ sram@8000 {
+ compatible = "fsl,mpc5200b-sram","fsl,mpc5200-sram","sram";
+ reg = <0x8000 0x4000>;
+ };
+ };
+
+ chosen {
+ linux,stdout-path = &console;
+ };
+};
diff --git a/arch/powerpc/platforms/52xx/Kconfig b/arch/powerpc/platforms/52xx/Kconfig
index a0636d4..1914650 100644
--- a/arch/powerpc/platforms/52xx/Kconfig
+++ b/arch/powerpc/platforms/52xx/Kconfig
@@ -21,7 +21,8 @@ config PPC_MPC5200_SIMPLE
and if there is a PCI bus node defined in the device tree.
Boards that are compatible with this generic platform support
- are: 'tqc,tqm5200', 'promess,motionpro', 'schindler,cm5200'.
+ are: 'tqc,tqm5200', 'promess,motionpro', 'schindler,cm5200',
+ 'fsl,media5200'.
config PPC_EFIKA
bool "bPlan Efika 5k2. MPC5200B based computer"
diff --git a/arch/powerpc/platforms/52xx/mpc5200_simple.c b/arch/powerpc/platforms/52xx/mpc5200_simple.c
index c48b82b..3a31576 100644
--- a/arch/powerpc/platforms/52xx/mpc5200_simple.c
+++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
@@ -53,6 +53,7 @@ static char *board[] __initdata = {
"promess,motionpro",
"schindler,cm5200",
"tqc,tqm5200",
+ "fsl,media5200",
NULL
};
^ permalink raw reply related
* RE: Xilinx network trouble (mostly solved)
From: Stephen Neuendorffer @ 2008-04-21 16:50 UTC (permalink / raw)
To: Guillaume Dargaud, Rick Moleres, linuxppc-dev
In-Reply-To: <05d401c8a3cb$0b3cc640$ad289e86@LPSC0173W>
The easiest way is to edit the .mhs by hand.
Steve
> -----Original Message-----
> From: =
linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org] On Behalf Of
Guillaume Dargaud
> Sent: Monday, April 21, 2008 9:16 AM
> To: Rick Moleres; linuxppc-dev@ozlabs.org
> Subject: Re: Xilinx network trouble (mostly solved)
>=20
> Hi Rick,
>=20
> > You might try v1.00a of the xps_ll_temac core. There are a couple
of
> > issues with v1.00b (posted previously on this list) that may (or may
> > not) be causing the problem you see.
>=20
> Thanks for the answer... but I can't figure out how to revert to
1.00a. Is
> the option accessible from xps ?
>=20
> As for the EmacLite, it works rather imperfectly:
> ping -s 2952 works
> ping -s 2953 doesn't...:
> [ 2340.664293] Badness at net/core/skbuff.c:317
> [ 2340.668479] NIP: c015bd24 LR: c015b3f4 CTR: 00000000
> [ 2340.673410] REGS: c7d0fd20 TRAP: 0700 Not tainted
(2.6.24-rc8-xlnx)
> [ 2340.679876] MSR: 00029030 <EE,ME,IR,DR> CR: 28000048 XER:
20000000
> [ 2340.686189] TASK =3D c7c35810[243] 'ping' THREAD: c7d0e000
> [ 2340.691279] GPR00: 00000001 c7d0fdd0 c7c35810 c7d318e0 80000009
00000004
> c027bd38 00000200
> [ 2340.699571] GPR08: c7d0fdb8 c7d0e000 c027bd1c c0159910 c7d0fdb8
100b46f4
> ffffffff 00000000
> [ 2340.707864] GPR16: 10090000 100bd6e0 100b0000 100b0000 00000c11
7fbcf9a0
> 00000000 10004634
> [ 2340.716158] GPR24: 1007d370 7fbced90 10003fbc 100adf18 00000000
00000000
> c7c9e000 c7d318e0
> [ 2340.724625] NIP [c015bd24] skb_release_all+0x6c/0x94
> [ 2340.729551] LR [c015b3f4] __kfree_skb+0x18/0xc0
> [ 2340.734042] Call Trace:
> [ 2340.736465] [c7d0fdd0] [c0161b6c] netif_rx+0x124/0x158 (unreliable)
> [ 2340.742684] [c7d0fde0] [c015b3f4] __kfree_skb+0x18/0xc0
> [ 2340.747866] [c7d0fdf0] [c01466a0] SendHandler+0x44/0x94
> [ 2340.753050] [c7d0fe10] [c0147284]
XEmacLite_InterruptHandler+0x12c/0x140
> [ 2340.759702] [c7d0fe20] [c0146078] xemaclite_interrupt+0x20/0x34
> [ 2340.765577] [c7d0fe30] [c003c98c] handle_IRQ_event+0x4c/0xa0
> [ 2340.771193] [c7d0fe50] [c003ca94] __do_IRQ+0xb4/0x130
> [ 2340.776203] [c7d0fe70] [c0006990] do_IRQ+0x6c/0xa4
> [ 2340.780954] [c7d0fe80] [c000329c] ret_from_except+0x0/0x18
> [ 2340.786397] [c7d0ff40] [c0002c50] ret_from_syscall+0x0/0x3c
> [ 2340.791923] Instruction dump:
> [ 2340.794865] 3000ffff 7c005a2c 7c00592d 40a2fff0 817f006c 54290024
> 2f8b0000 419e0024
> [ 2340.802549] 8009000c 5400011e 7c0000d0 54000ffe <0f000000> 7fe3fb78
> 7d6903a6 4e800421
> (192.168.1.185): 2953 data bytes
> --
> Guillaume Dargaud
> http://www.gdargaud.net/
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 4/5] [POWERPC] QE: implement support for the GPIO LIB API
From: Anton Vorontsov @ 2008-04-21 16:41 UTC (permalink / raw)
To: Grant Likely; +Cc: David Brownell, linuxppc-dev
In-Reply-To: <fa686aa40804210758r70a5906eqb090cd3d8b797317@mail.gmail.com>
On Mon, Apr 21, 2008 at 08:58:09AM -0600, Grant Likely wrote:
> On Mon, Apr 21, 2008 at 8:49 AM, Anton Vorontsov
> <avorontsov@ru.mvista.com> wrote:
> > > > Should this really be a arch_initcall()? Would it be better for
> > > > platforms needing it to call it explicitly from one of the platform's
> > > > machine_arch_initcall()? Otherwise it gets called for all platforms
> > > > in a multiplatform kernel.
> > >
> > > Ok, I'll place it into qe_reset().
> >
> > Ugh, no, I can't. qe_reset() is called too early. And I don't like
> > having every QE board file to call this through machine_arch_initcall...
> > Hmm, what to do.. well, is this thaat bad to call this for every
> > platform?..
>
> Its not great. It has a boot time impact for every platform compiled
> into the kernel. The problem gets worse every time another block of
> code uses this method. Personally I prefer platform code calling it
> explicitly.
>
> Making it an of_platform device would also eliminate that problem, but
> you'd need a method to synchronize the driver with its users.
>
> I'm not going to raise a big stink about it, but the issue should not
> be ignored.
Heh.. how QE GPIO is different from FSL GTM then? Should I call
fsl_gtm_init() from the board file too? For the every board? I do
believe that years later someone will show up with something like this:
From: J. Random Hacker
Subject: [POWERPC] cleanup board initialization code
This patch removes vast amount of machine_arch_initcall()s that were
used to solely initialize some hardware, like this:
qe_add_gpio_chips();
fsl_gtm_init();
fsl_spi_init();
...
So, instead of calling this stuff from the board files, we implement
own arch_initcalls for these functions.
This causes negligible run-time overhead for the boards that aren't
using that hardware, but this overhead isn't measurable anyway. Also,
this patch shrinks .text size a bit, and produces nice looking diffstat.
12 file changed, 6 insertions(+), 140 deletions(-)
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 4/5] [POWERPC] QE: implement support for the GPIO LIB API
From: Segher Boessenkool @ 2008-04-21 16:30 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, David Brownell
In-Reply-To: <20080421143313.GB18008@polina.dev.rtsoft.ru>
>> Also, why is <bank> encoded in compatible? Do the different banks
>> have different register interfaces?
>
> Yes, they could. For example, interrupt pins are bank-specific.
In what way? If different banks just have different IRQ #s,
there are easier ways to express this.
Segher
^ permalink raw reply
* Re: [PATCH 1/5] [POWERPC] sysdev: implement FSL GTM support
From: Segher Boessenkool @ 2008-04-21 16:28 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080421142826.GA19458@polina.dev.rtsoft.ru>
>>> +static inline void gtm_ack_timer16(struct gtm_timer *tmr, u16
>>> events)
>>> +{
>>> + out_be16(tmr->gtevr, events);
>>> +}
>>
>> Drop 'inline' and expect gcc to do the right thing.
>
> Not sure about newer gccs, but older complained about "defined but not
> used" functions w/o inline keyword. I'm almost sure that this is still
> true.
It is. So why is it unused? Because you put the code in the header
file. Can't you move it to the .c file instead?
> I can surely use __maybe_unused, but "static inline" is pretty
> settled tradition, plus this function is small enough anyway.
All code in header files should be inline. Code in implementation
files should only be inline if you have a very good reason for
doing so. Same goes for __maybe_unused.
Segher
^ permalink raw reply
* Re: pci issue - wrong detection of pci ressources
From: Sergei Shtylyov @ 2008-04-21 16:20 UTC (permalink / raw)
To: Christian Ehrhardt; +Cc: linuxppc-dev, Hollis Blanchard
In-Reply-To: <480CAFD2.2050108@ru.mvista.com>
Hello, I wrote:
> Ah, that's what happens -- BAR0 in functions 0/1 takes up the whole
> 265 MiB of the PCI memory space (128+128), so no place is left for other
> memory BARs.
What's interesting, the Sequoia/Rainier board user manual says that PCI
memory is 0x80000000 thru 0xbfffffff (i.e. 1 GiB), while the Linux code seem
to always have assumed only 0x[1]800000000 thru 0x[1]8fffffff...
WBR, Sergei
^ permalink raw reply
* RFC: Possible section mismatch problem in ibm_newemac?
From: Steven A. Falco @ 2008-04-21 16:02 UTC (permalink / raw)
To: linuxppc-dev
I am using a recent DENX git tree. I want to enable debugging in prom_parse.c.
When I do that, I see link warnings like:
WARNING: drivers/net/ibm_newemac/ibm_newemac.o(.data+0x6e0): Section mismatch in reference from the variable emac_of_bus_notifier to the function .devinit.text:emac_of_bus_notify()
The variable emac_of_bus_notifier references
the function __devinit emac_of_bus_notify()
WARNING: drivers/net/ibm_newemac/built-in.o(.devinit.text+0x14d4): Section mismatch in reference from the function emac_probe() to the function .devexit.text:rgmii_detach()
The function __devinit emac_probe() references
a function __devexit rgmii_detach().
I've made the following changes, which clean up the link warnings, but I'm not
sure this is the right way to fix the problem. If it is correct, I'd like to
submit the patch.
Signed-off-by: Steve Falco <sfalco@harris.com>
---
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 5153901..d54393e 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -2241,7 +2241,7 @@ static int __devinit emac_of_bus_notify(struct notifier_block *nb,
return 0;
}
-static struct notifier_block emac_of_bus_notifier = {
+static struct notifier_block __devinitdata emac_of_bus_notifier = {
.notifier_call = emac_of_bus_notify
};
diff --git a/drivers/net/ibm_newemac/mal.c b/drivers/net/ibm_newemac/mal.c
index fb9c9eb..e9dbd6b 100644
--- a/drivers/net/ibm_newemac/mal.c
+++ b/drivers/net/ibm_newemac/mal.c
@@ -61,7 +61,7 @@ int __devinit mal_register_commac(struct mal_instance *mal,
return 0;
}
-void __devexit mal_unregister_commac(struct mal_instance *mal,
+void mal_unregister_commac(struct mal_instance *mal,
struct mal_commac *commac)
{
unsigned long flags;
diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
index 5757788..e32da3d 100644
--- a/drivers/net/ibm_newemac/rgmii.c
+++ b/drivers/net/ibm_newemac/rgmii.c
@@ -179,7 +179,7 @@ void rgmii_put_mdio(struct of_device *ofdev, int input)
mutex_unlock(&dev->lock);
}
-void __devexit rgmii_detach(struct of_device *ofdev, int input)
+void rgmii_detach(struct of_device *ofdev, int input)
{
struct rgmii_instance *dev = dev_get_drvdata(&ofdev->dev);
struct rgmii_regs __iomem *p = dev->base;
diff --git a/drivers/net/ibm_newemac/zmii.c b/drivers/net/ibm_newemac/zmii.c
index 2ea472a..17b1541 100644
--- a/drivers/net/ibm_newemac/zmii.c
+++ b/drivers/net/ibm_newemac/zmii.c
@@ -189,7 +189,7 @@ void zmii_set_speed(struct of_device *ofdev, int input, int speed)
mutex_unlock(&dev->lock);
}
-void __devexit zmii_detach(struct of_device *ofdev, int input)
+void zmii_detach(struct of_device *ofdev, int input)
{
struct zmii_instance *dev = dev_get_drvdata(&ofdev->dev);
^ permalink raw reply related
* Re: Xilinx network trouble (mostly solved)
From: Guillaume Dargaud @ 2008-04-21 16:16 UTC (permalink / raw)
To: Rick Moleres, linuxppc-dev
In-Reply-To: <20080418161454.E9E0C44009E@mail114-dub.bigfish.com>
Hi Rick,
> You might try v1.00a of the xps_ll_temac core. There are a couple of
> issues with v1.00b (posted previously on this list) that may (or may
> not) be causing the problem you see.
Thanks for the answer... but I can't figure out how to revert to 1.00a. Is
the option accessible from xps ?
As for the EmacLite, it works rather imperfectly:
ping -s 2952 works
ping -s 2953 doesn't...:
[ 2340.664293] Badness at net/core/skbuff.c:317
[ 2340.668479] NIP: c015bd24 LR: c015b3f4 CTR: 00000000
[ 2340.673410] REGS: c7d0fd20 TRAP: 0700 Not tainted (2.6.24-rc8-xlnx)
[ 2340.679876] MSR: 00029030 <EE,ME,IR,DR> CR: 28000048 XER: 20000000
[ 2340.686189] TASK = c7c35810[243] 'ping' THREAD: c7d0e000
[ 2340.691279] GPR00: 00000001 c7d0fdd0 c7c35810 c7d318e0 80000009 00000004
c027bd38 00000200
[ 2340.699571] GPR08: c7d0fdb8 c7d0e000 c027bd1c c0159910 c7d0fdb8 100b46f4
ffffffff 00000000
[ 2340.707864] GPR16: 10090000 100bd6e0 100b0000 100b0000 00000c11 7fbcf9a0
00000000 10004634
[ 2340.716158] GPR24: 1007d370 7fbced90 10003fbc 100adf18 00000000 00000000
c7c9e000 c7d318e0
[ 2340.724625] NIP [c015bd24] skb_release_all+0x6c/0x94
[ 2340.729551] LR [c015b3f4] __kfree_skb+0x18/0xc0
[ 2340.734042] Call Trace:
[ 2340.736465] [c7d0fdd0] [c0161b6c] netif_rx+0x124/0x158 (unreliable)
[ 2340.742684] [c7d0fde0] [c015b3f4] __kfree_skb+0x18/0xc0
[ 2340.747866] [c7d0fdf0] [c01466a0] SendHandler+0x44/0x94
[ 2340.753050] [c7d0fe10] [c0147284] XEmacLite_InterruptHandler+0x12c/0x140
[ 2340.759702] [c7d0fe20] [c0146078] xemaclite_interrupt+0x20/0x34
[ 2340.765577] [c7d0fe30] [c003c98c] handle_IRQ_event+0x4c/0xa0
[ 2340.771193] [c7d0fe50] [c003ca94] __do_IRQ+0xb4/0x130
[ 2340.776203] [c7d0fe70] [c0006990] do_IRQ+0x6c/0xa4
[ 2340.780954] [c7d0fe80] [c000329c] ret_from_except+0x0/0x18
[ 2340.786397] [c7d0ff40] [c0002c50] ret_from_syscall+0x0/0x3c
[ 2340.791923] Instruction dump:
[ 2340.794865] 3000ffff 7c005a2c 7c00592d 40a2fff0 817f006c 54290024
2f8b0000 419e0024
[ 2340.802549] 8009000c 5400011e 7c0000d0 54000ffe <0f000000> 7fe3fb78
7d6903a6 4e800421
(192.168.1.185): 2953 data bytes
--
Guillaume Dargaud
http://www.gdargaud.net/
^ permalink raw reply
* Re: [PATCH] [PPC] Remove mpc8272 ads board from arch/ppc
From: Kumar Gala @ 2008-04-21 15:25 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40804191114i2cef26eegabfe9bc28d8ecc18@mail.gmail.com>
On Apr 19, 2008, at 1:14 PM, Grant Likely wrote:
> On Sat, Apr 19, 2008 at 9:52 AM, Kumar Gala
> <galak@kernel.crashing.org> wrote:
>> We have a board port in arch/powerpc so we dont need this one
>> anymore.
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> Personally, I'd rather not do the piecemeal removal of board ports
> from arch/ppc. We've only got one release left anyway. Removing them
> just generates more churn and has the risk of causing other side
> effects.
I can understand it, but I think removing them makes it obvious to
anyone that's lurking. Call in maintainer prerogative :)
- k
^ permalink raw reply
* RE: XLlTemac soft lockup BUG
From: Hugo Villeneuve @ 2008-04-21 15:19 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <48076ABA.1030500@conceptxdesign.com>
Brian Silverman wrote:
> Hugo,
> We have a design with the BCM5482, and will be trying it out shortly.
> Any chance you could post a patch of your BCM5466 mods?=20
Hi,
The main issue here is that you need to tell the LLTEMAC interface about =
the speed of your PHY. You can do this by adding this code example in =
the function=20
set_mac_speed():
---
#define BROADCOM_BCM5466_RGMII_AUX_STATUS 0x19
#define BCM5466_SPEED_1000BASE_T_FULL_DUPLEX 7
#define BCM5466_SPEED_1000BASE_T_HALF_DUPLEX 6
#define BCM5466_SPEED_100BASE_T_FULL_DUPLEX 5
#define BCM5466_SPEED_100BASE_T4 4
#define BCM5466_SPEED_100BASE_T_HALF_DUPLEX 3
#define BCM5466_SPEED_10BASE_T_FULL_DUPLEX 2
#define BCM5466_SPEED_10BASE_T_HALF_DUPLEX 1
#define BCM5466_SPEED_AN_NOT_COMPLETE 0
u16 RegValue;
_XLlTemac_PhyRead(&lp->Emac, lp->gmii_addr, =
BROADCOM_BCM5466_RGMII_AUX_STATUS, &RegValue);
phylinkspeed =3D ( RegValue & 0x0700 ) >> 8; /* Keeping only =
bits 10-8 */
/* Update TEMAC speed accordingly */
switch (phylinkspeed) {
case BCM5466_SPEED_1000BASE_T_FULL_DUPLEX:
case BCM5466_SPEED_1000BASE_T_HALF_DUPLEX:
lp->cur_speed =3D 1000;
break;
case BCM5466_SPEED_100BASE_T_FULL_DUPLEX:
case BCM5466_SPEED_100BASE_T_HALF_DUPLEX:
case BCM5466_SPEED_100BASE_T4:
lp->cur_speed =3D 100;
break;
case BCM5466_SPEED_10BASE_T_FULL_DUPLEX:
case BCM5466_SPEED_10BASE_T_HALF_DUPLEX:
lp->cur_speed =3D 10;
break;
default:
lp->cur_speed =3D 1000;
break;
}
_XLlTemac_SetOperatingSpeed(&lp->Emac, lp->cur_speed);
---
Hope it helps, Hugo.
> Hugo Villeneuve wrote:
>=20
> linuxppc-embedded-bounces+hugo.villeneuve=3Dlyrtech.com@ozlabs.org
> wrote:=20
>=20
>=20
> Hi all,
>=20
> I am trying to switch my design from the PLB Temac to the local link
> temac, and i have a problem when trying to run ifconfig in my init
> script. It gives me a BUG: soft lockup - CPU#0 stuck for 11s!
> [ifconfig:208] Here is the rest of the dump, thanks for your help in
> advance. [ 233.114960] eth0: XLlTemac: Options: 0x3fa
>=20
> [ 233.118449] eth0: XLlTemac: allocating interrupt 8 for fifo mode.
>=20
> [ 237.135029] eth0: XLlTemac: We renegotiated the speed to: 100
>=20
> [ 237.150339] eth0: XLlTemac: speed set to 100Mb/s
>=20
> [ 244.792140] BUG: soft lockup - CPU#0 stuck for 11s!
> [ifconfig:204]=20
>=20
>=20
>=20
> Hi,
> we had a similar error message, which was caused by us selecting the
> wrong PHY type in the kernel configuration menu (latest
> linux-2.6-xlnx-git tree). In fact, we had to modify the lltemac
> driver to support our PHY (BCM5466). Once we did that, the error
> message went away. =20
>=20
> Hugo V.
>=20
>=20
> Hugo Villeneuve
> Hardware developer | Concepteur mat=E9riel
> Lyrtech
> Phone/T=E9l. : (1) (418) 877-4644 #2395
> Toll-free/Sans frais - Canada & USA : (1) (888) 922-4644 #2395
> Fax/T=E9l=E9c. : (1) (418) 877-7710
> www.lyrtech.com
> Infinite possibilities...TM
>=20
> THIS MESSAGE AND ALL ATTACHED DOCUMENTS ARE EXCLUSIVELY INTENDED
> TO THE INDICATED RECIPIENTS AND ITS CONTENTS MAY BE CONFIDENTIAL.
> IT IS STRICTLY FORBIDDEN TO ANYONE TO TAKE COGNIZANCE, USE, OR
> DIVULGE THE INFORMATION CONTAINED HEREIN. IF YOU MISTAKENLY
> RECEIVE THIS MESSAGE, IMMEDIATELY INFORM LYRTECH AND DESTROY THE
> MESSAGE AND ATTACHMENTS FORTHWITH.THANK YOU.
>=20
> LE PRESENT MESSAGE ET LES DOCUMENTS QUI Y SONT JOINTS S'ADRESSENT
> EXCLUSIVEMENT AU(X)DESTINATAIRE(S) INDIQUE(S) ET LEUR TENEUR PEUT
> ETRE CONFIDENTIELLE. IL EST STRICTEMENT INTERDIT A QUICONQUE D'EN
> PRENDRE CONNAISSANCE, DE LES UTILISER OU DE LES DIVULGUER. SI
> VOUS RECEVEZ LE PRESENT MESSAGE PAR ERREUR, VEUILLEZ EN AVISER
> LYRTECH IMMEDIATEMENT ET DETRUIRE LE MESSAGE SEANCE TENANTE,
> AINSI QUE LES DOCUMENTS QUI Y SONT JOINTS.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Hugo Villeneuve
Hardware developer | Concepteur mat=E9riel
Lyrtech
Phone/T=E9l. : (1) (418) 877-4644 #2395
Toll-free/Sans frais - Canada & USA : (1) (888) 922-4644 #2395
Fax/T=E9l=E9c. : (1) (418) 877-7710
www.lyrtech.com
Infinite possibilities...TM
THIS MESSAGE AND ALL ATTACHED DOCUMENTS ARE EXCLUSIVELY INTENDED
TO THE INDICATED RECIPIENTS AND ITS CONTENTS MAY BE CONFIDENTIAL.
IT IS STRICTLY FORBIDDEN TO ANYONE TO TAKE COGNIZANCE, USE, OR
DIVULGE THE INFORMATION CONTAINED HEREIN. IF YOU MISTAKENLY
RECEIVE THIS MESSAGE, IMMEDIATELY INFORM LYRTECH AND DESTROY THE
MESSAGE AND ATTACHMENTS FORTHWITH.THANK YOU.
LE PRESENT MESSAGE ET LES DOCUMENTS QUI Y SONT JOINTS S'ADRESSENT
EXCLUSIVEMENT AU(X)DESTINATAIRE(S) INDIQUE(S) ET LEUR TENEUR PEUT
ETRE CONFIDENTIELLE. IL EST STRICTEMENT INTERDIT A QUICONQUE D'EN
PRENDRE CONNAISSANCE, DE LES UTILISER OU DE LES DIVULGUER. SI
VOUS RECEVEZ LE PRESENT MESSAGE PAR ERREUR, VEUILLEZ EN AVISER
LYRTECH IMMEDIATEMENT ET DETRUIRE LE MESSAGE SEANCE TENANTE,
AINSI QUE LES DOCUMENTS QUI Y SONT JOINTS.
^ permalink raw reply
* Re: pci issue - wrong detection of pci ressources
From: Sergei Shtylyov @ 2008-04-21 15:16 UTC (permalink / raw)
To: Christian Ehrhardt; +Cc: linuxppc-dev, Hollis Blanchard
In-Reply-To: <480C9FE2.4030601@linux.vnet.ibm.com>
Christian Ehrhardt wrote:
>>> +else {
>>> +printk(KERN_ERR"%s - continue with start 0x%0lx on %p\n", __func__,
>>> (this->end + 1), this->sibling);
>>> +}
>>> new->start = this->end + 1;
>>> this = this->sibling;
>>
>>
>> And here. Yet it's not clear why you call resource's 'end' 'start'...
> It's the new->start that get's calculated one line after that new else
> part.
> I printed that one to to see a bit how the loop iterates the resource
> elements.
Yeah, I figured that out right after sending mail. :-)
> ------------------------------------------------------------------------
> With DEBUG in arch/powerpc/kernel/pci-common.c, debug in commandline and a patch with some printk's (I attached the patch because it is the usual "put printk's everywhere" so the diff helps to understand where the prints come from). Corrected prinf format specifiers according to the comments from Sergei Shtylyov.
> PCI host bridge /plb/pci@1ec000000 (primary) ranges:
> MEM 0x0000000180000000..0x000000018fffffff -> 0x0000000080000000
> IO 0x00000001e8000000..0x00000001e80fffff -> 0x0000000000000000
> 4xx PCI DMA offset set to 0x00000000
> PCI: Probing PCI hardware
> PCI: Hiding 4xx host bridge resources 0000:00:00.0
> Try to map irq for 0000:00:00.0...
> -> got one, spec 2 cells (0x00000003 0x00000008...) on /interrupt-controller2
> -> mapped to linux irq 16
> Try to map irq for 0000:00:0a.0...
> -> got one, spec 2 cells (0x00000003 0x00000008...) on /interrupt-controller2
> -> mapped to linux irq 16
> Try to map irq for 0000:00:0a.1...
> PCI: PHB (bus 0) bridge rsrc 0: 0000000000000000-00000000000fffff [0x100], parent c0365060 (PCI IO)
> __request_resource - request 0xcf8045b0 name '/plb/pci@1ec000000' start 0x0 end 0xfffff
> __request_resource - no conflict parent 0xc0365060 sibling 0x00000000
> PCI: PHB (bus 0) bridge rsrc 1: 0000000180000000-000000018fffffff [0x200], parent c0365038 (PCI mem)
> __request_resource - request 0xcf8045d8 name '/plb/pci@1ec000000' start 0x180000000 end 0x18fffffff
> __request_resource - no conflict parent 0xc0365038 sibling 0x00000000
> PCI: Assigning unassigned resouces...
> pci_assign_unassigned_resources -#1- bus 0xcf82d400
> pci_assign_unassigned_resources -#2- bus 0xcf82d400
> pci_assign_resource - allocate with IORESOURCE_PREFETCH
> pci_bus_alloc_resource - enter
> pci_assign_resource - second pci_bus_alloc_resource call
> pci_bus_alloc_resource - enter
> pci_bus_alloc_resource - call allocate ressource size 0x8000000 startcalc 0xffffffff, align 0x8000000
> find_resource - size 0x8000000, min 0x180000000, max 0xffffffffffffffff
> find_resource - found start 0x180000000 end 0x187ffffff
> __request_resource - request 0xcf810578 name '0000:00:0a.0' start 0x180000000 end 0x187ffffff
> __request_resource - no conflict parent 0xcf8045d8 sibling 0x00000000
> pci_assign_resource - allocate with IORESOURCE_PREFETCH
> pci_bus_alloc_resource - enter
> pci_assign_resource - second pci_bus_alloc_resource call
> pci_bus_alloc_resource - enter
> pci_bus_alloc_resource - call allocate ressource size 0x8000000 startcalc 0xffffffff, align 0x8000000
> find_resource - size 0x8000000, min 0x180000000, max 0xffffffffffffffff
> find_resource - continue with start 0x188000000 on 0x00000000
> find_resource - found start 0x188000000 end 0x18fffffff
> __request_resource - request 0xcf810178 name '0000:00:0a.1' start 0x188000000 end 0x18fffffff
> __request_resource - no conflict parent 0xcf8045d8 sibling 0x00000000
> pci_assign_resource - allocate with IORESOURCE_PREFETCH
> pci_bus_alloc_resource - enter
> pci_assign_resource - second pci_bus_alloc_resource call
> pci_bus_alloc_resource - enter
Ah, that's what happens -- BAR0 in functions 0/1 takes up the whole 265
MiB of the PCI memory space (128+128), so no place is left for other memory BARs.
> pci_bus_alloc_resource - call allocate ressource size 0x20000 startcalc 0xffffffff, align 0x20000
> find_resource - size 0x20000, min 0x180000000, max 0xffffffffffffffff
> find_resource - continue with start 0x188000000 on 0xcf810178
> find_resource - continue with start 0x190000000 on 0x00000000
> find_resource - no this - exit
> PCI: pci_assign_resource - Failed to allocate mem resource #6:20000@190000000 for 0000:00:0a.0
> pci_assign_resource - allocate with IORESOURCE_PREFETCH
> pci_bus_alloc_resource - enter
> pci_bus_alloc_resource - call allocate ressource size 0x10000 startcalc 0xffffffff, align 0x10000
> find_resource - size 0x10000, min 0x180000000, max 0xffffffffffffffff
> find_resource - continue with start 0x188000000 on 0xcf810178
> find_resource - continue with start 0x190000000 on 0x00000000
> find_resource - no this - exit
> PCI: pci_assign_resource - Failed to allocate mem resource #2:10000@190000000 for 0000:00:0a.0
> pci_assign_resource - allocate with IORESOURCE_PREFETCH
Hm, BAR2 shouldn't be allocated in theprefetchable space -- it corresponds
to non-prefetchable (from lspci's output) MMIO register region...
WBR, Sergei
^ permalink raw reply
* Re: mpc8349, gb ethernet, bridging
From: rje @ 2008-04-21 15:10 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <480AD64E.1040406@valleytech.com>
Hi.
Anybody have any idea what could cause the NETDEV WATCHDOG timeout?
On the GB ethernet port?
Could that happen if the other port was being overflowed?
That watchdog timeout seems to be involved pretty much every time
that the bridge goes down. When the timeout occurs, the gianfar driver
stops
and then (re)starts itself.
>
> Hi.
>
> We are having some issues regarding bridging the 2 ethernet ports of
> an mpc8349, and are
> trying to determine what is going on.
>
>
> We are attempting to daisy-chain several mpc8349-based boards via the
> 2 ethernet ports
> on each 8349. When we enable bridging for the units, we (sometimes)
> start seeing the following
> on one of the interior bridge's (mostly on the root bridge) console(s):
>
> NETDEV WATCHDOG: eth1 : transmit timed out
>
> We then see the bridge output messages that indicate that is is going
> through a topology
> state change.
>
> This situation keeps recurring.
>
> At some point, the message from the bridge that it is entering a
> disabled state for port #2
> (eth1) is followed by garbage (actually, it appears to be some
> pointers and/or memory
> addresses printed out), and the system hangs.
>
> We are using NAPI and the skbuff-recycling for the gianfar driver.
> We use ring(s) of 32 buffers.
> The gianfar's watchdog is set to 1Hz (once a seond ?)
>
> We are not sure if/how affect things:
>
> Port #1 of the 'root' bridge is attached directly to our LAN
> Port #1 of the 'root' bridge runs at 10 Mbs
> Port #2 of the 'root' bridge runs at 1Gbs
> All other ports in the chain are 1Gbs
> We are using CAT-5 cables for all connections
>
> We have an application on each bridge in the chain that periodically
> sends several hundred bytes
> 'up the chain', towards its head (ie, towards our LAN). This
> application is typically running
> when the issue is seen.
>
> Setting the bridge's forwarding delay to 0 and hellotime to 6,000
> helped, but did
> not solve the issue.
>
> ???
>
--
Sometimes I feel like a red shirt in the Star Trek episode of life.
--
This message contains confidential information and is intended only for the
individual named. If you are not the intended recipient you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system.
^ permalink raw reply
* [PATCH v2] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
From: Stefan Roese @ 2008-04-21 14:54 UTC (permalink / raw)
To: linuxppc-dev
This patch adds basic endpoint support to the 4xx PCIe driver.
This is done by checking the device_type property of the PCIe
device node ("pci" for root-complex and "pci-endpoint" for endpoint
configuration).
Note: Currently we map a fixed 64MByte window to PLB address 0 (SDRAM).
This should probably be configurable via a dts property.
Signed-off-by: Stefan Roese <sr@denx.de>
---
Changes in v2:
--------------
- As suggested by Benjamin Herrenschmidt, don't determine endpoint mode
by looking at the already configured PCIe port state, but evaluate
the device_type property instead. This makes it possible for boards
without a previously run PCIe configuration (e.g. U-Boot) to configure
a port as endpoint as well.
- Don't map the big external config space upon endpoint configuration.
- Introduce "vendor-id" and "device-id" properties to be written to
the host bridge.
arch/powerpc/sysdev/ppc4xx_pci.c | 180 +++++++++++++++++++++++++++----------
1 files changed, 131 insertions(+), 49 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index 1087196..acdc309 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -1390,28 +1390,59 @@ static void __init ppc4xx_configure_pciex_PIMs(struct ppc4xx_pciex_port *port,
resource_size_t size = res->end - res->start + 1;
u64 sa;
- /* Calculate window size */
- sa = (0xffffffffffffffffull << ilog2(size));;
- if (res->flags & IORESOURCE_PREFETCH)
- sa |= 0x8;
+ if (port->endpoint) {
+ resource_size_t ep_addr = 0;
+ resource_size_t ep_size = 32 << 20;
+
+ /* Currently we map a fixed 64MByte window to PLB address
+ * 0 (SDRAM). This should probably be configurable via a dts
+ * property.
+ */
+
+ /* Calculate window size */
+ sa = (0xffffffffffffffffull << ilog2(ep_size));;
+
+ /* Setup BAR0 */
+ out_le32(mbase + PECFG_BAR0HMPA, RES_TO_U32_HIGH(sa));
+ out_le32(mbase + PECFG_BAR0LMPA, RES_TO_U32_LOW(sa) |
+ PCI_BASE_ADDRESS_MEM_TYPE_64);
- out_le32(mbase + PECFG_BAR0HMPA, RES_TO_U32_HIGH(sa));
- out_le32(mbase + PECFG_BAR0LMPA, RES_TO_U32_LOW(sa));
+ /* Disable BAR1 & BAR2 */
+ out_le32(mbase + PECFG_BAR1MPA, 0);
+ out_le32(mbase + PECFG_BAR2HMPA, 0);
+ out_le32(mbase + PECFG_BAR2LMPA, 0);
- /* The setup of the split looks weird to me ... let's see if it works */
- out_le32(mbase + PECFG_PIM0LAL, 0x00000000);
- out_le32(mbase + PECFG_PIM0LAH, 0x00000000);
- out_le32(mbase + PECFG_PIM1LAL, 0x00000000);
- out_le32(mbase + PECFG_PIM1LAH, 0x00000000);
- out_le32(mbase + PECFG_PIM01SAH, 0xffff0000);
- out_le32(mbase + PECFG_PIM01SAL, 0x00000000);
+ out_le32(mbase + PECFG_PIM01SAH, RES_TO_U32_HIGH(sa));
+ out_le32(mbase + PECFG_PIM01SAL, RES_TO_U32_LOW(sa));
+
+ out_le32(mbase + PCI_BASE_ADDRESS_0, RES_TO_U32_LOW(ep_addr));
+ out_le32(mbase + PCI_BASE_ADDRESS_1, RES_TO_U32_HIGH(ep_addr));
+ } else {
+ /* Calculate window size */
+ sa = (0xffffffffffffffffull << ilog2(size));;
+ if (res->flags & IORESOURCE_PREFETCH)
+ sa |= 0x8;
+
+ out_le32(mbase + PECFG_BAR0HMPA, RES_TO_U32_HIGH(sa));
+ out_le32(mbase + PECFG_BAR0LMPA, RES_TO_U32_LOW(sa));
+
+ /* The setup of the split looks weird to me ... let's see
+ * if it works
+ */
+ out_le32(mbase + PECFG_PIM0LAL, 0x00000000);
+ out_le32(mbase + PECFG_PIM0LAH, 0x00000000);
+ out_le32(mbase + PECFG_PIM1LAL, 0x00000000);
+ out_le32(mbase + PECFG_PIM1LAH, 0x00000000);
+ out_le32(mbase + PECFG_PIM01SAH, 0xffff0000);
+ out_le32(mbase + PECFG_PIM01SAL, 0x00000000);
+
+ out_le32(mbase + PCI_BASE_ADDRESS_0, RES_TO_U32_LOW(res->start));
+ out_le32(mbase + PCI_BASE_ADDRESS_1, RES_TO_U32_HIGH(res->start));
+ }
/* Enable inbound mapping */
out_le32(mbase + PECFG_PIMEN, 0x1);
- out_le32(mbase + PCI_BASE_ADDRESS_0, RES_TO_U32_LOW(res->start));
- out_le32(mbase + PCI_BASE_ADDRESS_1, RES_TO_U32_HIGH(res->start));
-
/* Enable I/O, Mem, and Busmaster cycles */
out_le16(mbase + PCI_COMMAND,
in_le16(mbase + PCI_COMMAND) |
@@ -1425,13 +1456,8 @@ static void __init ppc4xx_pciex_port_setup_hose(struct ppc4xx_pciex_port *port)
const int *bus_range;
int primary = 0, busses;
void __iomem *mbase = NULL, *cfg_data = NULL;
-
- /* XXX FIXME: Handle endpoint mode properly */
- if (port->endpoint) {
- printk(KERN_WARNING "PCIE%d: Port in endpoint mode !\n",
- port->index);
- return;
- }
+ const u32 *pval;
+ u32 val;
/* Check if primary bridge */
if (of_get_property(port->node, "primary", NULL))
@@ -1465,21 +1491,30 @@ static void __init ppc4xx_pciex_port_setup_hose(struct ppc4xx_pciex_port *port)
hose->last_busno = hose->first_busno + busses;
}
- /* We map the external config space in cfg_data and the host config
- * space in cfg_addr. External space is 1M per bus, internal space
- * is 4K
+ if (!port->endpoint) {
+ /* Only map the external config space in cfg_data for
+ * PCIe root-complexes. External space is 1M per bus
+ */
+ cfg_data = ioremap(port->cfg_space.start +
+ (hose->first_busno + 1) * 0x100000,
+ busses * 0x100000);
+ if (cfg_data == NULL) {
+ printk(KERN_ERR "%s: Can't map external config space !",
+ port->node->full_name);
+ goto fail;
+ }
+ hose->cfg_data = cfg_data;
+ }
+
+ /* Always map the host config space in cfg_addr.
+ * Internal space is 4K
*/
- cfg_data = ioremap(port->cfg_space.start +
- (hose->first_busno + 1) * 0x100000,
- busses * 0x100000);
mbase = ioremap(port->cfg_space.start + 0x10000000, 0x1000);
- if (cfg_data == NULL || mbase == NULL) {
- printk(KERN_ERR "%s: Can't map config space !",
+ if (mbase == NULL) {
+ printk(KERN_ERR "%s: Can't map internal config space !",
port->node->full_name);
goto fail;
}
-
- hose->cfg_data = cfg_data;
hose->cfg_addr = mbase;
pr_debug("PCIE %s, bus %d..%d\n", port->node->full_name,
@@ -1492,12 +1527,14 @@ static void __init ppc4xx_pciex_port_setup_hose(struct ppc4xx_pciex_port *port)
port->hose = hose;
mbase = (void __iomem *)hose->cfg_addr;
- /*
- * Set bus numbers on our root port
- */
- out_8(mbase + PCI_PRIMARY_BUS, hose->first_busno);
- out_8(mbase + PCI_SECONDARY_BUS, hose->first_busno + 1);
- out_8(mbase + PCI_SUBORDINATE_BUS, hose->last_busno);
+ if (!port->endpoint) {
+ /*
+ * Set bus numbers on our root port
+ */
+ out_8(mbase + PCI_PRIMARY_BUS, hose->first_busno);
+ out_8(mbase + PCI_SECONDARY_BUS, hose->first_busno + 1);
+ out_8(mbase + PCI_SUBORDINATE_BUS, hose->last_busno);
+ }
/*
* OMRs are already reset, also disable PIMs
@@ -1518,17 +1555,49 @@ static void __init ppc4xx_pciex_port_setup_hose(struct ppc4xx_pciex_port *port)
ppc4xx_configure_pciex_PIMs(port, hose, mbase, &dma_window);
/* The root complex doesn't show up if we don't set some vendor
- * and device IDs into it. Those are the same bogus one that the
- * initial code in arch/ppc add. We might want to change that.
+ * and device IDs into it. The defaults below are the same bogus
+ * one that the initial code in arch/ppc had. This can be
+ * overwritten by setting the "vendor-id/device-id" properties
+ * in the pciex node.
*/
- out_le16(mbase + 0x200, 0xaaa0 + port->index);
- out_le16(mbase + 0x202, 0xbed0 + port->index);
- /* Set Class Code to PCI-PCI bridge and Revision Id to 1 */
- out_le32(mbase + 0x208, 0x06040001);
+ /* Get the (optional) vendor-/device-id from the device-tree */
+ pval = of_get_property(port->node, "vendor-id", NULL);
+ if (pval) {
+ val = *pval;
+ } else {
+ if (!port->endpoint)
+ val = 0xaaa0 + port->index;
+ else
+ val = 0xeee0 + port->index;
+ }
+ out_le16(mbase + 0x200, val);
+
+ pval = of_get_property(port->node, "device-id", NULL);
+ if (pval) {
+ val = *pval;
+ } else {
+ if (!port->endpoint)
+ val = 0xbed0 + port->index;
+ else
+ val = 0xfed0 + port->index;
+ }
+ out_le16(mbase + 0x202, val);
+
+ if (!port->endpoint) {
+ /* Set Class Code to PCI-PCI bridge and Revision Id to 1 */
+ out_le32(mbase + 0x208, 0x06040001);
+
+ printk(KERN_INFO "PCIE%d: successfully set as root-complex\n",
+ port->index);
+ } else {
+ /* Set Class Code to Processor/PPC */
+ out_le32(mbase + 0x208, 0x0b200001);
+
+ printk(KERN_INFO "PCIE%d: successfully set as endpoint\n",
+ port->index);
+ }
- printk(KERN_INFO "PCIE%d: successfully set as root-complex\n",
- port->index);
return;
fail:
if (hose)
@@ -1545,6 +1614,7 @@ static void __init ppc4xx_probe_pciex_bridge(struct device_node *np)
const u32 *pval;
int portno;
unsigned int dcrs;
+ const char *val;
/* First, proceed to core initialization as we assume there's
* only one PCIe core in the system
@@ -1576,8 +1646,20 @@ static void __init ppc4xx_probe_pciex_bridge(struct device_node *np)
}
port->sdr_base = *pval;
- /* XXX Currently, we only support root complex mode */
- port->endpoint = 0;
+ /* Check if device_type property is set to "pci" or "pci-endpoint".
+ * Resulting from this setup this PCIe port will be configured
+ * as root-complex or as endpoint.
+ */
+ val = of_get_property(port->node, "device_type", NULL);
+ if (!strcmp(val, "pci-endpoint")) {
+ port->endpoint = 1;
+ } else if (!strcmp(val, "pci")) {
+ port->endpoint = 0;
+ } else {
+ printk(KERN_ERR "PCIE: missing or incorrect device_type for %s\n",
+ np->full_name);
+ return;
+ }
/* Fetch config space registers address */
if (of_address_to_resource(np, 0, &port->cfg_space)) {
--
1.5.5
^ permalink raw reply related
* Re: eldk and usb to serial converters
From: Detlev Zundel @ 2008-04-21 14:59 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <27dfa3d0804171704j711aad1cwe7b558c077da3350@mail.gmail.com>
Hi Daniel,
> I'm currently trying to compile a kernel for an AMCC440EP board within an eldk
> environment. We've got a FTDI usb2serial converter we need to connect to the
> board. Now I've compiled a kernel on a gentoo machine for this device and had
> no problems. With this board, the kernel recognizes the device fine:
>
> ftdi_sio 1-1:1.0: FTDI USB Serial Device converter detected
> usb 1-1: FTDI USB Serial Device converter now attached to ttyUSB0
> drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial Converters Driver
>
> but udev doesn't actually make the ttyUSB0 node. If anyone knows what may have
> caused the problem and how to fix it, it'd be much appreciated.
Maybe udev isn't running at all? The ELDKs including udev disable it
per default (what version are you using?). Embedded systeme like to
have static kernel configurations presenting no surprises at runtime...
Cheers
Detlev
--
Programming X-Windows is like trying to find the square root of pi
using roman numerals.
-- The UNIX Haters Handbook
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* Re: [PATCH 4/5] [POWERPC] QE: implement support for the GPIO LIB API
From: Grant Likely @ 2008-04-21 14:58 UTC (permalink / raw)
To: avorontsov; +Cc: David Brownell, linuxppc-dev
In-Reply-To: <20080421144938.GA25627@polina.dev.rtsoft.ru>
On Mon, Apr 21, 2008 at 8:49 AM, Anton Vorontsov
<avorontsov@ru.mvista.com> wrote:
> > > Should this really be a arch_initcall()? Would it be better for
> > > platforms needing it to call it explicitly from one of the platform's
> > > machine_arch_initcall()? Otherwise it gets called for all platforms
> > > in a multiplatform kernel.
> >
> > Ok, I'll place it into qe_reset().
>
> Ugh, no, I can't. qe_reset() is called too early. And I don't like
> having every QE board file to call this through machine_arch_initcall...
> Hmm, what to do.. well, is this thaat bad to call this for every
> platform?..
Its not great. It has a boot time impact for every platform compiled
into the kernel. The problem gets worse every time another block of
code uses this method. Personally I prefer platform code calling it
explicitly.
Making it an of_platform device would also eliminate that problem, but
you'd need a method to synchronize the driver with its users.
I'm not going to raise a big stink about it, but the issue should not
be ignored.
Cheers,
g.
>
>
>
> --
> Anton Vorontsov
> email: cbouatmailru@gmail.com
> irc://irc.freenode.net/bd2
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 4/5] [POWERPC] QE: implement support for the GPIO LIB API
From: Anton Vorontsov @ 2008-04-21 14:49 UTC (permalink / raw)
To: Grant Likely; +Cc: David Brownell, linuxppc-dev
In-Reply-To: <20080421143313.GB18008@polina.dev.rtsoft.ru>
On Mon, Apr 21, 2008 at 06:33:13PM +0400, Anton Vorontsov wrote:
[...]
> > > +static int __init qe_add_gpiochips(void)
> > > +{
> > > + int ret;
> > > + struct device_node *np;
> > > +
> > > + for_each_compatible_node(np, NULL, "fsl,qe-pario-bank") {
> > > + struct qe_gpio_chip *qe_gc;
> > > + struct of_mm_gpio_chip *mm_gc;
> > > + struct of_gpio_chip *of_gc;
> > > + struct gpio_chip *gc;
> > > +
> > > + qe_gc = kzalloc(sizeof(*qe_gc), GFP_KERNEL);
> > > + if (!qe_gc) {
> > > + ret = -ENOMEM;
> > > + goto err;
> > > + }
> > > +
> > > + spin_lock_init(&qe_gc->lock);
> > > +
> > > + mm_gc = &qe_gc->mm_gc;
> > > + of_gc = &mm_gc->of_gc;
> > > + gc = &of_gc->gc;
> > > +
> > > + mm_gc->save_regs = qe_gpio_save_regs;
> > > + of_gc->gpio_cells = 2;
> > > + gc->ngpio = QE_PIO_PINS;
> > > + gc->direction_input = qe_gpio_dir_in;
> > > + gc->direction_output = qe_gpio_dir_out;
> > > + gc->get = qe_gpio_get;
> > > + gc->set = qe_gpio_set;
> > > +
> > > + ret = of_mm_gpiochip_add(np, mm_gc);
> > > + if (ret)
> > > + goto err;
> > > + }
> > > +
> > > + return 0;
> > > +err:
> > > + pr_err("%s: registration failed with status %d\n", np->full_name, ret);
> > > + of_node_put(np);
> > > + return ret;
> > > +}
> > > +arch_initcall(qe_add_gpiochips);
> >
> > Should this really be a arch_initcall()? Would it be better for
> > platforms needing it to call it explicitly from one of the platform's
> > machine_arch_initcall()? Otherwise it gets called for all platforms
> > in a multiplatform kernel.
>
> Ok, I'll place it into qe_reset().
Ugh, no, I can't. qe_reset() is called too early. And I don't like
having every QE board file to call this through machine_arch_initcall...
Hmm, what to do.. well, is this thaat bad to call this for every
platform?..
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ 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