* RE: Xilinx PIC and kernel interrupt handler
From: Martin, Tim @ 2006-07-31 18:06 UTC (permalink / raw)
To: Stig Telfer, linuxppc-embedded
Regarding the IVR patch: Have you seen this bug in practice, or just
from examining the code?
The reason I ask is I've recently looked at this myself, and was under
the impression that "w" is the width of the data bus (DB) (per page 9 of
dcr_intc.pdf). So regardless of how many interrupt sources are
connected, assuming the data bus width is 32 bits, w=3D32.
I've specifically confirmed this is true if you have less than 32
interrupt sources connected, the one named INT0 shows up in bit position
31 (w-1 for w=3D32 is 31) of the ISR and IPR. Bit position 31 in PPC
notation is the LSB.
Tim=20
> -----Original Message-----
> From: linuxppc-embedded-bounces+tmartin=3Dviasat.com@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces+tmartin=3Dviasat.com@ozlabs.or
> g] On Behalf Of Stig Telfer
> Sent: Monday, July 31, 2006 6:51 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Xilinx PIC and kernel interrupt handler=20
>=20
> Hi -
>=20
> There appears to be a kernel bug in the 2.4 and 2.6.17.7=20
> kernel trees relating to reading the interrupt vector from=20
> the Xilinx PIC
> (xilinx_pic_get_irq() in xilinx_pic.c). As I see it, here's the
> problem: If no interrupt is pending, the register should read=20
> all ones.=20
> However, the IVR is only as wide as the number of interrupt=20
> sources. =20
> The routine mistakenly assumes sign extension and checks for=20
> a 32-bit read of -1 instead of a read of w bits where w is=20
> the number of connected interrupt sources.
>=20
> The 2.6 version also has a search-and-replace glitch relating=20
> to removal of the reversal of bit numbering. I have attached=20
> a two line patch (for 2.6.17.7) that makes the IVR comparison=20
> against the right bit pattern and removes the remnants of the=20
> former bit-reversal code.
>=20
> Share and enjoy,
> Stig Telfer
>=20
>=20
^ permalink raw reply
* Re: [PATCH] remove bogomips from /proc/cpuinfo
From: Olaf Hering @ 2006-07-31 17:49 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Paul Mackeras
In-Reply-To: <200607311946.18331.arnd.bergmann@de.ibm.com>
On Mon, Jul 31, Arnd Bergmann wrote:
> On Monday 31 July 2006 14:59, Olaf Hering wrote:
> > Remove bogomips from /proc/cpuinfo.
> > It is now really bogus since "timebase-frequency" is shown.
>
> Well, but it's still part of the ABI, right?
> How do you determine that there are no broken applications
> still relying on it?
Everything works on a G5, as example. Alpha doesnt have it either.
What pratical value had bogomips for an application?
^ permalink raw reply
* Re: [PATCH] remove bogomips from /proc/cpuinfo
From: Arnd Bergmann @ 2006-07-31 17:46 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackeras, Olaf Hering
In-Reply-To: <20060731125904.GA1997@suse.de>
On Monday 31 July 2006 14:59, Olaf Hering wrote:
> Remove bogomips from /proc/cpuinfo.
> It is now really bogus since "timebase-frequency" is shown.
Well, but it's still part of the ABI, right?
How do you determine that there are no broken applications
still relying on it?
Arnd <><
^ permalink raw reply
* booting with BootX corrupts memory
From: Olaf Hering @ 2006-07-31 17:46 UTC (permalink / raw)
To: linuxppc-dev
Booting an old Mac with BootX corrupts memory, the kernel seldom gets
into init. Even the built-in initramfs archive gets corrupted. So far I
havent figured out where the corruption starts. The only data point so
far is that a passed initrd gets overwritten with stuff that looks like
part of the device-tree after the call to free_area_init_node() from
paging_init(). Perhaps the virtual/real address mapping isnt handled
correctly.
This is broken since at least 2.6.15, 2.6.14 dies very early, 2.6.13 was
still ok.
Symptoms differ, depending on used .config and wether an initrd is passed.
This one is without CONFIG_BOOTX_TEXT.
.....
Using PowerMac machine description
Total memory = 72MB; using 256kB for hash table (at c0a80000)
Linux version 2.6.18-rc3 (olaf@g5) (gcc version 4.1.0 (SUSE Linux)) #39 Mon Jul 31 19:06:09 CEST 2006
1f8b0808 d4015944 0203696e 69747264 20313438 323100ec bd0f7c94 c5b92f3e Found initrd at 0xc04e0000:0xc0ac3b46
Found a Grand Central mac-io controller, rev: 2, mapped at 0xfdf00000
PowerMac motherboard: PowerMac 7200/7300
Cache coherency enabled for bandit/PSX
Found Bandit PCI host bridge at 0x00000000f2000000. Firmware bus number: 0->1
1f8b0808 d4015944 0203696e 69747264 20313438 323100ec bd0f7c94 c5b92f3e paging_init(334) exit
00000400 00000001 ffffffff 00000000 00000000 00000000 c04e0018 c04e0018 paging_init(344) exit
Built 1 zonelists. Total pages: 18432
Kernel command line: ramdisk_size=8192 start_shell nosshkey console=ttyS0,38400 onsole=tty0 video=platinumfb:off minmemory=0 memyasttext=0
irq: Found primary Apple PIC /bandit/gc for 32 irqs
irq: System has 32 possible interrupts
PID hash table entries: 512 (order: 9, 2048 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 56688k/73728k available (2608k kernel code, 16976k reserved, 136k data, 2110k bss, 1472k init)
Mount-cache hash table entries: 512
Unpacking initramfs... done
Freeing initrd memory: 6030k freed
Bad page state in process 'swapper'
page:c04d8f00 flags:0x00000080 mapping:00000000 mapcount:0 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Call Trace:
[C159DF20] [C0007A58] show_stack+0x50/0x184 (unreliable)
[C159DF40] [C0048EDC] bad_page+0x58/0x9c
[C159DF50] [C0049228] free_hot_cold_page+0xa0/0x15c
[C159DF70] [C0011F88] free_initrd_mem+0x70/0xac
[C159DF80] [C011F614] populate_rootfs+0x84/0xa0
[C159DFA0] [C000390C] init+0x2c/0x260
[C159DFF0] [C000F390] kernel_thread+0x44/0x60
Bad page state in process 'swapper'
page:c04d8f20 flags:0x00000080 mapping:00000000 mapcount:0 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Call Trace:
[C159DF20] [C0007A58] show_stack+0x50/0x184 (unreliable)
[C159DF40] [C0048EDC] bad_page+0x58/0x9c
[C159DF50] [C0049228] free_hot_cold_page+0xa0/0x15c
[C159DF70] [C0011F88] free_initrd_mem+0x70/0xac
[C159DF80] [C011F614] populate_rootfs+0x84/0xa0
[C159DFA0] [C000390C] init+0x2c/0x260
[C159DFF0] [C000F390] kernel_thread+0x44/0x60
Bad page state in process 'swapper'
page:c04d8f40 flags:0x00000080 mapping:00000000 mapcount:0 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Call Trace:
[C159DF20] [C0007A58] show_stack+0x50/0x184 (unreliable)
...
^ permalink raw reply
* RE: USB flashdrive on Motorola MPC5200 (IceCube) board, linux ker nel 2.4.25 (DENX drop)
From: Furxhi, Orges @ 2006-07-31 16:35 UTC (permalink / raw)
To: 'Roman Fietze', Furxhi, Orges; +Cc: linuxppc-embedded
Hello,
Thanks for responding,
> > usb.c: USB device not accepting new address=2 (error=-110)
>
> We had that problem on a few of our boards as well.
>
> For the old Icecube exists the possibility to mount two different USB
> transceivers, one of them the ISP1107DH, the other one the
> P11PAPW. Which one of the two is mounted on your board?
The Icecube board has the USBP11A transceiver and our custom board has the
ISP1105 (this has a problem with low speed devices according to PHILIPS).
> On our own boards we had problems with low speed devices and the
> ISP1107, the other transceiver that Freescale used worked
> fine. Connecting those low speed devices via a hub worked.
We get the same message when we connect the hub itself to the USB port
Does anything need to be configured in the kernel to accept the USB hub, if
so which switch is it?
> We ended up using a Fairchild USB1T11A, the ISP1107 seemed to have a
> problem, we just didn't have luck with them. The Fairchild's are pin
> compatible, maybe you just give it a try.
I'll relay this to our hardware guys.
Thanks,
Orges
^ permalink raw reply
* Xilinx PIC and kernel interrupt handler
From: Stig Telfer @ 2006-07-31 13:50 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 825 bytes --]
Hi -
There appears to be a kernel bug in the 2.4 and 2.6.17.7 kernel trees
relating to reading the interrupt vector from the Xilinx PIC
(xilinx_pic_get_irq() in xilinx_pic.c). As I see it, here's the
problem: If no interrupt is pending, the register should read all ones.
However, the IVR is only as wide as the number of interrupt sources.
The routine mistakenly assumes sign extension and checks for a 32-bit
read of -1 instead of a read of w bits where w is the number of
connected interrupt sources.
The 2.6 version also has a search-and-replace glitch relating to
removal of the reversal of bit numbering. I have attached a two line
patch (for 2.6.17.7) that makes the IVR comparison against the right
bit pattern and removes the remnants of the former bit-reversal code.
Share and enjoy,
Stig Telfer
[-- Attachment #2: xilinx_pic.patch --]
[-- Type: application/octet-stream, Size: 475 bytes --]
diff -Naurb linux-2.6.17.7/arch/ppc/syslib/xilinx_pic.c linux-2.6.17.7-stig/arch/ppc/syslib/xilinx_pic.c
--- linux-2.6.17.7/arch/ppc/syslib/xilinx_pic.c 2006-07-25 04:36:01.000000000 +0100
+++ linux-2.6.17.7-stig/arch/ppc/syslib/xilinx_pic.c 2006-07-31 14:20:04.000000000 +0100
@@ -97,8 +97,8 @@
*/
irq = intc_in_be32(intc + IVR);
- if (irq != -1)
- irq = irq;
+ if (irq == (1 << XPAR_INTC_MAX_NUM_INTR_INPUTS) - 1)
+ irq = -1;
pr_debug("get_irq: %d\n", irq);
^ permalink raw reply
* Re: Compilation error in fsl_soc.c
From: Vitaly Bordug @ 2006-07-31 13:39 UTC (permalink / raw)
To: Demke Torsten-atd012; +Cc: linuxppc-embedded
In-Reply-To: <67194FEE6056B947B4EF756C9E497A2EA198F8@zuk35exm60.ds.mot.com>
On Mon, 31 Jul 2006 08:37:56 +0100
"Demke Torsten-atd012" <torsten.demke@motorola.com> wrote:
> Hi all,
>
> with a recent versions from Paulus merge-tree the compilation
> of MPC85xx CDS failed with following output:
> ...
> LD arch/powerpc/lib/built-in.o
> CC arch/powerpc/sysdev/mpic.o
> CC arch/powerpc/sysdev/indirect_pci.o
> AS arch/powerpc/sysdev/dcr.o
> CC arch/powerpc/sysdev/fsl_soc.o
> arch/powerpc/sysdev/fsl_soc.c: In function 'gfar_mdio_of_init':
> arch/powerpc/sysdev/fsl_soc.c:88: error: 'struct device_node' has no
> member name d 'n_intrs'
> arch/powerpc/sysdev/fsl_soc.c:91: error: 'struct device_node' has no
> member name d 'intrs'
> arch/powerpc/sysdev/fsl_soc.c: In function 'gfar_of_init':
> arch/powerpc/sysdev/fsl_soc.c:142: error: 'struct device_node' has no
> member nam ed 'intrs'
> arch/powerpc/sysdev/fsl_soc.c:143: error: 'struct device_node' has no
> member nam ed 'intrs'
> arch/powerpc/sysdev/fsl_soc.c:153: error: 'struct device_node' has no
> member nam ed 'intrs'
> arch/powerpc/sysdev/fsl_soc.c:154: error: 'struct device_node' has no
> member nam ed 'intrs'
> arch/powerpc/sysdev/fsl_soc.c:158: error: 'struct device_node' has no
> member nam ed 'intrs'
> arch/powerpc/sysdev/fsl_soc.c:159: error: 'struct device_node' has no
> member nam ed 'intrs'
> arch/powerpc/sysdev/fsl_soc.c:165: error: 'struct device_node' has no
> member nam ed 'n_intrs'
> arch/powerpc/sysdev/fsl_soc.c: In function 'fsl_i2c_of_init':
> arch/powerpc/sysdev/fsl_soc.c:254: error: 'struct device_node' has no
> member nam ed 'intrs'
> arch/powerpc/sysdev/fsl_soc.c:255: error: 'struct device_node' has no
> member nam ed 'intrs'
> arch/powerpc/sysdev/fsl_soc.c: In function 'fsl_usb_of_init':
> arch/powerpc/sysdev/fsl_soc.c:391: error: 'struct device_node' has no
> member nam ed 'intrs'
> arch/powerpc/sysdev/fsl_soc.c:392: error: 'struct device_node' has no
> member nam ed 'intrs'
> arch/powerpc/sysdev/fsl_soc.c:440: error: 'struct device_node' has no
> member nam ed 'intrs'
> arch/powerpc/sysdev/fsl_soc.c:441: error: 'struct device_node' has no
> member nam ed 'intrs'
> make[1]: *** [arch/powerpc/sysdev/fsl_soc.o] Error 1
> make: *** [arch/powerpc/sysdev] Error 2
No, since it is just going to be out.
I'll submit some patches addressing that this week...
--
Sincerely,
Vitaly
^ permalink raw reply
* DMA buffer synchronisation with ioremap()
From: Phil Nitschke @ 2006-07-31 13:10 UTC (permalink / raw)
To: linuxppc-embedded
(I go no replies last week, so I'll try again, with less explanation...)
If I master a DMA from a PCI device into a main memory buffer allocated
with dma_alloc_noncoherent(), I need to synchronise the destination
buffer using dma_sync_single_range_for_xxx() before and after the DMA.
But if the buffer is a very large chunk of memory (reserved at boot
time) which has been ioremap()-ed into the virtual address space, do I
need to still synchronise that memory?
Thanks,
--
Phil
^ permalink raw reply
* [PATCH] remove bogomips from /proc/cpuinfo
From: Olaf Hering @ 2006-07-31 12:59 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Remove bogomips from /proc/cpuinfo.
It is now really bogus since "timebase-frequency" is shown.
Signed-off-by: Olaf Hering <olh@suse.de>
---
arch/powerpc/kernel/setup-common.c | 14 --------------
1 file changed, 14 deletions(-)
Index: linux-2.6.18-rc3/arch/powerpc/kernel/setup-common.c
===================================================================
--- linux-2.6.18-rc3.orig/arch/powerpc/kernel/setup-common.c
+++ linux-2.6.18-rc3/arch/powerpc/kernel/setup-common.c
@@ -163,14 +163,6 @@ static int show_cpuinfo(struct seq_file
unsigned short min;
if (cpu_id == NR_CPUS) {
-#if defined(CONFIG_SMP) && defined(CONFIG_PPC32)
- unsigned long bogosum = 0;
- int i;
- for_each_online_cpu(i)
- bogosum += loops_per_jiffy;
- seq_printf(m, "total bogomips\t: %lu.%02lu\n",
- bogosum/(500000/HZ), bogosum/(5000/HZ) % 100);
-#endif /* CONFIG_SMP && CONFIG_PPC32 */
seq_printf(m, "timebase\t: %lu\n", ppc_tb_freq);
if (ppc_md.name)
seq_printf(m, "platform\t: %s\n", ppc_md.name);
@@ -263,12 +255,6 @@ static int show_cpuinfo(struct seq_file
seq_printf(m, "revision\t: %hd.%hd (pvr %04x %04x)\n",
maj, min, PVR_VER(pvr), PVR_REV(pvr));
-#ifdef CONFIG_PPC32
- seq_printf(m, "bogomips\t: %lu.%02lu\n",
- loops_per_jiffy / (500000/HZ),
- (loops_per_jiffy / (5000/HZ)) % 100);
-#endif
-
#ifdef CONFIG_SMP
seq_printf(m, "\n");
#endif
^ permalink raw reply
* RE: cpm_dpalloc
From: Li Yang-r58472 @ 2006-07-31 8:56 UTC (permalink / raw)
To: GSM909, linuxppc-embedded
In-Reply-To: <20060731085022.138740@gmx.net>
There is a bug in rheap for alignment. The patch is still hanging =
around. =20
Search rheap and alignment on the linuxppc-dev list for patch previously =
posted.
Best Regards,
Leo
> -----Original Message-----
> From: linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org] On =
Behalf Of
> GSM909@gmx.de
> Sent: Monday, July 31, 2006 4:50 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: cpm_dpalloc
>=20
> Hi All
>=20
> I have a MPC82xx Processor from Freescale with Linux 2.6.14 ( Can=B4t =
chance to an
> new version).
>=20
> My Problem is that I want to allocate a 64byte of memory in the dual =
ported ram
> with an alignment of 64bytes. (Needed for SPI Parameter Ram)
>=20
> the funktion cpm_dpalloc(64,64) returned 0x220 but that are not in a =
64 byte
> alignment.
>=20
> Regards
> Fred
> --
>=20
>=20
> Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> Ideal f=FCr Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* cpm_dpalloc
From: GSM909 @ 2006-07-31 8:50 UTC (permalink / raw)
To: linuxppc-embedded
Hi All
I have a MPC82xx Processor from Freescale with Linux 2.6.14 ( Can´t chance to an new version).
My Problem is that I want to allocate a 64byte of memory in the dual ported ram with an alignment of 64bytes. (Needed for SPI Parameter Ram)
the funktion cpm_dpalloc(64,64) returned 0x220 but that are not in a 64 byte alignment.
Regards
Fred
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* RE: Host USB on MPC8247
From: Li Yang-r58472 @ 2006-07-31 8:23 UTC (permalink / raw)
To: Uros Borovsak, linuxppc-embedded; +Cc: linux-usb-devel
In-Reply-To: <44CDBBDD.6000401@razvoj-verbic.si>
> -----Original Message-----
> From: linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org] On
Behalf Of
> Uros Borovsak
> Sent: Monday, July 31, 2006 4:14 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: Host USB on MPC8247
>=20
> Thanks for reply,
>=20
> I made a mistake while typing the message.
>=20
> In reality I was asking how difficult would it be to port USB part of
> kernel from 2.6.10 to 2.6.13, but I mixed kernel version's when
typing.
USB subsystem is relatively stand-alone. So, try replace the whole
drivers/usb/ directory and update usb related header files under
include/.
ps: the question is off-topic on powerpc list.
>=20
> Mike Rapoport wrote:
> > Uros Borovsak wrote:
> >
> >
> >> Hello,
> >>
> >> Can you at least give me some idea how difficult would it be to
patch
> >> USB part of kernel from 2.6.13 to 2.6.10?
> >>
> >>
> >>
> > As far as I know USB core undergone signifcant changes between
2.6.10
> > and 2.6.13. Still it's hard to tell how difficult would it be to
> > backport USB from 2.6.13 to 2.6.10.
> > Besides, it maybe worth upgrading your kernel instead of backporing
> > USB to 2.6.10.
> >
> >
> Upgrading the whole kernel is not a way to go for me here, becouse
> company is using montavista kernel, and if I upgrade the whole kernel,
I
> would have to port all their patches also.
>=20
> I believe that MontaVista will use higher kernel version some time, so
I
> wouldn't go backporting driver to 2.6.10, but I would prefer to port
USB
> part of kernel from 2.6.10 to 2.6.13.
>=20
> Do you think that is possible and how hard would it be?
>=20
> Best regards
>=20
> Uros
> >> Are changes only in usb part of kernel, or are there also some
> >> changes in other parts of kernel, that I would have to port?
> >>
> >> Thanks,
> >>
> >> Best regards
> >>
> >> Uros
^ permalink raw reply
* Re: Host USB on MPC8247
From: Uros Borovsak @ 2006-07-31 8:14 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <44CDBA3C.2040402@compulab.co.il>
Thanks for reply,
I made a mistake while typing the message.
In reality I was asking how difficult would it be to port USB part of
kernel from 2.6.10 to 2.6.13, but I mixed kernel version's when typing.
Mike Rapoport wrote:
> Uros Borovsak wrote:
>
>
>> Hello,
>>
>> Can you at least give me some idea how difficult would it be to patch
>> USB part of kernel from 2.6.13 to 2.6.10?
>>
>>
>>
> As far as I know USB core undergone signifcant changes between 2.6.10
> and 2.6.13. Still it's hard to tell how difficult would it be to
> backport USB from 2.6.13 to 2.6.10.
> Besides, it maybe worth upgrading your kernel instead of backporing
> USB to 2.6.10.
>
>
Upgrading the whole kernel is not a way to go for me here, becouse
company is using montavista kernel, and if I upgrade the whole kernel, I
would have to port all their patches also.
I believe that MontaVista will use higher kernel version some time, so I
wouldn't go backporting driver to 2.6.10, but I would prefer to port USB
part of kernel from 2.6.10 to 2.6.13.
Do you think that is possible and how hard would it be?
Best regards
Uros
>> Are changes only in usb part of kernel, or are there also some
>> changes in other parts of kernel, that I would have to port?
>>
>> Thanks,
>>
>> Best regards
>>
>> Uros
>>
>>
>>
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>>
>>
>>
>
>
^ permalink raw reply
* Compilation error in fsl_soc.c
From: Demke Torsten-atd012 @ 2006-07-31 7:37 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
with a recent versions from Paulus merge-tree the compilation
of MPC85xx CDS failed with following output:
...
LD arch/powerpc/lib/built-in.o
CC arch/powerpc/sysdev/mpic.o
CC arch/powerpc/sysdev/indirect_pci.o
AS arch/powerpc/sysdev/dcr.o
CC arch/powerpc/sysdev/fsl_soc.o
arch/powerpc/sysdev/fsl_soc.c: In function 'gfar_mdio_of_init':
arch/powerpc/sysdev/fsl_soc.c:88: error: 'struct device_node' has no
member name d 'n_intrs'
arch/powerpc/sysdev/fsl_soc.c:91: error: 'struct device_node' has no
member name d 'intrs'
arch/powerpc/sysdev/fsl_soc.c: In function 'gfar_of_init':
arch/powerpc/sysdev/fsl_soc.c:142: error: 'struct device_node' has no
member nam ed 'intrs'
arch/powerpc/sysdev/fsl_soc.c:143: error: 'struct device_node' has no
member nam ed 'intrs'
arch/powerpc/sysdev/fsl_soc.c:153: error: 'struct device_node' has no
member nam ed 'intrs'
arch/powerpc/sysdev/fsl_soc.c:154: error: 'struct device_node' has no
member nam ed 'intrs'
arch/powerpc/sysdev/fsl_soc.c:158: error: 'struct device_node' has no
member nam ed 'intrs'
arch/powerpc/sysdev/fsl_soc.c:159: error: 'struct device_node' has no
member nam ed 'intrs'
arch/powerpc/sysdev/fsl_soc.c:165: error: 'struct device_node' has no
member nam ed 'n_intrs'
arch/powerpc/sysdev/fsl_soc.c: In function 'fsl_i2c_of_init':
arch/powerpc/sysdev/fsl_soc.c:254: error: 'struct device_node' has no
member nam ed 'intrs'
arch/powerpc/sysdev/fsl_soc.c:255: error: 'struct device_node' has no
member nam ed 'intrs'
arch/powerpc/sysdev/fsl_soc.c: In function 'fsl_usb_of_init':
arch/powerpc/sysdev/fsl_soc.c:391: error: 'struct device_node' has no
member nam ed 'intrs'
arch/powerpc/sysdev/fsl_soc.c:392: error: 'struct device_node' has no
member nam ed 'intrs'
arch/powerpc/sysdev/fsl_soc.c:440: error: 'struct device_node' has no
member nam ed 'intrs'
arch/powerpc/sysdev/fsl_soc.c:441: error: 'struct device_node' has no
member nam ed 'intrs'
make[1]: *** [arch/powerpc/sysdev/fsl_soc.o] Error 1
make: *** [arch/powerpc/sysdev] Error 2
Did I missed a patch?
Regards,
Torsten
^ permalink raw reply
* Re: Host USB on MPC8247
From: Mike Rapoport @ 2006-07-31 8:07 UTC (permalink / raw)
To: Uros Borovsak; +Cc: linuxppc-embedded
In-Reply-To: <44C9F398.4060109@razvoj-verbic.si>
Uros Borovsak wrote:
>Hello,
>
>Can you at least give me some idea how difficult would it be to patch
>USB part of kernel from 2.6.13 to 2.6.10?
>
>
As far as I know USB core undergone signifcant changes between 2.6.10
and 2.6.13. Still it's hard to tell how difficult would it be to
backport USB from 2.6.13 to 2.6.10.
Besides, it maybe worth upgrading your kernel instead of backporing USB
to 2.6.10.
>Are changes only in usb part of kernel, or are there also some changes
>in other parts of kernel, that I would have to port?
>
>Thanks,
>
>Best regards
>
>Uros
>
>
>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
>
>
--
Sincerely yours,
Mike Rapoport
^ permalink raw reply
* Re: [RFC] I2C-MPC: Fix up error handling
From: Jean Delvare @ 2006-07-31 6:57 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Munaut, Sylvain
In-Reply-To: <A18434C2-2C6F-4052-B3F3-AE9D2CE38BE3@kernel.crashing.org>
> > Quoting myself:
> > > Could anyone please comment on this i2c-mpc patch, and give it some
> > > testing on different systems? I'm fine with the error propagation
> > > fixes, but less fine with the random resets being added, and rather
> > > unhappy with the "retry once more just in case" thing, which I think,
> > > if really needed, should instead be implemented using the standard
> > > i2c_adapter.retries mechanism.
> >
> > Can anyone please comment on this patch? Andrew Morton keeps
> > forwarding it to me, but I don't think I can accept it as is (see
> > my complaints above.)
>
> If I find some time, let me split out the error propagation so we can
> get that fix up stream. The other code was to handle a buggy device
> that was connected in one system I was working on.
Sounds like a good plan, thanks.
--
Jean Delvare
^ permalink raw reply
* Re: USB flashdrive on Motorola MPC5200 (IceCube) board, linux ker nel 2.4.25 (DENX drop)
From: Roman Fietze @ 2006-07-31 5:53 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Furxhi, Orges
In-Reply-To: <162B449665D6D643AD9E1D50FC6F4B14042F1C9A@mdcexc05.na.ops.local>
[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]
Hello,
On Saturday 29 July 2006 00:07, Furxhi, Orges wrote:
> usb.c: USB device not accepting new address=2 (error=-110)
We had that problem on a few of our boards as well.
For the old Icecube exists the possibility to mount two different USB
transceivers, one of them the ISP1107DH, the other one the
P11PAPW. Which one of the two is mounted on your board?
On our own boards we had problems with low speed devices and the
ISP1107, the other transceiver that Freescale used worked
fine. Connecting those low speed devices via a hub worked. Sometimes
it helped to add an additional capacitor to the power lines, but
that's not really a viable solution.
We ended up using a Fairchild USB1T11A, the ISP1107 seemed to have a
problem, we just didn't have luck with them. The Fairchild's are pin
compatible, maybe you just give it a try.
Roman
--
Roman Fietze Telemotive AG Büro Mühlhausen
Breitwiesen 73347 Mühlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: please pull powerpc.git 'merge' branch
From: Paul Mackerras @ 2006-07-31 5:37 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do a pull from the "merge" branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
to get the commits listed below.
There is also a set of 5 patches for sound/aoa that need to go in
2.6.18. I'm trying to coordinate with Takashi Iwai about whether he
or I will send you those.
Paul.
arch/powerpc/Kconfig | 2
arch/powerpc/configs/pmac32_defconfig | 112 ++++++++-
arch/powerpc/kernel/head_64.S | 35 +++
arch/powerpc/kernel/legacy_serial.c | 13 +
arch/powerpc/kernel/misc_64.S | 2
arch/powerpc/kernel/prom_init.c | 36 +++
arch/powerpc/kernel/smp.c | 24 +-
arch/powerpc/kernel/udbg_16550.c | 6 -
arch/powerpc/mm/lmb.c | 3
arch/powerpc/platforms/chrp/setup.c | 12 +
arch/powerpc/platforms/maple/setup.c | 17 +
arch/powerpc/platforms/powermac/bootx_init.c | 35 ++-
arch/powerpc/platforms/powermac/cpufreq_64.c | 78 ++++---
arch/powerpc/platforms/pseries/setup.c | 6 -
drivers/ide/Kconfig | 14 -
drivers/macintosh/Kconfig | 11 +
drivers/macintosh/therm_pm72.c | 218 +++++++++++++++++-
drivers/macintosh/therm_pm72.h | 33 +++
drivers/macintosh/via-pmu-led.c | 2
drivers/video/offb.c | 307 ++++++++++++++------------
20 files changed, 703 insertions(+), 263 deletions(-)
Benjamin Herrenschmidt:
[POWERPC] Workaround Pegasos incorrect ISA "ranges"
[POWERPC] Fix 32 bits warning in prom_init.c
[POWERPC] Fix non-MPIC CHRPs with CONFIG_SMP set
[POWERPC] Fix default clock for udbg_16550
[POWERPC] Fix legacy_serial.c error handling on 32 bits
[POWERPC] More offb/bootx fixes
[POWERPC] Xserve G5 thermal control fixes
[POWERPC] Add cpufreq support for Xserve G5
Danny van Dyk:
[POWERPC] PMAC_APM_EMU should depend on ADB_PMU
Geoff Levand:
[POWERPC] Minor comment fix for misc_64.S
Jake Moilanen:
[POWERPC] Use H_CEDE on non-SMT
Johannes Berg:
[POWERPC] fix up front-LED Kconfig
Michael Ellerman:
[POWERPC] Fix mem= handling when the memory limit is > RMO size
Olaf Hering:
[POWERPC] force 64bit mode in fwnmi handlers to workaround firmware bugs
Segher Boessenkool:
[POWERPC] Fix new interrupt code (MPIC endianness)
[POWERPC] Fix new interrupt code (MPIC detection)
^ permalink raw reply
* how to download the ppclinux
From: hpchen @ 2006-07-31 3:47 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 223 bytes --]
hi,all
I've just begun to run linux on MPC8245.
I'll use a graphic card which interface with mpc8245.
Can anyone tell me where i can download the ppclinux
which also contains the driver for graphics card
3X!
[-- Attachment #2: Type: text/html, Size: 3362 bytes --]
^ permalink raw reply
* Re: [PATCH] Add rtas_set_indicator_fast() for RTAS call without extended delay
From: Nathan Lynch @ 2006-07-31 4:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: External List, Milton Miller
In-Reply-To: <17613.33093.767856.432771@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Haren Myneni writes:
>
> > + WARN_ON(rc == -2 || (rc >= 9900 && rc <= 9905));
>
> This worries me... do we know for sure that RTAS will never return a
> busy code? If it could possibly return a busy code, and we can't
> sleep, then we should spin doing the call again and again until it
> works, I think.
The PAPR marks certain RTAS calls as "fast", meaning they must not
return any kind of busy status. Manipulating the GIQ (set-indicator
with token 9005) is defined as "fast".
^ permalink raw reply
* Re: [PATCH][2/2] RTAS MSI
From: Michael Ellerman @ 2006-07-31 4:33 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1154024834.29826.240.camel@goblue>
[-- Attachment #1: Type: text/plain, Size: 3003 bytes --]
On Thu, 2006-07-27 at 13:27 -0500, Jake Moilanen wrote:
> Rebased with the IRQ layer rewrite. The code is not deallocating the
> vectors on a pci_disable_msi(). This is to work around a firmware
> vector release bug. Plus it is really not needed, as
> irq_create_mapping() just returns mappings to irqs that it knows of.
>
> Additionally, the patch includes the client architecture bit for MSI,
> and correctly identifying that MSI is edge triggered.
Hey Jake, just a few niggles below ..
> Index: 2.6-msi/drivers/pci/msi-rtas.c
> ===================================================================
> --- /dev/null
> +++ 2.6-msi/drivers/pci/msi-rtas.c
> @@ -0,0 +1,111 @@
> +/*
> + * Jake Moilanen <moilanen@austin.ibm.com>
> + * Copyright (C) 2006 IBM
> + *
> + * 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; version 2 of the
> + * License.
> + *
> + */
> +
> +#include <linux/pci.h>
> +#include <linux/irq.h>
> +#include <asm/rtas.h>
> +#include <asm/hw_irq.h>
> +#include <asm/ppc-pci.h>
> +
> +int rtas_enable_msi(struct pci_dev* pdev)
> +{
> + static int seq_num = 1;
Do we really want seq_num to be static? By my reading of PAPR we only
need to maintain the seq number across calls that return -2/990x, and we
handle that all inside this function. If it does need to be unique for
_all_ calls, then I don't see how seq_num being static is going to work,
a different cpu could stomp on the seq_num value between calls, which
presumably would make firmware mad.
> + int i;
> + int rc;
> + int query_token = rtas_token("ibm,query-interrupt-source-number");
> + int devfn;
> + int busno;
> + u32 *reg;
> + int reglen;
> + int ret[3];
You only need ret[2] I think, the first return value (status) is handled
inside rtas_call for you.
> + int dummy;
> + int n_intr;
> + int last_virq = NO_IRQ;
> + int virq;
> + unsigned int addr;
> + unsigned long buid = -1;
No need to set buid to -1 as you unconditionally assign to it later.
> + struct device_node * dn;
> +
> + dn = pci_device_to_OF_node(pdev);
> +
> + if (!of_find_property(dn, "ibm,req#msi", &dummy))
> + return -ENOENT;
You don't need dummy, just pass NULL.
> +
> + reg = (u32 *) get_property(dn, "reg", ®len);
> + if (reg == NULL || reglen < 20)
> + return -ENXIO;
> +
> + devfn = (reg[0] >> 8) & 0xff;
> + busno = (reg[0] >> 16) & 0xff;
> +
> + buid = get_phb_buid(dn->parent);
> + addr = (busno << 16) | (devfn << 8);
Why do we need to read the reg here, can't we just use the existing
fields? ie:
addr = (pdev->bus->number << 16) | (pdev->devfn << 8);
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH][2/2] RTAS MSI
From: Paul Mackerras @ 2006-07-31 4:07 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev
In-Reply-To: <1154024834.29826.240.camel@goblue>
Jake Moilanen writes:
> -msiobj-y := msi.o msi-apic.o
> -msiobj-$(CONFIG_IA64_GENERIC) += msi-altix.o
> -msiobj-$(CONFIG_IA64_SGI_SN2) += msi-altix.o
> +msiobj-$(CONFIG_X86) += msi.o msi-apic.o
> +msiobj-$(CONFIG_IA64) += msi.o msi-apic.o
> +msiobj-$(CONFIG_IA64_GENERIC) += msi.o msi-apic.o msi-altix.o
> +msiobj-$(CONFIG_IA64_SGI_SN2) += msi.o msi-apic.o msi-altix.o
Doesn't this mean that ia64 configs might now get msi.o and msi-apic.o
listed twice? Why did you need to change the
msiobj-$(CONFIG_IA64_GENERIC) and msiobj-$(CONFIG_IA64_SGI_SN2) lines
at all?
Paul.
^ permalink raw reply
* Re: [PATCH] Add rtas_set_indicator_fast() for RTAS call without extended delay
From: Paul Mackerras @ 2006-07-31 4:04 UTC (permalink / raw)
To: Haren Myneni; +Cc: External List, Nathan Lynch, Milton Miller
In-Reply-To: <44C9301C.7080300@us.ibm.com>
Haren Myneni writes:
> + WARN_ON(rc == -2 || (rc >= 9900 && rc <= 9905));
This worries me... do we know for sure that RTAS will never return a
busy code? If it could possibly return a busy code, and we can't
sleep, then we should spin doing the call again and again until it
works, I think.
Paul.
^ permalink raw reply
* Help for IDMA/DMA PCI on MPC8250
From: jimmy liu @ 2006-07-30 22:39 UTC (permalink / raw)
To: embedded linuxppc
Did anyone use IDMA/DMA for PCI transactions
on MPC8250? Where I can find the sample driver code?
Thanks.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [RFC] I2C-MPC: Fix up error handling
From: Kumar Gala @ 2006-07-30 16:23 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, Sylvain Munaut
In-Reply-To: <20060730131440.1d4fcbe6.khali@linux-fr.org>
On Jul 30, 2006, at 6:14 AM, Jean Delvare wrote:
> Quoting myself:
>> Could anyone please comment on this i2c-mpc patch, and give it some
>> testing on different systems? I'm fine with the error propagation
>> fixes, but less fine with the random resets being added, and rather
>> unhappy with the "retry once more just in case" thing, which I think,
>> if really needed, should instead be implemented using the standard
>> i2c_adapter.retries mechanism.
>
> Can anyone please comment on this patch? Andrew Morton keeps
> forwarding
> it to me, but I don't think I can accept it as is (see my complaints
> above.)
If I find some time, let me split out the error propagation so we can
get that fix up stream. The other code was to handle a buggy device
that was connected in one system I was working on.
- kumar
>> From: Kumar Gala <galak@kernel.crashing.org>
>>
>> * If we have an Unfinished (MCF) or Arbitration Lost (MAL) error and
>> the bus is still busy reset the controller. This prevents the
>> controller from getting in a hung state for transactions for other
>> devices.
>>
>> * Fixed up propogating the errors from i2c_wait.
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> Cc: Jean Delvare <khali@linux-fr.org>
>> Cc: Greg KH <greg@kroah.com>
>> Signed-off-by: Andrew Morton <akpm@osdl.org>
>> ---
>>
>> drivers/i2c/busses/i2c-mpc.c | 43 ++++++++++++++++++++++
>> +----------
>> 1 file changed, 31 insertions(+), 12 deletions(-)
>>
>> diff -puN drivers/i2c/busses/i2c-mpc.c~i2c-mpc-fix-up-error-
>> handling drivers/i2c/busses/i2c-mpc.c
>> --- devel/drivers/i2c/busses/i2c-mpc.c~i2c-mpc-fix-up-error-
>> handling 2006-06-01 20:22:55.000000000 -0700
>> +++ devel-akpm/drivers/i2c/busses/i2c-mpc.c 2006-06-01
>> 20:22:55.000000000 -0700
>> @@ -115,11 +115,20 @@ static int i2c_wait(struct mpc_i2c *i2c,
>>
>> if (!(x & CSR_MCF)) {
>> pr_debug("I2C: unfinished\n");
>> +
>> + /* reset the controller if the bus is still busy */
>> + if (x & CSR_MBB)
>> + writeccr(i2c, 0);
>> +
>> return -EIO;
>> }
>>
>> if (x & CSR_MAL) {
>> pr_debug("I2C: MAL\n");
>> +
>> + /* reset the controller if the bus is still busy */
>> + if (x & CSR_MBB)
>> + writeccr(i2c, 0);
>> return -EIO;
>> }
>>
>> @@ -160,7 +169,7 @@ static void mpc_i2c_stop(struct mpc_i2c
>> static int mpc_write(struct mpc_i2c *i2c, int target,
>> const u8 * data, int length, int restart)
>> {
>> - int i;
>> + int i, ret;
>> unsigned timeout = i2c->adap.timeout;
>> u32 flags = restart ? CCR_RSTA : 0;
>>
>> @@ -172,15 +181,17 @@ static int mpc_write(struct mpc_i2c *i2c
>> /* Write target byte */
>> writeb((target << 1), i2c->base + MPC_I2C_DR);
>>
>> - if (i2c_wait(i2c, timeout, 1) < 0)
>> - return -1;
>> + ret = i2c_wait(i2c, timeout, 1);
>> + if (ret < 0)
>> + return ret;
>>
>> for (i = 0; i < length; i++) {
>> /* Write data byte */
>> writeb(data[i], i2c->base + MPC_I2C_DR);
>>
>> - if (i2c_wait(i2c, timeout, 1) < 0)
>> - return -1;
>> + ret = i2c_wait(i2c, timeout, 1);
>> + if (ret < 0)
>> + return ret;
>> }
>>
>> return 0;
>> @@ -190,7 +201,7 @@ static int mpc_read(struct mpc_i2c *i2c,
>> u8 * data, int length, int restart)
>> {
>> unsigned timeout = i2c->adap.timeout;
>> - int i;
>> + int i, ret;
>> u32 flags = restart ? CCR_RSTA : 0;
>>
>> /* Start with MEN */
>> @@ -201,8 +212,9 @@ static int mpc_read(struct mpc_i2c *i2c,
>> /* Write target address byte - this time with the read flag set */
>> writeb((target << 1) | 1, i2c->base + MPC_I2C_DR);
>>
>> - if (i2c_wait(i2c, timeout, 1) < 0)
>> - return -1;
>> + ret = i2c_wait(i2c, timeout, 1);
>> + if (ret < 0)
>> + return ret;
>>
>> if (length) {
>> if (length == 1)
>> @@ -214,8 +226,9 @@ static int mpc_read(struct mpc_i2c *i2c,
>> }
>>
>> for (i = 0; i < length; i++) {
>> - if (i2c_wait(i2c, timeout, 0) < 0)
>> - return -1;
>> + ret = i2c_wait(i2c, timeout, 0);
>> + if (ret < 0)
>> + return ret;
>>
>> /* Generate txack on next to last byte */
>> if (i == length - 2)
>> @@ -246,8 +259,13 @@ static int mpc_xfer(struct i2c_adapter *
>> return -EINTR;
>> }
>> if (time_after(jiffies, orig_jiffies + HZ)) {
>> - pr_debug("I2C: timeout\n");
>> - return -EIO;
>> + writeccr(i2c, 0);
>> +
>> + /* try one more time before we error */
>> + if (readb(i2c->base + MPC_I2C_SR) & CSR_MBB) {
>> + pr_debug("I2C: timeout\n");
>> + return -EIO;
>> + }
>> }
>> schedule();
>> }
>> @@ -325,6 +343,7 @@ static int fsl_i2c_probe(struct platform
>> goto fail_irq;
>> }
>>
>> + writeccr(i2c, 0);
>> mpc_i2c_setclock(i2c);
>> platform_set_drvdata(pdev, i2c);
>
> --
> Jean Delvare
^ 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