[lkml]   [2010]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] arch/tile: new multi-core architecture for Linux
    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. In
    the sh case I started out with an arch/sh/pci and then migrated to an
    arch/sh/drivers/ model when we started having to support various bus
    operations similar to PCI. Anything common or shared on the other hand
    gets pushed in to drivers/sh/ directly.

    These days there is also a drivers/platform/<arch> abstraction which
    you could easily use for platform-specific drivers that aren't things
    like 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's
    not a road you want to go down. Its primary purpose was to provide
    definitions for memory segments, and specifically wrappers for flipping
    between them. For platforms that have 1:1 cached/uncached mappings for
    lowmem in different segments, old drivers used to commonly toggle the
    high bits of an address to determine whether access was cached or not.
    These days any driver that has knowledge of memory segmentation is almost
    certainly doing something wrong.

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

    These platforms have also traditionally had these segments bypass the MMU
    completely, so while you don't take page faults for lowmem, you can't
    reuse parts of the address space in untranslatable holes. Some
    architectures (like sh) have dropped the segmentation entirely for
    certain MMU modes which permits for things like setting up an uncached
    mapping for kernel text without enabling drivers to game the system
    without proper remapping.

     \ /
      Last update: 2010-05-26 07:05    [W:0.027 / U:0.812 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site