lkml.org 
[lkml]   [1998]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Accessing MMIO PCI space - crossplatform
    Date
    >      c) virt_to_phys and virt_to_bus should walk through pagetables instead
    > of anding/oring with something with something
    > (or explicitly say that they cannot be used for shared (adaptor)
    > memory... after reading up and down through IO-mapping it looks
    > clear to me, but...)
    > (after this change, you can do DMA I/O directly to/from userspace
    > much easier)

    I think it is not wise to slow everything down for no real reason.

    > P.P.S.: For Dave and/or Jakub (and others): On __sparc__, __sparc64__
    > (one PCI sparc is probably coming here next year) and other non-listed
    > ports (__m68k__), what is better, safe and working -
    > (*(volatile u_int32_t*)(x)) or readl(x) ?

    Both are good, safe and working on SPARC/PCI (ie. JavaStation) and
    SPARC64/PCI. The only difference is that the former does no endian
    conversion, while the latter swaps the bytes (on Ultra it has no performance
    degradation as it is done during the load from memory (but volatile asm
    impact)). So you have to know, if you can work with big endian apperture or
    how are those mappings called, or if you work with little endian memory
    only.

    > P.P.P.S.: Yes, I read Documentation/IO-mapping.txt couple of times.
    > P.P.P.P.S.: It (IO-mapping.txt) is a bit outdated, isn't it?
    > unsigned long signature = *(unsigned int*)0xC0000;
    > (at the end of doc) never worked in 2.1, isn't it?
    > P.P.P.P.P.S.: While I'm talking about ioremap, is there any chance that
    > ioremap_nocache or __ioremap will exist on non-ia32? Otherwise I have
    > to use #ifdef __i386__ ... Can I achieve same (similar) effect by MTRR
    > on non-Intel or non-PII (non-P6)? I do not believe that every PC hardware
    > around can handle this correctly without _nocache.

    On SPARC64 particularly, ioremap is a nop, as all RAM and all I/O memory is
    mapped all the time at PAGE_OFFSET+PA, in case of I/O memory non-cacheable
    with side-effects.
    So don't care about sparc64 very much in decisions about ioremap (and about
    sparc32 neither, as I guess you cannot have a matroxfb in a JavaStation).

    Cheers,
    Jakub
    ___________________________________________________________________
    Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
    Administrator of SunSITE Czech Republic, MFF, Charles University
    ___________________________________________________________________
    Ultralinux - first 64bit OS to take full power of the UltraSparc
    Linux version 2.1.127 on a sparc64 machine (498.80 BogoMips).
    ___________________________________________________________________

    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:45    [W:0.022 / U:151.124 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site