Re: PCI lib for 2.4

Re: PCI lib for 2.4

[Damien Couroussé]

Hi,

Actually, it will be first a user-space driver.

Maybe I wasn't clear:

I link the PCI library with '-lpci' option, but it seems the library is 
not complete, ie I can't use the whole lib. For example, the compiler 
cannot link pci_resource_start() func. or pci_fond_device(). I think 
these are usually in all pci libraries... My lib does not support dma 
abilities too.

My problem is that I have several pci.h files which contain these 
function (the 'whole package?'), but I don't have the lib that fits 
to...

For example
 >>grep pci_resource_start /usr/lib/pcilib.a
returns nothing. I think it should.

I was just wondering how I will be able to retrieve the good lib, which 
I can't find on my PC.  Tried to update the Red Hat (and kernel), but 
it didn't change anything in my lib. I guess someone installed sthg on 
my PC, which removed the 'good' pci library, or changed it for an other 
lighter version.

Is there anything related with CONFIG_... flags??

Damien

Le dimanche, 14 déc 2003, à 23:40 Europe/Paris, Peter Chubb a écrit :

>>>>>> "Damien" == Damien Courouss <Damien> writes:
>
> Damien> Hi all, I'm a rookie in Linux development, and I have to
> Damien> develop a small driver for a data-acquisition card on PCI
> Damien> port.
>
> Is this a user=space or in-kernel driver?  A user-space driver will
> link with -lpci; an in-kernel driver needs to be built as if part
> of the kernel.
>
> --
> Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT 
> gelato.unsw.edu.au
> The technical we do immediately,  the political takes *forever*
>
  
  

Re: PCI lib for 2.4

[Peter Chubb]

>>>>> "Damien" == Damien Courouss <Damien> writes:

Damien> Hi, Actually, it will be first a user-space driver.

Damien> Maybe I wasn't clear:

The user-space libpci.a has headers in /usr/include/pci/pci.h
Do #include <pci/pci.h> to get at them.
On debian, at least, you need the pciutils-dev package.
Unfortunately, there are no manual pages (yet?)

And *do* look at the example code that comes with libpci.a

pci_resource_start() and so on are kernel functions; you get the same
info in a different way using libpci.a -- Look at the source of lspci
to see what you can do.

(In brief:
        struct pci_access *pacc;
        struct pci_dev *dev;

	pacc = pci_alloc();

        pci_init(pacc);
        pci_scan_bus(pacc);
        for (dev = pacc->devices; dev; dev = dev->next)
        {
                if (dev->vendor_id == PCI_VENDOR_ID_AAA &&
                    dev->device_id == PCI_DEVICE_ID_AAA_BBB)
                    break;
        }
        if (dev == NULL){
                fprintf(stderr, "No AAA BBB device\n");
		exit(1);
	}
        
        pciconf = xmalloc(sizeof *pciconf);
        pciconf->pciconfig.accesstype = PCI_CONFIG;
        pciconf->pciconfig.devp = dev;

        pci_fill_info(dev, PCI_FILL_IDENT | PCI_FILL_BASES | PCI_FILL_IRQ); 

        /*
         * Get the first 64-bytes of config space
         */
        pci_read_block(dev, 0, config, 64);
)

--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
The technical we do immediately,  the political takes *forever*

Re: PCI lib for 2.4 //kwds: pci, dma, mapping memory, kernel vs. user-space.

[Damien Couroussé]

Hi Martin,

Thanks for your answer.

% 2 pci.h files %
I had a look at example code that comes with libpci.a. Actually, that's 
what I had done since that's the only way I may do it.

