[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-arm-kernel
Subject:    Re: ixdp2850 problems (pci bus scanning/enumeration, etc.)
From:       Lennert Buytenhek <buytenh () wantstofly ! org>
Date:       2005-04-28 10:44:17
Message-ID: 20050428104417.GF28878 () xi ! wantstofly ! org
[Download RAW message or body]

On Wed, Apr 27, 2005 at 08:40:56AM -0400, Daly, Jeffrey wrote:

> > I don't disagree that it's a mess.  Just think of all the issues
> > if one of the CPUs reboots while the other one doesn't.  A
> > nontransparent bridge between the slave and its NIC and the rest
> > of the PCI devices would have been a much better solution.  (The
> > only reason why they didn't do this that I can think of would be
> > the extra latency that it incurs.)
> 
> Also agree.  There were reasons the board was designed the way
> it was (which I won't go into here).  These problems were realized
> quickly when I started working with Deepak to get Linux 2.4 working.
> We attempted to ameliorate the issues by putting a 21555 between the
> 2 NPU 'clusters' on the next design we did.  Since the ixdp28x0 is a
> development platform (the 'DP' in IXDP) intending to showcase the
> capabilities of the microengines and allow rapid early microcode
> development rather showing off the Xscale cores we weren't able to
> go back and redesign it.

Understandable.  I've mostly seen the IXDP2800 being used in lab-type
environments, and most IXDP2800 users (as opposed to kernel developers)
aren't going to care very much that rebooting might not always work
very well.


> >- Make the slave CPU scan the bus but not size the BARs.  Not knowing
> >  the BAR sizes probably will cause problems when subsequently trying
> >  to talk to any of the PCI devices.
> 
> The device drivers for the NICs 'know' the registers they want to
> talk to, so having a base address is all they need.

PCI drivers are free to use pci_resource_len(dev, nr), which returns
the size of one of the device's BARs, to figure out how much address
space to map in.  The eepro100 driver is one driver that uses this.
(The e100 driver doesn't.. yet.)


> Hopefully these issues aren't keeping people from making real
> progress on IXP28x0 Linux development...

Don't think so.  I think my last patch is a good compromise -- it
makes the normal bootup work, and doesn't try to fix the cases that
are not really fixable anyway (given the current hardware design)
without a lot of extra work, such as one NPU rebooting while the
other one doesn't.


cheers,
Lennert

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:       http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php
[prev in list] [next in list] [prev in thread] [next in thread]