lkml.org 
[lkml]   [2012]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 3/3] arch/tile: tilegx PCI root complex support
    Date
    On Monday 09 April 2012, Chris Metcalf wrote:
    >
    > On 4/9/2012 9:59 AM, Arnd Bergmann wrote:
    > > On Saturday 07 April 2012, Chris Metcalf wrote:
    > >> This change implements PCIe root complex support for tilegx using
    > >> the kernel support layer for accessing the TRIO hardware shim.
    > >>
    > >> Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
    > > Hi Chris,
    > >
    > > I don't know if we discussed it during the initial merge, but I notice that the PIO
    > > accessors (inb/outb and friends) are still not implemented in this patch. Normally
    > > PIO can just be mapped into the MMIO address space, so that inb() becomes
    > > a call to readb() with an offset on the address.
    >
    > I asked our PCI expert here, who said, "My understanding is that if someone
    > wants to use inb/outb to access MMIO space, he'll get the MMIO, as opposed
    > to methods implemented with I/O instructions which are not supported by
    > TILE. If the driver is dependent on the I/O instructions, it won't work on
    > TILE. These drivers are legacy PC drivers, e.g. ATA devices, which are not
    > supported by TILE."

    I'm not sure what that means. The inb/outb instructions cannot be used to access
    MMIO, they are only for PIO. They should instead be written to do whatever the
    architecture requires for accessing PIO space. While PIO is indeed meant
    for legacy x86 accesses and discouraged in new devices, any valid PCI
    implementation still needs to support them.

    > Should we just arrange to #include <asm-generic/io.h> to pick up inb/outb
    > et al? Any reason to think a non-zero offset should be part of the
    > solution? (I don't really understand how inb/outb are used by modern drivers.)

    A zero offset is almost always a bug, it would mean that you have ioremapped the
    PIO space into the NULL pointer of your virtual address space, which would be
    an extremely silly thing to do.

    Some background: Each PCI domain comes with three address spaces: memory, config
    and I/O. The memory space is usually identity mapped with your physical addresses
    and you use ioremap to create page table entries for that so you can dereference
    pointers to do an I/O. Your iorpc_ioremap() function suggests that this is not
    the case for Tile, which is fine: you use __gxio_mmio_read32() and friends to
    access the __iomem cookie, which is an arbitrary offsettable value returned from
    iorpc_ioremap().
    The configuration space is often memory mapped and ioremapped into the virtual
    address space at boot time. Other implementations use two registers: one to set
    the address and the other to access the data, or use an mmconfig hypercall.
    Again, tile seems to be doing something completely different here and uses its
    own __gxio_mmio_read32() function.
    The i/o space is normally 64KB per domain that either have special instructions
    (x86) or are accessed like the configuration space, typically memory mapped
    (everyone else). In Linux, we access the I/O space using inb/outb that get the
    16 bit register number as an argument, and in memory mapped implementations,
    this gets added to the virtual address into which the I/O space was mapped at
    boot time.

    Arnd



    \
     
     \ /
      Last update: 2012-04-10 12:45    [W:0.026 / U:2.040 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site