* Re: MontaVista 2.6 Kernel support for Xilinx ML40x
From: Frank D Lombardo @ 2006-08-24 19:27 UTC (permalink / raw)
To: Wade Maxfield; +Cc: ppc
In-Reply-To: <45a1b53e0608241057j4ebe519drd1e431a2275ccdde@mail.gmail.com>
The ml403 reference design has several evaluation cores: opb_uart16550,
opb_iic and opb_ethernet. They seem to time-out after about eight hours.
Frank
Wade Maxfield wrote:
> Good question. How long before lockup? The only core that should be
> licensed is the ethernet, and I know it was sysgened on a system with
> a license. This is the Xilinx reference design for the ml403 board.
>
>
> On 8/24/06, *Peter Ryser* <peter.ryser@xilinx.com
> <mailto:peter.ryser@xilinx.com>> wrote:
>
> Wade,
>
> are you sure that you did not build your hardware with evaluation
> cores of the licenses? If you are using the evaluation licenses
> the hardware (FPGA design) will stop working after a certain
> amount of time and you will see a lock-up.
>
> - Peter
>
>
> Wade Maxfield wrote:
>
> I've got the LSP, and have booted it on the ML40X.
>
> In my opinion it is currently unstable, but that is my opinion.
> I've not been able to keep it powered up for 24 hours without it
> locking up on the RS232 serial terminal. Also, running updatedb
> over nfs causes it to abort with a kernel panic, although that
> might be an interraction with the nfs server. (Although even if
> the nfs server dies (which it did not), I don't expect a kernel
> panic).
>
> I have had it run over 6 hours without issue, so I expect
> subtle memory leaks, not serious problems.
>
>
>
> On 8/24/06, *Claus Gindhart* < claus.gindhart@kontron.com
> <mailto:claus.gindhart@kontron.com>> wrote:
>
> Frank,
>
> due to my understanding of the GPL (and i have already
> invested some time
> in understanding the various flavours of open source
> licences), you should
> contact Montavista, and ask them for the sources.
>
> This board adaption is derivative work of the GPL Kernel, so
> the result of
> this work also falls under the GPL, and has to be made freely
> available
> under the terms of the GPL.
>
> --
> Mit freundlichen Gruessen / Best regards
>
> Claus Gindhart
> SW R&D
> Kontron Modular Computers
> phone :++49 (0)8341-803-374
> mailto:claus.gindhart@kontron-modular.com
> <mailto:claus.gindhart@kontron-modular.com>
> http://www.kontron.com
>
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.1
> GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o?
> K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++
> D-- G e++> h--- !r x+++
> ------END GEEK CODE BLOCK------
>
>
> -----Original Message-----
> From:
> linuxppc-embedded-bounces+claus.gindhart=kontron.com@ozlabs.org
> <mailto:kontron.com@ozlabs.org>
> [mailto:
> linuxppc-embedded-bounces+claus.gindhart=kontron.com@ozlabs.org
> <mailto:linuxppc-embedded-bounces+claus.gindhart=kontron.com@ozlabs.org>]
> On Behalf Of Frank D Lombardo
> Sent: Donnerstag, 24. August 2006 15:59
> To: linuxppc-embedded@ozlabs.org
> <mailto:linuxppc-embedded@ozlabs.org>
> Subject: MontaVista 2.6 Kernel support for Xilinx ML40x
>
>
> I noticed that MontaVista now has their Pro 4.0 version (2.6
> Kernel)
> available for the Xilinx ML40x series of boards. I would
> assume that
> means driver support for at least most of the hardware on the
> boards.
> Is this code that should be freely available? How would one
> get a copy
> of these drivers? I am interested in drivers for the ML403.
>
> Thanks,
> Frank
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org <mailto:Linuxppc-embedded@ozlabs.org>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org <mailto:Linuxppc-embedded@ozlabs.org>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> <https://ozlabs.org/mailman/listinfo/linuxppc-embedded>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________ Linuxppc-embedded
> mailing list Linuxppc-embedded@ozlabs.org
> <mailto:Linuxppc-embedded@ozlabs.org>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: MontaVista 2.6 Kernel support for Xilinx ML40x
From: T Ziomek @ 2006-08-24 19:38 UTC (permalink / raw)
To: Wade Maxfield; +Cc: ppc
In-Reply-To: <45a1b53e0608241057j4ebe519drd1e431a2275ccdde@mail.gmail.com>
[top-posting fixed :-) ]
On Thu, 24 Aug 2006, Wade Maxfield wrote:
>
> On 8/24/06, Peter Ryser <peter.ryser@xilinx.com> wrote:
>>
>> Wade,
>>
>> are you sure that you did not build your hardware with evaluation cores of
>> the licenses? If you are using the evaluation licenses the hardware (FPGA
>> design) will stop working after a certain amount of time and you will see a
>> lock-up.
>
> Good question. How long before lockup? The only core that should be
> licensed is the ethernet, and I know it was sysgened on a system with a
> license. This is the Xilinx reference design for the ml403 board.
When we were using the eval version of Xilinx's 10/100 EMAC it would time-
out after 8 hours (and the kernel would panic since our root fs was NFS-
mounted).
If your only [to-be-]licensed core is Ethernet, then I take it you're using
the UARTLite, or a non-Xilinx UART? We used Xilinx's 16550-compatible UART,
which is licensed, but I never ran with the eval version of that IP block
and so have no idea how long it will function before shutting down.
Tom
--
A: Because it breaks the logical |
flow of the message. | Email to user 'CTZ001'
| at 'email.mot.com'
Q: Why is top posting frowned upon? |
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Stefan Richter @ 2006-08-24 19:43 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev, billfink, linux1394-devel
In-Reply-To: <20060824192200.GA2715@localhost>
Wolfgang Pfeiffer wrote:
...
> Because i hate to burden my lousy memory with what I did to produce
> the logs above, I scrambled together my admittedly marginal bash
> knowledge and ran the tests with 4 scripts to produce the logs.
>
> All the following below is to give you control on how these logs were
> created.
...
Thanks, I will look at them as soon as I have my lookup table for the
hex codes and the mental capacity available. :-) BTW, a convenient way
to annotate the syslog is the command "logger". E.g.
$ logger "hello world"
$ ./hello_world 2>&1 | logger -t hi_world
--
Stefan Richter
-=====-=-==- =--- ==---
http://arcgraph.de/sr/
^ permalink raw reply
* communication with i2c client
From: Ladislav Klenovič @ 2006-08-24 13:12 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I've create an i2c client and my questions is how to access it from use=
rspace=2E This client is sitttng on adapter that I was able to access =
via /dev interface=2E After the client were successfuly loaded and dete=
cted,
ioctl(fd,I2C_SLAVE,=2E=2E=2E) and read/write functions didn't work and =
error messages like "device busy" or "ioctl error" have occured=2E Als=
o my debug messages from i2c client didn't arise when I am accessing=20
device only adapter's=2E
How to (standardly) access a an i2c client?=20
Do I need to create an ioctl interface or exports some helper function =
for access it from user space and also from kernel space? =20
regards,
Ladislav=2E
^ permalink raw reply
* Re: MontaVista 2.6 Kernel support for Xilinx ML40x
From: Wade Maxfield @ 2006-08-24 22:13 UTC (permalink / raw)
To: T Ziomek; +Cc: ppc
In-Reply-To: <Pine.WNT.4.61.0608241432311.200@holyoke.labs.mot.com>
[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]
sorry! ;) See my reply at the right location!
On 8/24/06, T Ziomek <ctz001@email.mot.com> wrote:
>
> [top-posting fixed :-) ]
>
>
> On Thu, 24 Aug 2006, Wade Maxfield wrote:
> >
> > On 8/24/06, Peter Ryser <peter.ryser@xilinx.com> wrote:
> >>
> >> Wade,
> >>
> >> are you sure that you did not build your hardware with evaluation cores
> of
> >> the licenses? If you are using the evaluation licenses the hardware
> (FPGA
> >> design) will stop working after a certain amount of time and you will
> see a
> >> lock-up.
> >
> > Good question. How long before lockup? The only core that should be
> > licensed is the ethernet, and I know it was sysgened on a system with a
> > license. This is the Xilinx reference design for the ml403 board.
>
> When we were using the eval version of Xilinx's 10/100 EMAC it would time-
> out after 8 hours (and the kernel would panic since our root fs was NFS-
> mounted).
>
> If your only [to-be-]licensed core is Ethernet, then I take it you're
> using
> the UARTLite, or a non-Xilinx UART? We used Xilinx's 16550-compatible
> UART,
> which is licensed, but I never ran with the eval version of that IP block
> and so have no idea how long it will function before shutting down.
We are doing an evaluation right now. We have operational 8 hours 55
minutes so far and counting on the Xilinx 16550 compatible uart. I think
that is the cause of the problem for us, but not sure so far.
Tom
> --
> A: Because it breaks the logical |
> flow of the message. | Email to user 'CTZ001'
> | at 'email.mot.com'
> Q: Why is top posting frowned upon? |
x<>y
A2. but only for algebraic. RPN likes it that way.
[-- Attachment #2: Type: text/html, Size: 2928 bytes --]
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Wolfgang Pfeiffer @ 2006-08-24 22:56 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, billfink, linux1394-devel
In-Reply-To: <44EE0173.9060403@s5r6.in-berlin.de>
On Thu, Aug 24, 2006 at 09:43:47PM +0200, Stefan Richter wrote:
> Wolfgang Pfeiffer wrote:
> ...
> >Because i hate to burden my lousy memory with what I did to produce
> >the logs above, I scrambled together my admittedly marginal bash
> >knowledge and ran the tests with 4 scripts to produce the logs.
> >
> >All the following below is to give you control on how these logs were
> >created.
> ...
>
> Thanks, I will look at them as soon as I have my lookup table for the
> hex codes and the mental capacity available. :-) BTW, a convenient way
> to annotate the syslog is the command "logger". E.g.
> $ logger "hello world"
> $ ./hello_world 2>&1 | logger -t hi_world
I'll keep that on my radar for the next time I could use 'logger' ...
But after reading the - how do I say that without becoming offensive,
- err .. possibly slightly esoteric explanations in "man logger" I'm
not that much enthusiastic to use the tool ... but let's see .. :)
Note: Please ignore most of the ugly explanations on how I created the
logs for ieee1394 in my previous mail. Some should be nothing more
than a reference if (and only if) the ieee logs I put on my home page
don't help to debug the FW issue ...
Thanks
Best regards
Wolfgang
--
Wolfgang Pfeiffer: /ICQ: 286585973/ + + + /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on
^ permalink raw reply
* Cache coherency question
From: Martin, Tim @ 2006-08-24 23:08 UTC (permalink / raw)
To: ppc
I'm using an MVME6100 with Linux 2.6.14 and experiencing what I think is
a cache coherency problem. An external PCIX master performs a DMA
transfer of a well known data pattern into SDRAM, but when the device
driver goes to look at the data it is mostly okay, but occasionally has
garbage.
I'm allocating the memory using alloc_skb, then giving a PCI translated
pointer to the PCIX master. Since I think it is a cache coherency
problem, I tried to use the dma_cache_inv macro to invalidate the cache
before looking at the data, but realized that for this board, that
function does nothing since CONFIG_NOT_COHERENT_CACHE is undefined. So
questions:
1) Should the processor bus cache snooping actually work on an MVME6100?
E.g. is it correct that CONFIG_NOT_COHERENT_CACHE is undefined?
1a) Does this type of bus snooping work when a bus master physically
external to the PowerPC chip is doing the transfer?
2) If this really is a cache coherency problem, are there other cache
management functions available in ppc linux besides the dma_cache_inv,
dma_cache_wback, dma_cache_wback_inv macros I should be looking at?
Tim
^ permalink raw reply
* "ip=" command line strangeness...
From: T Ziomek @ 2006-08-24 23:38 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: tomz
On my previous project, a 2.4 kernel on PPC, I frequently used
"ip=w.x.y.z" on the kernel command line to specify a static IP address for
my target board (when booting with a flash- or RAM-based root filesystem).
Similarly, when using an NFS-mounted root fs, I would use
"ip=w.x.y.z:a.b.c.d", along with the appropriate "nfsroot=..." setting,
with my NFS server having IP a.b.c.d .
Now I am working with a 2.6.10-based kernel on ARM. Using an NFS root fs
works fine when I use the expected "ip=w.x.y.z:a.b.c.d". And booting off
with "root=/dev/hda1" works fine with "ip=dhcp".
I'd expect to be able to use "root=/dev/hda1 ip=w.x.y.z" if I want the
target using a static IP address. But this fails, and in a VERY weird
way: (1) It tries doing DHCP, which it shouldn't, and (2) the DHCP fails,
which it shouldn't because it works when I want DHCP to be used.
Here's a snippet of console output:
.
.
.
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
Sending DHCP requests ...... timed out!
EMAC: TX Complete: Starting queue
IP-Config: Reopening network devices...
Sending DHCP requests ...
Okay, that's two weird things. There is a third -- this problem goes a-
way if I change the command line to something like
"root=/dev/hda1 ip=w.x.y.z:a.b.c.d". The only change is adding an NFS
server IP address to the "ip=" command, which should have no effect be-
cause NFS is not being used. Yet when I do that the board boots as ex-
pected -- it does not try to do DHCP, it does use /dev/hda1 for its root
fs, and it does take the specified IP address.
In fact, it works even if I use a command line with, literally,
"root=/dev/hda1 ip=199.5.233.72:gobbledygook":
.
.
.
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
device=eth0, addr=199.5.233.72, mask=255.255.255.0, gw=255.255.255.255,
host=199.5.233.72, domain=, nis-domain=(none),
bootserver=232.0.0.0, rootserver=232.0.0.0, rootpath=
.
.
.
This isn't a big problem, but can anybody explain what the heck is going
on?
Thanks, Tom
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
^ permalink raw reply
* communication with i2c client
From: Ladislav Klenovič @ 2006-08-24 13:15 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I've create an i2c client and my questions is how to access it from use=
rspace=2E This client is sitttng on adapter that I was able to access =
via /dev interface=2E After the client were successfuly loaded and dete=
cted,
ioctl(fd,I2C_SLAVE,=2E=2E=2E) and read/write functions didn't work and =
error messages like "device busy" or "ioctl error" have occured=2E Als=
o my debug messages from i2c client didn't arise when I am accessing=20
device only adapter's=2E
How to (standardly) access a an i2c client?=20
Do I need to create an ioctl interface or exports some helper function =
for access it from user space and also from kernel space? =20
regards,
Ladislav=2E
^ permalink raw reply
* Re: [PATCH ] powerpc: Add tsi108/9 and non standard mpic support
From: Zang Roy-r61911 @ 2006-08-25 1:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Paul Mackerras, Yang Xin-Xin-r48390
In-Reply-To: <1156418003.8433.246.camel@localhost.localdomain>
On Thu, 2006-08-24 at 19:13, Benjamin Herrenschmidt wrote:
> > I have tested on mpc8641hpcn board with CONFIG_MPIC.
>
> I need to test it with normal MPIC machines and CONFIG_MPIC_WEIRD
> enabled
>
For my design, it should have the same behavior just as CONFIG_MPIC, if
you pass MPIC_ID_MPIC flag.
We can see your result.
Roy
^ permalink raw reply
* Help with booting with very large initrd
From: Howard, Marc @ 2006-08-25 1:38 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm developing a PPC440GX based board that uses U-Boot to boot a
multi-file boot image composed of the kernel and a very large (> 96MB
uncompressed) initrd file. The board has 512MB of RAM of which the
upper 16MB is reserved for dedicated hardware. The 16MB block is
reserved via "mem=3D496M" and U-Boot is told to stay out of that area by
setting "initrd_high=3D1f000000".
Before anyone asks there are several reasons for doing things this way.
NFS is not an option in the target environment.
I can tftp the combined boot image to my board. I checked the crc with
the crc32 command and it agrees exactly with the result obtained on the
host machine using the boot file. Therefore there is not a "TFTP >32MB"
problem here.
If I boot I get the following:
=3D> boot
Waiting for PHY auto negotiation to complete... done
ENET Speed is 1000 Mbps - FULL duplex connection
Using ppc_4xx_eth2 device
TFTP from server 192.168.168.108; our IP address is 192.168.168.111
Filename 'pMulti-ramdisk'.
Load address: 0x400000
Loading: *
done
Bytes transferred =3D 38825407 (2506dbf hex)
Automatic boot of image at addr 0x00400000 ...
## Booting image at 00400000 ...
Image Name: Linux-2.6.10_mvl401-440gx_eval-I
Created: 2006-08-25 1:01:29 UTC
Image Type: PowerPC Linux Multi-File Image (gzip compressed)
Data Size: 38825343 Bytes =3D 37 MB
Load Address: 00000000
Entry Point: 00000000
Contents:
Image 0: 1137986 Bytes =3D 1.1 MB
Image 1: 37687343 Bytes =3D 35.9 MB
Verifying Checksum ... OK
Uncompressing Multi-File Image ... OK
Loading Ramdisk to 1cc0e000, end 1efff02f ... OK
Linux version 2.6.10_mvl401-440gx_eval (cram@toaster.kla-tencor.com)
(gcc version 3.4.3 (MontaVista 3.4.3-25.0.107.0601076 2006-07-21)) #46
Thu Aug 24 17:28:09 PDT 2006
IBM Ocotea port (MontaVista Software, Inc. <source@mvista.com>)
Built 1 zonelists
Kernel command line: ramdisk_size=3D262144 root=3D/dev/ram rw
console=3DttyS0,115200
ip=3D192.168.168.111:192.168.168.108::255.255.255.0:scpu2:eth0: off
mem=3D496M
PID hash table entries: 2048 (order: 11, 32768 bytes)
......stuff deleted......
RAMDISK driver initialized: 8 RAM disks of 262144K size 1024 blocksize
loop: loaded (max 8 devices)
......more stuff deleted......
eth0: link is down
eth0: link is up, 1000 FDX, pause enabled
IP-Config: Complete:
device=3Deth0, addr=3D192.168.168.111, mask=3D255.255.255.0,
gw=3D255.255.255.255, host=3Dscpu2, domain=3D, nis-domain=3D(none),
bootserver=3D192.168.168.108, rootserver=3D192.168.168.108, =
rootpath=3D
RAMDISK: Compressed image found at block 0
crc error (orig 0x9a278d64, CRC_VALUE 0xa7bcd2e3 -- ignoring!
length error (orig =3D 0x0c000000, bytes_out =3D 0x0c000015 -- ignored
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 120k init
Warning: unable to open an initial console.
Kernel panic - not syncing: No init found. Try passing init=3D option =
to
kernel.
<0>Rebooting in 180 seconds..
(I modified lib/inflate.c so that the crc and length checks would
provide more info).
Since the overall file CRC is good and U-Boot checksums are also okay
this looks like some sort of size limitation with the inflate routine.
BTW, The kerenel was made assuming a 256MB ramdisk; likewise the command
line specs one as well. The initrd image would fit easily in that
space.
Have any of you worked on this problem before and come up with a
solution?
Thanks,
Marc Howard
^ permalink raw reply
* Re: communication with i2c client
From: Frank @ 2006-08-25 1:54 UTC (permalink / raw)
To: Ladislav Klenoviè, linuxppc-embedded
In-Reply-To: <99de7cba0d63488089aa1add47109fb9@pobox.sk>
--- Ladislav Klenoviè <lk99336@pobox.sk> wrote:
> Hi,
> I've create an i2c client and my questions is how to access it
> from userspace. This client is sitttng on adapter that I was
> able to access via /dev interface. After the client were
> successfuly loaded and detected,
> ioctl(fd,I2C_SLAVE,...) and read/write functions didn't work
> and error messages like "device busy" or "ioctl error" have
> occured. Also my debug messages from i2c client didn't arise
> when I am accessing
> device only adapter's.
> How to (standardly) access a an i2c client?
> Do I need to create an ioctl interface or exports some helper
> function for access it from user space and also from kernel
> space?
>
> regards,
> Ladislav.
You might get an answer here:
http://www.lm-sensors.org/
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* RE: atomic operations in user space
From: Li Yang-r58472 @ 2006-08-25 2:33 UTC (permalink / raw)
To: Brent Cook, linuxppc-embedded; +Cc: Terry Liang
In-Reply-To: <200608240918.19450.bcook@bpointsys.com>
> -----Original Message-----
> From: Brent Cook [mailto:bcook@bpointsys.com]
> Sent: Thursday, August 24, 2006 10:18 PM
> To: linuxppc-embedded@ozlabs.org
> Cc: Li Yang-r58472; Terry Liang
> Subject: Re: atomic operations in user space
>=20
> On Thursday 24 August 2006 05:39, Li Yang-r58472 wrote:
>=20
> > Why do you need atomic operations in user land? IPC will be
sufficient
>=20
> > to deal with race conditions between processes.
>=20
> >
>=20
> > Best Regards,
>=20
> > Leo
>=20
> What about multiple threads within a process updating a counter?
Is there anything preventing semaphore to be used in threads?
>=20
> Of course, if you look at these functions in the kernel header,
they're just 2 or
> 3 inline assembly calls - you could easily rewrite them. Google for
'PowerPC atomic
> increment' and grab one of the unencumbered implementations if you
need to use it
> in a non-GPL program.
>=20
> On the other hand, I see no license at the top of my
/usr/include/asm-i386/atomic.h
> file at all, same for PowerPC - are Linux header files actually GPL or
are they
> more like the glibc headers, with exceptions made for userspace
programs?
>=20
> The atomic operations on x86 were accidentally exported early on, so
they have to
> hang around apparently for compatibility (there are some mailing list
threads out
> there to this effect.) Currently, you just have to assume in Linux
that if you
> include something from /usr/include/linux or asm that it will not
necessarily be
> cross-version or cross-architecture compatible. Not every arch in
Linux even has
> atomic operations of this nature, which I guess is the main reason why
they are
> not exported in general.
>=20
> - Brent
^ permalink raw reply
* RE: Cache coherency question
From: Liu Dave-r63238 @ 2006-08-25 3:26 UTC (permalink / raw)
To: Martin, Tim, ppc
In-Reply-To: <821B2170E9E7F04FA38DF7EC21DE487106282397@VCAEXCH01.hq.corp.viasat.com>
Tim> I'm using an MVME6100 with Linux 2.6.14 and experiencing what=20
Tim> I think is a cache coherency problem. An external PCIX=20
Tim> master performs a DMA transfer of a well known data pattern=20
Tim> into SDRAM, but when the device driver goes to look at the=20
Tim> data it is mostly okay, but occasionally has garbage.
If the hardware is reliable, I think you are right. The cache coherency
problem.
Tim> I'm allocating the memory using alloc_skb, then giving a PCI=20
Tim> translated pointer to the PCIX master. Since I think it is a=20
Tim> cache coherency problem, I tried to use the dma_cache_inv=20
Tim> macro to invalidate the cache before looking at the data, but=20
Tim> realized that for this board, that function does nothing=20
Tim> since CONFIG_NOT_COHERENT_CACHE is undefined. So
Tim> questions:
If the CONFIG_NOT_COHERENT_CACHE is not set.
You are assuming and using the hardware cache coherency mechanism.
Tim> 1) Should the processor bus cache snooping actually work on=20
Tim> an MVME6100?
Tim> E.g. is it correct that CONFIG_NOT_COHERENT_CACHE is undefined?
Yes, you can undefine the CONFIG_NOT_COHERENT_CACHE, but you must
make sure the host bridge did the snooping setup for PCI inbound
transaction.
If you setup the snooping window, I think the host bridge will assert
/GLB signal
to processor. The processor will snoop the 60x/MPX bus to keep cache
coherence.
Also, you can define the CONFIG_NOT_COHERENT_CACHE, then you are
assuming
The system has not hardware coherency. You need use the software to keep
the cache
coherency.
Tim> 1a) Does this type of bus snooping work when a bus master=20
Tim> physically external to the PowerPC chip is doing the transfer?
As above, you must tell the bridge what address need snoop. If you did,
The proceesor will do snooping.
Tim> 2) If this really is a cache coherency problem, are there=20
Tim> other cache management functions available in ppc linux=20
Tim> besides the dma_cache_inv, dma_cache_wback,=20
Tim> dma_cache_wback_inv macros I should be looking at?
I think it is a cache coherency problem,
if you define the CONFIG_NOT_COHERENT_CACHE
You can get these functions, dma_map_single
-Dave
^ permalink raw reply
* [PATCH] powerpc: Support for "weird" MPICs and fixup mpc7448_hpc2
From: Benjamin Herrenschmidt @ 2006-08-25 4:16 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras
This patch is a slightly cleaned up version of Zang Roy's support for
the TSI108 MPIC variant. It also fixes up MPC7448_hpc2 to use the new
version of the type macros and changes the way MPIC is selected in
Kconfig to better match what is done for other system devices.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Zang Roy, please verify that it still works for you. I've tested it on
an Apple G5 with and without CONFIG_MPIC_WEIRD .
>From tie-fei.zang@freescale.com Thu Aug 24 05:04:51 2006
Return-Path: <tie-fei.zang@freescale.com>
Received: from de01egw01.freescale.net (de01egw01.freescale.net
[192.88.165.102]) by gate.crashing.org (8.12.8/8.12.8) with ESMTP id
k7OA4mAu020592 for <benh@kernel.crashing.org>; Thu, 24 Aug 2006 05:04:51
-0500
Received: from de01smr01.freescale.net (de01smr01.freescale.net
[10.208.0.31]) by de01egw01.freescale.net (8.12.11/de01egw01) with ESMTP id
k7OBBP81018127 for <benh@kernel.crashing.org>; Thu, 24 Aug 2006 05:11:25
-0600 (MDT)
Received: from zch01exm23.fsl.freescale.net (zch01exm23.ap.freescale.net
[10.192.129.207]) by de01smr01.freescale.net (8.13.1/8.13.0) with ESMTP id
k7O9qXun020289 for <benh@kernel.crashing.org>; Thu, 24 Aug 2006 04:52:34
-0500 (CDT)
Received: from [10.193.20.86] ([10.193.20.86]) by
zch01exm23.fsl.freescale.net with Microsoft SMTPSVC(6.0.3790.2499); Thu, 24
Aug 2006 17:52:32 +0800
Subject: Re: [PATCH ] powerpc: Add tsi108/9 and non standard mpic support
From: Zang Roy-r61911 <tie-fei.zang@freescale.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>, linuxppc-dev list <linuxppc-dev@ozlabs.org>, Yang Xin-Xin-r48390 <Xin-Xin.Yang@freescale.com>
In-Reply-To: <1156398861.8433.197.camel@localhost.localdomain>
References:
<7EA18FDD2DC2154AA3BD6D2F22A62A0E19E353@zch01exm23.fsl.freescale.net>
<1156398135.5913.43.camel@localhost.localdomain>
<1156398861.8433.197.camel@localhost.localdomain>
Content-Type: text/plain
Organization:
Message-Id: <1156413135.6591.14.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4)
Date: 24 Aug 2006 17:52:15 +0800
X-OriginalArrivalTime: 24 Aug 2006 09:52:32.0621 (UTC)
FILETIME=[04FFF1D0:01C6C763]
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on gate.crashing.org
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0
tests=AWL,BAYES_00,UPPERCASE_25_50 autolearn=no version=3.0.1
Status:
X-Evolution-Source: pop://benh@localhost:10110/
Content-Transfer-Encoding: 8bit
On Thu, 2006-08-24 at 13:54, Benjamin Herrenschmidt wrote:
> On Thu, 2006-08-24 at 13:42 +0800, Zang Roy-r61911 wrote:
> > On Tue, 2006-08-22 at 18:07, Zang Roy-r61911 wrote:
> > > The patch adds new hardware information table for mpic. This
> > > enables mpic code to deal with mpic controller with
> > > hardware behavior difference.
> > >
> > > CONFIG_MPIC_WEIRD is introduced in the code.
> > > If a board with non standard mpic controller, it can select the
> > > CONFIG_MPIC_WEIRD with board and add its hardware information
> > > in the array mpic_infos.
> > >
> > > TSI108/109 PIC takes the first index of weird hardware
> information
> > > table:) . The table can be extended. The Tsi108/109 PIC looks
> like
> > > standard OpenPIC but, in fact, is different in registers mapping
> and
> > > behavior.
>
> The table should still contain the entries for a normal MPIC. One can
> build a kernel that will boot both machines with the "weird" one and
> with the normal one. Thus CONFIG_MPIC_WEIRD shall not exclude normal
> MPICs, though not having it does exclude weird ones. I thus would
> suggest to keep the table as it was in your earlier patches, that is
> with the normal MPIC mapping at 0.
>
> I intend to re-use that to handle another weird MPIC from some other
> project :)
That is also my target. I hope the imported mpic_info table can support
more non-standard mpic structure.
The following patch adds the standard MPIC entry to the table.
I post it here.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Index: linux-work/arch/powerpc/Kconfig
===================================================================
--- linux-work.orig/arch/powerpc/Kconfig 2006-08-17 09:26:19.000000000 +1000
+++ linux-work/arch/powerpc/Kconfig 2006-08-25 14:00:10.000000000 +1000
@@ -354,6 +354,7 @@ endchoice
config PPC_PSERIES
depends on PPC_MULTIPLATFORM && PPC64
bool "IBM pSeries & new (POWER5-based) iSeries"
+ select MPIC
select PPC_I8259
select PPC_RTAS
select RTAS_ERROR_LOGGING
@@ -363,6 +364,7 @@ config PPC_PSERIES
config PPC_CHRP
bool "Common Hardware Reference Platform (CHRP) based machines"
depends on PPC_MULTIPLATFORM && PPC32
+ select MPIC
select PPC_I8259
select PPC_INDIRECT_PCI
select PPC_RTAS
@@ -373,6 +375,7 @@ config PPC_CHRP
config PPC_PMAC
bool "Apple PowerMac based machines"
depends on PPC_MULTIPLATFORM
+ select MPIC
select PPC_INDIRECT_PCI if PPC32
select PPC_MPC106 if PPC32
default y
@@ -380,6 +383,7 @@ config PPC_PMAC
config PPC_PMAC64
bool
depends on PPC_PMAC && POWER4
+ select MPIC
select U3_DART
select MPIC_BROKEN_U3
select GENERIC_TBSYNC
@@ -389,6 +393,7 @@ config PPC_PMAC64
config PPC_PREP
bool "PowerPC Reference Platform (PReP) based machines"
depends on PPC_MULTIPLATFORM && PPC32 && BROKEN
+ select MPIC
select PPC_I8259
select PPC_INDIRECT_PCI
select PPC_UDBG_16550
@@ -397,6 +402,7 @@ config PPC_PREP
config PPC_MAPLE
depends on PPC_MULTIPLATFORM && PPC64
bool "Maple 970FX Evaluation Board"
+ select MPIC
select U3_DART
select MPIC_BROKEN_U3
select GENERIC_TBSYNC
@@ -439,12 +445,6 @@ config U3_DART
depends on PPC_MULTIPLATFORM && PPC64
default n
-config MPIC
- depends on PPC_PSERIES || PPC_PMAC || PPC_MAPLE || PPC_CHRP \
- || MPC7448HPC2
- bool
- default y
-
config PPC_RTAS
bool
default n
@@ -812,6 +812,14 @@ config GENERIC_ISA_DMA
depends on PPC64 || POWER4 || 6xx && !CPM2
default y
+config MPIC
+ bool
+ default n
+
+config MPIC_WEIRD
+ bool
+ default n
+
config PPC_I8259
bool
default n
Index: linux-work/arch/powerpc/sysdev/mpic.c
===================================================================
--- linux-work.orig/arch/powerpc/sysdev/mpic.c 2006-08-17 09:26:19.000000000 +1000
+++ linux-work/arch/powerpc/sysdev/mpic.c 2006-08-25 13:46:53.000000000 +1000
@@ -54,6 +54,94 @@ static DEFINE_SPINLOCK(mpic_lock);
#endif
#endif
+#ifdef CONFIG_MPIC_WEIRD
+static u32 mpic_infos[][MPIC_IDX_END] = {
+ [0] = { /* Original OpenPIC compatible MPIC */
+ MPIC_GREG_BASE,
+ MPIC_GREG_FEATURE_0,
+ MPIC_GREG_GLOBAL_CONF_0,
+ MPIC_GREG_VENDOR_ID,
+ MPIC_GREG_IPI_VECTOR_PRI_0,
+ MPIC_GREG_IPI_STRIDE,
+ MPIC_GREG_SPURIOUS,
+ MPIC_GREG_TIMER_FREQ,
+
+ MPIC_TIMER_BASE,
+ MPIC_TIMER_STRIDE,
+ MPIC_TIMER_CURRENT_CNT,
+ MPIC_TIMER_BASE_CNT,
+ MPIC_TIMER_VECTOR_PRI,
+ MPIC_TIMER_DESTINATION,
+
+ MPIC_CPU_BASE,
+ MPIC_CPU_STRIDE,
+ MPIC_CPU_IPI_DISPATCH_0,
+ MPIC_CPU_IPI_DISPATCH_STRIDE,
+ MPIC_CPU_CURRENT_TASK_PRI,
+ MPIC_CPU_WHOAMI,
+ MPIC_CPU_INTACK,
+ MPIC_CPU_EOI,
+
+ MPIC_IRQ_BASE,
+ MPIC_IRQ_STRIDE,
+ MPIC_IRQ_VECTOR_PRI,
+ MPIC_VECPRI_VECTOR_MASK,
+ MPIC_VECPRI_POLARITY_POSITIVE,
+ MPIC_VECPRI_POLARITY_NEGATIVE,
+ MPIC_VECPRI_SENSE_LEVEL,
+ MPIC_VECPRI_SENSE_EDGE,
+ MPIC_VECPRI_POLARITY_MASK,
+ MPIC_VECPRI_SENSE_MASK,
+ MPIC_IRQ_DESTINATION
+ },
+ [1] = { /* Tsi108/109 PIC */
+ TSI108_GREG_BASE,
+ TSI108_GREG_FEATURE_0,
+ TSI108_GREG_GLOBAL_CONF_0,
+ TSI108_GREG_VENDOR_ID,
+ TSI108_GREG_IPI_VECTOR_PRI_0,
+ TSI108_GREG_IPI_STRIDE,
+ TSI108_GREG_SPURIOUS,
+ TSI108_GREG_TIMER_FREQ,
+
+ TSI108_TIMER_BASE,
+ TSI108_TIMER_STRIDE,
+ TSI108_TIMER_CURRENT_CNT,
+ TSI108_TIMER_BASE_CNT,
+ TSI108_TIMER_VECTOR_PRI,
+ TSI108_TIMER_DESTINATION,
+
+ TSI108_CPU_BASE,
+ TSI108_CPU_STRIDE,
+ TSI108_CPU_IPI_DISPATCH_0,
+ TSI108_CPU_IPI_DISPATCH_STRIDE,
+ TSI108_CPU_CURRENT_TASK_PRI,
+ TSI108_CPU_WHOAMI,
+ TSI108_CPU_INTACK,
+ TSI108_CPU_EOI,
+
+ TSI108_IRQ_BASE,
+ TSI108_IRQ_STRIDE,
+ TSI108_IRQ_VECTOR_PRI,
+ TSI108_VECPRI_VECTOR_MASK,
+ TSI108_VECPRI_POLARITY_POSITIVE,
+ TSI108_VECPRI_POLARITY_NEGATIVE,
+ TSI108_VECPRI_SENSE_LEVEL,
+ TSI108_VECPRI_SENSE_EDGE,
+ TSI108_VECPRI_POLARITY_MASK,
+ TSI108_VECPRI_SENSE_MASK,
+ TSI108_IRQ_DESTINATION
+ },
+};
+
+#define MPIC_INFO(name) mpic->hw_set[MPIC_IDX_##name]
+
+#else /* CONFIG_MPIC_WEIRD */
+
+#define MPIC_INFO(name) MPIC_##name
+
+#endif /* CONFIG_MPIC_WEIRD */
+
/*
* Register accessor functions
*/
@@ -80,7 +168,8 @@ static inline void _mpic_write(unsigned
static inline u32 _mpic_ipi_read(struct mpic *mpic, unsigned int ipi)
{
unsigned int be = (mpic->flags & MPIC_BIG_ENDIAN) != 0;
- unsigned int offset = MPIC_GREG_IPI_VECTOR_PRI_0 + (ipi * 0x10);
+ unsigned int offset = MPIC_INFO(GREG_IPI_VECTOR_PRI_0) +
+ (ipi * MPIC_INFO(GREG_IPI_STRIDE));
if (mpic->flags & MPIC_BROKEN_IPI)
be = !be;
@@ -89,7 +178,8 @@ static inline u32 _mpic_ipi_read(struct
static inline void _mpic_ipi_write(struct mpic *mpic, unsigned int ipi, u32 value)
{
- unsigned int offset = MPIC_GREG_IPI_VECTOR_PRI_0 + (ipi * 0x10);
+ unsigned int offset = MPIC_INFO(GREG_IPI_VECTOR_PRI_0) +
+ (ipi * MPIC_INFO(GREG_IPI_STRIDE));
_mpic_write(mpic->flags & MPIC_BIG_ENDIAN, mpic->gregs, offset, value);
}
@@ -120,7 +210,7 @@ static inline u32 _mpic_irq_read(struct
unsigned int idx = src_no & mpic->isu_mask;
return _mpic_read(mpic->flags & MPIC_BIG_ENDIAN, mpic->isus[isu],
- reg + (idx * MPIC_IRQ_STRIDE));
+ reg + (idx * MPIC_INFO(IRQ_STRIDE)));
}
static inline void _mpic_irq_write(struct mpic *mpic, unsigned int src_no,
@@ -130,7 +220,7 @@ static inline void _mpic_irq_write(struc
unsigned int idx = src_no & mpic->isu_mask;
_mpic_write(mpic->flags & MPIC_BIG_ENDIAN, mpic->isus[isu],
- reg + (idx * MPIC_IRQ_STRIDE), value);
+ reg + (idx * MPIC_INFO(IRQ_STRIDE)), value);
}
#define mpic_read(b,r) _mpic_read(mpic->flags & MPIC_BIG_ENDIAN,(b),(r))
@@ -156,8 +246,8 @@ static void __init mpic_test_broken_ipi(
{
u32 r;
- mpic_write(mpic->gregs, MPIC_GREG_IPI_VECTOR_PRI_0, MPIC_VECPRI_MASK);
- r = mpic_read(mpic->gregs, MPIC_GREG_IPI_VECTOR_PRI_0);
+ mpic_write(mpic->gregs, MPIC_INFO(GREG_IPI_VECTOR_PRI_0), MPIC_VECPRI_MASK);
+ r = mpic_read(mpic->gregs, MPIC_INFO(GREG_IPI_VECTOR_PRI_0));
if (r == le32_to_cpu(MPIC_VECPRI_MASK)) {
printk(KERN_INFO "mpic: Detected reversed IPI registers\n");
@@ -394,8 +484,8 @@ static inline struct mpic * mpic_from_ir
/* Send an EOI */
static inline void mpic_eoi(struct mpic *mpic)
{
- mpic_cpu_write(MPIC_CPU_EOI, 0);
- (void)mpic_cpu_read(MPIC_CPU_WHOAMI);
+ mpic_cpu_write(MPIC_INFO(CPU_EOI), 0);
+ (void)mpic_cpu_read(MPIC_INFO(CPU_WHOAMI));
}
#ifdef CONFIG_SMP
@@ -419,8 +509,8 @@ static void mpic_unmask_irq(unsigned int
DBG("%p: %s: enable_irq: %d (src %d)\n", mpic, mpic->name, irq, src);
- mpic_irq_write(src, MPIC_IRQ_VECTOR_PRI,
- mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI) &
+ mpic_irq_write(src, MPIC_INFO(IRQ_VECTOR_PRI),
+ mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI)) &
~MPIC_VECPRI_MASK);
/* make sure mask gets to controller before we return to user */
do {
@@ -428,7 +518,7 @@ static void mpic_unmask_irq(unsigned int
printk(KERN_ERR "mpic_enable_irq timeout\n");
break;
}
- } while(mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI) & MPIC_VECPRI_MASK);
+ } while(mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI)) & MPIC_VECPRI_MASK);
}
static void mpic_mask_irq(unsigned int irq)
@@ -439,8 +529,8 @@ static void mpic_mask_irq(unsigned int i
DBG("%s: disable_irq: %d (src %d)\n", mpic->name, irq, src);
- mpic_irq_write(src, MPIC_IRQ_VECTOR_PRI,
- mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI) |
+ mpic_irq_write(src, MPIC_INFO(IRQ_VECTOR_PRI),
+ mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI)) |
MPIC_VECPRI_MASK);
/* make sure mask gets to controller before we return to user */
@@ -449,7 +539,7 @@ static void mpic_mask_irq(unsigned int i
printk(KERN_ERR "mpic_enable_irq timeout\n");
break;
}
- } while(!(mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI) & MPIC_VECPRI_MASK));
+ } while(!(mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI)) & MPIC_VECPRI_MASK));
}
static void mpic_end_irq(unsigned int irq)
@@ -560,24 +650,28 @@ static void mpic_set_affinity(unsigned i
cpus_and(tmp, cpumask, cpu_online_map);
- mpic_irq_write(src, MPIC_IRQ_DESTINATION,
+ mpic_irq_write(src, MPIC_INFO(IRQ_DESTINATION),
mpic_physmask(cpus_addr(tmp)[0]));
}
-static unsigned int mpic_type_to_vecpri(unsigned int type)
+static unsigned int mpic_type_to_vecpri(struct mpic *mpic, unsigned int type)
{
/* Now convert sense value */
switch(type & IRQ_TYPE_SENSE_MASK) {
case IRQ_TYPE_EDGE_RISING:
- return MPIC_VECPRI_SENSE_EDGE | MPIC_VECPRI_POLARITY_POSITIVE;
+ return MPIC_INFO(VECPRI_SENSE_EDGE) |
+ MPIC_INFO(VECPRI_POLARITY_POSITIVE);
case IRQ_TYPE_EDGE_FALLING:
case IRQ_TYPE_EDGE_BOTH:
- return MPIC_VECPRI_SENSE_EDGE | MPIC_VECPRI_POLARITY_NEGATIVE;
+ return MPIC_INFO(VECPRI_SENSE_EDGE) |
+ MPIC_INFO(VECPRI_POLARITY_NEGATIVE);
case IRQ_TYPE_LEVEL_HIGH:
- return MPIC_VECPRI_SENSE_LEVEL | MPIC_VECPRI_POLARITY_POSITIVE;
+ return MPIC_INFO(VECPRI_SENSE_LEVEL) |
+ MPIC_INFO(VECPRI_POLARITY_POSITIVE);
case IRQ_TYPE_LEVEL_LOW:
default:
- return MPIC_VECPRI_SENSE_LEVEL | MPIC_VECPRI_POLARITY_NEGATIVE;
+ return MPIC_INFO(VECPRI_SENSE_LEVEL) |
+ MPIC_INFO(VECPRI_POLARITY_NEGATIVE);
}
}
@@ -609,13 +703,14 @@ static int mpic_set_irq_type(unsigned in
vecpri = MPIC_VECPRI_POLARITY_POSITIVE |
MPIC_VECPRI_SENSE_EDGE;
else
- vecpri = mpic_type_to_vecpri(flow_type);
+ vecpri = mpic_type_to_vecpri(mpic, flow_type);
- vold = mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI);
- vnew = vold & ~(MPIC_VECPRI_POLARITY_MASK | MPIC_VECPRI_SENSE_MASK);
+ vold = mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI));
+ vnew = vold & ~(MPIC_INFO(VECPRI_POLARITY_MASK) |
+ MPIC_INFO(VECPRI_SENSE_MASK));
vnew |= vecpri;
if (vold != vnew)
- mpic_irq_write(src, MPIC_IRQ_VECTOR_PRI, vnew);
+ mpic_irq_write(src, MPIC_INFO(IRQ_VECTOR_PRI), vnew);
return 0;
}
@@ -798,17 +893,22 @@ struct mpic * __init mpic_alloc(struct d
mpic->irq_count = irq_count;
mpic->num_sources = 0; /* so far */
+#ifdef CONFIG_MPIC_WEIRD
+ mpic->hw_set = mpic_infos[MPIC_GET_REGSET(flags)];
+#endif
+
/* Map the global registers */
- mpic->gregs = ioremap(phys_addr + MPIC_GREG_BASE, 0x1000);
- mpic->tmregs = mpic->gregs + ((MPIC_TIMER_BASE - MPIC_GREG_BASE) >> 2);
+ mpic->gregs = ioremap(phys_addr + MPIC_INFO(GREG_BASE), 0x1000);
+ mpic->tmregs = mpic->gregs +
+ ((MPIC_INFO(TIMER_BASE) - MPIC_INFO(GREG_BASE)) >> 2);
BUG_ON(mpic->gregs == NULL);
/* Reset */
if (flags & MPIC_WANTS_RESET) {
- mpic_write(mpic->gregs, MPIC_GREG_GLOBAL_CONF_0,
- mpic_read(mpic->gregs, MPIC_GREG_GLOBAL_CONF_0)
+ mpic_write(mpic->gregs, MPIC_INFO(GREG_GLOBAL_CONF_0),
+ mpic_read(mpic->gregs, MPIC_INFO(GREG_GLOBAL_CONF_0))
| MPIC_GREG_GCONF_RESET);
- while( mpic_read(mpic->gregs, MPIC_GREG_GLOBAL_CONF_0)
+ while( mpic_read(mpic->gregs, MPIC_INFO(GREG_GLOBAL_CONF_0))
& MPIC_GREG_GCONF_RESET)
mb();
}
@@ -817,7 +917,7 @@ struct mpic * __init mpic_alloc(struct d
* MPICs, num sources as well. On ISU MPICs, sources are counted
* as ISUs are added
*/
- reg = mpic_read(mpic->gregs, MPIC_GREG_FEATURE_0);
+ reg = mpic_read(mpic->gregs, MPIC_INFO(GREG_FEATURE_0));
mpic->num_cpus = ((reg & MPIC_GREG_FEATURE_LAST_CPU_MASK)
>> MPIC_GREG_FEATURE_LAST_CPU_SHIFT) + 1;
if (isu_size == 0)
@@ -826,16 +926,16 @@ struct mpic * __init mpic_alloc(struct d
/* Map the per-CPU registers */
for (i = 0; i < mpic->num_cpus; i++) {
- mpic->cpuregs[i] = ioremap(phys_addr + MPIC_CPU_BASE +
- i * MPIC_CPU_STRIDE, 0x1000);
+ mpic->cpuregs[i] = ioremap(phys_addr + MPIC_INFO(CPU_BASE) +
+ i * MPIC_INFO(CPU_STRIDE), 0x1000);
BUG_ON(mpic->cpuregs[i] == NULL);
}
/* Initialize main ISU if none provided */
if (mpic->isu_size == 0) {
mpic->isu_size = mpic->num_sources;
- mpic->isus[0] = ioremap(phys_addr + MPIC_IRQ_BASE,
- MPIC_IRQ_STRIDE * mpic->isu_size);
+ mpic->isus[0] = ioremap(phys_addr + MPIC_INFO(IRQ_BASE),
+ MPIC_INFO(IRQ_STRIDE) * mpic->isu_size);
BUG_ON(mpic->isus[0] == NULL);
}
mpic->isu_shift = 1 + __ilog2(mpic->isu_size - 1);
@@ -879,7 +979,8 @@ void __init mpic_assign_isu(struct mpic
BUG_ON(isu_num >= MPIC_MAX_ISU);
- mpic->isus[isu_num] = ioremap(phys_addr, MPIC_IRQ_STRIDE * mpic->isu_size);
+ mpic->isus[isu_num] = ioremap(phys_addr,
+ MPIC_INFO(IRQ_STRIDE) * mpic->isu_size);
if ((isu_first + mpic->isu_size) > mpic->num_sources)
mpic->num_sources = isu_first + mpic->isu_size;
}
@@ -904,14 +1005,16 @@ void __init mpic_init(struct mpic *mpic)
printk(KERN_INFO "mpic: Initializing for %d sources\n", mpic->num_sources);
/* Set current processor priority to max */
- mpic_cpu_write(MPIC_CPU_CURRENT_TASK_PRI, 0xf);
+ mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), 0xf);
/* Initialize timers: just disable them all */
for (i = 0; i < 4; i++) {
mpic_write(mpic->tmregs,
- i * MPIC_TIMER_STRIDE + MPIC_TIMER_DESTINATION, 0);
+ i * MPIC_INFO(TIMER_STRIDE) +
+ MPIC_INFO(TIMER_DESTINATION), 0);
mpic_write(mpic->tmregs,
- i * MPIC_TIMER_STRIDE + MPIC_TIMER_VECTOR_PRI,
+ i * MPIC_INFO(TIMER_STRIDE) +
+ MPIC_INFO(TIMER_VECTOR_PRI),
MPIC_VECPRI_MASK |
(MPIC_VEC_TIMER_0 + i));
}
@@ -940,21 +1043,22 @@ void __init mpic_init(struct mpic *mpic)
(8 << MPIC_VECPRI_PRIORITY_SHIFT);
/* init hw */
- mpic_irq_write(i, MPIC_IRQ_VECTOR_PRI, vecpri);
- mpic_irq_write(i, MPIC_IRQ_DESTINATION,
+ mpic_irq_write(i, MPIC_INFO(IRQ_VECTOR_PRI), vecpri);
+ mpic_irq_write(i, MPIC_INFO(IRQ_DESTINATION),
1 << hard_smp_processor_id());
}
/* Init spurrious vector */
- mpic_write(mpic->gregs, MPIC_GREG_SPURIOUS, MPIC_VEC_SPURRIOUS);
+ mpic_write(mpic->gregs, MPIC_INFO(GREG_SPURIOUS), MPIC_VEC_SPURRIOUS);
- /* Disable 8259 passthrough */
- mpic_write(mpic->gregs, MPIC_GREG_GLOBAL_CONF_0,
- mpic_read(mpic->gregs, MPIC_GREG_GLOBAL_CONF_0)
- | MPIC_GREG_GCONF_8259_PTHROU_DIS);
+ /* Disable 8259 passthrough, if supported */
+ if (!(mpic->flags & MPIC_NO_PTHROU_DIS))
+ mpic_write(mpic->gregs, MPIC_INFO(GREG_GLOBAL_CONF_0),
+ mpic_read(mpic->gregs, MPIC_INFO(GREG_GLOBAL_CONF_0))
+ | MPIC_GREG_GCONF_8259_PTHROU_DIS);
/* Set current processor priority to 0 */
- mpic_cpu_write(MPIC_CPU_CURRENT_TASK_PRI, 0);
+ mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), 0);
}
void __init mpic_set_clk_ratio(struct mpic *mpic, u32 clock_ratio)
@@ -997,9 +1101,9 @@ void mpic_irq_set_priority(unsigned int
mpic_ipi_write(src - MPIC_VEC_IPI_0,
reg | (pri << MPIC_VECPRI_PRIORITY_SHIFT));
} else {
- reg = mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI)
+ reg = mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI))
& ~MPIC_VECPRI_PRIORITY_MASK;
- mpic_irq_write(src, MPIC_IRQ_VECTOR_PRI,
+ mpic_irq_write(src, MPIC_INFO(IRQ_VECTOR_PRI),
reg | (pri << MPIC_VECPRI_PRIORITY_SHIFT));
}
spin_unlock_irqrestore(&mpic_lock, flags);
@@ -1017,7 +1121,7 @@ unsigned int mpic_irq_get_priority(unsig
if (is_ipi)
reg = mpic_ipi_read(src = MPIC_VEC_IPI_0);
else
- reg = mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI);
+ reg = mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI));
spin_unlock_irqrestore(&mpic_lock, flags);
return (reg & MPIC_VECPRI_PRIORITY_MASK) >> MPIC_VECPRI_PRIORITY_SHIFT;
}
@@ -1043,12 +1147,12 @@ void mpic_setup_this_cpu(void)
*/
if (distribute_irqs) {
for (i = 0; i < mpic->num_sources ; i++)
- mpic_irq_write(i, MPIC_IRQ_DESTINATION,
- mpic_irq_read(i, MPIC_IRQ_DESTINATION) | msk);
+ mpic_irq_write(i, MPIC_INFO(IRQ_DESTINATION),
+ mpic_irq_read(i, MPIC_INFO(IRQ_DESTINATION)) | msk);
}
/* Set current processor priority to 0 */
- mpic_cpu_write(MPIC_CPU_CURRENT_TASK_PRI, 0);
+ mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), 0);
spin_unlock_irqrestore(&mpic_lock, flags);
#endif /* CONFIG_SMP */
@@ -1058,7 +1162,7 @@ int mpic_cpu_get_priority(void)
{
struct mpic *mpic = mpic_primary;
- return mpic_cpu_read(MPIC_CPU_CURRENT_TASK_PRI);
+ return mpic_cpu_read(MPIC_INFO(CPU_CURRENT_TASK_PRI));
}
void mpic_cpu_set_priority(int prio)
@@ -1066,7 +1170,7 @@ void mpic_cpu_set_priority(int prio)
struct mpic *mpic = mpic_primary;
prio &= MPIC_CPU_TASKPRI_MASK;
- mpic_cpu_write(MPIC_CPU_CURRENT_TASK_PRI, prio);
+ mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), prio);
}
/*
@@ -1088,11 +1192,11 @@ void mpic_teardown_this_cpu(int secondar
/* let the mpic know we don't want intrs. */
for (i = 0; i < mpic->num_sources ; i++)
- mpic_irq_write(i, MPIC_IRQ_DESTINATION,
- mpic_irq_read(i, MPIC_IRQ_DESTINATION) & ~msk);
+ mpic_irq_write(i, MPIC_INFO(IRQ_DESTINATION),
+ mpic_irq_read(i, MPIC_INFO(IRQ_DESTINATION)) & ~msk);
/* Set current processor priority to max */
- mpic_cpu_write(MPIC_CPU_CURRENT_TASK_PRI, 0xf);
+ mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), 0xf);
spin_unlock_irqrestore(&mpic_lock, flags);
}
@@ -1108,7 +1212,8 @@ void mpic_send_ipi(unsigned int ipi_no,
DBG("%s: send_ipi(ipi_no: %d)\n", mpic->name, ipi_no);
#endif
- mpic_cpu_write(MPIC_CPU_IPI_DISPATCH_0 + ipi_no * 0x10,
+ mpic_cpu_write(MPIC_INFO(CPU_IPI_DISPATCH_0) +
+ ipi_no * MPIC_INFO(CPU_IPI_DISPATCH_STRIDE),
mpic_physmask(cpu_mask & cpus_addr(cpu_online_map)[0]));
}
@@ -1116,7 +1221,7 @@ unsigned int mpic_get_one_irq(struct mpi
{
u32 src;
- src = mpic_cpu_read(MPIC_CPU_INTACK) & MPIC_VECPRI_VECTOR_MASK;
+ src = mpic_cpu_read(MPIC_INFO(CPU_INTACK)) & MPIC_INFO(VECPRI_VECTOR_MASK);
#ifdef DEBUG_LOW
DBG("%s: get_one_irq(): %d\n", mpic->name, src);
#endif
Index: linux-work/include/asm-powerpc/mpic.h
===================================================================
--- linux-work.orig/include/asm-powerpc/mpic.h 2006-08-17 09:26:22.000000000 +1000
+++ linux-work/include/asm-powerpc/mpic.h 2006-08-25 13:49:01.000000000 +1000
@@ -41,6 +41,7 @@
#define MPIC_GREG_IPI_VECTOR_PRI_1 0x000b0
#define MPIC_GREG_IPI_VECTOR_PRI_2 0x000c0
#define MPIC_GREG_IPI_VECTOR_PRI_3 0x000d0
+#define MPIC_GREG_IPI_STRIDE 0x10
#define MPIC_GREG_SPURIOUS 0x000e0
#define MPIC_GREG_TIMER_FREQ 0x000f0
@@ -68,6 +69,7 @@
#define MPIC_CPU_IPI_DISPATCH_1 0x00050
#define MPIC_CPU_IPI_DISPATCH_2 0x00060
#define MPIC_CPU_IPI_DISPATCH_3 0x00070
+#define MPIC_CPU_IPI_DISPATCH_STRIDE 0x00010
#define MPIC_CPU_CURRENT_TASK_PRI 0x00080
#define MPIC_CPU_TASKPRI_MASK 0x0000000f
#define MPIC_CPU_WHOAMI 0x00090
@@ -114,6 +116,103 @@
#define MPIC_VEC_TIMER_1 248
#define MPIC_VEC_TIMER_0 247
+/*
+ * Tsi108 implementation of MPIC has many differences from the original one
+ */
+
+/*
+ * Global registers
+ */
+
+#define TSI108_GREG_BASE 0x00000
+#define TSI108_GREG_FEATURE_0 0x00000
+#define TSI108_GREG_GLOBAL_CONF_0 0x00004
+#define TSI108_GREG_VENDOR_ID 0x0000c
+#define TSI108_GREG_IPI_VECTOR_PRI_0 0x00204 /* Doorbell 0 */
+#define TSI108_GREG_IPI_STRIDE 0x0c
+#define TSI108_GREG_SPURIOUS 0x00010
+#define TSI108_GREG_TIMER_FREQ 0x00014
+
+/*
+ * Timer registers
+ */
+#define TSI108_TIMER_BASE 0x0030
+#define TSI108_TIMER_STRIDE 0x10
+#define TSI108_TIMER_CURRENT_CNT 0x00000
+#define TSI108_TIMER_BASE_CNT 0x00004
+#define TSI108_TIMER_VECTOR_PRI 0x00008
+#define TSI108_TIMER_DESTINATION 0x0000c
+
+/*
+ * Per-Processor registers
+ */
+#define TSI108_CPU_BASE 0x00300
+#define TSI108_CPU_STRIDE 0x00040
+#define TSI108_CPU_IPI_DISPATCH_0 0x00200
+#define TSI108_CPU_IPI_DISPATCH_STRIDE 0x00000
+#define TSI108_CPU_CURRENT_TASK_PRI 0x00000
+#define TSI108_CPU_WHOAMI 0xffffffff
+#define TSI108_CPU_INTACK 0x00004
+#define TSI108_CPU_EOI 0x00008
+
+/*
+ * Per-source registers
+ */
+#define TSI108_IRQ_BASE 0x00100
+#define TSI108_IRQ_STRIDE 0x00008
+#define TSI108_IRQ_VECTOR_PRI 0x00000
+#define TSI108_VECPRI_VECTOR_MASK 0x000000ff
+#define TSI108_VECPRI_POLARITY_POSITIVE 0x01000000
+#define TSI108_VECPRI_POLARITY_NEGATIVE 0x00000000
+#define TSI108_VECPRI_SENSE_LEVEL 0x02000000
+#define TSI108_VECPRI_SENSE_EDGE 0x00000000
+#define TSI108_VECPRI_POLARITY_MASK 0x01000000
+#define TSI108_VECPRI_SENSE_MASK 0x02000000
+#define TSI108_IRQ_DESTINATION 0x00004
+
+/* weird mpic register indices and mask bits in the HW info array */
+enum {
+ MPIC_IDX_GREG_BASE = 0,
+ MPIC_IDX_GREG_FEATURE_0,
+ MPIC_IDX_GREG_GLOBAL_CONF_0,
+ MPIC_IDX_GREG_VENDOR_ID,
+ MPIC_IDX_GREG_IPI_VECTOR_PRI_0,
+ MPIC_IDX_GREG_IPI_STRIDE,
+ MPIC_IDX_GREG_SPURIOUS,
+ MPIC_IDX_GREG_TIMER_FREQ,
+
+ MPIC_IDX_TIMER_BASE,
+ MPIC_IDX_TIMER_STRIDE,
+ MPIC_IDX_TIMER_CURRENT_CNT,
+ MPIC_IDX_TIMER_BASE_CNT,
+ MPIC_IDX_TIMER_VECTOR_PRI,
+ MPIC_IDX_TIMER_DESTINATION,
+
+ MPIC_IDX_CPU_BASE,
+ MPIC_IDX_CPU_STRIDE,
+ MPIC_IDX_CPU_IPI_DISPATCH_0,
+ MPIC_IDX_CPU_IPI_DISPATCH_STRIDE,
+ MPIC_IDX_CPU_CURRENT_TASK_PRI,
+ MPIC_IDX_CPU_WHOAMI,
+ MPIC_IDX_CPU_INTACK,
+ MPIC_IDX_CPU_EOI,
+
+ MPIC_IDX_IRQ_BASE,
+ MPIC_IDX_IRQ_STRIDE,
+ MPIC_IDX_IRQ_VECTOR_PRI,
+
+ MPIC_IDX_VECPRI_VECTOR_MASK,
+ MPIC_IDX_VECPRI_POLARITY_POSITIVE,
+ MPIC_IDX_VECPRI_POLARITY_NEGATIVE,
+ MPIC_IDX_VECPRI_SENSE_LEVEL,
+ MPIC_IDX_VECPRI_SENSE_EDGE,
+ MPIC_IDX_VECPRI_POLARITY_MASK,
+ MPIC_IDX_VECPRI_SENSE_MASK,
+ MPIC_IDX_IRQ_DESTINATION,
+ MPIC_IDX_END
+};
+
+
#ifdef CONFIG_MPIC_BROKEN_U3
/* Fixup table entry */
struct mpic_irq_fixup
@@ -171,15 +270,29 @@ struct mpic
volatile u32 __iomem *cpuregs[MPIC_MAX_CPUS];
volatile u32 __iomem *isus[MPIC_MAX_ISU];
+#ifdef CONFIG_MPIC_WEIRD
+ /* Pointer to HW info array */
+ u32 *hw_set;
+#endif
+
/* link */
struct mpic *next;
};
+/*
+ * MPIC flags (passed to mpic_alloc)
+ *
+ * The top 4 bits contain an MPIC bhw id that is used to index the
+ * register offsets and some masks when CONFIG_MPIC_WEIRD is set.
+ * Note setting any ID (leaving those bits to 0) means standard MPIC
+ */
+
/* This is the primary controller, only that one has IPIs and
* has afinity control. A non-primary MPIC always uses CPU0
* registers only
*/
#define MPIC_PRIMARY 0x00000001
+
/* Set this for a big-endian MPIC */
#define MPIC_BIG_ENDIAN 0x00000002
/* Broken U3 MPIC */
@@ -188,6 +301,18 @@ struct mpic
#define MPIC_BROKEN_IPI 0x00000008
/* MPIC wants a reset */
#define MPIC_WANTS_RESET 0x00000010
+/* Spurious vector requires EOI */
+#define MPIC_SPV_EOI 0x00000020
+/* No passthrough disable */
+#define MPIC_NO_PTHROU_DIS 0x00000040
+
+/* MPIC HW modification ID */
+#define MPIC_REGSET_MASK 0xf0000000
+#define MPIC_REGSET(val) (((val) & 0xf ) << 28)
+#define MPIC_GET_REGSET(flags) (((flags) >> 28) & 0xf)
+
+#define MPIC_REGSET_STANDARD MPIC_REGSET(0) /* Original MPIC */
+#define MPIC_REGSET_TSI108 MPIC_REGSET(1) /* Tsi108/109 PIC */
/* Allocate the controller structure and setup the linux irq descs
* for the range if interrupts passed in. No HW initialization is
Index: linux-work/arch/powerpc/platforms/embedded6xx/Kconfig
===================================================================
--- linux-work.orig/arch/powerpc/platforms/embedded6xx/Kconfig 2006-06-30 11:45:54.000000000 +1000
+++ linux-work/arch/powerpc/platforms/embedded6xx/Kconfig 2006-08-25 13:24:32.000000000 +1000
@@ -80,6 +80,7 @@ config MPC7448HPC2
select DEFAULT_UIMAGE
select PPC_UDBG_16550
select MPIC
+ select MPIC_WEIRD
help
Select MPC7448HPC2 if configuring for Freescale MPC7448HPC2 (Taiga)
platform
Index: linux-work/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c 2006-06-30 11:45:54.000000000 +1000
+++ linux-work/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c 2006-08-25 13:46:04.000000000 +1000
@@ -248,7 +248,7 @@ static void __init mpc7448_hpc2_init_IRQ
mpic = mpic_alloc(mpic_paddr,
MPIC_PRIMARY | MPIC_BIG_ENDIAN | MPIC_WANTS_RESET |
- MPIC_SPV_EOI | MPIC_MOD_ID(MPIC_ID_TSI108),
+ MPIC_SPV_EOI | MPIC_NO_PTHROU_DIS | MPIC_REGSET_TSI108,
0, /* num_sources used */
TSI108_IRQ_BASE,
0, /* num_sources used */
^ permalink raw reply
* [PATCH] powerpc: Make OF irq map code detect more error cases
From: Benjamin Herrenschmidt @ 2006-08-25 4:46 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: Paul Mackerras
Device-tree bugs on js20 with some versions of SLOF were causing the
interrupt for IDE to not be parsed correctly and fail to boot. This
patch adds a bit more sanity checking to the parser to detet some of
those errors and fail instead of returning bogus informations. The
powerpc PCI code can then trigger a fallback that works on those
machines.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/powerpc/kernel/pci_64.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/pci_64.c 2006-08-17 09:26:19.000000000 +1000
+++ linux-work/arch/powerpc/kernel/pci_64.c 2006-08-25 14:38:55.000000000 +1000
@@ -1289,6 +1289,9 @@ int pci_read_irq_line(struct pci_dev *pc
DBG("Try to map irq for %s...\n", pci_name(pci_dev));
+#ifdef DEBUG
+ memset(&oirq, 0xff, sizeof(oirq));
+#endif
/* Try to get a mapping from the device-tree */
if (of_irq_map_pci(pci_dev, &oirq)) {
u8 line, pin;
@@ -1314,8 +1317,9 @@ int pci_read_irq_line(struct pci_dev *pc
if (virq != NO_IRQ)
set_irq_type(virq, IRQ_TYPE_LEVEL_LOW);
} else {
- DBG(" -> got one, spec %d cells (0x%08x...) on %s\n",
- oirq.size, oirq.specifier[0], oirq.controller->full_name);
+ DBG(" -> got one, spec %d cells (0x%08x 0x%08x...) on %s\n",
+ oirq.size, oirq.specifier[0], oirq.specifier[1],
+ oirq.controller->full_name);
virq = irq_create_of_mapping(oirq.controller, oirq.specifier,
oirq.size);
@@ -1324,6 +1328,9 @@ int pci_read_irq_line(struct pci_dev *pc
DBG(" -> failed to map !\n");
return -1;
}
+
+ DBG(" -> mapped to linux irq %d\n", virq);
+
pci_dev->irq = virq;
pci_write_config_byte(pci_dev, PCI_INTERRUPT_LINE, virq);
Index: linux-work/arch/powerpc/kernel/prom_parse.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/prom_parse.c 2006-08-17 09:26:19.000000000 +1000
+++ linux-work/arch/powerpc/kernel/prom_parse.c 2006-08-25 14:38:29.000000000 +1000
@@ -644,14 +644,17 @@ void of_irq_map_init(unsigned int flags)
}
-int of_irq_map_raw(struct device_node *parent, u32 *intspec, u32 *addr,
- struct of_irq *out_irq)
+int of_irq_map_raw(struct device_node *parent, u32 *intspec, u32 ointsize,
+ u32 *addr, struct of_irq *out_irq)
{
struct device_node *ipar, *tnode, *old = NULL, *newpar = NULL;
u32 *tmp, *imap, *imask;
u32 intsize = 1, addrsize, newintsize = 0, newaddrsize = 0;
int imaplen, match, i;
+ DBG("of_irq_map_raw: par=%s,intspec=[0x%08x 0x%08x...],ointsize=%d\n",
+ parent->full_name, intspec[0], intspec[1], ointsize);
+
ipar = of_node_get(parent);
/* First get the #interrupt-cells property of the current cursor
@@ -675,6 +678,9 @@ int of_irq_map_raw(struct device_node *p
DBG("of_irq_map_raw: ipar=%s, size=%d\n", ipar->full_name, intsize);
+ if (ointsize != intsize)
+ return -EINVAL;
+
/* Look for this #address-cells. We have to implement the old linux
* trick of looking for the parent here as some device-trees rely on it
*/
@@ -880,12 +886,15 @@ int of_irq_map_one(struct device_node *d
}
intsize = *tmp;
+ DBG(" intsize=%d intlen=%d\n", intsize, intlen);
+
/* Check index */
if ((index + 1) * intsize > intlen)
return -EINVAL;
/* Get new specifier and map it */
- res = of_irq_map_raw(p, intspec + index * intsize, addr, out_irq);
+ res = of_irq_map_raw(p, intspec + index * intsize, intsize,
+ addr, out_irq);
of_node_put(p);
return res;
}
@@ -964,7 +973,7 @@ int of_irq_map_pci(struct pci_dev *pdev,
laddr[0] = (pdev->bus->number << 16)
| (pdev->devfn << 8);
laddr[1] = laddr[2] = 0;
- return of_irq_map_raw(ppnode, &lspec, laddr, out_irq);
+ return of_irq_map_raw(ppnode, &lspec, 1, laddr, out_irq);
}
EXPORT_SYMBOL_GPL(of_irq_map_pci);
Index: linux-work/include/asm-powerpc/prom.h
===================================================================
--- linux-work.orig/include/asm-powerpc/prom.h 2006-08-17 09:26:22.000000000 +1000
+++ linux-work/include/asm-powerpc/prom.h 2006-08-25 14:35:55.000000000 +1000
@@ -276,6 +276,7 @@ extern void of_irq_map_init(unsigned int
* of_irq_map_raw - Low level interrupt tree parsing
* @parent: the device interrupt parent
* @intspec: interrupt specifier ("interrupts" property of the device)
+ * @ointsize: size of the passed in interrupt specifier
* @addr: address specifier (start of "reg" property of the device)
* @out_irq: structure of_irq filled by this function
*
@@ -288,7 +289,8 @@ extern void of_irq_map_init(unsigned int
*
*/
-extern int of_irq_map_raw(struct device_node *parent, u32 *intspec, u32 *addr,
+extern int of_irq_map_raw(struct device_node *parent, u32 *intspec,
+ u32 ointsize, u32 *addr,
struct of_irq *out_irq);
^ permalink raw reply
* Problems with uaccsess.h
From: Keinen Namen @ 2006-08-25 5:28 UTC (permalink / raw)
To: linuxppc-embedded
Hi
when I compile my program i got this message
bash-2.05b# make
gcc -O2 -DMODULE -D__KERNEL__ -W -Wall -Wstrict-prototypes
-Wmissing-prototypes -isystem /lib/modules/`uname -r`/build/include
-c -o hello.o hello.c
hello.c:5:25: linux/version: No such file or directory
In file included from hello.c:9:
/usr/include/asm/uaccess.h: In function `verify_area':
/usr/include/asm/uaccess.h:37: error: `CONFIG_TASK_SIZE' undeclared
(first use in this function)
/usr/include/asm/uaccess.h:37: error: (Each undeclared identifier is
reported only once
/usr/include/asm/uaccess.h:37: error: for each function it appears in.)
/usr/include/asm/uaccess.h: In function `copy_from_user':
/usr/include/asm/uaccess.h:280: error: `CONFIG_TASK_SIZE' undeclared
(first use in this function)
/usr/include/asm/uaccess.h: In function `copy_to_user':
/usr/include/asm/uaccess.h:294: error: `CONFIG_TASK_SIZE' undeclared
(first use in this function)
/usr/include/asm/uaccess.h: In function `clear_user':
/usr/include/asm/uaccess.h:313: error: `CONFIG_TASK_SIZE' undeclared
(first use in this function)
/usr/include/asm/uaccess.h: In function `strncpy_from_user':
/usr/include/asm/uaccess.h:327: error: `CONFIG_TASK_SIZE' undeclared
(first use in this function)
/usr/include/asm/uaccess.h: In function `strnlen_user':
/usr/include/asm/uaccess.h:350: error: `CONFIG_TASK_SIZE' undeclared
(first use in this function)
These Header files I have include
#include <linux/module.h> /* Needed by all modules */
#include <linux/kernel.h> /* Needed for KERN_ALERT */
#include <linux/slab.h>
#include <linux/delay.h>
#include <linux/version>
#include <linux/init.h>
#include <linux/fs.h>
#include <asm/types.h>
#include <asm/mpc8260.h>
#include <asm/cpm_8260.h>
#include <asm/page.h>
#include <asm/uaccess.h>
My linux is 2.4.25
Need I a patch to correct this ?? I need the funktion copy_to_user.
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: "ip=" command line strangeness...
From: Claus Gindhart @ 2006-08-25 5:48 UTC (permalink / raw)
To: T Ziomek, linuxppc-embedded
Hi,
please provide the ip-commandline in the full-size format
ip=3D<my ip>:<server ip>:<host ip>:<net mask>:<hostname>:<which =
ethernet port, e.g. "eth0">=20
I assume, that this will fix your problem
--=20
Mit freundlichen Gruessen / Best regards
Claus Gindhart
SW R&D
Kontron Modular Computers
phone :++49 (0)8341-803-374
mailto:claus.gindhart@kontron-modular.com
http://www.kontron.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o?
K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++
D-- G e++> h--- !r x+++
------END GEEK CODE BLOCK------
=20
-----Original Message-----
From: linuxppc-embedded-bounces+claus.gindhart=3Dkontron.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+claus.gindhart=3Dkontron.com@ozlabs.org=
]
On Behalf Of T Ziomek
Sent: Freitag, 25. August 2006 01:39
To: linuxppc-embedded
Cc: tomz
Subject: "ip=3D" command line strangeness...
On my previous project, a 2.4 kernel on PPC, I frequently used=20
"ip=3Dw.x.y.z" on the kernel command line to specify a static IP address =
for
my target board (when booting with a flash- or RAM-based root =
filesystem).
Similarly, when using an NFS-mounted root fs, I would use
"ip=3Dw.x.y.z:a.b.c.d", along with the appropriate "nfsroot=3D..." =
setting,
with my NFS server having IP a.b.c.d .
Now I am working with a 2.6.10-based kernel on ARM. Using an NFS root =
fs
works fine when I use the expected "ip=3Dw.x.y.z:a.b.c.d". And booting =
off
with "root=3D/dev/hda1" works fine with "ip=3Ddhcp".
I'd expect to be able to use "root=3D/dev/hda1 ip=3Dw.x.y.z" if I =
want the
target using a static IP address. But this fails, and in a VERY weird
way: (1) It tries doing DHCP, which it shouldn't, and (2) the DHCP =
fails,
which it shouldn't because it works when I want DHCP to be used.
Here's a snippet of console output:
.
.
.
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
Sending DHCP requests ...... timed out!
EMAC: TX Complete: Starting queue
IP-Config: Reopening network devices...
Sending DHCP requests ...
Okay, that's two weird things. There is a third -- this problem goes a-
way if I change the command line to something like
"root=3D/dev/hda1 ip=3Dw.x.y.z:a.b.c.d". The only change is adding an =
NFS
server IP address to the "ip=3D" command, which should have no effect =
be-
cause NFS is not being used. Yet when I do that the board boots as ex-
pected -- it does not try to do DHCP, it does use /dev/hda1 for its root
fs, and it does take the specified IP address.
In fact, it works even if I use a command line with, literally,
"root=3D/dev/hda1 ip=3D199.5.233.72:gobbledygook":
.
.
.
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
device=3Deth0, addr=3D199.5.233.72, =
mask=3D255.255.255.0, gw=3D255.255.255.255,
host=3D199.5.233.72, domain=3D, nis-domain=3D(none),
bootserver=3D232.0.0.0, rootserver=3D232.0.0.0, =
rootpath=3D
.
.
.
This isn't a big problem, but can anybody explain what the heck is going
on?
Thanks, Tom
--=20
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH] powerpc: Improve IRQ radix tree locking
From: Benjamin Herrenschmidt @ 2006-08-25 6:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
When reworking the powerpc irq code, I figured out that we were using
the radix tree in a racy way. As a temporary fix, I put a spinlock in
there. However, this can have a significant impact on performances. This
patch reworks that to use a smarter technique based on the fact that
what we need is in fact a rwlock with extremely rare writers (thus
optimized for the read path).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/powerpc/kernel/irq.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/irq.c 2006-08-25 14:08:41.000000000 +1000
+++ linux-work/arch/powerpc/kernel/irq.c 2006-08-25 15:56:17.000000000 +1000
@@ -322,7 +322,8 @@ EXPORT_SYMBOL(do_softirq);
static LIST_HEAD(irq_hosts);
static spinlock_t irq_big_lock = SPIN_LOCK_UNLOCKED;
-
+static DEFINE_PER_CPU(unsigned int, irq_radix_reader);
+static unsigned int irq_radix_writer;
struct irq_map_entry irq_map[NR_IRQS];
static unsigned int irq_virq_count = NR_IRQS;
static struct irq_host *irq_default_host;
@@ -455,6 +456,60 @@ void irq_set_virq_count(unsigned int cou
irq_virq_count = count;
}
+/* radix tree not lockless safe ! we use a brlock-type mecanism
+ * for now, until we can use a lockless radix tree
+ */
+static void irq_radix_wrlock(unsigned long *flags)
+{
+ unsigned int cpu, ok;
+
+ spin_lock_irqsave(&irq_big_lock, *flags);
+ irq_radix_writer = 1;
+ do {
+ ok = 1;
+ smp_mb();
+ for_each_possible_cpu(cpu) {
+ if (per_cpu(irq_radix_reader, cpu)) {
+ ok = 0;
+ break;
+ }
+ }
+ if (!ok)
+ cpu_relax();
+ } while(!ok);
+}
+
+static void irq_radix_wrunlock(unsigned long flags)
+{
+ smp_wmb();
+ irq_radix_writer = 0;
+ spin_unlock_irqrestore(&irq_big_lock, flags);
+}
+
+static void irq_radix_rdlock(unsigned long *flags)
+{
+ local_irq_save(*flags);
+ if (irq_radix_writer)
+ goto slow;
+ __get_cpu_var(irq_radix_reader) = 1;
+ smp_mb();
+ if (irq_radix_writer == 0)
+ return;
+ __get_cpu_var(irq_radix_reader) = 0;
+ smp_wmb();
+ slow:
+ spin_lock(&irq_big_lock);
+ __get_cpu_var(irq_radix_reader) = 1;
+ spin_unlock(&irq_big_lock);
+}
+
+static void irq_radix_rdunlock(unsigned long flags)
+{
+ __get_cpu_var(irq_radix_reader) = 0;
+ local_irq_restore(flags);
+}
+
+
unsigned int irq_create_mapping(struct irq_host *host,
irq_hw_number_t hwirq)
{
@@ -604,13 +659,9 @@ void irq_dispose_mapping(unsigned int vi
/* Check if radix tree allocated yet */
if (host->revmap_data.tree.gfp_mask == 0)
break;
- /* XXX radix tree not safe ! remove lock whem it becomes safe
- * and use some RCU sync to make sure everything is ok before we
- * can re-use that map entry
- */
- spin_lock_irqsave(&irq_big_lock, flags);
+ irq_radix_wrlock(&flags);
radix_tree_delete(&host->revmap_data.tree, hwirq);
- spin_unlock_irqrestore(&irq_big_lock, flags);
+ irq_radix_wrunlock(flags);
break;
}
@@ -677,25 +728,24 @@ unsigned int irq_radix_revmap(struct irq
if (tree->gfp_mask == 0)
return irq_find_mapping(host, hwirq);
- /* XXX Current radix trees are NOT SMP safe !!! Remove that lock
- * when that is fixed (when Nick's patch gets in
- */
- spin_lock_irqsave(&irq_big_lock, flags);
-
/* Now try to resolve */
+ irq_radix_rdlock(&flags);
ptr = radix_tree_lookup(tree, hwirq);
+ irq_radix_rdunlock(flags);
+
/* Found it, return */
if (ptr) {
virq = ptr - irq_map;
- goto bail;
+ return virq;
}
/* If not there, try to insert it */
virq = irq_find_mapping(host, hwirq);
- if (virq != NO_IRQ)
+ if (virq != NO_IRQ) {
+ irq_radix_wrlock(&flags);
radix_tree_insert(tree, hwirq, &irq_map[virq]);
- bail:
- spin_unlock_irqrestore(&irq_big_lock, flags);
+ irq_radix_wrunlock(flags);
+ }
return virq;
}
@@ -806,12 +856,12 @@ static int irq_late_init(void)
struct irq_host *h;
unsigned long flags;
- spin_lock_irqsave(&irq_big_lock, flags);
+ irq_radix_wrlock(&flags);
list_for_each_entry(h, &irq_hosts, link) {
if (h->revmap_type == IRQ_HOST_MAP_TREE)
INIT_RADIX_TREE(&h->revmap_data.tree, GFP_ATOMIC);
}
- spin_unlock_irqrestore(&irq_big_lock, flags);
+ irq_radix_wrunlock(flags);
return 0;
}
^ permalink raw reply
* RE: Problems with uaccsess.h
From: Chun Chung Lo @ 2006-08-25 5:43 UTC (permalink / raw)
To: Keinen Namen; +Cc: linuxppc-embedded
Hi,
Seems your makefile does not include all the kernel header ...
Please try to add this ' -I(linux kernel source path)/include ' to your=
makefile as CFLAGS.
Best regards,
Lo Chun Chung
-----Original Message-----
From: linuxppc-embedded-bounces+cclo=3Dastri.org@ozlabs.org=
[mailto:linuxppc-embedded-bounces+cclo=3Dastri.org@ozlabs.org] On Behalf=
Of Keinen Namen
Sent: Friday, 25 August, 2006 1:29 PM
To: linuxppc-embedded@ozlabs.org
Subject: Problems with uaccsess.h
Hi
when I compile my program i got this message
bash-2.05b# make
gcc -O2 -DMODULE -D__KERNEL__ -W -Wall -Wstrict-prototypes=
-Wmissing-prototypes -isystem /lib/modules/`uname -r`/build/include -c -o=
hello.o hello.c
hello.c:5:25: linux/version: No such file or directory
In file included from hello.c:9:
/usr/include/asm/uaccess.h: In function `verify_area':
/usr/include/asm/uaccess.h:37: error: `CONFIG_TASK_SIZE' undeclared (first=
use in this function)
/usr/include/asm/uaccess.h:37: error: (Each undeclared identifier is=
reported only once
/usr/include/asm/uaccess.h:37: error: for each function it appears in.)
/usr/include/asm/uaccess.h: In function `copy_from_user':
/usr/include/asm/uaccess.h:280: error: `CONFIG_TASK_SIZE' undeclared (first=
use in this function)
/usr/include/asm/uaccess.h: In function `copy_to_user':
/usr/include/asm/uaccess.h:294: error: `CONFIG_TASK_SIZE' undeclared (first=
use in this function)
/usr/include/asm/uaccess.h: In function `clear_user':
/usr/include/asm/uaccess.h:313: error: `CONFIG_TASK_SIZE' undeclared (first=
use in this function)
/usr/include/asm/uaccess.h: In function `strncpy_from_user':
/usr/include/asm/uaccess.h:327: error: `CONFIG_TASK_SIZE' undeclared (first=
use in this function)
/usr/include/asm/uaccess.h: In function `strnlen_user':
/usr/include/asm/uaccess.h:350: error: `CONFIG_TASK_SIZE' undeclared (first=
use in this function)
These Header files I have include
#include <linux/module.h> /* Needed by all modules */
#include <linux/kernel.h> /* Needed for KERN_ALERT */
#include <linux/slab.h>
#include <linux/delay.h>
#include <linux/version>
#include <linux/init.h>
#include <linux/fs.h>
#include <asm/types.h>
#include <asm/mpc8260.h>
#include <asm/cpm_8260.h>
#include <asm/page.h>
#include <asm/uaccess.h>
My linux is 2.4.25
Need I a patch to correct this ?? I need the funktion copy_to_user.
Regards
Fred
--=0D
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
This message (including any attachments) is for the named addressee(s)'s=
use only. It may contain
sensitive, confidential, private proprietary or legally privileged=
information intended for a
specific individual and purpose, and is protected by law. If you are not=
the intended recipient,
please immediately delete it and all copies of it from your system, destroy=
any hard copies of it
and notify the sender. Any use, disclosure, copying, or distribution of=
this message and/or any
attachments is strictly prohibited.
^ permalink raw reply
* Toolchain for ppc405
From: Akhilesh Soni @ 2006-08-25 6:01 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 289 bytes --]
Hi,
I'm current running 2.4.18 kernel from montavista for my pp405(redwood6) platform. I wish to upgrade to 2.6 kernel. Is is possible ? How should I proceed in this direction.
Has anybody earlier ported ppc405(redwood6) for 2.6 kernel
Thanx in advance.
Regards,
Akhilesh
[-- Attachment #2: Type: text/html, Size: 1058 bytes --]
^ permalink raw reply
* RE: Toolchain for ppc405
From: Chun Chung Lo @ 2006-08-25 6:37 UTC (permalink / raw)
To: Akhilesh Soni, linuxppc-embedded
Hi,=0D
For quick reference, ELDK (Embedded Linux Development Kit) may be
suitable for you.
http://www.denx.de/en/News/PressReleaseELDK40 or
http://www.denx.de/wiki/DULG/ELDK
The latest version is 4.0, which support linux kernel 2.6.
Thanks.
Best regards,
Lo Chun Chung=0D
-----Original Message-----
From: linuxppc-embedded-bounces+cclo=3Dastri.org@ozlabs.org
[mailto:linuxppc-embedded-bounces+cclo=3Dastri.org@ozlabs.org] On Behalf
Of Akhilesh Soni
Sent: Friday, 25 August, 2006 2:01 PM
To: linuxppc-embedded@ozlabs.org
Subject: Toolchain for ppc405
Hi,
I'm current running 2.4.18 kernel from montavista for my pp405(redwood6)
platform. I wish to upgrade to 2.6 kernel. Is is possible ? How should I
proceed in this direction.
Has anybody earlier ported ppc405(redwood6) for 2.6 kernel
Thanx in advance.
Regards,
Akhilesh=0D
This message (including any attachments) is for the named addressee(s)'s=
use only. It may contain
sensitive, confidential, private proprietary or legally privileged=
information intended for a
specific individual and purpose, and is protected by law. If you are not=
the intended recipient,
please immediately delete it and all copies of it from your system, destroy=
any hard copies of it
and notify the sender. Any use, disclosure, copying, or distribution of=
this message and/or any
attachments is strictly prohibited.
^ permalink raw reply
* Re: communication with i2c client
From: Yong Wang @ 2006-08-25 7:14 UTC (permalink / raw)
To: lk99336; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 233 bytes --]
I think you should check the i2c drivers first.
Only the i2c drivers support the slave mode, the user space application can
access the i2c device.
The i2c drivers should modify the mode register of i2c controller to switch
the mode.
[-- Attachment #2: Type: text/html, Size: 267 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Support for "weird" MPICs and fixup mpc7448_hpc2
From: Zang Roy-r61911 @ 2006-08-25 7:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1156479390.8433.293.camel@localhost.localdomain>
On Fri, 2006-08-25 at 12:16, Benjamin Herrenschmidt wrote:
> This patch is a slightly cleaned up version of Zang Roy's support for
> the TSI108 MPIC variant. It also fixes up MPC7448_hpc2 to use the new
> version of the type macros and changes the way MPIC is selected in
> Kconfig to better match what is done for other system devices.
>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Zang Roy, please verify that it still works for you. I've tested it on
> an Apple G5 with and without CONFIG_MPIC_WEIRD .
>
It works OK on my mpc7448hpc2 board.
There is a sequence for the patch applying.
(1) patch for IRQ update for mpc7448hpc2:
http://ozlabs.org/pipermail/linuxppc-dev/2006-August/025559.html
(2) the weird mpic patch repost by your mail.
(3) the following minor patch to build mpic.o for CONFIG_MPIC_WEIRD
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index cebfae2..8ae887b 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -3,6 +3,7 @@ EXTRA_CFLAGS += -mno-minimal-toc
endif
obj-$(CONFIG_MPIC) += mpic.o
+obj-$(CONFIG_MPIC_WEIRD) += mpic.o
obj-$(CONFIG_PPC_INDIRECT_PCI) += indirect_pci.o
obj-$(CONFIG_PPC_MPC106) += grackle.o
obj-$(CONFIG_BOOKE) += dcr.o
^ permalink raw reply related
* [PATCH ] powerpc: mpc7448hpc2 device tree source file
From: Zang Roy-r61911 @ 2006-08-25 8:43 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Yang Xin-Xin-r48390
In-Reply-To: <7EA18FDD2DC2154AA3BD6D2F22A62A0E19E353@zch01exm23.fsl.freescale.net>
This patch adds the mpc7448hpc2 device tree source file.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
arch/powerpc/boot/dts/mpc7448hpc2.dts | 190 +++++++++++++++++++++++++++++++++
1 files changed, 190 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc7448hpc2.dts b/arch/powerpc/boot/dts/mpc7448hpc2.dts
new file mode 100644
index 0000000..d7b985e
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc7448hpc2.dts
@@ -0,0 +1,190 @@
+/*
+ * MPC7448HPC2 (Taiga) board Device Tree Source
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ * 2006 Roy Zang <Roy Zang at freescale.com>.
+ *
+ * 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.
+ */
+
+
+/ {
+ model = "mpc7448hpc2";
+ compatible = "mpc74xx";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ linux,phandle = <100>;
+
+ cpus {
+ #cpus = <1>;
+ #address-cells = <1>;
+ #size-cells =<0>;
+ linux,phandle = <200>;
+
+ PowerPC,7448@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <20>; // 32 bytes
+ i-cache-line-size = <20>; // 32 bytes
+ d-cache-size = <8000>; // L1, 32K bytes
+ i-cache-size = <8000>; // L1, 32K bytes
+ timebase-frequency = <0>; // 33 MHz, from uboot
+ clock-frequency = <0>; // From U-Boot
+ bus-frequency = <0>; // From U-Boot
+ 32-bit;
+ linux,phandle = <201>;
+ linux,boot-cpu;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ linux,phandle = <300>;
+ reg = <00000000 20000000 // DDR2 512M at 0
+ >;
+ };
+
+ tsi108@c0000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ device_type = "tsi-bridge";
+ ranges = <00000000 c0000000 00010000>;
+ reg = <c0000000 00010000>;
+ bus-frequency = <0>;
+
+ i2c@7000 {
+ interrupt-parent = <7400>;
+ interrupts = <E 0>;
+ reg = <7000 400>;
+ device_type = "i2c";
+ compatible = "tsi-i2c";
+ };
+
+ mdio@6000 {
+ device_type = "mdio";
+ compatible = "tsi-ethernet";
+
+ ethernet-phy@6000 {
+ linux,phandle = <6000>;
+ interrupt-parent = <7400>;
+ interrupts = <2 1>;
+ reg = <6000 50>;
+ phy-id = <8>;
+ device_type = "ethernet-phy";
+ };
+
+ ethernet-phy@6400 {
+ linux,phandle = <6400>;
+ interrupt-parent = <7400>;
+ interrupts = <2 1>;
+ reg = <6000 50>;
+ phy-id = <9>;
+ device_type = "ethernet-phy";
+ };
+
+ };
+
+ ethernet@6200 {
+ #size-cells = <0>;
+ device_type = "network";
+ model = "TSI-ETH";
+ compatible = "tsi-ethernet";
+ reg = <6000 200>;
+ address = [ 00 06 D2 00 00 01 ];
+ interrupts = <10 2>;
+ interrupt-parent = <7400>;
+ phy-handle = <6000>;
+ };
+
+ ethernet@6600 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "TSI-ETH";
+ compatible = "tsi-ethernet";
+ reg = <6400 200>;
+ address = [ 00 06 D2 00 00 02 ];
+ interrupts = <11 2>;
+ interrupt-parent = <7400>;
+ phy-handle = <6400>;
+ };
+
+ serial@7808 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <7808 200>;
+ clock-frequency = <3f6b5a00>;
+ interrupts = <c 0>;
+ interrupt-parent = <7400>;
+ };
+
+ serial@7c08 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <7c08 200>;
+ clock-frequency = <3f6b5a00>;
+ interrupts = <d 0>;
+ interrupt-parent = <7400>;
+ };
+
+ pic@7400 {
+ linux,phandle = <7400>;
+ clock-frequency = <0>;
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <7400 400>;
+ built-in;
+ compatible = "chrp,open-pic";
+ device_type = "open-pic";
+ big-endian;
+ };
+ pci@1000 {
+ compatible = "tsi10x";
+ device_type = "pci";
+ linux,phandle = <1000>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <1000 1000>;
+ bus-range = <0 0>;
+ ranges = <02000000 0 e0000000 e0000000 0 1A000000
+ 01000000 0 00000000 fa000000 0 00010000>;
+ clock-frequency = <7f28154>;
+ interrupt-parent = <7400>;
+ interrupts = <17 2>;
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+
+ /* IDSEL 0x11 */
+ 0800 0 0 1 7400 24 0
+ 0800 0 0 2 7400 25 0
+ 0800 0 0 3 7400 26 0
+ 0800 0 0 4 7400 27 0
+
+ /* IDSEL 0x12 */
+ 1000 0 0 1 7400 25 0
+ 1000 0 0 2 7400 26 0
+ 1000 0 0 3 7400 27 0
+ 1000 0 0 4 7400 24 0
+
+ /* IDSEL 0x13 */
+ 1800 0 0 1 7400 26 0
+ 1800 0 0 2 7400 27 0
+ 1800 0 0 3 7400 24 0
+ 1800 0 0 4 7400 25 0
+
+ /* IDSEL 0x14 */
+ 2000 0 0 1 7400 27 0
+ 2000 0 0 2 7400 24 0
+ 2000 0 0 3 7400 25 0
+ 2000 0 0 4 7400 26 0
+ >;
+ };
+ };
+
+};
--
1.4.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox