[PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.

Gabriel Paubert paubert at iram.es
Sun Jun 3 20:10:52 EST 2007


On Sun, Jun 03, 2007 at 10:57:59AM +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 ;-)
> 
> 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.
> 

Thanks for this explanation.

> 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.

Maybe, but it ultimately has to go the mpic, no?
I can see how the cascade of interrupt parents and 
other specifications could lead there.

> 
> >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 ;-)

That maybe the best explanation.

> 
> >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 is a way to fetch the vector from the interrupt controller.
Among all the types of cycles defined by PCI (configuration,
I/O and memory spaces read and write), there is one which 
is generated by the host bridge when an x86 processor 
acknowledges an interrupt (it has changed with the APIC
and IO-APIC where "A" stands for awkward IMO[1]).

The sequence of events is the following:
- an interrupt is raised
- when switching to the interrupt handler, the
  processor generates a special bus cycle
- this is translated by the host bridge into
  a PCI interrupt acknowledge cycle
- one and only one agent on the bus behind the host bridge
  (this cycle is not propagated by P2P bridges) answers
  by placing a byte sized interrupt vector on the bus.
- this vector is used by the processor to index into the 
  interrupt descriptor table and starts execution wherever
  it is told to go.

Generating a pci interrupt acknowledge cycle is a faster 
way to get at the vector than doing this explicitly in
the controller: a simple byte fetch instead of 2 or
4 I/O accesses guardered by a lock acquisition and
release.

If you need more details, ask me.

Now a question: how would you describe the nvram and RTC
on the PreP boards that I have?

In the residual data I have:

ISA Device, Slot 0, LogicalDev 0: IBM0008, SystemPeripheral, NVRAM, #-1, IndirectNVRAM
  Device flags 2800: Integrated, Static
  Packets describing allocated resources:
    Variable (16 decoded bits) I/O port
      from 0x0074 to 0x0074, alignment 1, 2 ports
    Variable (16 decoded bits) I/O port
      from 0x0077 to 0x0077, alignment 1, 1 ports
  No packets describing possible resources.
  No packets describing compatible resources.
ISA Device, Slot 0, LogicalDev 0: PNP0B00, SystemPeripheral, RealTimeClock, #-1, interface 129
  Device flags 2800: Integrated, Static
  Packets describing allocated resources:
    Variable (16 decoded bits) I/O port
      from 0x0074 to 0x0074, alignment 1, 2 ports
    Variable (16 decoded bits) I/O port
      from 0x0077 to 0x0077, alignment 1, 1 ports
    Chip identification: MOT3040
    Small vendor item type 0x00, data (hex): 01 f8 1f 00 00 
  No packets describing possible resources.
  No packets describing compatible resources.

It is the same chip that has the NVRAM and the RTC, only that 
the last 8 bytes of the NVRAM change with time. I've not found
the last "Small vendor item" described in any doc, but it looks
like a byte of 1, followed by the offset of the RTC inside the 
NVRAM in little-endian byte order.

But essentially the problem is that I have two logically 
different devices in the same chip. Of course the size of
the nvram should be somewhere (8k-8, starting at 0).


	Gabriel


[1] Read the last paragraph of http://lkml.org/lkml/2006/11/1/294, 
and I believe that it is an understatement. There are also Linus'
rants about handling of edge triggered interrupts in APIC: it's
fairly easy to lose them, that's what cutting-edge (pun intended)
innovation is :-)



More information about the Linuxppc-dev mailing list