PCI: fix cardbus and sriov regressions
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 20110620214127.GA22917@ram-laptop
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hello RP,
unfortunately i noticed the discussion on linux-kernel ML a bit late, as i did not subscribe it due to the traffic.
Did you get further with the unusual alignment?
Even if i did not see any problems (i did not test the CardBus slot but only the sdhci_pci), i wonder if the register layout of some adapters would get into problems with this alignment shown below?!?
Regards,
Oliver
ps. pls put me in CC in the next patch servies. tnx
Quoted 26 lines · Oliver Hartkopp
Quoted 15 lines
Quoted 15 lines
When comparing the logs with mgdiff, i found
in revered:
pci_bus0000:04: resource 0 [io 0x2000-0x20ff]pci_bus0000:04: resource 1 [io 0x2400-0x24ff]in the fixed version (4 patches)
pci_bus0000:04: resource 0 [io 0x2400-0x24ff]pci_bus0000:04: resource 1 [io 0x2001-0x2100]Don't you think that the ressource 0x2001-0x2100 looks a bit weird?
Quoted 8 lines
Quoted 1 line
off-by-one problem?
The resource location has slid by 1. That is because a reassign of resource unfortunately does not let me realign it at the same location.
ALIGN()macro is causing that weirdness.However is that slide by 1 causing you any problem?
No. I don't have a PCMCIA card here to test but the SD-Card is working properly. I just wondered about the unusual alignment ...
Quoted 4 lines · Oliver Hartkopp
Hello RP,
unfortunately i noticed the discussion on linux-kernel ML a bit late, as i did not subscribe it due to the traffic.
sorry, did not see this mail earlier.
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
When comparing the logs with mgdiff, i found
in revered:
pci_bus0000:04: resource 0 [io 0x2000-0x20ff]pci_bus0000:04: resource 1 [io 0x2400-0x24ff]
Quoted 6 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
in the fixed version (4 patches)
pci_bus0000:04: resource 0 [io 0x2400-0x24ff]pci_bus0000:04: resource 1 [io 0x2001-0x2100]Did you get further with the unusual alignment?
No. i was thinking this alignment should be ok, since that cardbus resource has to be SIZE aligned and not START aligned.
However if it is not acceptable, i will figure out a way to get it aligned on the right boundaries.
RP
Quoted 21 lines · Ram Pai
Quoted 4 lines · Oliver Hartkopp
Hello RP,
unfortunately i noticed the discussion on linux-kernel ML a bit late, as i did not subscribe it due to the traffic.
sorry, did not see this mail earlier.
Quoted 12 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
When comparing the logs with mgdiff, i found
in revered:
pci_bus0000:04: resource 0 [io 0x2000-0x20ff]pci_bus0000:04: resource 1 [io 0x2400-0x24ff]in the fixed version (4 patches)
pci_bus0000:04: resource 0 [io 0x2400-0x24ff]pci_bus0000:04: resource 1 [io 0x2001-0x2100]
Quoted 7 lines
Quoted 1 line
Did you get further with the unusual alignment?
No. i was thinking this alignment should be ok, since that cardbus resource has to be SIZE aligned and not START aligned.
However if it is not acceptable, i will figure out a way to get it aligned on the right boundaries.
I'm not sure how drivers expect to access the register layouts of their specific hardware. E.g. if you have a 32-bit register at the beginning of the io resource and the driver accesses this with a 32-bit write operation, the misalignment would be handled (by the CPU) very expensive at runtime, which is definitely a big drawback in performance. I know the networking people re-arranging structs to get less cycles in accessing data structures ...
I tried to understand the reason for the original commit in 3.0.0-rc1 that broke my system - very ambitious :-)
But IMHO you should meet analogue starting boundaries as we had before to make sure that you don't brake things on machines that did not show up yet.
Best regards,
Oliver
[+linux-pci again]
Quoted 21 lines · Ram Pai
Quoted 4 lines · Oliver Hartkopp
Hello RP,
unfortunately i noticed the discussion on linux-kernel ML a bit late, as i did not subscribe it due to the traffic.
sorry, did not see this mail earlier.
Quoted 12 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
When comparing the logs with mgdiff, i found
in revered:
pci_bus0000:04: resource 0 [io 0x2000-0x20ff]pci_bus0000:04: resource 1 [io 0x2400-0x24ff]in the fixed version (4 patches)
pci_bus0000:04: resource 0 [io 0x2400-0x24ff]pci_bus0000:04: resource 1 [io 0x2001-0x2100]
Quoted 7 lines
Quoted 1 line
Did you get further with the unusual alignment?
No. i was thinking this alignment should be ok, since that cardbus resource has to be SIZE aligned and not START aligned.
However if it is not acceptable, i will figure out a way to get it aligned on the right boundaries.
Does the bridge leading to bus 04 really support a window starting at 0x2001?
I assume this is a CardBus bridge because it has two I/O windows. My interpretation of the MindShare CardBus book (I don't have the PC Card Standard) is that the low two bits of the I/O base address register tell you whether 16- or 32-bit addressing is supported (00b means 16-bit decoding is used, 01b means 32-bit decoding is used), and that the actual window starts on a four-byte aligned address.
If that's correct, an I/O base register containing 0x2001 would mean a window starting at 0x2000 and supporting 32-bit decoding, and it would be impossible to have a window starting at 0x2001, i.e., one that contains 0x2001 but not 0x2000.
Bjorn