Messages in this thread | | | Date | Mon, 7 Jun 1999 14:46:44 +0200 | From | Martin Mares <> | Subject | Re: [RFC] new bus architecture (+ byte-endianess) |
| |
Hi Petr,
> I read your specification and it looks good, except that > (1) in proc filesystem, you (probably due to mistake) used > pci0/xx.x/... > pci1/xx.x/... > usb0/xx.x/... > Isn't it better to use pci/0/..., pci/1/... ?
I prefer pci0 and pci1 in case where these are two really independent buses having separate host bridges and separate device numbering. For normal PCI-to-PCI bridge situation, it's surely pci0/03.0/...
> I also did not understand, if pci0/07.0/x.xx are devices on > bridge 7.0 on bus pci0, how is accessible bridge itself? As some > file in 07.0 subdirectory?
Yes. The 07.0 directory contains files related to the bridge and subdirectories for devices connected to the bus behind the bridge.
> (2) will you offer some bus_to_bus address translation functions, for > example for supporting DMA from one (PCI) bus to another on PowerPC > (PowerPC uses translating bridge)?
Any translation will be probably done via physical addresses, i.e. you translate address on the first bus to a physical address and then the physical address to address on the second bus.
> (3) do not forget about architectures which maps regular I/O into > memory address space - we should have ioremap_io() and inl/outl (_le?) - > on ia32, ioremap_io = nothing, inl/outl are I/O operations, on > PreP PPC, ioremap_io = return io+0x80000000; and inl/outl are synonyms > for readl/writel...
I see that it would be useful for ISA devices, but for PCI we can do this easily without using ioremap_io() if we just translate the I/O addresses read from the device before passing them to the driver. I'm not sure whether this is worth the effort or not as I know of no PCI device where I/O accesses would be time critical.
> And for byte endianess in readl/writel - if you'll say that on every > architecture readl/writel will store long in little endian, we can > live with it - but I do not know why. If processors supports storing > data with both endianess, why not to export this functionality to kernel > drivers? I can understand that ia32 peoples complaints about supporting > readl_be on their hardware, but PPC can do both be and le accesses very > easy...
I'd like to hear the opinion of PPC people, because in case we can get automatic conversion LE->BE at no extra cost, DaveM's argument about readl_be() being just extra complexity with no benefits is perfectly correct.
> For example matroxfb have to be compatible with old XF86_SVGA on PPC > (do not have, but it is better if it cost almost nothing...). And XF86_SVGA > on PPC switched matrox into big endian mode... So have I to byteswap > all pixels and commands written to hardware and then store these data > to hardware using little-endian store? Why? Or should I break backward > compatibility for no real reason? I do not want to do that.
I don't understand the compatibility problem there -- what have XF86_SVGA and matroxfb in common?
Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "You might have mail."
- 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/
| |