[LinuxBIOS] PCI max buses patch

[Richard Smith]

The following patch adds a CONFIG_MAX_PCI_BUSES to pci_locate_device()

It defaults to 5 buses which should be plenty for 99% of us.

I only added the actual option to the epia-m config but the global
defaut should pickup for all the other boards.

Please someone apply and auto-build to see if I broke anything.  If
not then I'll commit.

[yhlu]

why?

we already have
pci_locate_device().
pci_locate_device_on_bus(...unsigned bus).

you may add
pci_locate_device_before_bus(...unsigned bus).

YH

On 4/21/06, Richard Smith  wrote:
> The following patch adds a CONFIG_MAX_PCI_BUSES to pci_locate_device()
>
> It defaults to 5 buses which should be plenty for 99% of us.
>
> I only added the actual option to the epia-m config but the global
> defaut should pickup for all the other boards.
>
> Please someone apply and auto-build to see if I broke anything.  If
> not then I'll commit.

[LinuxBIOS] PCI max buses - Simple solution

[Stefan Reinauer]

* yhlu  [060422 06:37]:
> we already have
> pci_locate_device().
> pci_locate_device_on_bus(...unsigned bus).

Cool! I guess most of us just did not know about that.

static device_t pci_locate_device_on_bus(unsigned pci_id, unsigned bus)

is defined in romcc_io.h and does exactly what is needed in this case.
Firewire on the Epia is always on bus 0.

Stefan

[LinuxBIOS] PCI max buses - Simple solution

[Richard Smith]

On 4/22/06, Stefan Reinauer  wrote:
> yhlu  [060422 06:37]:
> > we already have
> > pci_locate_device().
> > pci_locate_device_on_bus(...unsigned bus).
>
> Cool! I guess most of us just did not know about that.
>
> static device_t pci_locate_device_on_bus(unsigned pci_id, unsigned bus)
>
> is defined in romcc_io.h and does exactly what is needed in this case.
> Firewire on the Epia is always on bus 0.

Ok so the "right" solution for the epia-m is to change
pci_locate_device() to pci_locate_device_on_bus(0);

Eric:  Please confirm that it fixes your problem.

That still leaves the outstanding issue that pci_locate_device() will
pause for long periods if it can't find a device.  And probing the
entire pci space may not be a good thing anyway.

I would propose that pci_locate_device still needs a hard cap.

Whats the maximum number of PCI buses that any one has ever seen on one board?

[LinuxBIOS] PCI max buses - Simple solution

[yhlu]

For K8, I put second chain on 0x40, third chain on 0x80, and fourth
chain on 0xc0.

YH

On 4/22/06, Richard Smith  wrote:
> On 4/22/06, Stefan Reinauer  wrote:
> > yhlu  [060422 06:37]:
> > > we already have
> > > pci_locate_device().
> > > pci_locate_device_on_bus(...unsigned bus).
> >
> > Cool! I guess most of us just did not know about that.
> >
> > static device_t pci_locate_device_on_bus(unsigned pci_id, unsigned bus)
> >
> > is defined in romcc_io.h and does exactly what is needed in this case.
> > Firewire on the Epia is always on bus 0.
>
> Ok so the "right" solution for the epia-m is to change
> pci_locate_device() to pci_locate_device_on_bus(0);
>
> Eric:  Please confirm that it fixes your problem.
>
> That still leaves the outstanding issue that pci_locate_device() will
> pause for long periods if it can't find a device.  And probing the
> entire pci space may not be a good thing anyway.
>
> I would propose that pci_locate_device still needs a hard cap.
>
> Whats the maximum number of PCI buses that any one has ever seen on one board?

[LinuxBIOS] PCI max buses - Simple solution

[Richard Smith]

On 4/22/06, yhlu  wrote:
> For K8, I put second chain on 0x40, third chain on 0x80, and fourth
> chain on 0xc0.

Ok so even though there are only 4 buses they are not numbered
consecutively.  Ah..well that changes things a bit then dosen't it?

So then we just need to leave it alone?   So far its only been the
epia-ml that has a problem.

[Ronald G Minnich]

Richard Smith wrote:
> The following patch adds a CONFIG_MAX_PCI_BUSES to pci_locate_device()

sorry I have not been following this discussion more closely. So, the 
basic idea here is that for the romcc part, we rarely need to look on 
high busses for devices? Is that really true?

ron

[Stefan Reinauer]

* Ronald G Minnich  [060423 16:53]:
> sorry I have not been following this discussion more closely. So, the 
> basic idea here is that for the romcc part, we rarely need to look on 
> high busses for devices? Is that really true?

The romcc part is not supposed to "talk" to any non-onboard devices.

The scanning process takes forever in the romcc part. So as long as we
want to claim fast boot we simply _have_ to believe that we dont have to
look at high busses there.

S.

[Ronald G Minnich]

Stefan Reinauer wrote:
> The scanning process takes forever in the romcc part. So as long as we
> want to claim fast boot we simply _have_ to believe that we dont have to
> look at high busses there.

