Hello
Somehow I can't access a PCI card on a PowerMac. I once wrote a
driver for this card on MacOS8, but that does not seem to help me so
far.
It's a digital I/O card Computer Boards PCI-DIO96H showing this info
in lspci -vvn:
00:0e.0 Class ffff: 1307:0017 (rev 02) (prog-if ff)
Subsystem: 1307:0017
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 24
Region 1: I/O ports at 0800 [disabled] [size=128]
Region 2: I/O ports at 0880 [disabled] [size=16]
This is what I am doing (irrelevant parts stripped):
error= pci_enable_device(mydevicep);
mybase1_phys= pci_resource_start(dev, 2);
mybase1length= pci_resource_len(dev,2);
// gives: address 0x00000880, len 16
error = pci_request_regions (dev, NAME);
pci_set_master (dev);
mybase1= (unsigned long)ioremap(mybase1_phys,mybase1length);
// gives: 0, while the following is printed to the kernel log:
// __ioremap(): phys addr 0 is RAM lr c0010c34
I have also tried the following:
- pass mybase1_phys to phys_to_virt() (this gave 0xc0000880)
and pass that for ioremap. The latter then returned
address 0xc7898880. But I then got this:
Mar 23 17:09:34 Sensor kernel: Machine check in kernel mode.
Mar 23 17:09:34 Sensor kernel: Caused by (from SRR1=49030): Transfer error ack signal
Mar 23 17:09:34 Sensor kernel: Oops: machine check, sig: 7
(...)
- pass mybase1_phys to phys_to_bus(), but insmod then gives
"unresolved symbol phys_to_bus".
- ~same thing for pci_resource_start(dev, 1) instead of 2.
(- and many further combinations)
Questions:
- What does pci_resource_start return, a phys/virt/bus address?
- What does ioremap expect?
- I'm seeing a special case in the source of the C ioremap() version,
which assumes ISA for an address as low as 0x00000880. Thus it seems
like I have to convert that address? On the other hand, the 8139too
driver which I've glimpsed at does not do any conversion.
- do I need pci_set_master? Which other PCI calls are important?
- where do I find up to date information about handling PCI on linux?
The Documentation/pci.txt and Documentation/IO-mapping.txt files
do not mention many important details.
You can see my code at:
http://pflanze.mine.nu/~chris/linux/sensor/sensor.c
Thanks for your help
Christian.
On Sun, 2003-03-23 at 17:30, Christian Jaeger wrote:
> - What does pci_resource_start return, a phys/virt/bus address?
Normally a pci bus address, but its really a cookie
> - What does ioremap expect?
The same cookie
> - do I need pci_set_master? Which other PCI calls are important?
You need enable_device, and before you touch the others. That should
ensure the hardware is in D0 (active) not powersaving or some other
inconvenience
Basically the logic goes
Ask the pci layer for pci register values
Feed values to ioremap
Get a cookie for use with readb/readw/readl etc
The return of ioremap may be a physical mapping, it might be the
cpu view of the bus address, or something else.
On Sun, 2003-03-23 at 18:30, Christian Jaeger wrote:
> Hello
>
> Somehow I can't access a PCI card on a PowerMac. I once wrote a
> driver for this card on MacOS8, but that does not seem to help me so
> far.
>
> It's a digital I/O card Computer Boards PCI-DIO96H showing this info
> in lspci -vvn:
>
> 00:0e.0 Class ffff: 1307:0017 (rev 02) (prog-if ff)
> Subsystem: 1307:0017
> Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Interrupt: pin A routed to IRQ 24
> Region 1: I/O ports at 0800 [disabled] [size=128]
> Region 2: I/O ports at 0880 [disabled] [size=16]
>
> This is what I am doing (irrelevant parts stripped):
> error= pci_enable_device(mydevicep);
> mybase1_phys= pci_resource_start(dev, 2);
> mybase1length= pci_resource_len(dev,2);
> // gives: address 0x00000880, len 16
> error = pci_request_regions (dev, NAME);
> pci_set_master (dev);
> mybase1= (unsigned long)ioremap(mybase1_phys,mybase1length);
> // gives: 0, while the following is printed to the kernel log:
> // __ioremap(): phys addr 0 is RAM lr c0010c34
According to lspci output, the resources for your card are of type
"IO", not "memory". You use ioremap only for the later.
If you are not sure about the resource type, look at the resource
flags.
So instead of using ioremap along with {read,write}{b,w,l} accessors,
use the output of pci_resource_start() directly with {in,out}{b,w,l}
(and eventually {in,out}s{w,l} for non-byteswapped "stream" access).
Ben.
Thanks for your help, Benjamin and Alan.
It works now, the reason it didn't when I first used inb/outb was
simply that I used the wrong I/O region :o}
Source available for those who are interested at
http://pflanze.mine.nu/~chris/linux/sensor/
Cheers
Christian.