lkml.org 
[lkml]   [1999]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: kmalloc
    Date
    >   unfortunately, I must admit that this is not true. There are four
    > problems:
    > At first, ioremap does not exist on sparc32, if I did not
    > critically miss something (I'm not sure whether sparc32 can have PCI,
    > but there should be one interface, for SBUS too).

    It can, but AFAIK there are no PCI slots in JavaStations, so with the
    exception of the onboard devices you don't have to write drivers.
    But, if we want one interface for all buses, then that interface has to be
    made so that all buses work. Like e.g. SBUS cannot cope (on some systems,
    like sun4c, sun4d) with simple virt_to_bus, one has to grab some region for
    DMA (mmu_get_scsi_one/sgl) and then after DMA is complete release it
    (mmu_release_scsi_one/sgl). The mmu_get_scsi_* give you the DMA (aka bus)
    address/addresses you then use in subsequent communication with the
    hardware. IMHO if we decide to write some nice common interface, then this
    should be in it (and most architectures would just implement the
    mmu_get_scsi_one so that it simply gives you the bus address of a virtual
    one and does nothing else, plus the release would be a noop).

    > And I'm not sure, whether
    > ioremap works correctly on PReP. When writting matroxfb, I tried
    > ioremap(vga_base, 16MB), ioremap(vga_base+0xC0000000, 16MB) and
    > ioremap(vga_base+0x80000000, 16MB). Some of them died with
    > `invalid value written into msr2', some did not return from ioremap
    > (FYI, PowerStack I, 32MB RAM). I found only one working way:
    > `virt = vga_base + _ISA_MEM_BASE' - because of whole PCI MMIO space is
    > mapped at _ISA_MEM_BASE on PReP (sorry, do not ask me for patches for PPC,
    > I do not understand neither that architecture nor their assembly language).
    > At second, on some (all?) big endian archs, readl/writel stores data
    > in little-endian format. I do not know, whether this idea is correct
    > and I'm sure that it is not documented.

    IMHO, we should in 2.3 get rid of read[bwlq] (first as obsolete interface,
    then slowly remove it once everything is checked/converted), and use
    read_8/read_16/read_32/read_64 for native host order reads, then read_le16,
    read_le32 and read_le64 for little endian accesses and be for big endian.
    And the same with write. Those read/writes should be deviced to simply
    dereferencing the virtual address on all archs but Alpha, ie. no address
    computation (of course, those _le/_be should be [lb]eXX_to_cpu).
    Alpha should do its address tricks to achieve 8/16 bit loads/stores, but
    again, compute it from some virtual address given to it.

    Cheers,
    Jakub
    ___________________________________________________________________
    Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
    Administrator of SunSITE Czech Republic, MFF, Charles University
    ___________________________________________________________________
    UltraLinux | http://ultra.linux.cz/ | http://ultra.penguin.cz/
    Linux version 2.2.0 on a sparc64 machine (3958.37 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:50    [W:0.021 / U:0.568 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site