Re: EV-64260-BP & GT64260 bi_recs

On Sun, Mar 24, 2002 at 01:20:48PM +0100, Benjamin Herrenschmidt wrote:

What I now want to do is to keep the exising scheme for most
informations (that is a flat list of bi_recs), with only one
exception that doesn't affect the current parsing code, only

            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I like this part!

<A bunch of stuff about various ways to identify driver specific
bi_recs>

What do you think ?

I like the general idea - have a bunch of bi_recs that the kernel
ignores, and then define a driver interface to easily get that
information.

I would like a simpler, more generic interface between drivers and
bi_recs.  The model is this: Firmware creates a top-level bi_rec and
puts something in it.  When the driver wants to get the information,
it calls:

  my_bi_rec = bi_find_id(NULL, BI_SOME_ID);

This gives it a pointer to the top-level bi_rec containing its info.
If the firmware put more bi_recs inside that bi_rec, the driver calls:

  my_other_bi_rec = bi_find_id(&(my_bi_rec->data), BI_SOME_OTHER_ID);

Basically, don't create special cases, just treat the generic case of
a driver and a bootloader and some information you want to pass
between them.  I don't like BI_DEVICE, I do like BI_NOT_FOR_THE_KERNEL
or something shorter but equivalent. :)

I'm happy to hear reasons for why a more complicated interface is a
good idea.

-VAL

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Basically, don't create special cases, just treat the generic case of
a driver and a bootloader and some information you want to pass
between them.  I don't like BI_DEVICE, I do like BI_NOT_FOR_THE_KERNEL
or something shorter but equivalent. :)

I'm happy to hear reasons for why a more complicated interface is a
good idea.

Ok, so first, the generic case is there as you can always stuff
things inside a toplevel bi_rec and use bi_find within that.

The point of BI_DEVICE is to standardize a bit the interface
between known drivers and the bootloader. Your scheme would
require each device on my board to have a different bi_rec,
which will lead into proprietary stuff & more driver patching.

For example, let's say we fix some "common" ethernet drivers
like pcnet32, tulip, etc... to be able to locate a bi_rec
for a BI_DEV_TYPE_PCI based on the bus/devfn and use the HW
address in there. Once that's done, no kernel/driver change
is needed, even if you happen to have 3 instances of the
ethernet chip on your PCI bus, just pass the appropriate infos
from the bootloader. Of course, this is mostly useful for
embedded cases where the PCI device is wired, not in a slot.

Also, a set BI_DEV_TYPE_PCI with just a BI_IRQ_NUMBER
(no indication of the device class/name) can also be used
to provide the PCI interrupt routing for PCI slots, though
in this specific case, I'd prefer seeing the firmware fill
the PCI_INTERRUPT_LINE register in the config space and the
kernel retreive that.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Tue, 26 Mar 2002 benh@kernel.crashing.org wrote:

Also, a set BI_DEV_TYPE_PCI with just a BI_IRQ_NUMBER
(no indication of the device class/name) can also be used
to provide the PCI interrupt routing for PCI slots, though
in this specific case, I'd prefer seeing the firmware fill
the PCI_INTERRUPT_LINE register in the config space and the
kernel retreive that.

Won't fly, this is a byte wide register and there are machines with more
than 256 interrupt lines. And they are even more likely with PCI 2.2+ so
called message passing interrupts, which is a simple way to admit that the
way of doing interrupts was so dumb that even (one physical PCB trace per
vector) the Cro-Magnon man would have done better

Basically, PCI is going to implement interrupts in the way similar to waht
VME/m68k (and even Z80) hardware have done for over 25 years. The
electrical details are different, but it is the device that puts the
interrupt vector on the bus, not some PIC (where P stands for
paleolithic) through a maze of PCB traces.

BTW, I don't even allow sharing VME interrupt vectors in my PCI<->VME
bridge driver, because I have something like 1792 (7*256) separately
identifiable interrupt sources.

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Won't fly, this is a byte wide register and there are machines with more
than 256 interrupt lines. And they are even more likely with PCI 2.2+ so
called message passing interrupts, which is a simple way to admit that the
way of doing interrupts was so dumb that even (one physical PCB trace per
vector) the Cro-Magnon man would have done better

Well, I would expect such machines to have a device-tree :) Anyway, a
bi_rec would indeed help if really needed here but again, it's optional
and I would expect embedded not to require it for PCI routing.

Basically, PCI is going to implement interrupts in the way similar to waht
VME/m68k (and even Z80) hardware have done for over 25 years. The
electrical details are different, but it is the device that puts the
interrupt vector on the bus, not some PIC (where P stands for
paleolithic) through a maze of PCB traces.

BTW, I don't even allow sharing VME interrupt vectors in my PCI<->VME
bridge driver, because I have something like 1792 (7*256) separately
identifiable interrupt sources.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/