Sandpoint added to 2_5 tree

Sandpoint added to 2_5 tree

[Mark A. Greer]

For those of you with sandpoints, there has been sandpoint support
pushed out into the 2_5 tree.  It requires the patch at:
ftp://ftp.mvista.com/pub/Area51/sandpoint/sp_patch_2_5

You will get an [intentional] compile error without the patch.

Please give it a try and see how it works.

Mark


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

Re: Sandpoint added to 2_5 tree

[Dan Malek]

"Mark A. Greer" wrote:
>
> For those of you with sandpoints, there has been sandpoint support
> pushed out into the 2_5 tree.  It requires the patch at:
> ftp://ftp.mvista.com/pub/Area51/sandpoint/sp_patch_2_5

This is a "don't touch yourself", right?  Shouldn't this be generally
useful (or required)?  Why don't other architectures have this
problem and can we create a generic solution (i.e. we shouldn't have
to hard-code the device number)?

Thanks.

	-- Dan

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

Re: Sandpoint added to 2_5 tree

[Matt Porter]

On Wed, Mar 07, 2001 at 10:07:21PM -0500, Dan Malek wrote:
>
> "Mark A. Greer" wrote:
> >
> > For those of you with sandpoints, there has been sandpoint support
> > pushed out into the 2_5 tree.  It requires the patch at:
> > ftp://ftp.mvista.com/pub/Area51/sandpoint/sp_patch_2_5
>
> This is a "don't touch yourself", right?  Shouldn't this be generally
> useful (or required)?  Why don't other architectures have this
> problem and can we create a generic solution (i.e. we shouldn't have
> to hard-code the device number)?

The generic solution has already been proposed on the commit list
in some other thread.  My PCI "exception" system would provide a
system to take care of this (among other things).  In the case of
a "don't touch" exception you have to have bus and devfn. Of course,
bus doesn't mean much since it's abstracted in multi hose systems.
Now, ideally we would use an IDSEL path/tree to uniquely identify a
device and eventually couple that with a hose identifier since it's
possible to have duplicate IDSEL chains on two separate hoses.

For the first cut, I'm just using bus/devfn to identify the device.
The exceptions can be registered as part of a device driver or
in the arch/ppc/ bringup code, wherever is the logical place
to put it.  In the case of the Sandpoint's problem (feature),
the exception should be registered in sandpoint_pci.c since it's
board specific.

Anyway, the kludge is all we should do for now...

Oh, and yes I'm planning to show the code when I make enough time to
finish it...

--
Matt Porter
mmporter@home.com
This is Linux Country. On a quiet night, you can hear Windows reboot.

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

Re: Sandpoint added to 2_5 tree

[Mark A. Greer]

Dan Malek wrote:

> "Mark A. Greer" wrote:
> >
> > For those of you with sandpoints, there has been sandpoint support
> > pushed out into the 2_5 tree.  It requires the patch at:
> > ftp://ftp.mvista.com/pub/Area51/sandpoint/sp_patch_2_5
>
> This is a "don't touch yourself", right?  Shouldn't this be generally
> useful (or required)?  Why don't other architectures have this
> problem and can we create a generic solution (i.e. we shouldn't have
> to hard-code the device number)?

Yes, its the "don't touch yourself" problem with 824x & 107 bridges.
Most boards don't have the IDSEL wired up so its not an issue for them.
I expect more & more people to start wiring it up, though, so I think it
will become more of an issue.

Yes, there should be some general feature for skipping PCI slots, it
just doesn't exist yet.  There are 2 places that this skip needs to be
put in, drivers/pci/pci.c and arch/ppc/kerner/pci_auto.c.  I chose to
make a patch instead of cluttering up those files (plus the
drivers/pci/pci.c #ifdef would probably never be accepted into
kernel.org).

Matt Porter has a scheme for doing the skipping (plus other stuff), he
just hasn't had the time to do it yet.

Mark


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