lkml.org 
[lkml]   [1999]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.122 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site