I tried to disable the onboard graphics on my s2892:
device pci 6.0 off end
But that made it probe 6.1 - 6.7. Since the code only checks for multifunction devices at function 0, all of those responded. So now instead of disabling my card, it had 7 instances of it. I realize that the card probably shouldn't have responded to all of those functions, but it probably doesn't bother checking which function is addressed.
device pci 6.0 off end device pci 6.1 off end device pci 6.2 off end device pci 6.3 off end device pci 6.4 off end device pci 6.5 off end device pci 6.6 off end device pci 6.7 off end
This worked, but it is non-obvious. I wonder what the "right" way would be to handle this.
Is there any time when you want to disable function 0 but still have all the other functions enabled/probed?
Thanks, Myles
On Mon, Jul 6, 2009 at 4:03 PM, Myles Watsonmylesgw@gmail.com wrote:
I tried to disable the onboard graphics on my s2892:
device pci 6.0 off end
But that made it probe 6.1 - 6.7. Since the code only checks for multifunction devices at function 0, all of those responded. So now instead of disabling my card, it had 7 instances of it. I realize that the card probably shouldn't have responded to all of those functions, but it probably doesn't bother checking which function is addressed.
device pci 6.0 off end device pci 6.1 off end device pci 6.2 off end device pci 6.3 off end device pci 6.4 off end device pci 6.5 off end device pci 6.6 off end device pci 6.7 off end
This worked, but it is non-obvious. I wonder what the "right" way would be to handle this.
Is there any time when you want to disable function 0 but still have all the other functions enabled/probed?
Myles,
That seems like a defective card but something is strange. Why wouldn't it detect the functions when the first function was enabled?
A PCI cards functions don't have to be related to each other. It is legitimate to disable the first function and expect the others to work.
Marc
That seems like a defective card but something is strange. Why wouldn't it detect the functions when the first function was enabled?
It doesn't probe the other functions when the first function is enabled because it is not a multi-function device. It reads that from the config space and skips to the next slot.
A PCI cards functions don't have to be related to each other. It is legitimate to disable the first function and expect the others to work.
Yeah. That's what I figured. It was just a pain when it quit working, then when it decided to work again. It took a while to figure out what went wrong.
Thanks, Myles
On Tue, Jul 7, 2009 at 9:28 AM, Myles Watsonmylesgw@gmail.com wrote:
That seems like a defective card but something is strange. Why wouldn't it detect the functions when the first function was enabled?
It doesn't probe the other functions when the first function is enabled because it is not a multi-function device. It reads that from the config space and skips to the next slot.
Ah, OK. Maybe we should make the scan a little smarter by checking the device capability and skip to the next device instead of next function.
Marc
On Tue, Jul 7, 2009 at 9:34 AM, Marc Jones marcj303@gmail.com wrote:
On Tue, Jul 7, 2009 at 9:28 AM, Myles Watsonmylesgw@gmail.com wrote:
That seems like a defective card but something is strange. Why wouldn't it detect the functions when the first function was enabled?
It doesn't probe the other functions when the first function is enabled because it is not a multi-function device. It reads that from the config space and skips to the next slot.
Ah, OK. Maybe we should make the scan a little smarter by checking the device capability and skip to the next device instead of next function.
That would work in my situation. I guess I was also asking what it means for a device to be disabled. Does that mean that we don't touch it at all? Should we read config space values from a disabled device?
Maybe it's too much of a corner case to worry about. Disabling all 8 functions isn't too much of a pain.
Thanks, Myles
Myles Watson wrote:
I guess I was also asking what it means for a device to be disabled.
Disabled how? In Config.lb ?
Does that mean that we don't touch it at all? Should we read config space values from a disabled device?
My gut reaction is that reading config space also from disabled devices ought to be OK.
Counter-question: What are the reasons for disabling a device?
//Peter
Myles Watson wrote:
I guess I was also asking what it means for a device to be disabled.
Disabled how? In Config.lb ?
Yes.
Does that mean that we don't touch it at all? Should we read config space values from a disabled device?
My gut reaction is that reading config space also from disabled devices ought to be OK.
Counter-question: What are the reasons for disabling a device?
The reason I'm doing it is the device is flaky. I can't trust what I get back from it. Sometimes it doesn't respond at all. Another reason would be for onboard graphics that you don't want to use.
Thanks, Myles
On Tue, Jul 7, 2009 at 11:16 AM, Myles Watsonmylesgw@gmail.com wrote:
Myles Watson wrote:
I guess I was also asking what it means for a device to be disabled.
Disabled how? In Config.lb ?
Yes.
Does that mean that we don't touch it at all? Should we read config space values from a disabled device?
My gut reaction is that reading config space also from disabled devices ought to be OK.
Counter-question: What are the reasons for disabling a device?
The reason I'm doing it is the device is flaky. I can't trust what I get back from it. Sometimes it doesn't respond at all. Another reason would be for onboard graphics that you don't want to use.
I guess we should be clear. We don't disable the device. We skip it and don't enable the BARs. The device header is still in PCI config space and can be accessed any time.
Marc
On 07.07.2009 22:23, Marc Jones wrote:
On Tue, Jul 7, 2009 at 11:16 AM, Myles Watsonmylesgw@gmail.com wrote:
Myles Watson wrote:
I guess I was also asking what it means for a device to be disabled.
Disabled how? In Config.lb ?
Yes.
I guess we should be clear. We don't disable the device. We skip it and don't enable the BARs. The device header is still in PCI config space and can be accessed any time.
Can't we use a better name for this? Maybe call it "ignore" instead of "disable"?
Regards, Carl-Daniel
I guess we should be clear. We don't disable the device. We skip it and don't enable the BARs. The device header is still in PCI config space and can be accessed any time.
Can't we use a better name for this? Maybe call it "ignore" instead of "disable"?
The disable confusion is my fault. In the Config.lb we turn things "on" or "off". This sets the enabled flag, which makes sense to me. I should have said I turned it off in the Config.lb.
I think crystal clear terminology will be difficult to come up with here.
Thanks, Myles
On 07.07.2009 23:14, Myles Watson wrote:
Can't we use a better name for this? Maybe call it "ignore" instead of "disable"?
The disable confusion is my fault. In the Config.lb we turn things "on" or "off". This sets the enabled flag, which makes sense to me. I should have said I turned it off in the Config.lb.
I think crystal clear terminology will be difficult to come up with here.
I remember having the same problem in v3 dts. Basically, there are four possible states I can think of for devices: 1. Enabled 2. Disabled 3. Ignored 4. Hidden (5. Configured, but enable not touched)
Not all states are possible on all chipsets, but from time to time one of the functions is needed. By the way, we have various problems on SuperI/O chips where we want to configure GPIOs with their own LDN and the constraint is that the usual enable bit must not be set for the GPIO LDN.
Regards, Carl-Daniel
I think crystal clear terminology will be difficult to come up with
here.
I remember having the same problem in v3 dts. Basically, there are four possible states I can think of for devices:
- Enabled
The most common case.
- Disabled
So does this mean "not enabled?"
- Ignored
Meaning that it isn't touched at all.
- Hidden
Meaning that it doesn't respond.
(5. Configured, but enable not touched)
I guess this one is ambiguous to me.
Not all states are possible on all chipsets, but from time to time one of the functions is needed. By the way, we have various problems on SuperI/O chips where we want to configure GPIOs with their own LDN and the constraint is that the usual enable bit must not be set for the GPIO LDN.
I think things like that have to be handled in device-specific code. It seems unlikely that we could handle that correctly from the Config files.
Thanks, Myles
Myles Watson wrote:
I think things like that have to be handled in device-specific code. It seems unlikely that we could handle that correctly from the Config files.
With only on/off, yes, it has to be handled in device-specific code.
Would it make sense to express/expose all different actions in the board configuration? It was there in the v3 dts, just not standardized.
//Peter
On Tue, Jul 7, 2009 at 4:50 PM, Peter Stuge peter@stuge.se wrote:
Myles Watson wrote:
I think things like that have to be handled in device-specific code. It seems unlikely that we could handle that correctly from the Config files.
With only on/off, yes, it has to be handled in device-specific code.
We also have not present fwiw.
Would it make sense to express/expose all different actions in the board configuration?
I don't know which ones. It doesn't seem like a very common case.
It was there in the v3 dts, just not standardized.
Wasn't it handled by the device-specific code based on integer values passed from the dts?
Thanks, Myles
Myles Watson wrote:
With only on/off, yes, it has to be handled in device-specific code.
We also have not present fwiw.
Ok.
Would it make sense to express/expose all different actions in the board configuration?
I don't know which ones. It doesn't seem like a very common case.
Yeah, you're right. Typically everything should be enabled and up.
Motivation would be more to make exceptions easy and clear.
It was there in the v3 dts, just not standardized.
Wasn't it handled by the device-specific code based on integer values passed from the dts?
Right, but it was still moved to board configuration, which forced code to become a bit more general. I liked that.
//Peter
Marc Jones wrote:
It is legitimate to disable the first function and expect the others to work.
No, I don't think so. You need function 0 in order to read the multi-function flag.
Andrew
-
Andrew Goodbody -
Carl-Daniel Hailfinger -
Marc Jones -
Myles Watson -
Peter Stuge