Eric,
From my memory of the LXNI visit, the pci_domain represents different
ways to access PCI CS (0xcf8, 0xcfc). So the very low level of PCI access method will be different depends on the domain. Now the question is why not the pci_set_method() a device method of the PCI_DOMAIN device ? It is in the hardwarmain() now.
Ollie
Li-Ta Lo ollie@lanl.gov writes:
Eric,
From my memory of the LXNI visit, the pci_domain represents different
ways to access PCI CS (0xcf8, 0xcfc). So the very low level of PCI access method will be different depends on the domain. Now the question is why not the pci_set_method() a device method of the PCI_DOMAIN device ? It is in the hardwarmain() now.
Because no one has done the work :)
The immediate reason for introducing the concept was so that we would not need to override the root device methods, as chipsets have different requirements when scanning their busses.
pci_set_method is not something that we really want as a method. Because if we know what the hardware is we don't need to auto-detect the method. Although having scanbus call pci_set_method may not be the worst way to go.
I suspect what we want is a pci_read/write_config... set of methods that the code will keep looking to parent busses to provide if the current bus not provide the operations.
An alternative is to provide pci_read/write_config.... methods that also take a domain parameter. And just have the northbridge provide those.
The practical case where something like this comes soon is accessing the extra configuration bytes from pci-express devices.
So my immediate suggestion would be to call pci_set_method from the pci_domain's scan_bus method before it does anything. We can worry about the rest later.
Eric
On Wed, 2004-11-03 at 15:51, Eric W. Biederman wrote:
So my immediate suggestion would be to call pci_set_method from the pci_domain's scan_bus method before it does anything. We can worry about the rest later.
Isn't the root_dev::scan_bus() called before pci_domain::scan_bus() ? What if root_dev::scan_bus() wants to access PCI CS ?
Ollie
Li-Ta Lo ollie@lanl.gov writes:
On Wed, 2004-11-03 at 15:51, Eric W. Biederman wrote:
So my immediate suggestion would be to call pci_set_method from the
pci_domain's
scan_bus method before it does anything. We can worry about the rest later.
Isn't the root_dev::scan_bus() called before pci_domain::scan_bus() ?
Yes but it uses scan_static_bus()
What if root_dev::scan_bus() wants to access PCI CS ?
Currently that sounds like a bug. I am starting to go through the code now. If I don't see any problems I will make this change.
Hopefully I can get most of the tree compiling...
Eric
On Wed, 2004-11-03 at 16:19, Eric W. Biederman wrote:
Li-Ta Lo ollie@lanl.gov writes:
On Wed, 2004-11-03 at 15:51, Eric W. Biederman wrote:
So my immediate suggestion would be to call pci_set_method from the
pci_domain's
scan_bus method before it does anything. We can worry about the rest later.
Isn't the root_dev::scan_bus() called before pci_domain::scan_bus() ?
Yes but it uses scan_static_bus()
But the mainboard::enable_dev() updatea the root_dev::scan_bus(), if I am right. So the mainboard::scan_bus() will be called before pci_domain::scan_bus().
Ollie
Li-Ta Lo ollie@lanl.gov writes:
On Wed, 2004-11-03 at 16:19, Eric W. Biederman wrote:
Li-Ta Lo ollie@lanl.gov writes:
On Wed, 2004-11-03 at 15:51, Eric W. Biederman wrote:
So my immediate suggestion would be to call pci_set_method from the
pci_domain's
scan_bus method before it does anything. We can worry about the rest
later.
Isn't the root_dev::scan_bus() called before pci_domain::scan_bus() ?
Yes but it uses scan_static_bus()
But the mainboard::enable_dev() updatea the root_dev::scan_bus(), if I am right. So the mainboard::scan_bus() will be called before pci_domain::scan_bus().
I am not arguing that you cannot arrange a scenario where it cannot happen. And an enable_dev method may be a slightly more appropriate place to set the pci_ops than early in scan_bus. What I am arguing is that I believe we have no remaining code that sanely does that. And that for the future it can be as simple as saying don't do that then.
The only case I remember leaving code that looked like was in emulation/qemu-i386 and that was because I thought it did not define a northbridge. Since even that code defines a northbridge I don't for see any problems. I am going to examine all of the mainboard code though and actually look to see what is going on.
An advantage of doing this is that with just a little work I can not even compile in support for the unused configuration type which should keep the code a little smaller.
Eric
On Wed, 2004-11-03 at 17:31, Eric W. Biederman wrote:
Li-Ta Lo ollie@lanl.gov writes:
On Wed, 2004-11-03 at 16:19, Eric W. Biederman wrote:
Li-Ta Lo ollie@lanl.gov writes:
On Wed, 2004-11-03 at 15:51, Eric W. Biederman wrote:
So my immediate suggestion would be to call pci_set_method from the
pci_domain's
scan_bus method before it does anything. We can worry about the rest
later.
Isn't the root_dev::scan_bus() called before pci_domain::scan_bus() ?
Yes but it uses scan_static_bus()
But the mainboard::enable_dev() updatea the root_dev::scan_bus(), if I am right. So the mainboard::scan_bus() will be called before pci_domain::scan_bus().
I am not arguing that you cannot arrange a scenario where it cannot happen. And an enable_dev method may be a slightly more appropriate place to set the pci_ops than early in scan_bus. What I am arguing is that I believe we have no remaining code that sanely does that. And that for the future it can be as simple as saying don't do that then.
Hmm. you removed all mainboard:enable_dev(). Now there are much few code.
Ollie
On Thu, 4 Nov 2004, Li-Ta Lo wrote:
Hmm. you removed all mainboard:enable_dev(). Now there are much few code.
Ollie, I'm hoping you are saying this is good. :-)
I'm pretty happy about all the code-ectomy that the changes have allowed ...
ron
"Ronald G. Minnich" rminnich@lanl.gov writes:
On Thu, 4 Nov 2004, Li-Ta Lo wrote:
Hmm. you removed all mainboard:enable_dev(). Now there are much few code.
Ollie, I'm hoping you are saying this is good. :-)
I'm pretty happy about all the code-ectomy that the changes have allowed ...
I wasn't going to do it on the HDAMA but when I noticed how many ports had copied my debugging code I figured I needed a good example.
The northbridge code was almost equally simplified. For the pci_domains I have been able to describe all of their resources subtractively Which means all of the heavy lifting and resource assignment is done elsewhere. And more importantly for the K8. It allows all of the bridge resources to be assigned independently.
Eric
On Thu, 2004-11-04 at 12:18, Eric W. Biederman wrote:
"Ronald G. Minnich" rminnich@lanl.gov writes:
On Thu, 4 Nov 2004, Li-Ta Lo wrote:
Hmm. you removed all mainboard:enable_dev(). Now there are much few code.
Ollie, I'm hoping you are saying this is good. :-)
I'm pretty happy about all the code-ectomy that the changes have allowed ...
I wasn't going to do it on the HDAMA but when I noticed how many ports had copied my debugging code I figured I needed a good example.
The northbridge code was almost equally simplified. For the pci_domains I have been able to describe all of their resources subtractively Which means all of the heavy lifting and resource assignment is done elsewhere. And more importantly for the K8. It allows all of the bridge resources to be assigned independently.
For some reason you didn't convert the tyan/s2875/mainboard.c. Did you just miss it?
Ollie
Eric
Li-Ta Lo ollie@lanl.gov writes:
For some reason you didn't convert the tyan/s2875/mainboard.c. Did you just miss it?
That sounds like what happened. s2875 does not sound at all familiar.
Eric
-
ebiederman＠lnxi.com -
Li-Ta Lo -
Ronald G. Minnich