* [PATCH] fix pmac_zilog debug arg
From: Olaf Hering @ 2007-08-26 9:10 UTC (permalink / raw)
To: linuxppc-dev
drivers/serial/pmac_zilog.c:1590: warning: format '%d' expects type 'int', but argument 3 has type 'pm_message_t'
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
drivers/serial/pmac_zilog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/serial/pmac_zilog.c
+++ b/drivers/serial/pmac_zilog.c
@@ -1587,7 +1587,7 @@ static int pmz_suspend(struct macio_dev
if (pm_state.event == mdev->ofdev.dev.power.power_state.event)
return 0;
- pmz_debug("suspend, switching to state %d\n", pm_state);
+ pmz_debug("suspend, switching to state %d\n", pm_state.event);
state = pmz_uart_reg.state + uap->port.line;
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Add pci node to sequoia dts
From: Vitaly Bordug @ 2007-08-26 10:27 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <67f53d72d17c98f2b8a76ec42195c0aa@kernel.crashing.org>
On Sat, 25 Aug 2007 11:49:58 +0200
Segher Boessenkool wrote:
> > + pci {
> > + reg = <1 eec00000 40 1 ef400000
> > 40>; /* phb cfg, phb reg */
>
> First component of reg is the unit address, so: pci@1eec00000 .
>
> "phb cfg" is how you access PCI configuration space? It wouldn't
> hurt to document that, either in a little binding or just here in
> the code.
>
mmm, that was what my poor upper comment about, exactly.
do you mean that "PCI configuration space xxxx_xxxx, PCI register at xxxx_xxxx" will look more
appropriate?
> > + bus-range = <0 0>;
>
> Can't you have subordinate PCI busses? Or are there no slots :-)
>
Even if there are (and I dunno - Stefan did the HW validation and updates, since he has actual target),
the performance of such a beast would be low, with one shared irq for everybody...
> > + /*
> > + * mem is at 80000000 set up indirectly
> > + * io is at 0001_e800_0000
> > + */
> > + ranges = <02000000 0 80000000 1 80000000 0
> > 10000000
> > + 01000000 0 00000000 1 e8000000 0
> > 00100000>;
>
> Comment doesn't match code for the memory space. What does "set
> up indirectly" mean here? Oh wait, you want to say that the host
> addresses 1_8000_0000..1_8fff_ffff are translated to PCI addresses
> 8000_0000..8fff_ffff.
>
Yes, exactly.
> What about PCI DMA, is that identity mapped?
>
Not thinking about it atm, should "just work" /*though it never really does*/ :)
> > + #interrupt-cells = <1>;
> > + #size-cells = <2>;
> > + #address-cells = <3>;
>
> The reverse order of these is more conventional. Not that it
> actually matters ;-)
ok, I'll reorder them
>
> > + compatible = "ibm, 440epx";
>
> Stray space. And you need to say it is the PCI host, so something
> like "ibm,440epx-pci".
>
OK, will have "amcc,.440epx-pci" here
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [RFC] xmon: setjmp / longjmp implementation problems
From: Florian Boelstler @ 2007-08-26 14:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <46CE0CF6.2010804@arcor.de>
Just for the record:
I made a mistake in my userspace test environment regarding the
setjmp/longjmp implementation.
I defined setjmp/longjmp functions as static ones, which triggered
recent compilers to inline. Inlining breaks setjmp/longjmp of course.
Further I realized that the NuBus-specific setjmp/longjmp was also
defined as static functions. For xmon this was never the case (even
defined in a separate file).
Thanks to David Gibson and Sergei Shtylyov for answering my questions
on #mklinux.
Cheers,
Florian
^ permalink raw reply
* NFS failed in linux-2.6-virtex tree for xilinx ML403
From: Ming Liu @ 2007-08-26 16:09 UTC (permalink / raw)
To: grant.likely; +Cc: linuxppc-embedded
Dear Grant,
I am bringing up your linux-2.6-virtex tree. However the following problem
happened:
eth0: XTemac: speed set to 1000Mb/s
eth0: XTemac: Send Threshold = 16, Receive Threshold = 2
eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1
IP-Config: Complete:
device=eth0, addr=192.168.0.4, mask=255.255.255.0, gw=192.168.0.3,
host=192.168.0.4, domain=, nis-domain=(none),
bootserver=192.168.0.3, rootserver=192.168.0.3, rootpath=
Looking up port of RPC 100003/2 on 192.168.0.3
rpcbind: server 192.168.0.3 not responding, timed out
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 192.168.0.3
rpcbind: server 192.168.0.3 not responding, timed out
Root-NFS: Unable to get mountd port number from server, using default
mount: server 0.0.0.16 not responding, timed out
Root-NFS: Server returned error -5 while mounting
/home/mingliu/ml403_rootfs
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "nfs" or unknown-block(2,0)
Please append a correct "root=" boot option; here are the available
partitions:
fe00 509544 xsa (driver?)
fe01 98248 xsa1
fe02 402192 xsa2
1f00 8192 mtdblock0 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(2,0)
Rebooting in 180 seconds..
My CMD_LINE is "root=/dev/nfs
nfsaddrs=192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw
nfsroot=192.168.0.3:/home/mingliu/ml403_rootfs console=ttyS0,9600 mem=32M"
First of all, I can exclude the problem of my host PC, because the old
2.6.10 version could run with nfs and root directory mounted successfully.
So what's wrong with the NFS support in the new kernel? It's quite strange
that in the information above, why "mount: server 0.0.0.16 not responding",
rather than the server of 192.168.0.3 which should be there? Do you have
any hint? Thanks a lot in advance.
Best Regards
Ming
_________________________________________________________________
免费下载 MSN Explorer: http://explorer.msn.com/lccn/
^ permalink raw reply
* Re: [PATCH, RFC] linkstation: implement standby
From: Guennadi Liakhovetski @ 2007-08-26 19:10 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, linux-pm
In-Reply-To: <20070826110830.dfe6ea24.sfr@canb.auug.org.au>
On Sun, 26 Aug 2007, Stephen Rothwell wrote:
> On Sun, 26 Aug 2007 02:03:49 +0200 (CEST) Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote:
> >
> > +static int ls_pm_enter(suspend_state_t state)
> > +{
> > + char ier;
> > + int ret = 0;
> > + u64 tb;
> > +
> > + if ((ret = mpc10x_suspend(state)) < 0)
> > + return ret;
> > +
> > + /* Get timebase */
> > + tb = get_tb();
> > +
> > + /* put CPU to sleep, re-enabling interrupts */
> > + mpc6xx_enter_sleep();
> > +
> > + local_irq_disable();
> > +
> > + set_tb(tb >> 32, tb & 0xfffffffful);
> > +
> > +fail:
>
> Unused label?
Right, will fix in the next version, thanks.
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Add pci node to sequoia dts
From: Segher Boessenkool @ 2007-08-26 19:10 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20070826142750.0a6a228e@localhost.localdomain>
>>> + pci {
>>> + reg = <1 eec00000 40 1 ef400000
>>> 40>; /* phb cfg, phb reg */
>>
>> First component of reg is the unit address, so: pci@1eec00000 .
>>
>> "phb cfg" is how you access PCI configuration space? It wouldn't
>> hurt to document that, either in a little binding or just here in
>> the code.
>>
> mmm, that was what my poor upper comment about, exactly.
> do you mean that "PCI configuration space xxxx_xxxx, PCI register at
> xxxx_xxxx" will look more
> appropriate?
I just mean you should document what the two "reg" regions for this
device are meant to represent. "phb reg" isn't really verbose enough
;-)
>>> + bus-range = <0 0>;
>>
>> Can't you have subordinate PCI busses? Or are there no slots :-)
>>
> Even if there are (and I dunno - Stefan did the HW validation and
> updates, since he has actual target),
> the performance of such a beast would be low, with one shared irq for
> everybody...
Sure, but this is about correctness, not performance.
>>> + /*
>>> + * mem is at 80000000 set up indirectly
>>> + * io is at 0001_e800_0000
>>> + */
>>> + ranges = <02000000 0 80000000 1 80000000 0
>>> 10000000
>>> + 01000000 0 00000000 1 e8000000 0
>>> 00100000>;
>>
>> Comment doesn't match code for the memory space. What does "set
>> up indirectly" mean here? Oh wait, you want to say that the host
>> addresses 1_8000_0000..1_8fff_ffff are translated to PCI addresses
>> 8000_0000..8fff_ffff.
>>
> Yes, exactly.
Great. Could you please fix the comment to just say this, then?
>> What about PCI DMA, is that identity mapped?
>>
> Not thinking about it atm, should "just work" /*though it never really
> does*/ :)
Okay, if it's identity mapped, you don't need any properties in the
device tree for it. Good :-)
Segher
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: James Chapman @ 2007-08-26 19:36 UTC (permalink / raw)
To: David Miller
Cc: tklein, themann, stefan.roscher, netdev, linux-kernel, raisch,
linuxppc-dev, akepner, meder, ossthema, shemminger
In-Reply-To: <20070824.144711.18301866.davem@davemloft.net>
David Miller wrote:
> From: James Chapman <jchapman@katalix.com>
> Date: Fri, 24 Aug 2007 18:16:45 +0100
>
>> Does hardware interrupt mitigation really interact well with NAPI?
>
> It interacts quite excellently.
If NAPI disables interrupts and keeps them disabled while there are more
packets arriving or more transmits being completed, why do hardware
interrupt mitigation / coalescing features of the network silicon help?
> There was a long saga about this with tg3 and huge SGI numa
> systems with large costs for interrupt processing, and the
> fix was to do a minimal amount of interrupt mitigation and
> this basically cleared up all the problems.
>
> Someone should reference that thread _now_ before this discussion goes
> too far and we repeat a lot of information and people like myself have
> to stay up all night correcting the misinformation and
> misunderstandings that are basically guarenteed for this topic :)
I hope I'm not spreading misinformation. :) The original poster was
observing NAPI going in/out of polled mode because the CPU is fast
enough to process all work per poll. I've seen the same and I'm
suggesting that the NAPI driver keeps itself in polled mode for N polls
or M jiffies after it sees workdone=0. This has always worked for me in
packet forwarding scenarios to maximize packets/sec and minimize
latency. I'm considering putting a patch together to add this as another
tuning knob, hence I'm keen to understand what I'm missing. :)
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* Re: STK5200 pci_enable_device problem
From: Wolfgang Denk @ 2007-08-26 21:08 UTC (permalink / raw)
To: Mustafa Cayır; +Cc: linuxppc-embedded
In-Reply-To: <7B9A8FF57DBB524190E98CABF6E56F078FAE4E@itri.bte.mam.gov.tr>
In message <7B9A8FF57DBB524190E98CABF6E56F078FAE4E@itri.bte.mam.gov.tr> you wrote:
>
> I am working on TQ STK52000 development board with TQM5200-AB cpu module. I am trying to use PCI bus and Local Plus Bus together. SM501, video chip is located on local plus bus and PLX9030 based pci device is on pci bus.
>
> My pci driver is able to scan pci bus and find succesfully the pci device. After this point, pci_enable_device function returns following error:
>
> PCI: Device 00:18.0 not available because of resource collisions
Did you try the linux-2.6-denx repo on our server? Note that you'll
need a somewhat recent version of U-Boot for device tree support.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
PLEASE NOTE: Some Quantum Physics Theories Suggest That When the Con-
sumer Is Not Directly Observing This Product, It May Cease to Exist
or Will Exist Only in a Vague and Undetermined State.
^ permalink raw reply
* Re: STK5200 pci_enable_device problem
From: Wolfgang Denk @ 2007-08-26 21:10 UTC (permalink / raw)
To: Oliver Rutsch; +Cc: linuxppc-embedded
In-Reply-To: <46CD3618.70801@sympatec.com>
In message <46CD3618.70801@sympatec.com> you wrote:
>
> Which ELDK and kernel do you use? I had the same problem on this board
> with a PLX9054 based PCI card on a 2.4.25 kernel. I switched to the 2.6
> kernel and the 4.1 ELDK and the card was scanned correctly.
> But keep in mind that the linux PLX drivers do not work out of the box
> with a big endian platform like the MPC5200. Although there is a
> BIG_ENDIAN flag in the makefiles there are still some places left in the
> driver code which have to be patched (the parts with int64 adresses).
> It's not so easy to compile the PLX drivers on the 4.1 ELDK because of
> missing headers in the ppc architecture. I managed to build the drivers
> for the 2.6.19 kernel and I was able to work with the card except the
> DMA routines (still working on this issue).
WHy don't you use the arch/powerpc configuration, then? Note that the
STK5200 has never been supported in a 2.6 kernel with a arch/ppc
configuration.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"When the only tool you have is a hammer, you tend to treat
everything as if it were a nail." - Abraham Maslow
^ permalink raw reply
* Re: Sleep problems with kernels >= 2.6.21 on powerpc
From: Michal Piotrowski @ 2007-08-26 23:21 UTC (permalink / raw)
To: Rogério Brito
Cc: Rafael J. Wysocki, linux-kernel, Rogério Brito, linuxppc-dev,
debian-powerpc, Linux-pm mailing list
In-Reply-To: <6540c930708251937o2a9a23efv72a0f2b8947067bd@mail.gmail.com>
Hi
[Adding STR wizards to CC]
On 26/08/07, Rog=E9rio Brito <rbrito@gmail.com> wrote:
> Hi.
>
> Unfortunately, it seems that kernels later than 2.6.21 have problems
> letting my powerpc iBook (G3 processor) going to sleep (suspend to
> ram).
>
> The userland that I am using is a Debian testing (lenny) and the
> default kernel that comes with it is 2.6.22, with some patches applied
> and pbbuttonsd (as the daemon for making the machine sleep).
>
> With kernel 2.6.21, from Debian (and other earlier kernels), the
> symptoms that I see when I press the power button is that the machine
> goes to sleep and the led that indicates that the machine is sleeping
> is blinking normally.
>
> If I, on the other hand, use Debian's kernel 2.6.22 or compile my own
> kernel with just the necessary parts for my work (version 2.6.23-rc3
> taken from kernel.org), then I can't make the machine sleep: when I
> press the button, it acts like if I had, in sequence, pressed anything
> to wake it up (say, like pressing shift).
>
> I have already grabbed Linus's git tree and I am willing to do some
> cycles of "git bisect" to discover the point where it stopped working.
>
> I just thought that others may have seen such behaviour before or, if
> not, that being informative about what I see is of use for debugging
> this.
>
> I would also appreciate any guidance on this as I wish kernel 2.6.23
> to be working again on powerpc machines.
>
> Please, if any tests are required, don't hesitate to ask me and I will
> try to whatever is needed to restore the correct behaviour of sleep
> with the Linux kernel.
>
> I have copied mailing lists that I think that are relevant. If they
> aren't, then please let me know. I would also appreciate if I were
> kept on carbon copies as I am only subscribed to debian-powerpc at the
> moment.
>
>
> Regards, Rog=E9rio Brito.
>
> P.S.: It unfortunately doesn't matter if I switch to a console or if I
> am in X when I press the power button with recent kernels.
> -
Regards,
Michal
--=20
LOG
http://www.stardust.webpages.pl/log/
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-08-26 23:57 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
There are 4 bug fixes for Cell and a cell_defconfig update from Arnd,
and a bug fix each from Olof Johansson, Olaf Hering and myself.
Thanks,
Paul.
arch/powerpc/configs/cell_defconfig | 220 ++++++++++-------------------
arch/powerpc/mm/slb.c | 36 ++++-
arch/powerpc/platforms/cell/cbe_regs.h | 8 +
arch/powerpc/platforms/cell/cbe_thermal.c | 6 -
arch/powerpc/platforms/cell/pervasive.c | 26 +++
arch/powerpc/platforms/cell/spu_manage.c | 2
arch/powerpc/platforms/pasemi/iommu.c | 6 -
arch/powerpc/sysdev/axonram.c | 46 +-----
drivers/macintosh/adb.c | 4 -
drivers/macintosh/via-pmu.c | 34 ++--
include/linux/pmu.h | 2
11 files changed, 172 insertions(+), 218 deletions(-)
commit 175587cca7447daf5a13e4a53d32360ed8cba804
Author: Paul Mackerras <paulus@samba.org>
Date: Sat Aug 25 13:14:28 2007 +1000
[POWERPC] Fix SLB initialization at boot time
This partially reverts edd0622bd2e8f755c960827e15aa6908c3c5aa94.
It turns out that the part of that commit that aimed to ensure that we
created an SLB entry for the kernel stack on secondary CPUs when
starting the CPU didn't achieve its aim, and in fact caused a
regression, because get_paca()->kstack is not initialized at the point
where slb_initialize is called.
This therefore just reverts that part of that commit, while keeping
the change to slb_flush_and_rebolt, which is correct and necessary.
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit e120e8d03a263cf75f2abc0f8b3a03a65cfd3b88
Author: Olaf Hering <olaf@aepfle.de>
Date: Sat Aug 25 05:42:01 2007 +1000
[POWERPC] Fix undefined reference to device_power_up/resume
Current Linus tree fails to link on pmac32:
drivers/built-in.o: In function `pmac_wakeup_devices':
via-pmu.c:(.text+0x5bab4): undefined reference to `device_power_up'
via-pmu.c:(.text+0x5bb08): undefined reference to `device_resume'
drivers/built-in.o: In function `pmac_suspend_devices':
via-pmu.c:(.text+0x5c260): undefined reference to `device_power_down'
via-pmu.c:(.text+0x5c27c): undefined reference to `device_resume'
make[1]: *** [.tmp_vmlinux1] Error 1
changing CONFIG_PM > CONFIG_PM_SLEEP leads to:
drivers/built-in.o: In function `pmu_led_set':
via-pmu-led.c:(.text+0x5cdca): undefined reference to `pmu_sys_suspended'
via-pmu-led.c:(.text+0x5cdce): undefined reference to `pmu_sys_suspended'
drivers/built-in.o: In function `pmu_req_done':
via-pmu-led.c:(.text+0x5ce3e): undefined reference to `pmu_sys_suspended'
via-pmu-led.c:(.text+0x5ce42): undefined reference to `pmu_sys_suspended'
drivers/built-in.o: In function `adb_init':
(.init.text+0x4c5c): undefined reference to `pmu_register_sleep_notifier'
make[1]: *** [.tmp_vmlinux1] Error 1
So change even more places from PM to PM_SLEEP to allow linking.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit b22ddc703c5daa603d8d53881b530da3cab94cd4
Author: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Date: Thu Aug 23 03:09:17 2007 +1000
[POWERPC] cell: Update cell_defconfig for 2.6.23
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit b0e81ebb1062eba20fbcbe459662c0a6ec6075f7
Author: Maxim Shchetynin <maxim@de.ibm.com>
Date: Thu Aug 23 03:01:28 2007 +1000
[POWERPC] axonram: Do not delete gendisks queue in error path
On exit do not delete gendisk's queue because this is already done by
del_gendisk(). Doing it twice may cause memory damage.
Signed-off-by: Maximilian <maxim@de.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit fedcd2c53d838e7a69df699ce2a14e45d34d7f7f
Author: Maxim Shchetynin <maxim@de.ibm.com>
Date: Thu Aug 23 03:01:27 2007 +1000
[POWERPC] axonram: Module modification for latest firmware API changes
Firmware would not deliver two interrupt numbers in device-tree any more
but only one, for correctable ECC, because uncorrectable ECC from now
is handled by firmware itself.
Changes in the axonram module are necessary because in the old version, if
it is not allowed to fetch the second interrupt number from device-tree,
it interpretes this as an error case and exits.
Signed-off-by: Maximilian <maxim@de.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 3addf55c9415f9da039947b33d064332137e49fe
Author: Arnd Bergmann <arnd@arndb.de>
Date: Thu Aug 23 03:01:26 2007 +1000
[POWERPC] cell: Support pinhole-reset on IBM cell blades
The Cell Broadband Engine has a method of injecting a
system-reset-exception from an external source into the
operating system, which should trigger the regular behaviour
of entering xmon or kdump.
Unfortunately, the exception handler cannot distinguish it from
other interrupt causes by the SRR1 register, which gets used
for this on Power 6 and others.
IBM Blade servers that want to support triggering the
system reset exception using a pinhole button in the front
panel therefore use an extra register to determine the
reset cause.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
--
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit fa7f374bbf6d8e5fc7dd281a62498041066aaf43
Author: Christian Krafft <krafft@de.ibm.com>
Date: Thu Aug 23 03:01:25 2007 +1000
[POWERPC] spu_manage: Use newer physical-id attribute
Legacy device tree used the reg property for the physical id of an
spe. On newer device tree layouts the reg property contains the
"correct" value in the reg attribute. So there has been intoduced the
"physical-id" on newer devicetree layouts. The id is stored by
spu_manage into the spu struct as spe_id. cbe_thermal has been
changed to use the spu->spe_id. There's no need for the thermal code
to check devicetree attributes for itself.
Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Cc: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit dfa70f81a05fa857fb1428ac2a88da84ecd50dd9
Author: Olof Johansson <olof@lixom.net>
Date: Fri Aug 17 13:57:39 2007 +1000
[POWERPC] pasemi: Another IOMMU bugfix for 64K PAGE_SIZE
More fallout from the switch from PAGE_SIZE based IOMMU to the native page
size for the driver. By pure luck it happened to work most of the time, since
we end up invalidating the wrong entries in the TLB.
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH, RFC] linkstation: implement standby
From: Tony Breeds @ 2007-08-27 0:44 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, linux-pm
In-Reply-To: <Pine.LNX.4.60.0708260157330.3809@poirot.grange>
On Sun, Aug 26, 2007 at 02:03:49AM +0200, Guennadi Liakhovetski wrote:
> Implement suspend/resume for "mpc10x" compatible fsl host PCI controllers,
> use it for linkstation standby.
Hi Guennadi
<snip>
> +static int __init ls_pm_init(void)
> +{
> + if (!machine_is(linkstation))
> + return 0;
This should probably be -ENODEV.
<snip>
> +int mpc10x_suspend(suspend_state_t state)
You only seem to call this from ls_pm_enter() where you don't check the
return value, perhaps this should be void ?
> +{
> + struct pci_dev *bridge;
> + u16 pmcr1;
> +
> + bridge = pci_find_slot(0, 0);
> + if (!bridge)
> + return -ENODEV;
I think you want pci_get_bus_and_slot() here instead of pci_find_slot(),
in fact I think it'd be cleaner, if you located the bridge in
ls_pm_enter() and passed it in.
> +int mpc10x_resume(suspend_state_t state)
> +{
> + struct pci_dev *bridge;
> + u16 pmcr1;
> +
> + bridge = pci_find_slot(0, 0);
> + if (!bridge)
> + return -ENODEV;
Same comments ass mpc10x_suspend();
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Network Bad Kernel Access
From: Glenn.G.Hart @ 2007-08-27 1:00 UTC (permalink / raw)
To: linuxppc-embedded
I am having a problem with my network. I am using a V4FX12 running linux
2.6.21 with the TEMAC. I am running the PPC at 300 MHz and the TEMAC is
configured for DMA and DRE on the Xmit and the Recv. I have tried varying
the FIFO depth and enabling/disabling the checksum offloading. All produce
the error below when under heavy network traffic (specifically sending data
from the PPC). Has anybody seen this? It seems like I am overflowing some
memory, but I am not sure what/where to increase it.
Thanks,
Glenn
[ 484.696738] Oops: kernel access of bad area, sig: 11 [#1]
[ 484.761286] NIP: c00e1ef4 LR: c00cfec0 CTR: c00cfe34
[ 484.820650] REGS: c0483b10 TRAP: 0300 Not tainted (2.6.21)
[ 484.889378] MSR: 00029030 <EE,ME,IR,DR> CR: 93005999 XER: e0000000
[ 484.965410] DAR: bb857caf, DSISR: 00000000
[ 485.014365] TASK = c0648b60[129] 'rcS' THREAD: c0482000
[ 485.074765] GPR00: c04fdfb8 c0483bc0 c0648b60 bb857c2b c04fd9a0 c0483bcc
04000000 ff107ac0
[ 485.174747] GPR08: 0000000f c04fdfb8 c04d2478 00010001 00648d10 1003c2e0
00000000 00000001
[ 485.274732] GPR16: 00000003 c0483ed8 00004fd8 000005b4 000005b4 00000000
00000000 0001679c
[ 485.374716] GPR24: 7ff8b398 3002afe0 0000000f c04d2000 c04d23b8 c06bbe60
00000003 c04d2320
[ 485.476784] NIP [c00e1ef4] kfree_skb+0x8/0x3c
[ 485.528858] LR [c00cfec0] SgSendHandlerBH+0x8c/0x1cc
[ 485.588223] Call Trace:
[ 485.617389] [c0483bc0] [c00cfec0] SgSendHandlerBH+0x8c/0x1cc
(unreliable)
[ 485.698628] [c0483bf0] [c0019218] tasklet_action+0x90/0xd4
[ 485.764241] [c0483c00] [c0018ebc] __do_softirq+0x64/0xd0
[ 485.827772] [c0483c20] [c00064a8] do_softirq+0x40/0x58
[ 485.889221] [c0483c30] [c0018f74] irq_exit+0x38/0x48
[ 485.948586] [c0483c40] [c0006450] do_IRQ+0x88/0xa0
[ 486.005868] [c0483c50] [c00032d8] ret_from_except+0x0/0x18
[ 486.071483] [c0483d10] [c0483d00] 0xc0483d00
[ 486.122516] [c0483d20] [c00e17d4] __alloc_skb+0x48/0x11c
[ 486.186048] [c0483d40] [c0109218] tcp_sendmsg+0x1ac/0xc40
[ 486.250621] [c0483db0] [c0126b58] inet_sendmsg+0x60/0x74
[ 486.314152] [c0483dd0] [c00dcf34] sock_aio_write+0xe0/0xfc
[ 486.379765] [c0483e30] [c0050910] do_sync_write+0xb8/0x10c
[ 486.445381] [c0483ef0] [c0050a40] vfs_write+0xdc/0x10c
[ 486.506829] [c0483f10] [c0050b48] sys_write+0x4c/0x8c
[ 486.567236] [c0483f40] [c0002c90] ret_from_syscall+0x0/0x3c
[ 486.633888] Instruction dump:
[ 486.669300] 0f000000 7fe3fb78 7d6803a6 4e800021 80010014 7fe3fb78
7c0803a6 bbc10008
[ 486.761992] 38210010 4bfffe78 2c030000 4d820020 <80030084> 39230084
2f800001 409e0008
[ 486.858162] Kernel panic - not syncing: Aiee, killing interrupt handler!
[ 486.938382] Rebooting in 180 seconds..
^ permalink raw reply
* Re: [PATCH 1/3] [POWERPC] Merge 32 and 64 bit pci_process_bridge_OF_ranges() instances
From: David Gibson @ 2007-08-27 1:15 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20070825092947.4087.68187.stgit@localhost.localdomain>
On Sat, Aug 25, 2007 at 01:29:47PM +0400, Vitaly Bordug wrote:
>
> We are having 2 different instances of pci_process_bridge_OF_ranges(),
> which makes describing 64-bit physical addresses in non PPC64 case
> impossible.
>
> This approach inherits pci space parsing, but has a new way to behave
> equally good in both 32bit and 64bit environments. Currently validated
> with 440EPx (sequoia) and mpc8349-eitx.
>
> Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> Signed-off-by: Stefan Roese <sr@denx.de>
I like the idea, but I don't think this implementation is adequate
yet.
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
> index 083cfbd..57cd039 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -478,3 +478,162 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
> *start = rsrc->start - offset;
> *end = rsrc->end - offset;
> }
> +
> +void __devinit pci_process_bridge_OF_ranges(struct pci_controller *hose,
> + struct device_node *dev, int prim)
> +{
> + static unsigned int static_lc_ranges[256];
> + const unsigned int *ranges;
> + unsigned int *lc_ranges;
> + unsigned int pci_space;
> + unsigned long size = 0;
size can be 64-bit on 32-bit systems, at least in theory.
> + int rlen = 0;
> + int orig_rlen, ranges_amnt, i;
> + int memno = 0;
> + struct resource *res;
> + int np, na = of_n_addr_cells(dev);
> + struct ranges_pci64_sz64 *ranges64 = NULL;
> + struct ranges_pci32_sz64 *ranges32 = NULL;
> + phys_addr_t pci_addr,
This is wrong: the PCI binding defines the PCI addresses to be 64-bit,
even if the CPU has 32-bit physical addresses.
cpu_phys_addr;
> +
> + np = na + 5;
> +
> + /* From "PCI Binding to 1275"
z> + * The ranges property is laid out as an array of elements,
> + * each of which comprises:
> + * cells 0 - 2: a PCI address
> + * cells 3 or 3+4: a CPU physical address
> + * (size depending on dev->n_addr_cells)
> + * cells 4+5 or 5+6: the size of the range
> + */
> + ranges = of_get_property(dev, "ranges", &rlen);
> + if (ranges == NULL)
> + return;
if (!ranges) would be the usual idiom here.
> + /* Sanity check, though hopefully that never happens */
> + if (rlen > sizeof(static_lc_ranges)) {
> + printk(KERN_WARNING "OF ranges property too large !\n");
> + rlen = sizeof(static_lc_ranges);
> + }
> +
> + /* Let's work on a copy of the "ranges" property instead
> + * of damaging the device-tree image in memory
> + */
> + lc_ranges = static_lc_ranges;
> + memcpy(lc_ranges, ranges, rlen);
> + orig_rlen = rlen;
> +
> + ranges = lc_ranges;
You don't ever actually touch the ranges property in place, so there's
no need for this copy stuff.
> + /* Map ranges to struct according to spec. */
> + if (na >= 2) {
> + ranges64 = (void *)ranges;
> + ranges_amnt = rlen / sizeof(*ranges64);
> + } else {
> + ranges32 = (void *)ranges;
> + ranges_amnt = rlen / sizeof(*ranges32);
> + }
> +
> + hose->io_base_phys = 0;
> + for (i = 0; i < ranges_amnt; i++) {
> + res = NULL;
> + if (ranges64) {
> + if (ranges64[i].pci_space == 0)
> + continue;
> +
> + pci_space = ranges64[i].pci_space;
> + pci_addr =
> + (u64) ranges64[i].pci_addr[0] << 32 | ranges64[i].
> + pci_addr[1];
Why not just define the pci_addr field in your structures as u64? You
would have to define the structure with attribute((packed)), I guess.
> + cpu_phys_addr =
> + of_translate_address(dev, ranges64[i].phys_addr);
> + /*
> + * I haven't observed 2 significant size cells in kernel
> + * code, so we're accounting only LSB of size part
> + * from ranges. -vitb
> + */
> + size = ranges64[i].size[1];
> +#ifdef CONFIG_PPC64
> + if (ranges64[i].size[0])
> + size |= ranges64[i].size[0]<<32;
> +#endif
> + DBG("Observed: pci %llx phys %llx size %x\n", pci_addr,
> + cpu_phys_addr, size);
> + } else {
> + if (ranges32[i].pci_space == 0)
> + continue;
> +
> + pci_space = (unsigned int)ranges32[i].pci_space;
> + pci_addr = (unsigned int)ranges32[i].pci_addr[1];
> + cpu_phys_addr = (unsigned int)ranges32[i].phys_addr[0];
We should really be using of_translate_address() in all cases - that's
what it's for, after all.
> + size = ranges32[i].size[1];
> +
> + DBG("Observed: pci %x phys %x size %x\n",
> + (u32) pci_addr, (u32) cpu_phys_addr, size);
> + }
You don't have any equivalent of the code that exists in both
pre-existing versions to coalesce contiguous ranges. You probably
want to use the 64-bit version, since that doesn't need a local copy
of the ranges.
> +
> + switch ((pci_space >> 24) & 0x3) {
> + case 1: /* I/O space */
> +#ifdef CONFIG_PPC32
> + /*
> + * check from ppc32 pci implementation.
> + * not sure if it is needed. -vitb
> + */
> + if (pci_addr != 0)
> + break;
> +#endif
> + /* limit I/O space to 16MB */
> + if (size > 0x01000000)
> + size = 0x01000000;
> +
> + hose->io_base_phys = cpu_phys_addr - pci_addr;
> + /* handle from 0 to top of I/O window */
> +#ifdef CONFIG_PPC64
> + hose->pci_io_size = pci_addr + size;
> +#endif
> + hose->io_base_virt = ioremap(hose->io_base_phys, size);
> +
> + if (prim)
> + isa_io_base = (unsigned long)hose->io_base_virt;
The old 64-bit versions don't presently ioremap() or set isa_io_base.
I'd be worried about changing this semantic, at least without a rather
more widespread consolidation of the 32/64 bit PCI code.
> +
> + res = &hose->io_resource;
> + res->flags = IORESOURCE_IO;
> + res->start = pci_addr;
> + DBG("phb%d: IO 0x%llx -> 0x%llx\n", hose->global_number,
> + (u64) res->start, (u64) (res->start + size - 1));
> + DBG("IO phys %llx IO virt %p\n",
> + (u64) hose->io_base_phys, hose->io_base_virt);
> + break;
> + case 2: /* memory space */
> + memno = 0;
> +#ifdef CONFIG_PPC32
> + if ((pci_addr == 0) && (size <= (16 << 20))) {
> + /* 1st 16MB, i.e. ISA memory area */
> + if (prim)
> + isa_mem_base = cpu_phys_addr;
> + memno = 1;
> + }
> +#endif
> + while (memno < 3 && hose->mem_resources[memno].flags)
> + ++memno;
> +
> + if (memno == 0)
> + hose->pci_mem_offset = cpu_phys_addr - pci_addr;
> + if (memno < 3) {
> + res = &hose->mem_resources[memno];
> + res->flags = IORESOURCE_MEM;
> + res->start = cpu_phys_addr;
> + DBG("phb%d: MEM 0x%llx -> 0x%llx\n",
> + hose->global_number, res->start,
> + res->start + size - 1);
> + }
> + break;
> + }
> + if (res != NULL) {
> + res->name = dev->full_name;
> + res->end = res->start + size - 1;
> + res->parent = NULL;
> + res->sibling = NULL;
> + res->child = NULL;
> + }
> + }
> +}
> +
> diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
> index 0e2bee4..dc519e1 100644
> --- a/arch/powerpc/kernel/pci_32.c
> +++ b/arch/powerpc/kernel/pci_32.c
> @@ -843,120 +843,6 @@ pci_device_from_OF_node(struct device_node* node, u8* bus, u8* devfn)
> }
> EXPORT_SYMBOL(pci_device_from_OF_node);
>
> -void __init
> -pci_process_bridge_OF_ranges(struct pci_controller *hose,
> - struct device_node *dev, int primary)
> -{
> - static unsigned int static_lc_ranges[256] __initdata;
> - const unsigned int *dt_ranges;
> - unsigned int *lc_ranges, *ranges, *prev, size;
> - int rlen = 0, orig_rlen;
> - int memno = 0;
> - struct resource *res;
> - int np, na = of_n_addr_cells(dev);
> - np = na + 5;
> -
> - /* First we try to merge ranges to fix a problem with some pmacs
> - * that can have more than 3 ranges, fortunately using contiguous
> - * addresses -- BenH
> - */
> - dt_ranges = of_get_property(dev, "ranges", &rlen);
> - if (!dt_ranges)
> - return;
> - /* Sanity check, though hopefully that never happens */
> - if (rlen > sizeof(static_lc_ranges)) {
> - printk(KERN_WARNING "OF ranges property too large !\n");
> - rlen = sizeof(static_lc_ranges);
> - }
> - lc_ranges = static_lc_ranges;
> - memcpy(lc_ranges, dt_ranges, rlen);
> - orig_rlen = rlen;
> -
> - /* Let's work on a copy of the "ranges" property instead of damaging
> - * the device-tree image in memory
> - */
> - ranges = lc_ranges;
> - prev = NULL;
> - while ((rlen -= np * sizeof(unsigned int)) >= 0) {
> - if (prev) {
> - if (prev[0] == ranges[0] && prev[1] == ranges[1] &&
> - (prev[2] + prev[na+4]) == ranges[2] &&
> - (prev[na+2] + prev[na+4]) == ranges[na+2]) {
> - prev[na+4] += ranges[na+4];
> - ranges[0] = 0;
> - ranges += np;
> - continue;
> - }
> - }
> - prev = ranges;
> - ranges += np;
> - }
> -
> - /*
> - * The ranges property is laid out as an array of elements,
> - * each of which comprises:
> - * cells 0 - 2: a PCI address
> - * cells 3 or 3+4: a CPU physical address
> - * (size depending on dev->n_addr_cells)
> - * cells 4+5 or 5+6: the size of the range
> - */
> - ranges = lc_ranges;
> - rlen = orig_rlen;
> - while (ranges && (rlen -= np * sizeof(unsigned int)) >= 0) {
> - res = NULL;
> - size = ranges[na+4];
> - switch ((ranges[0] >> 24) & 0x3) {
> - case 1: /* I/O space */
> - if (ranges[2] != 0)
> - break;
> - hose->io_base_phys = ranges[na+2];
> - /* limit I/O space to 16MB */
> - if (size > 0x01000000)
> - size = 0x01000000;
> - hose->io_base_virt = ioremap(ranges[na+2], size);
> - if (primary)
> - isa_io_base = (unsigned long) hose->io_base_virt;
> - res = &hose->io_resource;
> - res->flags = IORESOURCE_IO;
> - res->start = ranges[2];
> - DBG("PCI: IO 0x%llx -> 0x%llx\n",
> - (u64)res->start, (u64)res->start + size - 1);
> - break;
> - case 2: /* memory space */
> - memno = 0;
> - if (ranges[1] == 0 && ranges[2] == 0
> - && ranges[na+4] <= (16 << 20)) {
> - /* 1st 16MB, i.e. ISA memory area */
> - if (primary)
> - isa_mem_base = ranges[na+2];
> - memno = 1;
> - }
> - while (memno < 3 && hose->mem_resources[memno].flags)
> - ++memno;
> - if (memno == 0)
> - hose->pci_mem_offset = ranges[na+2] - ranges[2];
> - if (memno < 3) {
> - res = &hose->mem_resources[memno];
> - res->flags = IORESOURCE_MEM;
> - if(ranges[0] & 0x40000000)
> - res->flags |= IORESOURCE_PREFETCH;
> - res->start = ranges[na+2];
> - DBG("PCI: MEM[%d] 0x%llx -> 0x%llx\n", memno,
> - (u64)res->start, (u64)res->start + size - 1);
> - }
> - break;
> - }
> - if (res != NULL) {
> - res->name = dev->full_name;
> - res->end = res->start + size - 1;
> - res->parent = NULL;
> - res->sibling = NULL;
> - res->child = NULL;
> - }
> - ranges += np;
> - }
> -}
> -
> /* We create the "pci-OF-bus-map" property now so it appears in the
> * /proc device tree
> */
> diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
> index 291ffbc..68bce38 100644
> --- a/arch/powerpc/kernel/pci_64.c
> +++ b/arch/powerpc/kernel/pci_64.c
> @@ -592,100 +592,6 @@ int pci_proc_domain(struct pci_bus *bus)
> }
> }
>
> -void __devinit pci_process_bridge_OF_ranges(struct pci_controller *hose,
> - struct device_node *dev, int prim)
> -{
> - const unsigned int *ranges;
> - unsigned int pci_space;
> - unsigned long size;
> - int rlen = 0;
> - int memno = 0;
> - struct resource *res;
> - int np, na = of_n_addr_cells(dev);
> - unsigned long pci_addr, cpu_phys_addr;
> -
> - np = na + 5;
> -
> - /* From "PCI Binding to 1275"
> - * The ranges property is laid out as an array of elements,
> - * each of which comprises:
> - * cells 0 - 2: a PCI address
> - * cells 3 or 3+4: a CPU physical address
> - * (size depending on dev->n_addr_cells)
> - * cells 4+5 or 5+6: the size of the range
> - */
> - ranges = of_get_property(dev, "ranges", &rlen);
> - if (ranges == NULL)
> - return;
> - hose->io_base_phys = 0;
> - while ((rlen -= np * sizeof(unsigned int)) >= 0) {
> - res = NULL;
> - pci_space = ranges[0];
> - pci_addr = ((unsigned long)ranges[1] << 32) | ranges[2];
> - cpu_phys_addr = of_translate_address(dev, &ranges[3]);
> - size = ((unsigned long)ranges[na+3] << 32) | ranges[na+4];
> - ranges += np;
> - if (size == 0)
> - continue;
> -
> - /* Now consume following elements while they are contiguous */
> - while (rlen >= np * sizeof(unsigned int)) {
> - unsigned long addr, phys;
> -
> - if (ranges[0] != pci_space)
> - break;
> - addr = ((unsigned long)ranges[1] << 32) | ranges[2];
> - phys = ranges[3];
> - if (na >= 2)
> - phys = (phys << 32) | ranges[4];
> - if (addr != pci_addr + size ||
> - phys != cpu_phys_addr + size)
> - break;
> -
> - size += ((unsigned long)ranges[na+3] << 32)
> - | ranges[na+4];
> - ranges += np;
> - rlen -= np * sizeof(unsigned int);
> - }
> -
> - switch ((pci_space >> 24) & 0x3) {
> - case 1: /* I/O space */
> - hose->io_base_phys = cpu_phys_addr - pci_addr;
> - /* handle from 0 to top of I/O window */
> - hose->pci_io_size = pci_addr + size;
> -
> - res = &hose->io_resource;
> - res->flags = IORESOURCE_IO;
> - res->start = pci_addr;
> - DBG("phb%d: IO 0x%lx -> 0x%lx\n", hose->global_number,
> - res->start, res->start + size - 1);
> - break;
> - case 2: /* memory space */
> - memno = 0;
> - while (memno < 3 && hose->mem_resources[memno].flags)
> - ++memno;
> -
> - if (memno == 0)
> - hose->pci_mem_offset = cpu_phys_addr - pci_addr;
> - if (memno < 3) {
> - res = &hose->mem_resources[memno];
> - res->flags = IORESOURCE_MEM;
> - res->start = cpu_phys_addr;
> - DBG("phb%d: MEM 0x%lx -> 0x%lx\n", hose->global_number,
> - res->start, res->start + size - 1);
> - }
> - break;
> - }
> - if (res != NULL) {
> - res->name = dev->full_name;
> - res->end = res->start + size - 1;
> - res->parent = NULL;
> - res->sibling = NULL;
> - res->child = NULL;
> - }
> - }
> -}
> -
> #ifdef CONFIG_HOTPLUG
>
> int pcibios_unmap_io_space(struct pci_bus *bus)
> diff --git a/include/asm-powerpc/ppc-pci.h b/include/asm-powerpc/ppc-pci.h
> index b847aa1..cd8ad87 100644
> --- a/include/asm-powerpc/ppc-pci.h
> +++ b/include/asm-powerpc/ppc-pci.h
> @@ -15,6 +15,22 @@
> #include <linux/pci.h>
> #include <asm/pci-bridge.h>
>
> +/* Address-cells and size-cells 2 */
> +struct ranges_pci64_sz64 {
> + unsigned int pci_space;
> + unsigned int pci_addr[2];
> + unsigned int phys_addr[2];
> + unsigned int size[2];
> +};
> +
> +/* Address-cells 1 */
> +struct ranges_pci32_sz64 {
> + unsigned int pci_space;
> + unsigned int pci_addr[2];
> + unsigned int phys_addr[1];
> + unsigned int size[2];
> +};
> +
> extern unsigned long isa_io_base;
>
> extern void pci_setup_phb_io(struct pci_controller *hose, int primary);
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
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 2/3] [POWERPC] Add pci node to sequoia dts
From: David Gibson @ 2007-08-27 1:54 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20070825092954.4087.95333.stgit@localhost.localdomain>
On Sat, Aug 25, 2007 at 01:29:54PM +0400, Vitaly Bordug wrote:
>
> Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> Signed-off-by: Stefan Roese <sr@denx.de>
>
> ---
>
> arch/powerpc/boot/dts/sequoia.dts | 26 ++++++++++++++++++++++++++
> 1 files changed, 26 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/sequoia.dts b/arch/powerpc/boot/dts/sequoia.dts
> index ef6f41c..8eb258f 100644
> --- a/arch/powerpc/boot/dts/sequoia.dts
> +++ b/arch/powerpc/boot/dts/sequoia.dts
> @@ -92,6 +92,32 @@
> #size-cells = <1>;
> ranges;
> clock-frequency = <0>; /* Filled in by zImage */
> +
> + pci {
> + /* irqs are routed to irq67, dependless of devsel/PIRQx */
> + interrupt-map-mask = <0 0 0 0>;
> + interrupt-map = <0 0 0 0 &UIC2 3 8>;
> +
> + interrupt-parent = <&UIC2>;
> + interrupts = <3 8>;
> +
> + bus-range = <0 0>;
> +
> + /*
> + * mem is at 80000000 set up indirectly
> + * io is at 0001_e800_0000
> + */
> + ranges = <02000000 0 80000000 1 80000000 0 10000000
> + 01000000 0 00000000 1 e8000000 0 00100000>;
> +
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> +
> + reg = <1 eec00000 40 1 ef400000 40>; /* phb cfg, phb reg */
> + compatible = "ibm, 440epx";
> + device_type = "pci";
I usually put device_type, compatible and reg at the top of the block,
to announce what the node actually is before giving all the details.
Also, apart from the stray space in the compatible, I'm guessing that
the 440EPx bridge is actually more-or-less like the PCI bridges on
other 4xx chips, so we should have a more general compatible string
too.
Is the 440EPx a vanilla PCI or a PCI-X bridge? If the later that
should be reflected in the name and compatible as well.
> + };
>
> SDRAM0: sdram {
> device_type = "memory-controller";
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
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 2/3] [POWERPC] Add pci node to sequoia dts
From: David Gibson @ 2007-08-27 1:55 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20070826142750.0a6a228e@localhost.localdomain>
On Sun, Aug 26, 2007 at 02:27:50PM +0400, Vitaly Bordug wrote:
> On Sat, 25 Aug 2007 11:49:58 +0200 Segher Boessenkool wrote:
[snip]
> > > + compatible = "ibm, 440epx";
> >
> > Stray space. And you need to say it is the PCI host, so something
> > like "ibm,440epx-pci".
> >
> OK, will have "amcc,.440epx-pci" here
Uh... now instead of a stray space you have a stray '.'
--
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 3/3] [POWERPC] Add PCI support for AMCC 440EPx (sequoia)
From: David Gibson @ 2007-08-27 1:57 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20070825093001.4087.18160.stgit@localhost.localdomain>
On Sat, Aug 25, 2007 at 01:30:01PM +0400, Vitaly Bordug wrote:
>
> In fact, loosely move of arch/ppc bits, though regions are
> set up using values from ranges property. This also adds
> setup_indirect_pci_noremap() function to handle indirect
> PCI without one more ioremap.
>
> Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> Signed-off-by: Stefan Roese <sr@denx.de>
>
> ---
>
> arch/powerpc/platforms/44x/44x.h | 28 ++++
> arch/powerpc/platforms/44x/Makefile | 4 +
> arch/powerpc/platforms/44x/ppc440epx-pci.c | 192 ++++++++++++++++++++++++++++
> arch/powerpc/platforms/44x/sequoia.c | 14 ++
> arch/powerpc/sysdev/indirect_pci.c | 14 ++
> include/asm-powerpc/pci-bridge.h | 2
> 6 files changed, 254 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/44x/44x.h b/arch/powerpc/platforms/44x/44x.h
> index 42eabf8..d3845f9 100644
> --- a/arch/powerpc/platforms/44x/44x.h
> +++ b/arch/powerpc/platforms/44x/44x.h
> @@ -1,8 +1,36 @@
> #ifndef __POWERPC_PLATFORMS_44X_44X_H
> #define __POWERPC_PLATFORMS_44X_44X_H
> +#include <asm/pci-bridge.h>
> +
> +/* PCI support */
> +#define PPC4xx_PCI_CFGA_OFFSET 0
> +#define PPC4xx_PCI_CFGD_OFFSET 0x4
> +
> +#define PPC4xx_PCIL0_PMM0LA 0x000
> +#define PPC4xx_PCIL0_PMM0MA 0x004
> +#define PPC4xx_PCIL0_PMM0PCILA 0x008
> +#define PPC4xx_PCIL0_PMM0PCIHA 0x00C
> +#define PPC4xx_PCIL0_PMM1LA 0x010
> +#define PPC4xx_PCIL0_PMM1MA 0x014
> +#define PPC4xx_PCIL0_PMM1PCILA 0x018
> +#define PPC4xx_PCIL0_PMM1PCIHA 0x01C
> +#define PPC4xx_PCIL0_PMM2LA 0x020
> +#define PPC4xx_PCIL0_PMM2MA 0x024
> +#define PPC4xx_PCIL0_PMM2PCILA 0x028
> +#define PPC4xx_PCIL0_PMM2PCIHA 0x02C
> +#define PPC4xx_PCIL0_PTM1MS 0x030
> +#define PPC4xx_PCIL0_PTM1LA 0x034
> +#define PPC4xx_PCIL0_PTM2MS 0x038
> +#define PPC4xx_PCIL0_PTM2LA 0x03C
>
> extern u8 as1_readb(volatile u8 __iomem *addr);
> extern void as1_writeb(u8 data, volatile u8 __iomem *addr);
> extern void ppc44x_reset_system(char *cmd);
>
> +#ifdef CONFIG_PCI
> +int ppc440epx_exclude_device(struct pci_controller *hose,
> + u_char bus, u_char devfn);
> +int ppc440epx_add_bridge(struct device_node *dev);
> +#endif
> +
> #endif /* __POWERPC_PLATFORMS_44X_44X_H */
> diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
> index 10ce674..d2a5278 100644
> --- a/arch/powerpc/platforms/44x/Makefile
> +++ b/arch/powerpc/platforms/44x/Makefile
> @@ -2,3 +2,7 @@ obj-$(CONFIG_44x) := misc_44x.o
> obj-$(CONFIG_EBONY) += ebony.o
> obj-$(CONFIG_BAMBOO) += bamboo.o
> obj-$(CONFIG_SEQUOIA) += sequoia.o
> +
> +ifeq ($(CONFIG_PCI),y)
> +obj-$(CONFIG_440EPX) += ppc440epx-pci.o
> +endif
> diff --git a/arch/powerpc/platforms/44x/ppc440epx-pci.c b/arch/powerpc/platforms/44x/ppc440epx-pci.c
> new file mode 100644
> index 0000000..bd4a352
> --- /dev/null
> +++ b/arch/powerpc/platforms/44x/ppc440epx-pci.c
> @@ -0,0 +1,192 @@
> +/*
> + * PPC44x PCI host support
> + *
> + * Vitaly Bordug <vitb@kernel.crashing.org>
> + * Stefan Roese <sr@denx.de>
> + *
> + * Based on arch/ppc sequoia pci bits, that are
> + * Copyright 2006-2007 DENX Software Engineering, Stefan Roese <sr@denx.de>
> + *
> + * Based on bamboo.c from Wade Farnsworth <wfarnsworth@mvista.com>
> + * Copyright 2004 MontaVista Software Inc.
> + * Copyright 2006 AMCC
> + * 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.
> + */
Unless there really is something peculiar about the EPx bridge
compared to say the GP, EP and other 4xx bridges, this should have a
more general name.
--
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: RFC: issues concerning the next NAPI interface
From: David Miller @ 2007-08-27 1:58 UTC (permalink / raw)
To: jchapman
Cc: tklein, themann, stefan.roscher, netdev, linux-kernel, raisch,
linuxppc-dev, akepner, meder, ossthema, shemminger
In-Reply-To: <46D1D634.7060007@katalix.com>
From: James Chapman <jchapman@katalix.com>
Date: Sun, 26 Aug 2007 20:36:20 +0100
> David Miller wrote:
> > From: James Chapman <jchapman@katalix.com>
> > Date: Fri, 24 Aug 2007 18:16:45 +0100
> >
> >> Does hardware interrupt mitigation really interact well with NAPI?
> >
> > It interacts quite excellently.
>
> If NAPI disables interrupts and keeps them disabled while there are more
> packets arriving or more transmits being completed, why do hardware
> interrupt mitigation / coalescing features of the network silicon help?
Because if your packet rate is low enough such that the cpu can
process the interrupt fast enough and thus only one packet gets
processed per NAPI poll, the cost of going into and out of NAPI mode
dominates the packet processing costs.
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Add pci node to sequoia dts
From: Stefan Roese @ 2007-08-27 5:56 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <15d18697dc6fe8e930deb1880daad3b6@kernel.crashing.org>
On Saturday 25 August 2007, Segher Boessenkool wrote:
> > + compatible = "ibm, 440epx";
>
> Oh, and shouldn't it be "amcc," anyway?
Not sure here. It's still the PCI core used on the early 405 and 440 platforms
build by IBM. If we use IBM on other core logic like UIC, EMAC etc, then we
should use IBM here too.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Add pci node to sequoia dts
From: Stefan Roese @ 2007-08-27 6:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: David Gibson
In-Reply-To: <20070827015417.GB12804@localhost.localdomain>
On Monday 27 August 2007, David Gibson wrote:
> On Sat, Aug 25, 2007 at 01:29:54PM +0400, Vitaly Bordug wrote:
> > Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> > Signed-off-by: Stefan Roese <sr@denx.de>
> >
> > ---
> >
> > arch/powerpc/boot/dts/sequoia.dts | 26 ++++++++++++++++++++++++++
> > 1 files changed, 26 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/sequoia.dts
> > b/arch/powerpc/boot/dts/sequoia.dts index ef6f41c..8eb258f 100644
> > --- a/arch/powerpc/boot/dts/sequoia.dts
> > +++ b/arch/powerpc/boot/dts/sequoia.dts
> > @@ -92,6 +92,32 @@
> > #size-cells = <1>;
> > ranges;
> > clock-frequency = <0>; /* Filled in by zImage */
> > +
> > + pci {
> > + /* irqs are routed to irq67, dependless of devsel/PIRQx */
> > + interrupt-map-mask = <0 0 0 0>;
> > + interrupt-map = <0 0 0 0 &UIC2 3 8>;
> > +
> > + interrupt-parent = <&UIC2>;
> > + interrupts = <3 8>;
> > +
> > + bus-range = <0 0>;
> > +
> > + /*
> > + * mem is at 80000000 set up indirectly
> > + * io is at 0001_e800_0000
> > + */
> > + ranges = <02000000 0 80000000 1 80000000 0 10000000
> > + 01000000 0 00000000 1 e8000000 0 00100000>;
> > +
> > + #interrupt-cells = <1>;
> > + #size-cells = <2>;
> > + #address-cells = <3>;
> > +
> > + reg = <1 eec00000 40 1 ef400000 40>; /* phb cfg, phb reg */
> > + compatible = "ibm, 440epx";
> > + device_type = "pci";
>
> I usually put device_type, compatible and reg at the top of the block,
> to announce what the node actually is before giving all the details.
>
> Also, apart from the stray space in the compatible, I'm guessing that
> the 440EPx bridge is actually more-or-less like the PCI bridges on
> other 4xx chips, so we should have a more general compatible string
> too.
Yes, it is "more-or-less" like any other 4xx PCI core. So it really would make
sense to define it more generally. Something like:
compatible = "ibm,pci-440epx", "ibm,pci4xx";
or even:
compatible = "ibm,pci-440epx", "ibm,pci";
?
> Is the 440EPx a vanilla PCI or a PCI-X bridge? If the later that
> should be reflected in the name and compatible as well.
It's a vanilla PCI bridge.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] Add PCI support for AMCC 440EPx (sequoia)
From: Stefan Roese @ 2007-08-27 6:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: David Gibson
In-Reply-To: <20070827015719.GD12804@localhost.localdomain>
On Monday 27 August 2007, David Gibson wrote:
> On Sat, Aug 25, 2007 at 01:30:01PM +0400, Vitaly Bordug wrote:
> > In fact, loosely move of arch/ppc bits, though regions are
> > set up using values from ranges property. This also adds
> > setup_indirect_pci_noremap() function to handle indirect
> > PCI without one more ioremap.
> >
> > Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> > Signed-off-by: Stefan Roese <sr@denx.de>
> >
> > ---
> >
> > arch/powerpc/platforms/44x/44x.h | 28 ++++
> > arch/powerpc/platforms/44x/Makefile | 4 +
> > arch/powerpc/platforms/44x/ppc440epx-pci.c | 192
> > ++++++++++++++++++++++++++++ arch/powerpc/platforms/44x/sequoia.c |
> > 14 ++
> > arch/powerpc/sysdev/indirect_pci.c | 14 ++
> > include/asm-powerpc/pci-bridge.h | 2
> > 6 files changed, 254 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/platforms/44x/44x.h
> > b/arch/powerpc/platforms/44x/44x.h index 42eabf8..d3845f9 100644
> > --- a/arch/powerpc/platforms/44x/44x.h
> > +++ b/arch/powerpc/platforms/44x/44x.h
> > @@ -1,8 +1,36 @@
> > #ifndef __POWERPC_PLATFORMS_44X_44X_H
> > #define __POWERPC_PLATFORMS_44X_44X_H
> > +#include <asm/pci-bridge.h>
> > +
> > +/* PCI support */
> > +#define PPC4xx_PCI_CFGA_OFFSET 0
> > +#define PPC4xx_PCI_CFGD_OFFSET 0x4
> > +
> > +#define PPC4xx_PCIL0_PMM0LA 0x000
> > +#define PPC4xx_PCIL0_PMM0MA 0x004
> > +#define PPC4xx_PCIL0_PMM0PCILA 0x008
> > +#define PPC4xx_PCIL0_PMM0PCIHA 0x00C
> > +#define PPC4xx_PCIL0_PMM1LA 0x010
> > +#define PPC4xx_PCIL0_PMM1MA 0x014
> > +#define PPC4xx_PCIL0_PMM1PCILA 0x018
> > +#define PPC4xx_PCIL0_PMM1PCIHA 0x01C
> > +#define PPC4xx_PCIL0_PMM2LA 0x020
> > +#define PPC4xx_PCIL0_PMM2MA 0x024
> > +#define PPC4xx_PCIL0_PMM2PCILA 0x028
> > +#define PPC4xx_PCIL0_PMM2PCIHA 0x02C
> > +#define PPC4xx_PCIL0_PTM1MS 0x030
> > +#define PPC4xx_PCIL0_PTM1LA 0x034
> > +#define PPC4xx_PCIL0_PTM2MS 0x038
> > +#define PPC4xx_PCIL0_PTM2LA 0x03C
> >
> > extern u8 as1_readb(volatile u8 __iomem *addr);
> > extern void as1_writeb(u8 data, volatile u8 __iomem *addr);
> > extern void ppc44x_reset_system(char *cmd);
> >
> > +#ifdef CONFIG_PCI
> > +int ppc440epx_exclude_device(struct pci_controller *hose,
> > + u_char bus, u_char devfn);
> > +int ppc440epx_add_bridge(struct device_node *dev);
> > +#endif
> > +
> > #endif /* __POWERPC_PLATFORMS_44X_44X_H */
> > diff --git a/arch/powerpc/platforms/44x/Makefile
> > b/arch/powerpc/platforms/44x/Makefile index 10ce674..d2a5278 100644
> > --- a/arch/powerpc/platforms/44x/Makefile
> > +++ b/arch/powerpc/platforms/44x/Makefile
> > @@ -2,3 +2,7 @@ obj-$(CONFIG_44x) := misc_44x.o
> > obj-$(CONFIG_EBONY) += ebony.o
> > obj-$(CONFIG_BAMBOO) += bamboo.o
> > obj-$(CONFIG_SEQUOIA) += sequoia.o
> > +
> > +ifeq ($(CONFIG_PCI),y)
> > +obj-$(CONFIG_440EPX) += ppc440epx-pci.o
> > +endif
> > diff --git a/arch/powerpc/platforms/44x/ppc440epx-pci.c
> > b/arch/powerpc/platforms/44x/ppc440epx-pci.c new file mode 100644
> > index 0000000..bd4a352
> > --- /dev/null
> > +++ b/arch/powerpc/platforms/44x/ppc440epx-pci.c
> > @@ -0,0 +1,192 @@
> > +/*
> > + * PPC44x PCI host support
> > + *
> > + * Vitaly Bordug <vitb@kernel.crashing.org>
> > + * Stefan Roese <sr@denx.de>
> > + *
> > + * Based on arch/ppc sequoia pci bits, that are
> > + * Copyright 2006-2007 DENX Software Engineering, Stefan Roese
> > <sr@denx.de> + *
> > + * Based on bamboo.c from Wade Farnsworth <wfarnsworth@mvista.com>
> > + * Copyright 2004 MontaVista Software Inc.
> > + * Copyright 2006 AMCC
> > + * 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.
> > + */
>
> Unless there really is something peculiar about the EPx bridge
> compared to say the GP, EP and other 4xx bridges, this should have a
> more general name.
We originally started naming this file sequoia-pci.c and changed it to be
440EPx specific (just by renaming). But you are right of course. We should
make it even more generic for 4xx PCI support. Perhaps we will overlook some
problems with other 4xx platforms, but those should be solved when other
platforms (Josh: 440ep and 405gp? ;)) will be added.
So what should it be called? arch/powerpc/syslib/ppc4xx_pci.c ?
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Add pci node to sequoia dts
From: David Gibson @ 2007-08-27 6:21 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200708270807.17351.sr@denx.de>
On Mon, Aug 27, 2007 at 08:07:17AM +0200, Stefan Roese wrote:
[snip]
> > I usually put device_type, compatible and reg at the top of the block,
> > to announce what the node actually is before giving all the details.
> >
> > Also, apart from the stray space in the compatible, I'm guessing that
> > the 440EPx bridge is actually more-or-less like the PCI bridges on
> > other 4xx chips, so we should have a more general compatible string
> > too.
>
> Yes, it is "more-or-less" like any other 4xx PCI core. So it really would make
> sense to define it more generally. Something like:
>
> compatible = "ibm,pci-440epx", "ibm,pci4xx";
>
> or even:
>
> compatible = "ibm,pci-440epx", "ibm,pci";
>
> ?
Hrm.. "xx" is ugly, and "ibm,pci" isn't specific enough. I think
we're better off just using the oldest similar chip. Since this is
vanilla PCI, I think that makes it "ibm,pci-405gp"
> > Is the 440EPx a vanilla PCI or a PCI-X bridge? If the later that
> > should be reflected in the name and compatible as well.
>
> It's a vanilla PCI bridge.
Ok, so it is different from 440GP which is PCI-X.
--
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: STK5200 pci_enable_device problem
From: Oliver Rutsch @ 2007-08-27 6:25 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20070826211021.BD3E724047@gemini.denx.de>
Hi,
[...]
>> It's not so easy to compile the PLX drivers on the 4.1 ELDK because of
>> missing headers in the ppc architecture. I managed to build the drivers
>> for the 2.6.19 kernel and I was able to work with the card except the
>> DMA routines (still working on this issue).
>
> WHy don't you use the arch/powerpc configuration, then? Note that the
> STK5200 has never been supported in a 2.6 kernel with a arch/ppc
> configuration.
>
Because I found at least a lite5200 configuration in the 4.1 ELDK
(2.6.19.2 kernel) in the ARCH/ppc architecure. With ARCH/powerpc I only
had a few configurations for other modules and I wasn't able to build a
running kernel for the TQM5200 (maybe my fault).
Is there support for the TQM5200 and the STK5200 with ARCH/powerpc in
newer kernels? I'm still using the 3.1.1 ELDK for the TQM5200 as it have
everything I need and I don't need to use the PLX card in this board
(although it would have been nice if I got it working...).
Bye,
--
Dipl. Ing. Oliver Rutsch
^ permalink raw reply
* Re: [PATCH 1/3] [POWERPC] Merge 32 and 64 bit pci_process_bridge_OF_ranges() instances
From: Vitaly Bordug @ 2007-08-27 6:31 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20070827011515.GA12804@localhost.localdomain>
On Mon, 27 Aug 2007 11:15:16 +1000
David Gibson wrote:
> On Sat, Aug 25, 2007 at 01:29:47PM +0400, Vitaly Bordug wrote:
> >=20
> > We are having 2 different instances of
> > pci_process_bridge_OF_ranges(), which makes describing 64-bit
> > physical addresses in non PPC64 case impossible.
> >=20
> > This approach inherits pci space parsing, but has a new way to
> > behave equally good in both 32bit and 64bit environments. Currently
> > validated with 440EPx (sequoia) and mpc8349-eitx.
> >=20
> > Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> > Signed-off-by: Stefan Roese <sr@denx.de>
>=20
> I like the idea, but I don't think this implementation is adequate
> yet.
OK, I'll try to address notes below, thanks for looking at it.
>=20
> > diff --git a/arch/powerpc/kernel/pci-common.c
> > b/arch/powerpc/kernel/pci-common.c index 083cfbd..57cd039 100644
> > --- a/arch/powerpc/kernel/pci-common.c
> > +++ b/arch/powerpc/kernel/pci-common.c
> > @@ -478,3 +478,162 @@ void pci_resource_to_user(const struct
> > pci_dev *dev, int bar, *start =3D rsrc->start - offset;
> > *end =3D rsrc->end - offset;
> > }
> > +
> > +void __devinit pci_process_bridge_OF_ranges(struct pci_controller
> > *hose,
> > + struct device_node
> > *dev, int prim) +{
> > + static unsigned int static_lc_ranges[256];
> > + const unsigned int *ranges;
> > + unsigned int *lc_ranges;
> > + unsigned int pci_space;
> > + unsigned long size =3D 0;
>=20
> size can be 64-bit on 32-bit systems, at least in theory.
>=20
hm, well, but later, we'll call ioremap (at least for IO region) that has s=
ize passed as ulong type. And, such a size could be consumed by the code,o=
nly if resource_size_t is 64bit too. I'll look at it further.
> > + int rlen =3D 0;
> > + int orig_rlen, ranges_amnt, i;
> > + int memno =3D 0;
> > + struct resource *res;
> > + int np, na =3D of_n_addr_cells(dev);
> > + struct ranges_pci64_sz64 *ranges64 =3D NULL;
> > + struct ranges_pci32_sz64 *ranges32 =3D NULL;
> > + phys_addr_t pci_addr,=20
>=20
> This is wrong: the PCI binding defines the PCI addresses to be 64-bit,
> even if the CPU has 32-bit physical addresses.
>=20
hmm, ok
> cpu_phys_addr;
> > +
> > + np =3D na + 5;
> > +
> > + /* From "PCI Binding to 1275"
> z> + * The ranges property is laid out as an array of
> z> elements,
> > + * each of which comprises:
> > + * cells 0 - 2: a PCI address
> > + * cells 3 or 3+4: a CPU physical address
> > + * (size depending on
> > dev->n_addr_cells)
> > + * cells 4+5 or 5+6: the size of the range
> > + */
> > + ranges =3D of_get_property(dev, "ranges", &rlen);
> > + if (ranges =3D=3D NULL)
> > + return;
>=20
> if (!ranges) would be the usual idiom here.
>=20
ok
> > + /* Sanity check, though hopefully that never happens */
> > + if (rlen > sizeof(static_lc_ranges)) {
> > + printk(KERN_WARNING "OF ranges property too
> > large !\n");
> > + rlen =3D sizeof(static_lc_ranges);
> > + }
> > +
> > + /* Let's work on a copy of the "ranges" property instead
> > + * of damaging the device-tree image in memory
> > + */
> > + lc_ranges =3D static_lc_ranges;
> > + memcpy(lc_ranges, ranges, rlen);
> > + orig_rlen =3D rlen;
> > +
> > + ranges =3D lc_ranges;
>=20
> You don't ever actually touch the ranges property in place, so there's
> no need for this copy stuff.
>=20
ok
> > + /* Map ranges to struct according to spec. */
> > + if (na >=3D 2) {
> > + ranges64 =3D (void *)ranges;
> > + ranges_amnt =3D rlen / sizeof(*ranges64);
> > + } else {
> > + ranges32 =3D (void *)ranges;
> > + ranges_amnt =3D rlen / sizeof(*ranges32);
> > + }
> > +
> > + hose->io_base_phys =3D 0;
> > + for (i =3D 0; i < ranges_amnt; i++) {
> > + res =3D NULL;
> > + if (ranges64) {
> > + if (ranges64[i].pci_space =3D=3D 0)
> > + continue;
> > +
> > + pci_space =3D ranges64[i].pci_space;
> > + pci_addr =3D
> > + (u64) ranges64[i].pci_addr[0] << 32 |
> > ranges64[i].
> > + pci_addr[1];
>=20
> Why not just define the pci_addr field in your structures as u64? You
> would have to define the structure with attribute((packed)), I guess.
>=20
that was in the first approach, but it gets really interesting numbers (and=
with contents nothing to do with real stuff),
on platforms that are pure 32bit. I mean,=20
u32 foo, foo1;
u64 foo64;
foo =3D bar[1];
foo1 =3D bar[2];
foo64 =3D ((u64)foo << 32) | foo1;
does not seem to work on 32bit board. I may need to write a clear testcase =
and submit it here, maybe I'm missing something
very obvious.
> > + cpu_phys_addr =3D
> > + of_translate_address(dev,
> > ranges64[i].phys_addr);
> > + /*
> > + * I haven't observed 2 significant size
> > cells in kernel
> > + * code, so we're accounting only LSB of
> > size part
> > + * from ranges. -vitb
> > + */
> > + size =3D ranges64[i].size[1];
> > +#ifdef CONFIG_PPC64
> > + if (ranges64[i].size[0])
> > + size |=3D ranges64[i].size[0]<<32;
> > +#endif
> > + DBG("Observed: pci %llx phys %llx size
> > %x\n", pci_addr,
> > + cpu_phys_addr, size);
> > + } else {
> > + if (ranges32[i].pci_space =3D=3D 0)
> > + continue;
> > +
> > + pci_space =3D (unsigned
> > int)ranges32[i].pci_space;
> > + pci_addr =3D (unsigned
> > int)ranges32[i].pci_addr[1];
> > + cpu_phys_addr =3D (unsigned
> > int)ranges32[i].phys_addr[0];
>=20
>=20
> We should really be using of_translate_address() in all cases - that's
> what it's for, after all.
>=20
being called, it gives 0 in 32bit branch of if () {. Since, iirc,
32bit range parsing does not have it in original, variant,
I have it put as is. worths a brief investigation...
> > + size =3D ranges32[i].size[1];
> > +
> > + DBG("Observed: pci %x phys %x size %x\n",
> > + (u32) pci_addr, (u32) cpu_phys_addr,
> > size);
> > + }
>=20
> You don't have any equivalent of the code that exists in both
> pre-existing versions to coalesce contiguous ranges. You probably
> want to use the 64-bit version, since that doesn't need a local copy
> of the ranges.
>=20
correct. yet, the whole aim of the upper seems to use summary size of
contiguous block and that's it.
How would we recognize IORESOURCE_PREFETCH then? (I know, my code is missin=
g that prefetch regions so far, but anyway).
=46rom the code, it seems to declare each resource that is part of contiguous=
block, with the size of entire block.
That's prolly from binding, but can you please elaborate the logic for bett=
er understanding?
> > +
> > + switch ((pci_space >> 24) & 0x3) {
> > + case 1: /* I/O space */
> > +#ifdef CONFIG_PPC32
> > + /*
> > + * check from ppc32 pci implementation.
> > + * not sure if it is needed. -vitb
> > + */
> > + if (pci_addr !=3D 0)
> > + break;
> > +#endif
> > + /* limit I/O space to 16MB */
> > + if (size > 0x01000000)
> > + size =3D 0x01000000;
> > +
> > + hose->io_base_phys =3D cpu_phys_addr -
> > pci_addr;
> > + /* handle from 0 to top of I/O window */
> > +#ifdef CONFIG_PPC64
> > + hose->pci_io_size =3D pci_addr + size;
> > +#endif
> > + hose->io_base_virt =3D
> > ioremap(hose->io_base_phys, size); +
> > + if (prim)
> > + isa_io_base =3D (unsigned
> > long)hose->io_base_virt;
>=20
> The old 64-bit versions don't presently ioremap() or set isa_io_base.
> I'd be worried about changing this semantic, at least without a rather
> more widespread consolidation of the 32/64 bit PCI code.
>=20
Will ifdef it out.
> > +
> > + res =3D &hose->io_resource;
> > + res->flags =3D IORESOURCE_IO;
[snip]
--=20
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Add pci node to sequoia dts
From: Stefan Roese @ 2007-08-27 6:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: David Gibson
In-Reply-To: <20070827062135.GC7306@localhost.localdomain>
On Monday 27 August 2007, David Gibson wrote:
> On Mon, Aug 27, 2007 at 08:07:17AM +0200, Stefan Roese wrote:
> [snip]
>
> > > I usually put device_type, compatible and reg at the top of the block,
> > > to announce what the node actually is before giving all the details.
> > >
> > > Also, apart from the stray space in the compatible, I'm guessing that
> > > the 440EPx bridge is actually more-or-less like the PCI bridges on
> > > other 4xx chips, so we should have a more general compatible string
> > > too.
> >
> > Yes, it is "more-or-less" like any other 4xx PCI core. So it really would
> > make sense to define it more generally. Something like:
> >
> > compatible = "ibm,pci-440epx", "ibm,pci4xx";
> >
> > or even:
> >
> > compatible = "ibm,pci-440epx", "ibm,pci";
> >
> > ?
>
> Hrm.. "xx" is ugly, and "ibm,pci" isn't specific enough. I think
> we're better off just using the oldest similar chip. Since this is
> vanilla PCI, I think that makes it "ibm,pci-405gp"
Fine with me.
> > > Is the 440EPx a vanilla PCI or a PCI-X bridge? If the later that
> > > should be reflected in the name and compatible as well.
> >
> > It's a vanilla PCI bridge.
>
> Ok, so it is different from 440GP which is PCI-X.
Yes. There are some common parts (IIRC), but there are differences. Perhaps
both, IBM-PCI and IBM-PCI-X can be integrated into one source too, but I
think we should start with PCI-only right now.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ 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