I did not yet understand why I find two differents pci.h files, and why 
I cannot use one of them (since my compiler can't link with the lib)... 
Is there a specific way of using the second one, which I did not 
understand?

I work on RedHat 8, kernel 2.4.18-14
- pci.h No 1 is in /usr/include/pci , linked with /usr/include/linux 
 >>> the one I can use

- No 2 is in /usr/src/linux2.4.18-14/include/linux >>> the one I can't 
use, but I'd like to.


% dma support %
It should be OK like that, but my driver will have to support dma 
features... and I don't have available functions to do it, since I may 
not use pci.h file Number 2.
Do I have any other solution?


% mapping memory %
It seems I have many(?) ways for mapping memory, depending if the 
driver will be in kernel or user-space:
- I could use 'ioremap', but it seems to be designed for kernel-driver. 
And that's again the same thing, since I cannot use it. My <asm/io.h> 
file does not support it. (ugh?) I think I should find it here, as all 
documentation I found says that.
- I may use mmap too.

% kernel/user-space %
I have to develop a driver for a card designed for data-acquisition. 
The stream of data will have to be as fast as possible, since the card 
will have to support high data-rates.
What is the best, do  you think, to develop a driver. Should I do it in 
kernel or user-space? I mean, it seems that kernel accesses cost many 
CPU resources, whereas in user-space, I could have better performances 
if kernel accesses are limited...

Damien




Le lundi, 15 déc 2003, à 23:14 Europe/Paris, Peter Chubb a écrit :

>>>>>> "Damien" == Damien Courouss <Damien> writes:
>
> Damien> Hi, Actually, it will be first a user-space driver.
>
> Damien> Maybe I wasn't clear:
>
> The user-space libpci.a has headers in /usr/include/pci/pci.h
> Do #include <pci/pci.h> to get at them.
> On debian, at least, you need the pciutils-dev package.
> Unfortunately, there are no manual pages (yet?)
>
> And *do* look at the example code that comes with libpci.a
>
> pci_resource_start() and so on are kernel functions; you get the same
> info in a different way using libpci.a -- Look at the source of lspci
> to see what you can do.
>
> (In brief:
>         struct pci_access *pacc;
>         struct pci_dev *dev;
>
> 	pacc = pci_alloc();
>
>         pci_init(pacc);
>         pci_scan_bus(pacc);
>         for (dev = pacc->devices; dev; dev = dev->next)
>         {
>                 if (dev->vendor_id == PCI_VENDOR_ID_AAA &&
>                     dev->device_id == PCI_DEVICE_ID_AAA_BBB)
>                     break;
>         }
>         if (dev == NULL){
>                 fprintf(stderr, "No AAA BBB device\n");
> 		exit(1);
> 	}
>
>         pciconf = xmalloc(sizeof *pciconf);
>         pciconf->pciconfig.accesstype = PCI_CONFIG;
>         pciconf->pciconfig.devp = dev;
>
>         pci_fill_info(dev, PCI_FILL_IDENT | PCI_FILL_BASES | 
> PCI_FILL_IRQ);
>
>         /*
>          * Get the first 64-bytes of config space
>          */
>         pci_read_block(dev, 0, config, 64);
> )
>
> --
> Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT 
> gelato.unsw.edu.au
> The technical we do immediately,  the political takes *forever*
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: PCI lib for 2.4 //kwds: pci, dma, mapping memory, kernel vs. user-space.

[Peter Chubb]

>>>>> "Damien" == Damien Courouss <Damien> writes:

Damien> Hi Martin, Thanks for your answer.

Damien> I did not yet understand why I find two differents pci.h
Damien> files, and why I cannot use one of them (since my compiler
Damien> can't link with the lib)... Is there a specific way of using
Damien> the second one, which I did not understand?

/usr/include/pci/XXX.h are the header files to use with libpci.a
They are *all* you can use for a user-space driver.

/usr/include/linux and /usr/include/asm are copies from the kernel,
and should not be used directly in user code --- they document
internal kernel interfaces that are not accessible from user space.

You should be able to do high speed data streaming from user space --
we have a user-mode gigabit ethernet driver here that achieves
~700Mb/s for reasonable sized packets --- but latency may be a killer.
I'm measuring 10 microseconds from a PCI board asserting an interrupt
line until a driver can acknowledge it from user space; only a little lower
for a kernel driver.  (That seems about the same on P4 at 2.5GHz and
IA64 at 900MHz, BTW, so I suspect there are hardware-imposed delays
--- to acknowledge the interrupt, the driver has to do one inw and one
outw; these are slow).

You will however have to modify the kernel to allow mapping from your
address space into bus space, so that you can set up the devices's DMA
scatterlist; and to allow interrupts to be delivered to user space
(unless you plan to poll).  There are preliminary patches to do this at
http://www.gelato.unsw.edu.au/patches/usrdrivers for 2.6.0-testXXX
kernels; the work to support user drivers here is ongoing, and the
interfaces *will* change (currently they're what was easy to implement
fast (i.e., hack up) and do not correspond to production quality code)
We're not interested in 2.4 kernels for this; I'm hoping that when the
interfaces are cleaned up I can push it to 2.7.

--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
The technical we do immediately,  the political takes *forever*

Re: PCI lib for 2.4 //kwds: pci, dma, mapping memory, kernel vs. user-space.

[Damien Couroussé]

Hi Peter,

Thanks a lot, now it's OK differences between user-kernel space. It's a 
bit more clear...

  I guess your perfs info will be usefull... Actually, we do not need 
such high data rates, but we'll have 16 channels to drive I/O, and 
latencies will have to be very short, because there is a real-time loop 
(gesture control). I hope I can do the job without sending to much irqs 
since the real-time task has started.

Damien