* (no subject)
From: ramesh mrm @ 2007-08-21 9:25 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 447 bytes --]
Hai,
I am using the kernel 2.6.21. In the file
(arch/ppc/syslib/pci_auto.c) we have the function pciauto_bus_scan(). In
this function it will skip the host birdge. But in the arch/powepc
directory we don't have that types of file and the function
pciauto_bus_scan() also removed.
I want to know where the function was moved in arch/powerpc directory ?
How the host bridge was skip in the arch/powerpc directory.
Thanks and Regards
Ramesh
[-- Attachment #2: Type: text/html, Size: 553 bytes --]
^ permalink raw reply
* Re: Driver for device behind a PCI-VME bridge
From: Konstantin Boyanov @ 2007-08-21 9:49 UTC (permalink / raw)
To: Johan Borkhuis; +Cc: linuxppc-embedded
In-Reply-To: <46CAA332.9060907@dutchspace.nl>
[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]
Hi again,
I also work with devices on the VME bus. The approach we took is to map
> all the devices into userspace, and use Xenomai for RT performance. This
> avoids the need to write drivers for all the devices. The RT-performance
> of Xenomai is quite good: the jitter on a timer-interrupt is always less
> than 20usec, even under high load, where standard Linux only achieves
> this in a no load situatieo, under high load standard Linux has a jitter
> of over 10 msec.
Good advice, I will investigate in this direction.
The setup we choose was to have a RT-interrupt handler and a RT IOCTL
> call "WAIT_FOR_INTERRUPT". This is a slightly modified version from the
> Motorola driver (I guess that you also use the Tundra chipset to access
> the VME-bus).
Yes, I do. It is the Tsi148 in fact. I'll be interested to see some sample
code of yours, if it doesn't violate some restrictions ofcourse.
Here you can wait for a specific VME interrupt-level, and
> it returns the vector number. So you can have several applications
> connect to the same VME driver, but all on different levels.
So, if I understand you correctly, you altered the Motorola driver in order
for it to be able to communicate with user spae programms through Xenomai.
Which version of Xenomai ws that? I tried to test Xemonai 2.0 on my setup
but it iterfred somehow with SSH configuration and thats why i dropped it.
Many thanks,
Konstantin
[-- Attachment #2: Type: text/html, Size: 2017 bytes --]
^ permalink raw reply
* OF /chosen/initrd,* variables - patch, official?
From: Matt Sealey @ 2007-08-21 11:12 UTC (permalink / raw)
To: ppc-dev, linuxppc-embedded
Hi guys,
Just a query here, there was a patch for /chosen/initrd,start and initrd,end
variables gained from firmware or so, which allowed booting without getting
those values into r3/r4, does anyone know the maintainer/author of that
patch?
Also, what are the chances of pushing it for 2.6.23 or 2.6.24? I can imagine
it's fairly useful (at least it is to me)..
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: OF /chosen/initrd,* variables - patch, official?
From: Matt Sealey @ 2007-08-21 11:21 UTC (permalink / raw)
To: ppc-dev, linuxppc-embedded
In-Reply-To: <46CAC89F.2040100@genesi-usa.com>
Damn, I should use patchwork more efficiently;
http://patchwork.ozlabs.org/linuxppc/patch?q=initrd&filter=none&id=12168
Does anyone have any suggestion on the best way to integrate this so that
it "just works" on OF platforms? It seems only to be usable way too late
in boot to work, this code would have to be called in boot/main.c which seems
relatively.. impossible to achieve.. or called in some specialised platform
init code..
I hacked up a patch initially before I saw Milton's work and did it all
in main.c (and did the same to mkvmlinuz..) and it seemed to work okay
there.
I'm really curious as to the status and usefulness of this here.. :(
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Matt Sealey wrote:
> Hi guys,
>
> Just a query here, there was a patch for /chosen/initrd,start and initrd,end
> variables gained from firmware or so, which allowed booting without getting
> those values into r3/r4, does anyone know the maintainer/author of that
> patch?
>
> Also, what are the chances of pushing it for 2.6.23 or 2.6.24? I can imagine
> it's fairly useful (at least it is to me)..
>
^ permalink raw reply
* Re: OF /chosen/initrd,* variables - patch, official?
From: David Gibson @ 2007-08-21 11:32 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppc-dev, linuxppc-embedded
In-Reply-To: <46CACAAE.5000304@genesi-usa.com>
On Tue, Aug 21, 2007 at 12:21:18PM +0100, Matt Sealey wrote:
> Damn, I should use patchwork more efficiently;
>
> http://patchwork.ozlabs.org/linuxppc/patch?q=initrd&filter=none&id=12168
>
> Does anyone have any suggestion on the best way to integrate this so that
> it "just works" on OF platforms? It seems only to be usable way too late
> in boot to work, this code would have to be called in boot/main.c which seems
> relatively.. impossible to achieve.. or called in some specialised platform
> init code..
It would have to be called from platform_init(). If called in main()
it would clobber any other platform-specific initialization of the
initrd parameters in loader_info.
> I hacked up a patch initially before I saw Milton's work and did it all
> in main.c (and did the same to mkvmlinuz..) and it seemed to work okay
> there.
>
> I'm really curious as to the status and usefulness of this here.. :(
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: PS3 improved video mode autodetection for HDMI/DVI
From: Stefan Assmann @ 2007-08-21 11:58 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Cell Broadband Engine OSS Development,
Ben Collins
In-Reply-To: <Pine.LNX.4.62.0708201740080.6197@pademelon.sonytel.be>
Geert Uytterhoeven schrieb:
> I know you could get the PS3AV_CID_AV_VIDEO_DISABLE_SIG message in some cases
> when booting immediately into a VESA mode.
>
> I see you have
>
> CONFIG_CMDLINE="quiet sysrq=1 panic=42 video=ps3fb:mode:0"
>
> Does it go away if you remove the `video=...'?
>
removing video=ps3fb:mode:0 from CONFIG_CMDLINE has no effect.
Stefan
^ permalink raw reply
* Regarding PCIExpress Problem in MPC8641D
From: sivaji @ 2007-08-21 12:09 UTC (permalink / raw)
To: linuxppc-dev
Hai,
Currently I am involved in the testing of a MPC8641D based board designed by
us. We have planned to test the PCI Express interface through a back to back
interface, host being mpc8641d and target is mpc8548.
When trying a target DMA transaction we are not able to access the host
memory using pci Express bus. We are facingDMA Transfer Error. Without DMA
we are able to access the host memory from the target and target memory from
the host.
The processor rev number is 2.0. The external irq[0-3] are pulled down and
the polarity is active low and it is level sensitive.
Memory base address : 0x80000000 size:512MB
I/O base address : 0xe2000000 size:16MB.
Kernel Version : 2.6.21
PCI Express device node in the device tree:
pci@8000 {
compatible = "fsl,mpc86xx-pciex";
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <8000 1000>;
bus-range = <0 fe>;
ranges = <02000000 0 80000000 80000000 0 20000000
01000000 0 00000000 e2000000 0 01000000>;
clock-frequency = <1fca055>;
interrupt-parent = <40000>;
interrupts = <18 2>;
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x0 (PEX) */
0000 0 0 1 40000 30 2
0000 0 0 2 40000 31 2
0000 0 0 3 40000 32 2
0000 0 0 4 40000 33 2 >;
};
lspci result:
00:00.0 Class 0b20: 1957:7011 (rev 20)
!!! Invalid class 0b20 for header type 01
Flags: bus master, fast devsel, latency 0
Memory at 80400000 (32-bit, non-prefetchable) [size=1M]
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00000000-00000fff
Memory behind bridge: 9ff00000-9fffffff
Prefetchable memory behind bridge: 000000009fe00000-000000009fe00000
Capabilities: [44] Power Management version 2
Capabilities: [4c] #10 [0041]
00: 57 19 11 70 06 01 10 00 20 00 20 0b 00 00 01 00
10: 00 00 40 80 00 00 00 00 00 01 01 00 00 00 00 20
20: f0 9f f0 9f e1 9f e1 9f 00 00 00 00 00 00 00 00
30: 00 00 00 00 44 00 00 00 00 00 00 00 00 00 00 00
01:00.0 Class 0b20: 1957:0012 (rev 20) (prog-if 01)
Flags: bus master, fast devsel, latency 0, IRQ 48
Memory at 80000000 (32-bit, non-prefetchable) [size=1M]
Memory at 80100000 (32-bit, non-prefetchable) [size=1M]
Memory at 80200000 (64-bit, non-prefetchable) [size=1M]
Memory at 80300000 (64-bit, non-prefetchable) [size=1M]
Capabilities: [44] Power Management version 2
Capabilities: [4c] #10 [0001]
Capabilities: [70] Message Signalled Interrupts: 64bit+ Queue=0/4
Enable-
00: 57 19 12 00 06 00 10 00 20 01 20 0b 08 00 00 00
10: 00 00 00 80 00 00 10 80 04 00 20 80 00 00 00 00
20: 04 00 30 80 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 44 00 00 00 00 00 00 00 00 01 00 00
Host config space result(the value was taken in the kernel):
Vendor ID = 0x1957
Device ID = 0x7011
Command Register = 0x106
Status Register = 0x10
Revision ID = 0x20
Base class = 0x0
Sub Class = 0x20
Programming Interface = 0xb
Cache line register = 0x0
Latency Timer = 0x0
Header type = 0x1
BAR Address Register 0 = 0x80400000
Primary Bus Number Register = 0x0
Secondary Bus Number Register = 0x1
Subordinate Bus Number Register = 0x1
PCI Express I/O Base Register :0x0
PCI Express I/O Limit Register = 0x0
PCI Express Secondary Status Register = 0x2000
PCI Express Memory Base Register = 0x9ff0
PCI Express Memory I/O Limit Register = 0x9ff0
PCI Express Prefetchable Memory Base Register = 0x9fe1
PCI Express Prefetchable Memory Limit Register = 0x9fe1
PCI Express Prefetchable Base Upper 32 BitsRegister = 0x0
PCI Express Prefetchable Limite Upper 32 BitsRegister = 0x0
PCI Express I/O Base upper 16 BitsRegister = 0x0
PCI Express I/O Limit upper 16 BitsRegister = 0x0
PCI Express Capabilites pointer Register = 0x44
PCI Express Interrupt Line Register = 0x0
PCI Express Interrupt Pin Register = 0x0
PCI Express Bridge Control Register = 0x0
Please advice me.
--
View this message in context: http://www.nabble.com/Regarding-PCIExpress-Problem-in-MPC8641D-tf4304754.html#a12253307
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Skipping the host bridge in arch/powerpc
From: sivaji @ 2007-08-21 12:13 UTC (permalink / raw)
To: linuxppc-dev
Hai,
I am using the kernel 2.6.21. In the file
(arch/ppc/syslib/pci_auto.c) we have the function pciauto_bus_scan(). In
this function it will skip the host birdge. But in the arch/powepc directory
we don't have that types of file and the function pciauto_bus_scan() also
removed.
I want to know where the function was moved in arch/powerpc directory ?
How the host bridge was skip in the arch/powerpc directory.
--
View this message in context: http://www.nabble.com/Skipping-the-host-bridge-in-arch-powerpc-tf4304798.html#a12253417
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Linux 2.6.23.rc3 boot issues on XUPV2P
From: Computer - Service @ 2007-08-21 12:19 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20070821113232.GB1111@localhost.localdomain>
Hi all.
I try to port Linux 2.6 on my XUPV2P Board which is based on ML300.
It runs sometimes, but for the usual case it just doesn't.
My problem is the initialization.
I have no clue why I get different values almost every time.
This is a log from the same zImage.elf, which is just loaded certain
times in the row:
loaded at: 00400000 005331A0
board data at: 0000000E 0000008A
relocated to: 00404084 00404100
zimage at: 00404EB9 00530A50
avail ram: 00534000 3B784800
Linux/PPC load: console=ttyS0,9600
Uncompressing Linux...done.
Now booting the kernel
loaded at: 00400000 005331A0
board data at: 00000000 0000007C
relocated to: 00404084 00404100
zimage at: 00404EB9 00530A50
avail ram: 00534000 7C9E2378
Linux/PPC load: console=ttyS0,9600
Uncompressing Linux...done.
Now booting the kernel
loaded at: 00400000 005331A0
board data at: 40000000 4000007C
relocated to: 00404084 00404100
zimage at: 00404EB9 00530A50
avail ram: 00534000 00000000
Linux/PPC load: console=ttyS0,9600
Uncompressing Linux...oops... out of memory
pause
loaded at: 00400000 005331A0
board data at: 00000001 0000007D
relocated to: 00404084 00404100
zimage at: 00404EB9 00530A50
avail ram: 00534000 9E23787C
Linux/PPC load: console=ttyS0,9600
Uncompressing Linux...done.
Now booting the kernel
[ 0.000000] Linux version 2.6.23-rc3 (warkentin@iss2) (gcc version
4.1.1) #1 Tue Aug 21 14:01:45
CEST 2007
[ 0.000000] Xilinx ML300 Reference System (Virtex-II Pro)
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0 -> 196608
and just if the "avial ram" is about 10000000 it boots.
Anyone some idea why it could happens?
^ permalink raw reply
* Re: OF /chosen/initrd,* variables - patch, official?
From: Matt Sealey @ 2007-08-21 12:36 UTC (permalink / raw)
To: Matt Sealey, ppc-dev, linuxppc-embedded
In-Reply-To: <20070821113232.GB1111@localhost.localdomain>
David Gibson wrote:
> On Tue, Aug 21, 2007 at 12:21:18PM +0100, Matt Sealey wrote:
>> Damn, I should use patchwork more efficiently;
>>
>> http://patchwork.ozlabs.org/linuxppc/patch?q=initrd&filter=none&id=12168
>>
>> Does anyone have any suggestion on the best way to integrate this so that
>> it "just works" on OF platforms? It seems only to be usable way too late
>> in boot to work, this code would have to be called in boot/main.c which seems
>> relatively.. impossible to achieve.. or called in some specialised platform
>> init code..
>
> It would have to be called from platform_init(). If called in main()
> it would clobber any other platform-specific initialization of the
> initrd parameters in loader_info.
So just to get this straight.. platform_init would be the function called from
md.init or would be better at md.setup_arch?
My goal right now is get something for CHRP (Pegasos) and Efika and try not
to cause problems for anything else, but also really try not to clutter the
thing with config checks, platform checks etc.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: OF /chosen/initrd,* variables - patch, official?
From: David Gibson @ 2007-08-21 12:42 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppc-dev, linuxppc-embedded
In-Reply-To: <46CADC61.3050506@genesi-usa.com>
On Tue, Aug 21, 2007 at 01:36:49PM +0100, Matt Sealey wrote:
> David Gibson wrote:
> > On Tue, Aug 21, 2007 at 12:21:18PM +0100, Matt Sealey wrote:
> >> Damn, I should use patchwork more efficiently;
> >>
> >> http://patchwork.ozlabs.org/linuxppc/patch?q=initrd&filter=none&id=12168
> >>
> >> Does anyone have any suggestion on the best way to integrate this so that
> >> it "just works" on OF platforms? It seems only to be usable way too late
> >> in boot to work, this code would have to be called in boot/main.c which seems
> >> relatively.. impossible to achieve.. or called in some specialised platform
> >> init code..
> >
> > It would have to be called from platform_init(). If called in main()
> > it would clobber any other platform-specific initialization of the
> > initrd parameters in loader_info.
>
> So just to get this straight.. platform_init would be the function
> called from md.init or would be better at md.setup_arch?
Uh... no... this is in the bootwrapper, long before ppc_md even
exists. platform_init() is called from arch/powerpc/boot/crt0.S,
immediately before main().
> My goal right now is get something for CHRP (Pegasos) and Efika and try not
> to cause problems for anything else, but also really try not to clutter the
> thing with config checks, platform checks etc.
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 0/3 v2] Remove need for include/asm-ppc
From: Arnd Bergmann @ 2007-08-21 12:05 UTC (permalink / raw)
To: Josh Boyer, Scott Wood, linuxppc-dev
In-Reply-To: <20070821025015.GN15469@localhost.localdomain>
On Tuesday 21 August 2007, David Gibson wrote:
>=20
> > > > The point would be to keep the two trees separate, so that one
> > > > doesn't need to worry about breaking arch/ppc when making a change
> > > > to arch/powerpc.
> > >=20
> > > Exactly so. =A0Having to be careful about not breaking arch/ppc when
> > > doing cleanups for arch/powerpc is a pain in the bum.
> >=20
> > How many times has that happened recently? =A0If it's fairly infrequent,
>=20
> It's infrequent because I've shyed away from cleaning up shared files,
> precisely because I'm afraid of breaking arch/ppc.
How about splitting the files on a per-case bases then? There are at least
95 files that would need to be duplicated (again) to make ppc independent
from powerpc, and most of these files are about userland interfaces where
duplication makes no sense at all.
Some files in there (irq.h, ipic.h, dcr.h, i8259.h) already have large
parts hidden in #ifdef CONFIG_PPC_MERGE, so I guess for those it may
actually be interesting to split them in two again.
Arnd <><
^ permalink raw reply
* Re: Linux 2.6.23.rc3 boot issues on XUPV2P
From: Grant Likely @ 2007-08-21 12:52 UTC (permalink / raw)
To: Computer - Service; +Cc: linuxppc-embedded
In-Reply-To: <46CAD865.3030107@gmx.de>
On 8/21/07, Computer - Service <computer-service@gmx.de> wrote:
> Hi all.
>
> I try to port Linux 2.6 on my XUPV2P Board which is based on ML300.
>
> It runs sometimes, but for the usual case it just doesn't.
> My problem is the initialization.
> I have no clue why I get different values almost every time.
> This is a log from the same zImage.elf, which is just loaded certain
> times in the row:
Check that the Virtex support code in
arch/ppc/boot/simple/embed_config.c is getting compiled in (hint:
search for ML403). If it's configured out, then your board info
structure won't get setup correctly.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 0/3 v2] Remove need for include/asm-ppc
From: Josh Boyer @ 2007-08-21 12:56 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200708211405.59226.arnd@arndb.de>
On Tue, 21 Aug 2007 14:05:58 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 21 August 2007, David Gibson wrote:
> >=20
> > > > > The point would be to keep the two trees separate, so that one
> > > > > doesn't need to worry about breaking arch/ppc when making a change
> > > > > to arch/powerpc.
> > > >=20
> > > > Exactly so. =C2=A0Having to be careful about not breaking arch/ppc =
when
> > > > doing cleanups for arch/powerpc is a pain in the bum.
> > >=20
> > > How many times has that happened recently? =C2=A0If it's fairly infre=
quent,
> >=20
> > It's infrequent because I've shyed away from cleaning up shared files,
> > precisely because I'm afraid of breaking arch/ppc.
>=20
> How about splitting the files on a per-case bases then? There are at least
> 95 files that would need to be duplicated (again) to make ppc independent
> from powerpc, and most of these files are about userland interfaces where
> duplication makes no sense at all.
Sure. I said that in my previous reply too.
> Some files in there (irq.h, ipic.h, dcr.h, i8259.h) already have large
> parts hidden in #ifdef CONFIG_PPC_MERGE, so I guess for those it may
> actually be interesting to split them in two again.
Yeah, for those it might.
josh
^ permalink raw reply
* Re: Xilinx Virtex4 FX PPC
From: Josh Boyer @ 2007-08-21 12:57 UTC (permalink / raw)
To: Stelios Koroneos; +Cc: linuxppc-embedded
In-Reply-To: <HOECLKEKOHLAMMGDLLBHEEGHMAAA.stelios@stelioscellar.com>
On Tue, 21 Aug 2007 11:52:35 +0300
"Stelios Koroneos" <stelios@stelioscellar.com> wrote:
> > Question 1:
> > Do I need a special glibc for the Xilinx PPC 405????
>
> FYI we are at the last stage of implementing OpenEmbedded support for the
> Xilinx ml403 (and hopefully other Xilinx boards in the near future)
Cool.
> It also handles the EDK header copying procedure "automagically" i.e you
> point to your EDK project dir and pulls the file(s) it needs for the kernel.
> We will be working to "automate" the generation of ACE files also, since OE
> generates a full image (kernel+fs) and not just the toolchain.
> Currently toolchain is gcc 4.1.1 with glibc 2.5 and/or uclibc 0.9.28.
> There is some work done by other OE developers to get eglibc going (omap
> works according to the latest info i have)
>
> OpenEmbedded supports a number of ppc targets currently walnut
> (405),sequoia(440e),efika(603e) just to mention a few
>
> I will be speaking at the Power.org dev conference about OE and power
> architecure so if anyone will be there and wishes to get some knowledge
> about OE in "advance" , feel free to drop me a mail, as we will releasing a
> beta of our OE based distro soon.
I'm hoping to attend as well. Should be interesting.
josh
^ permalink raw reply
* Re: OF /chosen/initrd,* variables - patch, official?
From: Matt Sealey @ 2007-08-21 12:58 UTC (permalink / raw)
To: Matt Sealey, ppc-dev, linuxppc-embedded
In-Reply-To: <20070821124253.GC1111@localhost.localdomain>
David Gibson wrote:
> Uh... no... this is in the bootwrapper, long before ppc_md even
> exists. platform_init() is called from arch/powerpc/boot/crt0.S,
> immediately before main().
Oh *THAT* platform init.
So I could just drop a
} else {
dt_find_initrd();
}
.. at the end and nobody would be too disgusted or have any problems?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: Regarding PCIExpress Problem in MPC8641D
From: Kumar Gala @ 2007-08-21 13:15 UTC (permalink / raw)
To: sivaji; +Cc: linuxppc-dev
In-Reply-To: <12253307.post@talk.nabble.com>
On Aug 21, 2007, at 7:09 AM, sivaji wrote:
>
> Hai,
>
> Currently I am involved in the testing of a MPC8641D based board
> designed by
> us. We have planned to test the PCI Express interface through a
> back to back
> interface, host being mpc8641d and target is mpc8548.
>
> When trying a target DMA transaction we are not able to access the
> host
> memory using pci Express bus. We are facingDMA Transfer Error.
> Without DMA
> we are able to access the host memory from the target and target
> memory from
> the host.
>
>
> The processor rev number is 2.0. The external irq[0-3] are pulled
> down and
> the polarity is active low and it is level sensitive.
>
> Memory base address : 0x80000000 size:512MB
> I/O base address : 0xe2000000 size:16MB.
> Kernel Version : 2.6.21
I suggest upgrading to 2.6.23-rc3. There are a number of PCIe
related fixes that have gone in.
- k
^ permalink raw reply
* Re: Skipping the host bridge in arch/powerpc
From: Kumar Gala @ 2007-08-21 13:17 UTC (permalink / raw)
To: sivaji; +Cc: linuxppc-dev
In-Reply-To: <12253417.post@talk.nabble.com>
On Aug 21, 2007, at 7:13 AM, sivaji wrote:
>
> Hai,
> I am using the kernel 2.6.21. In the file
> (arch/ppc/syslib/pci_auto.c) we have the function pciauto_bus_scan
> (). In
> this function it will skip the host birdge. But in the arch/powepc
> directory
> we don't have that types of file and the function pciauto_bus_scan
> () also
> removed.
> I want to know where the function was moved in arch/powerpc
> directory ?
This code doesn't exist in arch/powerpc we use more of the generic
drivers/pci code
> How the host bridge was skip in the arch/powerpc directory.
Again, if you look 2.6.23-rc3 there have been some fixes so you don't
need to skip the host bridge anymore for Freescale PPC.
- k
^ permalink raw reply
* [PATCH v4 0/2] SPI support for fsl_soc and mpc832x_rdb
From: Anton Vorontsov @ 2007-08-21 13:45 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
Thanks for the previous reviews, this is v4 against Linus' tree,
as of today.
Changelog:
v3 -> v4
- removed fsl,device-id property from SPI nodes;
- instead of fsl_spi_info structure, now fsl_spi_init() accepting
four arguments;
- machine_is(mpc832x_rdb) added in the beginning of
mpc832x_spi_init().
v2 -> v3
o Device tree:
- completely removed mmc node;
- removed pio-handles and pio-maps.
o board file:
- Instead of par_io_of_config(), now par_io_config_pin() used to
configure GPIO pins, which does not require device tree node.
v1 -> v2
o Device tree:
- cosmetic cleanups (@01 -> @1);
- device-id renamed to fsl,device-id;
- removed max-chipselect and sysclk properties from spi node;
- removed chipselect property from mmc node, now reg property
used for this purpose, thereby address-cells and size-cells
added to the spi node;
- other non-mandatory (device-id, device_type, compatible, ...)
properties removed from mmc node, today board file is using
of_find_node_by_name(), instead of of_find_compatible_node();
- "qe" mode renamed to "cpu-qe".
o board file <-> fsl_soc interaction
- fsl_soc no longer scans for SPI nodes in the arch initcall.
Also it's no longer exports any global variables. Instead, it's
export fsl_spi_init function now, which accepts pointer to the
fsl_spi_board_info structure;
- board file fills fsl_spi_board_info structure and issues
fsl_spi_init(), which register SPI devices and SPI board infos.
Various sanity checks also perfromed.
I'd want to note that if spi_mpc83xx will be converted to
of_platform_driver then the scheme described above will not
work anymore, and I'll have to revert back ugly hacks:
global variables for activate/deactivate_cs functions. I see
no other options.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH v4 1/2] [POWERPC] fsl_soc: add support for fsl_spi
From: Anton Vorontsov @ 2007-08-21 13:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070821134537.GA7428@localhost.localdomain>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/fsl_soc.c | 85 +++++++++++++++++++++++++++++++++++++++++
arch/powerpc/sysdev/fsl_soc.h | 7 +++
2 files changed, 92 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 1cf29c9..25a96b5 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -24,6 +24,7 @@
#include <linux/platform_device.h>
#include <linux/of_platform.h>
#include <linux/phy.h>
+#include <linux/spi/spi.h>
#include <linux/fsl_devices.h>
#include <linux/fs_enet_pd.h>
#include <linux/fs_uart_pd.h>
@@ -1187,3 +1188,87 @@ err:
arch_initcall(cpm_smc_uart_of_init);
#endif /* CONFIG_8xx */
+
+int fsl_spi_init(struct spi_board_info *board_infos,
+ unsigned int num_board_infos,
+ void (*activate_cs)(u8 cs, u8 polarity),
+ void (*deactivate_cs)(u8 cs, u8 polarity))
+{
+ struct device_node *np;
+ unsigned int i;
+ u32 sysclk;
+
+ np = of_find_node_by_type(NULL, "qe");
+ if (!np)
+ return -ENODEV;
+
+ sysclk = *(u32 *)of_get_property(np, "bus-frequency", NULL);
+
+ for (np = NULL, i = 1;
+ (np = of_find_compatible_node(np, "spi", "fsl_spi")) != NULL;
+ i++) {
+ int ret = 0;
+ unsigned int j;
+ const char *mode;
+ struct resource res[2];
+ struct platform_device *pdev = NULL;
+ struct fsl_spi_platform_data pdata = {
+ .activate_cs = activate_cs,
+ .deactivate_cs = deactivate_cs,
+ };
+
+ memset(res, 0, sizeof(res));
+
+ mode = of_get_property(np, "mode", NULL);
+ pdata.sysclk = sysclk;
+ pdata.bus_num = *(u32 *)of_get_property(np, "reg", NULL);
+
+ for (j = 0; j < num_board_infos; j++) {
+ if (board_infos[j].bus_num == pdata.bus_num)
+ pdata.max_chipselect++;
+ }
+
+ if (!pdata.max_chipselect)
+ goto err;
+
+ if (!strcmp(mode, "cpu-qe"))
+ pdata.qe_mode = 1;
+
+ ret = of_address_to_resource(np, 0, &res[0]);
+ if (ret)
+ goto err;
+
+ res[1].start = res[2].end = irq_of_parse_and_map(np, 0);
+ if (res[1].start == NO_IRQ)
+ goto err;
+
+ res[1].name = "mpc83xx_spi";
+ res[1].flags = IORESOURCE_IRQ;;
+
+ pdev = platform_device_alloc("mpc83xx_spi", i);
+ if (!pdev)
+ goto err;
+
+ ret = platform_device_add_data(pdev, &pdata, sizeof(pdata));
+ if (ret)
+ goto unreg;
+
+ ret = platform_device_add_resources(pdev, res,
+ ARRAY_SIZE(res));
+ if (ret)
+ goto unreg;
+
+ ret = platform_device_register(pdev);
+ if (ret)
+ goto unreg;
+
+ continue;
+unreg:
+ platform_device_del(pdev);
+err:
+ continue;
+ }
+
+ return spi_register_board_info(board_infos, num_board_infos);
+}
+EXPORT_SYMBOL(fsl_spi_init);
diff --git a/arch/powerpc/sysdev/fsl_soc.h b/arch/powerpc/sysdev/fsl_soc.h
index 04e145b..618d91d 100644
--- a/arch/powerpc/sysdev/fsl_soc.h
+++ b/arch/powerpc/sysdev/fsl_soc.h
@@ -8,5 +8,12 @@ extern phys_addr_t get_immrbase(void);
extern u32 get_brgfreq(void);
extern u32 get_baudrate(void);
+struct spi_board_info;
+
+extern int fsl_spi_init(struct spi_board_info *board_infos,
+ unsigned int num_board_infos,
+ void (*activate_cs)(u8 cs, u8 polarity),
+ void (*deactivate_cs)(u8 cs, u8 polarity));
+
#endif
#endif
--
1.5.0.6
^ permalink raw reply related
* [PATCH v4 2/2] [POWERPC] MPC832x_RDB: update dts to use SPI1 in QE, register mmc_spi stub
From: Anton Vorontsov @ 2007-08-21 13:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070821134537.GA7428@localhost.localdomain>
mmc_spi already tested to work. When it will hit mainline
the only change that will be needed is replacing "spidev"
with "mmc_spi".
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc832x_rdb.dts | 2 +-
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 50 +++++++++++++++++++++++++++++
2 files changed, 51 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index e9c332f..1ac0025 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -211,7 +211,7 @@
reg = <4c0 40>;
interrupts = <2>;
interrupt-parent = <&qeic>;
- mode = "cpu";
+ mode = "cpu-qe";
};
spi@500 {
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index e021b08..cf58d06 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -15,6 +15,7 @@
*/
#include <linux/pci.h>
+#include <linux/spi/spi.h>
#include <asm/of_platform.h>
#include <asm/time.h>
@@ -24,6 +25,7 @@
#include <asm/qe_ic.h>
#include "mpc83xx.h"
+#include "../../sysdev/fsl_soc.h"
#undef DEBUG
#ifdef DEBUG
@@ -32,6 +34,54 @@
#define DBG(fmt...)
#endif
+extern int par_io_data_set(u8 port, u8 pin, u8 val);
+extern int par_io_config_pin(u8 port, u8 pin, int dir, int open_drain,
+ int assignment, int has_irq);
+
+static void mpc83xx_spi_activate_cs(u8 cs, u8 polarity)
+{
+ pr_debug("%s %d %d\n", __func__, cs, polarity);
+ par_io_data_set(3, 13, polarity);
+}
+
+static void mpc83xx_spi_deactivate_cs(u8 cs, u8 polarity)
+{
+ pr_debug("%s %d %d\n", __func__, cs, polarity);
+ par_io_data_set(3, 13, !polarity);
+}
+
+static struct spi_board_info mpc832x_spi_boardinfo = {
+ .bus_num = 0x4c0,
+ .chip_select = 0,
+ .max_speed_hz = 50000000,
+ /*
+ * XXX: This is spidev (spi in userspace) stub, should
+ * be replaced by "mmc_spi" when mmc_spi will hit mainline.
+ */
+ .modalias = "spidev",
+};
+
+static int __init mpc832x_spi_init(void)
+{
+ if (!machine_is(mpc832x_rdb))
+ return 0;
+
+ par_io_config_pin(3, 0, 3, 0, 1, 0); /* SPI1 MOSI, I/O */
+ par_io_config_pin(3, 1, 3, 0, 1, 0); /* SPI1 MISO, I/O */
+ par_io_config_pin(3, 2, 3, 0, 1, 0); /* SPI1 CLK, I/O */
+ par_io_config_pin(3, 3, 2, 0, 1, 0); /* SPI1 SEL, I */
+
+ par_io_config_pin(3, 13, 1, 0, 0, 0); /* !SD_CS, O */
+ par_io_config_pin(3, 14, 2, 0, 0, 0); /* SD_INSERT, I */
+ par_io_config_pin(3, 15, 2, 0, 0, 0); /* SD_PROTECT,I */
+
+ return fsl_spi_init(&mpc832x_spi_boardinfo, 1,
+ mpc83xx_spi_activate_cs,
+ mpc83xx_spi_deactivate_cs);
+}
+
+device_initcall(mpc832x_spi_init);
+
/* ************************************************************************
*
* Setup the architecture
--
1.5.0.6
^ permalink raw reply related
* Re: OF /chosen/initrd,* variables - patch, official?
From: David Gibson @ 2007-08-21 13:54 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppc-dev, linuxppc-embedded
In-Reply-To: <46CAE177.3010508@genesi-usa.com>
On Tue, Aug 21, 2007 at 01:58:31PM +0100, Matt Sealey wrote:
>
> David Gibson wrote:
> > Uh... no... this is in the bootwrapper, long before ppc_md even
> > exists. platform_init() is called from arch/powerpc/boot/crt0.S,
> > immediately before main().
>
> Oh *THAT* platform init.
>
> So I could just drop a
>
> } else {
> dt_find_initrd();
> }
>
> .. at the end and nobody would be too disgusted or have any problems?
Err.. at the end of what? Each platform has it's own version of
platform_init().
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: OF /chosen/initrd,* variables - patch, official?
From: Matt Sealey @ 2007-08-21 14:24 UTC (permalink / raw)
To: Matt Sealey, ppc-dev, linuxppc-embedded
In-Reply-To: <20070821135449.GA7438@localhost.localdomain>
David Gibson wrote:
> On Tue, Aug 21, 2007 at 01:58:31PM +0100, Matt Sealey wrote:
>> David Gibson wrote:
>>> Uh... no... this is in the bootwrapper, long before ppc_md even
>>> exists. platform_init() is called from arch/powerpc/boot/crt0.S,
>>> immediately before main().
>> Oh *THAT* platform init.
>>
>> So I could just drop a
>>
>> } else {
>> dt_find_initrd();
>> }
>>
>> .. at the end and nobody would be too disgusted or have any problems?
>
> Err.. at the end of what? Each platform has it's own version of
> platform_init().
arch/powerpc/boot/of.c since it's not really relevant to me for non-OF
platforms?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: Patches for ppc?
From: Segher Boessenkool @ 2007-08-21 15:14 UTC (permalink / raw)
To: David Gibson; +Cc: Linuxppc-dev, David Woodhouse
In-Reply-To: <20070821052514.GC21169@localhost.localdomain>
> It's not a question of indivudual files being copied over - things are
> done differently in arch/powerpc. Things are gradually being ported
> over to arch/powerpc as people get the time - that's why arch/ppc
> isn't gone yet.
And to be blunt, one of the points of arch/powerpc vs. arch/ppc is
to actually leave behind some stuff. "If no one ports it, no one
wants it".
Segher
^ permalink raw reply
* [PATCH v5 0/2] SPI support for fsl_soc and mpc832x_rdb
From: Anton Vorontsov @ 2007-08-21 15:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070821134537.GA7428@localhost.localdomain>
On Tue, Aug 21, 2007 at 05:45:37PM +0400, Anton Vorontsov wrote:
> Hi all,
>
> Thanks for the previous reviews, this is v4 against Linus' tree,
> as of today.
Okay, here is brand-new, shiny v5. Today and only today it comes
without section mismatch warnings, don't miss your chance. Get it
free of charge! ;-)
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
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