On Mon, May 24, 2010 at 11:29:18AM -0400, Chris Metcalf wrote:> On 5/23/2010 6:08 PM, Arnd Bergmann wrote:> > The notable exception is pci, which should go to arch/tile/pci> > but still be reviewed in the pci mailing list.> > So this is an interesting question. Currently the "device driver"> support in the arch/tile/drivers directory is for devices which exist> literally only as part of the Tilera silicon, i.e. they are not> separable from the tile architecture itself. For example, the network> driver is tied to the Tilera networking shim DMA engine on the chip. > Does it really make sense to move this to a directory where it is more> visible to other architectures? I can see that it might from the point> of view of code bombings done to network drivers, for example. > Similarly for our other drivers, which are tied to details of the> hypervisor API, etc.

It also depends what precisely your goal with arch/tile/drivers is. Inthe sh case I started out with an arch/sh/pci and then migrated to anarch/sh/drivers/ model when we started having to support various busoperations similar to PCI. Anything common or shared on the other handgets pushed in to drivers/sh/ directly.

These days there is also a drivers/platform/<arch> abstraction whichyou could easily use for platform-specific drivers that aren't thingslike CPU/board-specific bus operations/fixups.

> >> --- /dev/null> >> +++ b/arch/tile/include/asm/addrspace.h> >> > > This file is not referenced anywhere. I'd suggest removing it> > until you send code that actually uses it.> > > > OK, I've removed it. I assumed that it was required by architectures,> since it is used in various places in the kernel. I see four drivers> that just include it unconditionally at the moment, though curiously,> they don't seem to use any of the symbols it defines. And there are> four architectures (avr32, m32r, mips, sh) that all provide this header> at the moment, though there doesn't seem to be agreement as to what> symbols it should define.> To give a bit of background on this..

All of these platforms provide this header for legacy reasons, and it'snot a road you want to go down. Its primary purpose was to providedefinitions for memory segments, and specifically wrappers for flippingbetween them. For platforms that have 1:1 cached/uncached mappings forlowmem in different segments, old drivers used to commonly toggle thehigh bits of an address to determine whether access was cached or not.These days any driver that has knowledge of memory segmentation is almostcertainly doing something wrong.

If you need to support this sort of thing, then you ideally want to hidethe segmentation information in your ioremap() implementation (you canlook at what arch/sh/include/asm/io.h does for its ioremap cases, and wehave a wide variety of corner cases outside of legacy segmentation).

These platforms have also traditionally had these segments bypass the MMUcompletely, so while you don't take page faults for lowmem, you can'treuse parts of the address space in untranslatable holes. Somearchitectures (like sh) have dropped the segmentation entirely forcertain MMU modes which permits for things like setting up an uncachedmapping for kernel text without enabling drivers to game the systemwithout proper remapping.