* Re: need Open PIC infos
1999-10-16 17:14 need Open PIC infos Benjamin Herrenschmidt
@ 1999-10-17 14:16 ` Geert Uytterhoeven
1999-10-22 2:41 ` need Open PIC infos (and more) Gabriel Paubert
1999-10-25 1:17 ` need Open PIC infos Troy Benjegerdes
2 siblings, 0 replies; 6+ messages in thread
From: Geert Uytterhoeven @ 1999-10-17 14:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
On Sat, 16 Oct 1999, Benjamin Herrenschmidt wrote:
> However, the new Apple ASICs contains an Open PIC interrupt controller
> (advertised as beeing a "chrp,open-pic" controller). After looking at the
> various docs I have and a quick search on Altavista, I couldn't find any
> relevant documentation on the chip.
> There's already some OpenPIC support in the kernel, but I'll have to
> change it a little bit since, for example, Apple hardware is not a good
> place to search for a 8259 master ;)
> I'd like some docs in order to have better understanding of the chip.
The i8259 slaves are not mandatory in OpenPIC.
Do you have the OpenPIC docs? They are somewhere on the AMD website. If you
can't find them, please ask me, I have a copy on my docs CD-ROM, as usual :-)
Greetings,
Geert
--
Geert Uytterhoeven ----------------- Sony Suprastructure Center Europe (SUPC-E)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Phone +32-2-7248632 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: need Open PIC infos (and more)
1999-10-16 17:14 need Open PIC infos Benjamin Herrenschmidt
1999-10-17 14:16 ` Geert Uytterhoeven
@ 1999-10-22 2:41 ` Gabriel Paubert
1999-10-22 8:55 ` Benjamin Herrenschmidt
1999-10-25 1:17 ` need Open PIC infos Troy Benjegerdes
2 siblings, 1 reply; 6+ messages in thread
From: Gabriel Paubert @ 1999-10-22 2:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, cort
On Sat, 16 Oct 1999, Benjamin Herrenschmidt wrote:
>
> Hi !
>
> I'm working on support for new UMA machines (beginning with iBook). I
> have already figured out a lot of things and am now coding a very
> preliminary support (I'm not sure yet the PMU99 will work out of the box
> or not, but it looks similar to the old PMU from an interface point of view).
Great (and sorry for the delay in answering).
> However, the new Apple ASICs contains an Open PIC interrupt controller
> (advertised as beeing a "chrp,open-pic" controller). After looking at the
> various docs I have and a quick search on Altavista, I couldn't find any
> relevant documentation on the chip.
> There's already some OpenPIC support in the kernel, but I'll have to
> change it a little bit since, for example, Apple hardware is not a good
> place to search for a 8259 master ;)
I don't know on which board the 8259 is a master of the OpenPIC. On CHRP
boards and Motorola with Raven or Hawk chipsets, the 8259 is the slave
connected on interrupt 0 of the OpenPIC. If you don't have a 8259 on this
input of the OpenPIC then input 0 behaves like any other input and you'll
have to program it as edge/level as per the specification.
> I'd like some docs in order to have better understanding of the chip.
I have a copy of the pdf which once was on AMD's site. I'm not sure it's
there anymore since the Athlon uses an Intel's like APIC (arghhh!, where
'A' does not mean advanced as some would believe, but Awkward IMNSHO).
Besides this, look for documentation in the Motorola Computer Group
website about the boards with Raven and Hawk chipsets, for example the
programmer's guide for MVME2600 and MVME2400 (v2?00*pg*.pdf). The
description is more complete than in openpic.pdf, although there are still
bits which can be toggled and are not documented.
Note that on my machines with OpenPIC I have modified the 8259
interrupt handler to better coexist with the openpic: I have defined
another class of interrupts (struct hw_interrupt_type cascaded_i8259_pic)
to handle the case of a 8259 behind an OpenPIC in a cleaner way.
I also have a few remarks about 8259 interrupt handling introduced in
2.2.12:
a) the previous code worked perfectly AFAICT, was it changed for any
compelling reason (more on this in point d below) ?
b) reading the IRR (masked by the IMR to avoid calling disabled
interrupts) will work for level triggered interrupt but not necessary
for edge triggered ISA interrupts because the current code never sets
the corresponding ISR bit AFAICT. If you read any 8259 documentation,
you will find that the edge detection logic is reset only when the ISR
bit is set (i.e wit a poll command or an interrupt acknowledge cycle):
this causes a problem if a device generates edge triggered interrupt
with a low going pulse.
Guess what, that's exactly what the standard parallel port does since
the IRQ line follows the ACK signal from the interface (and also what a
number of ISA boards do from what I saw on a scope a few years ago);
this might result in interrupt storms (I can't test it right now but
will be able soon, just some time to find this damn connector and to
trigger interrupts).
c) I'm not totally convinced that the are no subtle coherency problems
with ISA DMA tranfers to main memory: when are the ISA DMA buffers
flushed in the bridge ? The device who has finished might raise the
interrupt request while the data is still in the PCI<->ISA bridge, then
a PCI interrupt acknowledge or a poll command must flush the buffers
for coherency reasons, I'm not sure only reading the IRR will have the
same effect (this depends on bridge design details and bugs in this
area would not be surprising).
d) there are actually 2 ways to read the 8259 interrupt vector: use the
poll method as previously done (although a careful reading of the 8259
spec shows that the high bit says whether an interrupt is present or
not: no need to perform additional checks for spurious interrupts) or
performing an access to the address which translates the access into
a PCI interrupt acknowledge cycle. MPC105/106.../GG2/Raven/Hawk
also support this method, so why not use it ? I've used both and they
work fine for me, of course I'm not sure that they will work perfectly
for everybody.
Note that I always rated the 8259 as the worst ever designed chip
(especially if you factor in the complexity/functionality ratio)..., until
Intel succeeded in surpassing themselves with the IO-APIC :-)
> Anyone knows if such a doc exist ? Apparently, if the register map is not
> completely bogus, the current code returns an OpenPIC versio 1.2, and the
> timer freq is 0x80000000 (ouch !).
The version number looks correct, but are you sure of the timer frequency
address ? 0x80000000 is the power up value of all the vector/priority
registers while the power up value of the timer frequency is 0, so this
looks suspiscious.
> Side note: the Keylargo IC contains the open-pic and the SCC cells at the
> exact same location as Hydra, things don't change so much ;) But the new
> chip contains a lot new things.
>
> The Uni-North is a rather weird beast. It appears in the device tree as 4
> devices on the root level:
>
> /uni-n (the memory controller part)
> /pci
> /agp stuffs
> /ATI
> /pci
> /mac-io (KeyLargo is here)
> /usb
> (/slots ?)
> /pci
> /ethernet
> (/firewire on some machines)
>
> All 3 "pci" nodes corresponding apparently to the various internal
> busses: the AGP, the ethernet/firewire, and the mac-io/usb, I beleive the
> external pci is on the mac-io/usb part).
It must be on same (sub)part as the key-largo (otherwise you would need 2
PCI buses, which means even more pins...).
> The annoying thing is that all the 3 pci nodes have the same bus number.
> (devices below those have various non-conflicting device number) but all
> 3 has different pairs of registers to access config space. This makes the
> config access code a bit weird since it has to lookup the OF node of the
> device in the device tree, get the parent "pci" node, etc... but It
> should work this way.
Oh well, as long as the RTAS handles this properly...
And why make things simple when they can be made awkward ?
Regards,
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: need Open PIC infos
1999-10-16 17:14 need Open PIC infos Benjamin Herrenschmidt
1999-10-17 14:16 ` Geert Uytterhoeven
1999-10-22 2:41 ` need Open PIC infos (and more) Gabriel Paubert
@ 1999-10-25 1:17 ` Troy Benjegerdes
2 siblings, 0 replies; 6+ messages in thread
From: Troy Benjegerdes @ 1999-10-25 1:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Benjamin Herrenschmidt wrote:
>
> Hi !
>
> I'm working on support for new UMA machines (beginning with iBook). I
> have already figured out a lot of things and am now coding a very
> preliminary support (I'm not sure yet the PMU99 will work out of the box
> or not, but it looks similar to the old PMU from an interface point of view).
>
> However, the new Apple ASICs contains an Open PIC interrupt controller
> (advertised as beeing a "chrp,open-pic" controller). After looking at the
> various docs I have and a quick search on Altavista, I couldn't find any
> relevant documentation on the chip.
> There's already some OpenPIC support in the kernel, but I'll have to
> change it a little bit since, for example, Apple hardware is not a good
> place to search for a 8259 master ;)
> I'd like some docs in order to have better understanding of the chip.
>
> Anyone knows if such a doc exist ? Apparently, if the register map is not
> completely bogus, the current code returns an OpenPIC versio 1.2, and the
> timer freq is 0x80000000 (ouch !).
You might try the programmers manual for the Motorola MTX series
motherboard, which has an OpenPIC (and an 8259, unfortunately). I believe
arch/ppc/kernel/openpic.c is a mostly complete implementation. Last I
checked (about kernel 2.2.5 or so) the only major thing missing was some
interprocessor interrupt support.
If you haven't already, you might check out the PReP and CHRP specific
kernel code, since both CHRP and some PReP machines use it.
Hope this helps.
Troy-- Anxiously awaiting a Sawtooth G4 to start hacking on
--
--------------------------------------------------------------------------
| Troy Benjegerdes | troy@blacklablinux.com | hozer@drgw.net |
| Unix is user friendly... You just have to be friendly to it first. |
| This message composed with 100% free software. http://www.gnu.org |
--------------------------------------------------------------------------
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 6+ messages in thread