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.075 / U:0.172 seconds]
©2003-2011 Jasper Spaans. Advertise on this site