Messages in this thread | | | From | Jakub Jelinek <> | Subject | Re: kmalloc | Date | Thu, 28 Jan 1999 12:27:27 +0100 (CET) |
| |
> 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/
| |