* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Segher Boessenkool @ 2007-06-03 9:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1180861620.31677.10.camel@localhost.localdomain>
> But feel free to disagree, it's not of terrible importance. The board
> code is the one to "find" the PICs, including the cascaded 8259, the
> acutal 8259 driver takes whatever node is given to it, so as long as
> your .dts matches your board, it doesn't matter that much.
Here at least we do agree -- with the one added nit that
when using "chrp,iic" you're _forcing_ it to be platform
code that handles this device. But like I said before,
not all that important.
>> This said, I'm looking at device trees right now, and I can understand
>> that interrupt-parent of the 8259 is &mpic in mpc8641_hpcn.dts, but
>> I don't understand at all why it is &pci1 on the mpc85??cds.dts.
>
> Maybe the ISA IRQ on that board is routed to a PCI IRQ# line in which
> case it will use the ISA bridge pci device to lookup in the PCI
> interrupt map... it's a bit weird but as long as it resolves using the
> standard parser, it's perfectly fine.
I don't think it resolves using the _standard_ parser,
it needs a few of the workarounds. But the tree there
is completely broken anyway, fixing it is highly
recommended ;-)
Segher
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Segher Boessenkool @ 2007-06-03 7:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1180828907.14025.37.camel@localhost.localdomain>
>> Oh what the hell, I'm too curious... "pnpPNP,0" it is.
>>
>>> I believe that "8259" should appear somewhere because of the
>>> "8259-interrupt-acknowledge" property (defined in CHRP bindings)
>>> which you can have on the parent bridge to speed up interrupt
>>> vector acquisition.
>>
>> You're not CHRP so you have nothing to do with the CHRP
>> bindings...
>
> Still, you are close to CHRP
Not at all, the rest of the device interrupt subsystem
is very different, too.
> and the CHRP bindings do apply :-)
Nope.
> the 8259
> should thus be chrp,iic :-) It's even documented that way in
> booting-without-of.txt iirc.
So fix the docs :-)
Segher
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Benjamin Herrenschmidt @ 2007-06-03 9:12 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <34eddd7ce58e7983017077454d592332@kernel.crashing.org>
On Sun, 2007-06-03 at 10:57 +0200, Segher Boessenkool wrote:
>
> I have no idea what this whole 8259-ack thing is
> so I cannot comment further.
When you get an IRQ on your main PIC (MPIC for example) which happens to
be the cascade to the 8259, you have two ways of retreiving the actual
8259 interrupt source.
One is the "poll" method which goes read IOs on the 8259. The other one
is to generate a PCI interrupt acknowledge cycle on the bus that leads
to the 8259. If your bridges properly forward it all the way to the ISA
bridge, it should "mimminc" the x86 interrupt acknowledge and return the
interrupt number (an INTACK cycle on PCI is pretty much a read from a
broadcast address).
The later is more efficient but the mecanism to generate such cycles is
very much platform specific and was never abstracted in the PCI stack
(possibly because x86 never needs to explicitely do it, it's all
implicit in the x86 bus protocol :-)
So on CHRP, that property in a PHB indicates, when possible, and address
you can ioremap and readb from to generate an INTACK cycle on that bus
and retreive the pending IRQ of any legacy PIC on that segment.
In theory, in fact, MPIC itself, at least the PCI variant of it, is also
supposed to be able to respond to these rather than reading an MMIO
register (remember, MPIC was supposed to be useable on x86 too, though I
don't know if that was never actually implemented). But then, I've never
seen that used or implemented in practice.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Benjamin Herrenschmidt @ 2007-06-03 9:07 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20070603083339.GB2157@iram.es>
> > Not at all, the rest of the device interrupt subsystem
> > is very different, too.
>
> Given how well you agree, I understand how other people
> might get a bit confused ;-)
Well... we initially decided to base the whole linux device-tree thing
on the CHRP specification. After all, it's flexible and pretty much
everything that has a PCI bus (and especially if it has an i8259) can
almost be considered as a superset of CHRP :-)
Now, Segher seems to disagree, but I tend to think that since it's been
the common practice -and- the chrp spec to make the cascaded i8259 on
the ISA bridge "chrp,iic" so far, doing differently gratuituously will
not help anybody whatsoever.
But feel free to disagree, it's not of terrible importance. The board
code is the one to "find" the PICs, including the cascaded 8259, the
acutal 8259 driver takes whatever node is given to it, so as long as
your .dts matches your board, it doesn't matter that much.
> This said, I'm looking at device trees right now, and I can understand
> that interrupt-parent of the 8259 is &mpic in mpc8641_hpcn.dts, but
> I don't understand at all why it is &pci1 on the mpc85??cds.dts.
Maybe the ISA IRQ on that board is routed to a PCI IRQ# line in which
case it will use the ISA bridge pci device to lookup in the PCI
interrupt map... it's a bit weird but as long as it resolves using the
standard parser, it's perfectly fine.
> But the definition of the ISA bridge in these files is very strange to
> start with: I've never seen an ISA bridge with only an interrupt controller
> on it, no interrupts are connected to it and its reg property is
> almost certainly wrong. Maybe it is an example of things that should
> not be done.
Heh, dunno, I haven't looked that closely at what they did... I would
have expected legacy devices to have their IRQ pointing to the 8259
indeed.
Ben.
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Geert Uytterhoeven @ 2007-06-03 8:59 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20070602085359.GA10333@iram.es>
On Sat, 2 Jun 2007, Gabriel Paubert wrote:
> I have vague memories of a node named i8259@20 one a board
> who had OF in 1997 (a Motorola MVME but they switched to
> PPCBUG just after :-().
On my LongTrail (RIP), I used to have /pci/isa@1/interrupt-controller@i20
(http://users.telenet.be/geertu/Linux/PPC/pci/isaAT1/interrupt-controllerATi20/)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Segher Boessenkool @ 2007-06-03 8:57 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20070603083339.GB2157@iram.es>
>>>> Oh what the hell, I'm too curious... "pnpPNP,0" it is.
>>>>
>>>>> I believe that "8259" should appear somewhere because of the
>>>>> "8259-interrupt-acknowledge" property (defined in CHRP bindings)
>>>>> which you can have on the parent bridge to speed up interrupt
>>>>> vector acquisition.
>>>>
>>>> You're not CHRP so you have nothing to do with the CHRP
>>>> bindings...
>>>
>>> Still, you are close to CHRP
>>
>> Not at all, the rest of the device interrupt subsystem
>> is very different, too.
>
> Given how well you agree, I understand how other people
> might get a bit confused ;-)
Heh. Let's look at it some other way: if you use
"chrp,iic", this node needs to be handled by either
CHRP platform code (which will not work, you aren't
CHRP), or by platform-specific code. If you use the
generic "pnpPNP,0" name, it can (in theory) be handled
by architecture-neutral code, even.
For the foreseeable future (or perhaps forever) the
interrupt stuff will be set up from the platform
code, so there is no direct impact on Linux. You
might want to support other OSes, or be more future-
proof, or generically want a cleaner device tree.
> This said, I'm looking at device trees right now, and I can understand
> that interrupt-parent of the 8259 is &mpic in mpc8641_hpcn.dts, but
> I don't understand at all why it is &pci1 on the mpc85??cds.dts.
Perhaps the 8259 IRQ output is routed to a PCI
interrupt. If not, this is just plain wrong.
> But the definition of the ISA bridge in these files is very strange to
> start with: I've never seen an ISA bridge with only an interrupt
> controller
> on it, no interrupts are connected to it
Maybe that's why it works ;-)
> and its reg property is
> almost certainly wrong.
<19000 0 0 0 0> could be right, that means device d#18
on PCI bus 1. There is a missing bus #1 node in between
though. And the unit address is @12 in that case,
not @19000 .
> Maybe it is an example of things that should
> not be done.
Maybe :-)
>>> and the CHRP bindings do apply :-)
>>
>> Nope.
>
> At least the 8259-interrupt-acknowledge property of the bus
> on which the ISA bridge is found should keep its name. It's what
> the kernel uses.
Only the CHRP Linux platform code should use that.
It's not necessarily a bad idea to define your
platform's binding to do the same, of course --
other platform's bindings do not apply to yours,
but there is no harm in creating a certain similarity.
I have no idea what this whole 8259-ack thing is
so I cannot comment further.
> It just seems odd to call the chip iic (for ISA interrupt controller
> I suppose) on one side and 8259 on the other. Naming consistency
> is important.
It certainly helps, yes.
> Technically the 8259-interrupt-acknowledge is not a very fortunate
> name choise since it is an a 8259 like chip (or an ISA bridge
> for the matter) that has to claim the interrupt acknowledge
> cycles, but it is what happens in practice.
Could you explain what this is (or point me to
some doc)?
>>> the 8259
>>> should thus be chrp,iic :-) It's even documented that way in
>>> booting-without-of.txt iirc.
>
> Nope.
Good to hear :-)
Segher
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Gabriel Paubert @ 2007-06-03 8:33 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <28e0600256815f93db45b2f4eb2d9df5@kernel.crashing.org>
On Sun, Jun 03, 2007 at 09:41:33AM +0200, Segher Boessenkool wrote:
> >>Oh what the hell, I'm too curious... "pnpPNP,0" it is.
> >>
> >>>I believe that "8259" should appear somewhere because of the
> >>>"8259-interrupt-acknowledge" property (defined in CHRP bindings)
> >>>which you can have on the parent bridge to speed up interrupt
> >>>vector acquisition.
> >>
> >>You're not CHRP so you have nothing to do with the CHRP
> >>bindings...
> >
> >Still, you are close to CHRP
>
> Not at all, the rest of the device interrupt subsystem
> is very different, too.
Given how well you agree, I understand how other people
might get a bit confused ;-)
This said, I'm looking at device trees right now, and I can understand
that interrupt-parent of the 8259 is &mpic in mpc8641_hpcn.dts, but
I don't understand at all why it is &pci1 on the mpc85??cds.dts.
But the definition of the ISA bridge in these files is very strange to
start with: I've never seen an ISA bridge with only an interrupt controller
on it, no interrupts are connected to it and its reg property is
almost certainly wrong. Maybe it is an example of things that should
not be done.
> >and the CHRP bindings do apply :-)
>
> Nope.
At least the 8259-interrupt-acknowledge property of the bus
on which the ISA bridge is found should keep its name. It's what
the kernel uses.
It just seems odd to call the chip iic (for ISA interrupt controller
I suppose) on one side and 8259 on the other. Naming consistency
is important.
Technically the 8259-interrupt-acknowledge is not a very fortunate
name choise since it is an a 8259 like chip (or an ISA bridge
for the matter) that has to claim the interrupt acknowledge
cycles, but it is what happens in practice.
>
> >the 8259
> >should thus be chrp,iic :-) It's even documented that way in
> >booting-without-of.txt iirc.
Nope.
Gabriel
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Gabriel Paubert @ 2007-06-03 7:53 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <438689f53c9fc6605b9091a54f112a37@kernel.crashing.org>
On Sun, Jun 03, 2007 at 09:42:55AM +0200, Segher Boessenkool wrote:
> >Maybe the 0x4d0/4d1 ports can be accessed with 16 bit
> >instructions, I don't know. What I know for sure is that
> >accessing port 0x20 with an inl/outl on some boards
> >locks immediately the system up (perhaps through infinite
> >retries).
>
> And inw/outw? There are only two bytes of registers
> there after all.
It does not lock up on the boards I've tested, but the results
are undefined (and perhaps implementation dependent). The problem
being that most accesses to the first register (command) change
the definition of which internal register is accessed with the
second byte.
Gabriel
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Segher Boessenkool @ 2007-06-03 7:42 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20070603001323.GA25653@iram.es>
> Maybe the 0x4d0/4d1 ports can be accessed with 16 bit
> instructions, I don't know. What I know for sure is that
> accessing port 0x20 with an inl/outl on some boards
> locks immediately the system up (perhaps through infinite
> retries).
And inw/outw? There are only two bytes of registers
there after all.
Segher
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Segher Boessenkool @ 2007-06-03 7:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org, Jon Loeliger
In-Reply-To: <1180826202.14025.12.camel@localhost.localdomain>
>> Feel free to ask for advice on IRC, on the list, or
>> elsewhere _before_ sending a patch.
>
> Bah, sending a patch is good too, don't be too hard there. I for one
> prefer the approach of sending a patch first.
I'm saying that if you're unsure about stuff, you can ask
about it -- sending a preliminary patch with the question
is one way, sure.
>>> Second, perhaps there is lingering legacy
>>> crap in some of the early DTS files that should be systematically
>>> cleaned up.
>>
>> Yes there is. Maybe one day I'll get to it, I'm hoping
>> someone else will fix this though ;-)
>
> We probably need to improve the documentation in fact. Maybe with a
> step
> by step HOWTO create your device-tree with examples for typical things
> like PCI etc.. and the rational of why for each of these, we chose to
> do
> XXX instead of YYY...
A howto-like doc would help yes. Rationale might help people
better understand how things work, too, sure.
>> The official (and unofficial) Open Firmware docs are quite
>> good. Perhaps we need a big huge fat sign in the DTS docs
>> pointing to them.
>
> They aren't -that- good when you come out of the blue and don't know
> where to start.
Well most people don't even know those docs _exist_ it
seems.
> I think a tutorial based on building a tree for an
> example board step by step would be best.
Would be nice yes.
Segher
^ permalink raw reply
* Re: ps3 64-bit kernel: patched prpmc2800.c (fwd)
From: Paul Mackerras @ 2007-06-03 1:51 UTC (permalink / raw)
To: Maik Nijhuis; +Cc: linuxppc-dev
In-Reply-To: <Pine.GSO.4.63.0705250829380.19095@hydra.cs.vu.nl>
Maik Nijhuis writes:
> I managed to fix this issue as follows: At the end of
> arch/powerpc/boot/prpmc2800.c, there is an assembly instruction
>
> rlwinm 10,10,0,~(1<<15)
>
> I replaced this by
>
> rlwinm 10,10,0,~(1<<15) & ((1<<32)-1)
It is a binutils bug, and Alan Modra has a patch for it. In the
meantime the best thing would be to change that to
rlwinm 10,10,0,17,15
which is equivalent.
Paul.
^ permalink raw reply
* Please pull powerpc.git master branch
From: Paul Mackerras @ 2007-06-03 1:15 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 master
to get some more powerpc bug fixes, compile fixes, and a comment-only
change, for 2.6.22.
Thanks,
Paul.
arch/powerpc/Makefile | 1 -
arch/powerpc/boot/Makefile | 22 ++++++++++++----------
arch/powerpc/boot/wrapper | 4 ++--
arch/powerpc/kernel/irq.c | 6 +++---
arch/powerpc/kernel/prom.c | 11 ++++++-----
arch/powerpc/kernel/ptrace.c | 2 ++
arch/powerpc/platforms/pasemi/idle.c | 1 +
arch/powerpc/platforms/ps3/interrupt.c | 1 +
arch/powerpc/platforms/pseries/xics.c | 10 ++++++----
arch/ppc/syslib/ibm_ocp.c | 1 +
drivers/macintosh/Kconfig | 2 +-
include/asm-powerpc/pgalloc-64.h | 3 ++-
include/asm-powerpc/tlb.h | 9 +++++++++
13 files changed, 46 insertions(+), 27 deletions(-)
commit 627aa944a17ba82ca3ba87dc1d6ee85bd314ec79
Author: Milton Miller <miltonm@bga.com>
Date: Thu May 31 01:29:01 2007 +1000
[POWERPC] Fix zImage.coff generation for 32-bit pmac
Commit 9da82a6dee9db4cd5ae7a74ab4f51afb52b6efb9 inadvertently
removed the platform override for zImage.coff to be generated
with pmaccoff. Rather than add a special makefile rule,
change the platform for which the wrapper platform uses
the special rules.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit f48419666e645208c0156aecab1ee6157303da3c
Author: Stefan Roese <sr@denx.de>
Date: Sat Jun 2 19:30:20 2007 +1000
[POWERPC] Fix compile breakage for IBM/AMCC 4xx arch/ppc platforms
The IBM/AMCC 405 platforms don't compile anymore in the current
kernel version. This fixes the compile breakage.
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit e358ae4dd4ca823abc5ee06c61e3915636e60191
Author: Johannes Berg <johannes@sipsolutions.net>
Date: Sat Jun 2 19:13:44 2007 +1000
[POWERPC] Don't allow PMAC_APM_EMU for 64-bit
In b302887854d6f0c6f9fc3f1080535e7c1bd53134 I switched the apm emulation
code to use the generic code but accidentally dropped the PPC32
dependency from the configuration symbol. This adds it back.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit f5921697cf5cae68dcbfa881d9e08f3cebef47eb
Author: Michael Ellerman <michael@ellerman.id.au>
Date: Fri Jun 1 17:23:26 2007 +1000
[POWERPC] Compare irq numbers with NO_IRQ not IRQ_NONE
There is a thinko in the irq code, it uses IRQ_NONE to indicate no irq,
whereas it should be using NO_IRQ. IRQ_NONE is returned from irq
handlers to say "not handled".
As it happens they currently have the same value (0), so this is just for
future proof-ness.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit a4c28ab7445f5ca60e56ffd90edb3e9fc1330b71
Author: Akinobu Mita <mita@fixstars.com>
Date: Tue May 29 20:46:51 2007 +1000
[POWERPC] Fix return from pte_alloc_one() in out-of-memory case
pte_alloc_one() is expected to return NULL if out of memory.
But it returns virt_to_page(NULL), which is not NULL.
This fixes it.
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Akinobu Mita <mita@fixstars.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 66b30922c8a2c880fe61080c5bf87ae6615b9f64
Author: Michael Neuling <mikey@neuling.org>
Date: Tue May 29 17:01:52 2007 +1000
[POWERPC] Fix compile warning in pseries xics code
In 616883df78bd4b3fcdb6ddc39bd3d4cb902bfa32 request_irq was marked as
__must_check so we must... er... check it.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit b610b9780bdb2750849f32c2eefef46af58c67f8
Author: David Gibson <david@gibson.dropbear.id.au>
Date: Tue May 29 15:37:12 2007 +1000
[POWERPC] Don't use HOSTCFLAGS in BOOTCFLAGS
In the bootwrapper code for powerpc, we include HOSTCFLAGS into the
BOOTCFLAGS used for building the zImage wrapper code. Since the
wrapper code is not host code, this makes no sense. This patch
removes the use of HOSTCFLAGS here, instead including directly into
BOOTCFLAGS those flags from the normal kernel CFLAGS which also make
sense in the bootwrapper code.
In particular, this makes the bootwrapper use -msoft-float, preventing
the compiler from generating floating point instructions. Previously,
under some circumstances the compiler could generate floating point
instructions in the bootwrapper which would cause exceptions on
embedded CPUS which don't have floating point support.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 0570d4ed4325c0fb2ceb75f45a21d878b1741b61
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon May 28 16:12:59 2007 +1000
[POWERPC] Create a zImage for legacy iSeries
This zImage is really just the stripped vmlinux, but it means that there
is one less special case for iSeries and also that the zImages will be
built for a combined kernel build that happens to include iSeries.
This zImage boots fine on legacy iSeries.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 18456d015c50bc903fc66c65621170170190a1fd
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon May 28 10:20:45 2007 +1000
[POWERPC] pasemi idle uses hard_smp_processor_id
and so needs to include asm/smp.h so a UP build works.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 42d284bc45a9d6625b30c3175563829847406e03
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon May 28 10:19:08 2007 +1000
[POWERPC] ps3/interrupt.c uses get_hard_smp_processor_id
and so needs to include asm/smp.h for a UP build to work.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 6ad8d010b2f364b739020e514e61b6a73444464b
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Sun May 27 15:18:22 2007 +1000
[POWERPC] Fix possible access to free pages
I think we have a subtle race on ppc64 with the tlb batching. The
common code expects tlb_flush() to actually flush any pending TLB
batch. It does that because it delays all page freeing until after
tlb_flush() is called, in order to ensure no stale reference to
those pages exist in any TLB, thus causing potential access to
the freed pages.
However, our tlb_flush only triggers the RCU for freeing page
table pages, it does not currently trigger a flush of a pending
TLB/hash batch, which is, I think, an error. This fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 988519acb3dbe7168276a36cbb8fd91fddbffaee
Author: David Gibson <david@gibson.dropbear.id.au>
Date: Fri May 25 13:19:17 2007 +1000
[POWERPC] Fix compiler/assembler flags for Ebony platform boot files
The recent addition of assembler flags for 44x.c and ebony.c in the
bootwrapper to make them compile on certain toolchains was not correct
and could break other platforms. This patch switches to using a
compiler flag instead, which implies the appropriate assembler flag,
and also stops the compiler itself generating instructions which are
invalid for the platform in question.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 7d43e57764fe6922703c36d8d0d56a7ead21f03d
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Thu May 24 15:41:04 2007 +1000
[POWERPC] Fix ppc32 single-stepping out of syscalls
The ppc32 kernel didn't properly set/clear the TIF_SINGLESTEP
flag, causing return from syscalls to not SIGTRAP, thus executing
one more instruction before stopping again.
This fixes it. The ptrace code is a bit of a mess, and is overdue
for at least a -proper- 32/64 bits split and possibly more cleanups
but this minimum fix should be ok for 2.6.22
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 5169b8a1659fef9cc093ed3d889a854945a18177
Author: Michael Ellerman <michael@ellerman.id.au>
Date: Wed May 23 18:08:13 2007 +1000
[POWERPC] Update documentation for of_find_node_by_type()
The documentation for of_find_node_by_type() incorrectly refers to the
"name" parameter - it should be "type".
Also the behaviour when from == NULL is not really documented, fix that.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Gabriel Paubert @ 2007-06-03 0:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1180828253.14025.22.camel@localhost.localdomain>
On Sun, Jun 03, 2007 at 09:50:53AM +1000, Benjamin Herrenschmidt wrote:
> Minor nits (in addition to needing a "reg" property)
>
> > +
> > + i8259: i8259@4d0 {
>
> Name should probably be "interrupt-controller" as well to follow the
> recommended naming practice.
>
> > + clock-frequency = <0>;
> > + interrupt-controller;
> > + device_type = "interrupt-controller";
> > + #address-cells = <0>;
> > + #interrupt-cells = <2>;
> > + built-in;
> > + compatible = "chrp,iic";
> > + big-endian;
>
> big-endian ? On a 8259 ?
Yes, I spotted that too. Funny on a device which is only ever
accessed through inb/outb!
Maybe the 0x4d0/4d1 ports can be accessed with 16 bit
instructions, I don't know. What I know for sure is that
accessing port 0x20 with an inl/outl on some boards
locks immediately the system up (perhaps through infinite
retries).
Gabriel
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Benjamin Herrenschmidt @ 2007-06-03 0:01 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <12ad593bd17f769e44f05bc24eac4d0a@kernel.crashing.org>
On Sat, 2007-06-02 at 22:23 +0200, Segher Boessenkool wrote:
>
>
> Oh what the hell, I'm too curious... "pnpPNP,0" it is.
>
> > I believe that "8259" should appear somewhere because of the
> > "8259-interrupt-acknowledge" property (defined in CHRP bindings)
> > which you can have on the parent bridge to speed up interrupt
> > vector acquisition.
>
> You're not CHRP so you have nothing to do with the CHRP
> bindings...
Still, you are close to CHRP and the CHRP bindings do apply :-) the 8259
should thus be chrp,iic :-) It's even documented that way in
booting-without-of.txt iirc.
Ben.
^ permalink raw reply
* Re: [PATCH 3/3] consolidate do_signal
From: Benjamin Herrenschmidt @ 2007-06-02 23:59 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev
In-Reply-To: <20070602102143.GA21707@lst.de>
On Sat, 2007-06-02 at 12:21 +0200, Christoph Hellwig wrote:
> do_signal has exactly the same behaviour on 32bit and 64bit and 32bit
> compat on 64bit for handling 32bit signals. Consolidate all these
> into one common function in signal.c. The oly odd left over is
> the try_to_free in the 32bit version that no other architecture has
> in mainline (only in i386 for some odd SuSE release). We should
> probably get rid of it in a separate patch.
Excellent, that's something I was planning to do too, nice that you beat
me to it :-)
Some comments after a quick look (I haven't gone deep into comparing
old/new implementation, I'll do that later from work).
> +
> +#ifdef CONFIG_PPC32
> +no_signal:
> +#endif
That really need to go (the freeze stuff)
> + /* Is there any syscall restart business here ? */
> + check_syscall_restart(regs, &ka, signr > 0);
> +
> + if (signr <= 0) {
> + /* No signal to deliver -- put the saved sigmask back */
> + if (test_thread_flag(TIF_RESTORE_SIGMASK)) {
> + clear_thread_flag(TIF_RESTORE_SIGMASK);
> + sigprocmask(SIG_SETMASK, ¤t->saved_sigmask, NULL);
> + }
> + return 0; /* no signals delivered */
> + }
> +
> +#ifdef CONFIG_PPC64
> + /*
> + * Reenable the DABR before delivering the signal to
> + * user space. The DABR will have been cleared if it
> + * triggered inside the kernel.
> + */
> + if (current->thread.dabr)
> + set_dabr(current->thread.dabr);
> +#endif
One of my patches is extending DABR to 32 bits, though I might have
missed that bit. I think if you apply yours on top of mines, then that
ifdef can go. (Note that I need to respin mines due to small changes, so
we might decide to shuffle things and put yours first, just on top of
the one of mine making the check restart common, and have the rest of my
changes moved on top of those).
> + if (is32) {
> + unsigned int newsp;
> +
> + if ((ka.sa.sa_flags & SA_ONSTACK) &&
> + current->sas_ss_size && !on_sig_stack(regs->gpr[1]))
> + newsp = current->sas_ss_sp + current->sas_ss_size;
> + else
> + newsp = regs->gpr[1];
Hrm... some gratuituous differences in the signal stack handling.. I
wonder if that hides a bug in one of the implementations...
> + if (ka.sa.sa_flags & SA_SIGINFO)
> + ret = handle_rt_signal32(signr, &ka, &info, oldset,
> + regs, newsp);
> + else
> + ret = handle_signal32(signr, &ka, &info, oldset,
> + regs, newsp);
> +#ifdef CONFIG_PPC64
> + } else {
> + ret = handle_rt_signal64(signr, &ka, &info, oldset, regs);
> +#endif
> + }
I'd rather have handle_rt_signal64() itself be defined as an empty
inline function than having an ifdef in here, don't you agree ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Benjamin Herrenschmidt @ 2007-06-02 23:52 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <3ebd6ca6877ea74925f066ff96ac81db@kernel.crashing.org>
On Sat, 2007-06-02 at 11:01 +0200, Segher Boessenkool wrote:
>
> I'm not sure what "compatible" should be for this node, someone
> else can dig that up :-)
chrp,iic
Ben.
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Benjamin Herrenschmidt @ 2007-06-02 23:51 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20070602085359.GA10333@iram.es>
> By far the most important registers are the ones at 0x20 since
> you access them at every interrupt. The registers at 0x4d0
> are typically set by firmware and never touched later, there
> is not a single access to them in sysdev/i8259.c.
>
> I have vague memories of a node named i8259@20 one a board
> who had OF in 1997 (a Motorola MVME but they switched to
> PPCBUG just after :-().
Here's the entry for a 8259 in an old pSeries device-tree:
(Note the use of the recommended naming practice where the name is
actually the device-class)
/proc/device-tree/pci@fef00000/isa@b/interrupt-controller@i20:
name "interrupt-controller"
linux,phandle 00ceed58 (13561176)
interrupt-parent 00c73068 (13054056)
interrupt-controller
#interrupt-cells 00000002
interrupts 00000000 00000002
reserved-interrupts
00000002 00000003
reg 00000001 00000020 00000002 00000001
000000a0 00000002 00000001 000004d0
00000002
compatible "chrp,iic"
built-in
model "WINB,W83C553"
device_type "interrupt-controller"
ibm,loc-code "P2"
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Benjamin Herrenschmidt @ 2007-06-02 23:50 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1180720112.14219.62.camel@ld0161-tx32>
Minor nits (in addition to needing a "reg" property)
> +
> + i8259: i8259@4d0 {
Name should probably be "interrupt-controller" as well to follow the
recommended naming practice.
> + clock-frequency = <0>;
> + interrupt-controller;
> + device_type = "interrupt-controller";
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + built-in;
> + compatible = "chrp,iic";
> + big-endian;
big-endian ? On a 8259 ?
> + interrupts = <49 2>;
> + interrupt-parent =
> + <&mpic>;
> + };
> + };
> + };
> };
>
> };
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Benjamin Herrenschmidt @ 2007-06-02 23:16 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org, Jon Loeliger
In-Reply-To: <27807251665003e059b2c39d2b700415@kernel.crashing.org>
On Sat, 2007-06-02 at 22:00 +0200, Segher Boessenkool wrote:
>
> Feel free to ask for advice on IRC, on the list, or
> elsewhere _before_ sending a patch.
Bah, sending a patch is good too, don't be too hard there. I for one
prefer the approach of sending a patch first.
> > Second, perhaps there is lingering legacy
> > crap in some of the early DTS files that should be systematically
> > cleaned up.
>
> Yes there is. Maybe one day I'll get to it, I'm hoping
> someone else will fix this though ;-)
We probably need to improve the documentation in fact. Maybe with a step
by step HOWTO create your device-tree with examples for typical things
like PCI etc.. and the rational of why for each of these, we chose to do
XXX instead of YYY...
> The official (and unofficial) Open Firmware docs are quite
> good. Perhaps we need a big huge fat sign in the DTS docs
> pointing to them.
They aren't -that- good when you come out of the blue and don't know
where to start. I think a tutorial based on building a tree for an
example board step by step would be best.
Ben.
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Segher Boessenkool @ 2007-06-02 20:23 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20070602195308.GA21618@iram.es>
>> Yes, I think we all agree -- it should be interrupt-controller@20,
>> with 20, a0, 4d0 in the "reg" property.
>
> In the current tree it is called "i8259" in mpc8641_hpcn.dts.
"interrupt-controller" is the preferred name for all
interrupt controller nodes. The "compatible" property
can easily distinguish between different types. Not
that it matters all that much -- just remember that
the "name" is used for device matching before "compatible"
is (_should_ be, Linux ignores this part of the standard
right now in most cases), so don't put junk in there!
> The other
> ones which have a 8259 are not usable (mpc8555 for example). I don't
> even understand their reg property (19000 0 0 0 1),
Very weird indeed. What bustype is this? (I looked it up,
it's PCI, and I can't make heads or tails of it either --
it says it sits on bus #1, although its parent isn't bus #1;
and the final "1" should be "0". Many more weird things
in that node, too).
> and the driver
> has hardcoded addresses at 0x20 and 0xa0, which is reasonable
> since I've never seen an ISA bridge put the 8259 at another address.
As long as the driver (platform code I hope?) at least checks
for the existence of the node, that's fair enough I guess.
Actually using the "reg" would be better of course.
>> I'm not sure what "compatible" should be for this node, someone
>> else can dig that up :-)
Oh what the hell, I'm too curious... "pnpPNP,0" it is.
> I believe that "8259" should appear somewhere because of the
> "8259-interrupt-acknowledge" property (defined in CHRP bindings)
> which you can have on the parent bridge to speed up interrupt
> vector acquisition.
You're not CHRP so you have nothing to do with the CHRP
bindings...
Segher
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Segher Boessenkool @ 2007-06-02 20:00 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <E1HuW61-00049R-FI@jdl.com>
>> That, and I often get tired of seeing the same mistakes
>> over and over again. When I see a proposed tree that's
>> just too awful I don't really know where to start.
>
> That is a good point.
>
> I think there are several factors at work here. First and
> foremost, I am not an expert in this area; it is new to me.
> I am not afraid to say that I really need the guidance of
> an expert here.
Feel free to ask for advice on IRC, on the list, or
elsewhere _before_ sending a patch.
> Second, perhaps there is lingering legacy
> crap in some of the early DTS files that should be systematically
> cleaned up.
Yes there is. Maybe one day I'll get to it, I'm hoping
someone else will fix this though ;-)
> Many of them were written during a time when we
> were really first learning about the whole Device Tree. While
> they may have been there on some, say, Apple boards, it's all
> new for the FSL embedded parts.
Many apple trees (pun intended) aren't all that great
either.
> Cloned mistakes then likely
> contributed to the problems and should be fixed. Finally,
> perhaps our documentation on how some of the important fields
> should work or be derived is lacking and could be improved.
The official (and unofficial) Open Firmware docs are quite
good. Perhaps we need a big huge fat sign in the DTS docs
pointing to them.
> Suggestions or patches down this line would likely be welcomed.
>
>> I also find the DTS source format a bit hard to read,
>> but maybe that's just me.
>
> I, at least, am open to suggestions that might improve it.
My biggest problem when reviewing patches (or whole trees)
in mail is the indenting. Part of that I could fix myself
by setting my mail reader to eight spaces indent. The bigger
problem is that trees are just not very readable in flat
text format (you really need to see the parent node together
with every of its child nodes). There's no real way to fix
this I'm afraid. In "real" OF, most properties are filled
in programmatibly, and you typically have one node per source
file. This won't help for DTS files. Maybe putting more
(good!) comments in DTS files would help though?
Segher
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Gabriel Paubert @ 2007-06-02 19:53 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <3ebd6ca6877ea74925f066ff96ac81db@kernel.crashing.org>
On Sat, Jun 02, 2007 at 11:01:29AM +0200, Segher Boessenkool wrote:
> >>>>>+ i8259: i8259@4d0 {
> >>>>
> >>>>Needs "reg". And 4d0 isn't the primary address
> >>>>I think?
> >>>
> >>>Yes, this is a standard i8259 with additional registers at 0x20 and
> >>>0xa0. I'll fix the address and add the registers.
> >>
> >>That sounds good, thanks!
> >
> >I'd beg to differ. There are three registers area:
> >
> >- 0x20 which is the master interrupt controller
> > (since the original 1981 IBM-PC)
> >- 0xa0 which is the slave interrupt controller, connected to
> > IRQ2 of the master (introduced with the XT or the AT, I don't
> > remember)
> >- 0x4d0 which was added later to allow per interrupt line setting
> > of edge or level triggering (instead of per controller).
> >
> >By far the most important registers are the ones at 0x20 since
> >you access them at every interrupt. The registers at 0x4d0
> >are typically set by firmware and never touched later, there
> >is not a single access to them in sysdev/i8259.c.
>
> Yes, I think we all agree -- it should be interrupt-controller@20,
> with 20, a0, 4d0 in the "reg" property.
In the current tree it is called "i8259" in mpc8641_hpcn.dts. The other
ones which have a 8259 are not usable (mpc8555 for example). I don't
even understand their reg property (19000 0 0 0 1), and the driver
has hardcoded addresses at 0x20 and 0xa0, which is reasonable
since I've never seen an ISA bridge put the 8259 at another address.
>
> I'm not sure what "compatible" should be for this node, someone
> else can dig that up :-)
I believe that "8259" should appear somewhere because of the
"8259-interrupt-acknowledge" property (defined in CHRP bindings)
which you can have on the parent bridge to speed up interrupt
vector acquisition.
Gabriel
^ permalink raw reply
* [2.6 patch] make drivers/char/hvc_console.c:khvcd() static
From: Adrian Bunk @ 2007-06-02 19:09 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, linux-kernel
This patch makes the needlesly global khvcd() static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
--- linux-2.6.22-rc3-mm1/drivers/char/hvc_console.c.old 2007-06-02 19:58:07.000000000 +0200
+++ linux-2.6.22-rc3-mm1/drivers/char/hvc_console.c 2007-06-02 19:58:28.000000000 +0200
@@ -674,7 +674,7 @@
* calling hvc_poll() who determines whether a console adapter support
* interrupts.
*/
-int khvcd(void *unused)
+static int khvcd(void *unused)
{
int poll_mask;
struct hvc_struct *hp;
^ permalink raw reply
* Re: ps3 64-bit kernel: patched prpmc2800.c (fwd)
From: Geoff Levand @ 2007-06-02 18:39 UTC (permalink / raw)
To: Maik Nijhuis; +Cc: linuxppc-dev
In-Reply-To: <Pine.GSO.4.63.0705250829380.19095@hydra.cs.vu.nl>
Maik Nijhuis wrote:
> While compiling a 64-bit kernel for the playstation 3 I noticed that
> arch/powerpc/boot/prpmc2800.c doesn't compile. The assembler complains
> about a constant that is too big.
>
> And then this error follows:
>
> /tmp/ccYHAOD7.s: Assembler messages:
> /tmp/ccYHAOD7.s:9: Error: operand out of range (0xffffffffffff7fff is not
> between 0x0000000000000000 and 0x00000000ffffffff)
>
> I managed to fix this issue as follows: At the end of
> arch/powerpc/boot/prpmc2800.c, there is an assembly instruction
>
> rlwinm 10,10,0,~(1<<15)
>
> I replaced this by
>
> rlwinm 10,10,0,~(1<<15) & ((1<<32)-1)
>
> I am running 64-bit gentoo linux with binutils 2.17.50.0.16. It has been
> compiled on my ps3 using gentoo ebuild scripts.
>
> Could you please either fix binutils or apply the above patch?
The trouble is that I have no way to test that change. I don't have the
hardware. Since that file is not for PS3, the best thing to do
is to not build that file when not building for prpmc2800. I will
post a patch that does that.
-Geoff
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Jon Loeliger @ 2007-06-02 16:04 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <e2020ffad171013c07f8809e1e1aef97@kernel.crashing.org>
So, like, the other day Segher Boessenkool mumbled:
>
> That, and I often get tired of seeing the same mistakes
> over and over again. When I see a proposed tree that's
> just too awful I don't really know where to start.
That is a good point.
I think there are several factors at work here. First and
foremost, I am not an expert in this area; it is new to me.
I am not afraid to say that I really need the guidance of
an expert here. Second, perhaps there is lingering legacy
crap in some of the early DTS files that should be systematically
cleaned up. Many of them were written during a time when we
were really first learning about the whole Device Tree. While
they may have been there on some, say, Apple boards, it's all
new for the FSL embedded parts. Cloned mistakes then likely
contributed to the problems and should be fixed. Finally,
perhaps our documentation on how some of the important fields
should work or be derived is lacking and could be improved.
Suggestions or patches down this line would likely be welcomed.
> I also find the DTS source format a bit hard to read,
> but maybe that's just me.
I, at least, am open to suggestions that might improve it.
Thanks,
jdl
^ 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