Re: A simple question about readw, readw and the like

From: David S. Miller (davem@redhat.com)
Date: Thu Jul 27 2000 - 18:42:58 EDT

  • Next message: Keith Owens: "Re: [RFC] Merge softirq, local_irq_count, local_bh_count"

       Date: Thu, 27 Jul 2000 18:21:16 +0200
       From: Abramo Bagnara <abramo@alsa-project.org>

    > PCI mmap to user space can be done (obvious coherency and other issues left
    > to the user mode sufferer) but that isnt done by ioremap

       I suppose you mean I need to use remap_page_range with the address
       obtained from ioremap, don't you?

    No, the ioremap address is not even really defined to be a kernel
    virtual address, which is why you must use readw and can't just
    dereference the pointer.

       But, that apart, is a device driver that give available a part of the
       PCI IO space of controlled card via mmap portable to all platforms that
       have PCI?

    If you do it correctly. I agree it's currently not all that aparent
    how to do this correctly. On sparc64, we actually store the physical
    addresses in the pci_dev->resource[xxx] values, but nobody should know
    that, it's implementation defined what these resource values mean.
    The only part of them which is defined is how you go about making use
    of them, that is all.

       And if this is true, the user application that use this mmaped area may
       be written in a platform independant way?

       I'd like that you show a little example of what you call "suffering".

    Frankly, if userspace wants to get at PCI I/O ports (as opposed to PCI
    MEM areas) it must know if it is x86/ia64 vs. some other
    architecture. Because on the former you just feed the raw base
    address register values + some offset into inb etc. instructions,
    whereas on the latter you must mmap the I/O space area desired and
    then go about accessing them. It gets even uglier on older Alpha's
    which need to access things specially since these cpus lack byte sized
    load and store instructions.

    Later,
    David S. Miller
    davem@redhat.com

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/



    This archive was generated by hypermail 2b29 : Thu Jul 27 2000 - 18:59:17 EDT