ok, that makes sense to me. I just wanted to make sure I understood it. 
I'm fine with that patch.

ron

[Richard Smith]

On 4/23/06, Ronald G Minnich  wrote:
> Stefan Reinauer wrote:
> > The scanning process takes forever in the romcc part. So as long as we
> > want to claim fast boot we simply _have_ to believe that we dont have to
> > look at high busses there.
>
> ok, that makes sense to me. I just wanted to make sure I understood it.
> I'm fine with that patch.

Its going to break any board that depends on pci_locate_device() to
find things on a high bus.  Is that going to be ok?

A grep for pci_locate_device() shows that its used in a lot of places.

[Ronald G Minnich]

Richard Smith wrote:
> On 4/23/06, Ronald G Minnich  wrote:
> > Stefan Reinauer wrote:
> > > The scanning process takes forever in the romcc part. So as long as we
> > > want to claim fast boot we simply _have_ to believe that we dont have to
> > > look at high busses there.
> >
> > ok, that makes sense to me. I just wanted to make sure I understood it.
> > I'm fine with that patch.
>
> Its going to break any board that depends on pci_locate_device() to
> find things on a high bus.  Is that going to be ok?
>
> A grep for pci_locate_device() shows that its used in a lot of places.

right, but unless I missed the point, that is configurable?

thanks

ron

[Richard Smith]

> right, but unless I missed the point, that is configurable?

Yes.  I've got the default set to 5.  I just wanted to make sure
before I go breaking boards in slient ways.

yulu are you ok with this?

[Ronald G Minnich]

Richard Smith wrote:
> > right, but unless I missed the point, that is configurable?
>
> Yes.  I've got the default set to 5.  I just wanted to make sure
> before I go breaking boards in slient ways.
>
> yulu are you ok with this?

I see the right way to do this is to make the default behaviour the 
'guaranteed no break boards' behaviour. That means default value is to 
scan all busses. For those who need/want it set lower, they can know 
where the config option is.

But we sure oculd use an addiiton to the wiki that explains stuff like this.

make sense?

ron

[Stefan Reinauer]

* Ronald G Minnich  [060423 22:19]:
> I see the right way to do this is to make the default behaviour the 
> 'guaranteed no break boards' behaviour. That means default value is to 
> scan all busses. For those who need/want it set lower, they can know 
> where the config option is.
>
> But we sure oculd use an addiiton to the wiki that explains stuff like this.
>
> make sense?

perfect sense.

[Richard Smith]

> I see the right way to do this is to make the default behaviour the
> 'guaranteed no break boards' behaviour. That means default value is to
> scan all busses. For those who need/want it set lower, they can know
> where the config option is.

Ok. I'll change the default to be 255 and commit.
> But we sure oculd use an addiiton to the wiki that explains stuff like this.

Any ideas on a section title and how we would lay it out?  There is
already the linuxBIOS options but its largly incomprehensible to a
newbe.

There is a disconnect between the lasting info that gets on the wiki
and all the discussion on the mailing list.  We need some method to
catagorize all the discussions on the list into something searchable
by mailboard or perhaps chipset.

[Ronald G Minnich]

Richard Smith wrote:
> > I see the right way to do this is to make the default behaviour the
> > 'guaranteed no break boards' behaviour. That means default value is to
> > scan all busses. For those who need/want it set lower, they can know
> > where the config option is.
>
> Ok. I'll change the default to be 255 and commit.
> > But we sure oculd use an addiiton to the wiki that explains stuff like this.
>
> Any ideas on a section title and how we would lay it out?  There is
> already the linuxBIOS options but its largly incomprehensible to a
> newbe.
>
> There is a disconnect between the lasting info that gets on the wiki
> and all the discussion on the mailing list.  We need some method to
> catagorize all the discussions on the list into something searchable
> by mailboard or perhaps chipset.

I'd say a preprocessor of some sort that can take the Options.lb and 
produce latex. Furthermore, we can add "hints" to Options.lb such as 
"you can set the MAX PCI to 5 if you are sure there are no higher 
devices" or some such.

But documents derived from source is probably all we can expect, given 
our time limits.

ron

[yhlu]

That function is only called in auto stage or cache_as_ram_stage....

To support more chains (4 chains ) and make it more dynamical (
installed or not), I need default to be set 255 at this time.

and some time later it will be 0xfff for segment num support and 24
chains or more.

YH

On 4/23/06, Richard Smith  wrote:
> > I see the right way to do this is to make the default behaviour the
> > 'guaranteed no break boards' behaviour. That means default value is to
> > scan all busses. For those who need/want it set lower, they can know
> > where the config option is.
>
> Ok. I'll change the default to be 255 and commit.
> > But we sure oculd use an addiiton to the wiki that explains stuff like this.
>
> Any ideas on a section title and how we would lay it out?  There is
> already the linuxBIOS options but its largly incomprehensible to a
> newbe.
>
> There is a disconnect between the lasting info that gets on the wiki
> and all the discussion on the mailing list.  We need some method to
> catagorize all the discussions on the list into something searchable
> by mailboard or perhaps chipset.