Re: [PATCH] arch/tile: new multi-core architecture for Linux

[Barry Song]

On Thu, May 20, 2010 at 1:43 PM, Chris Metcalf <cmetcalf@xxxxxxxxxx> wrote:
> At Tilera we have been running Linux 2.6.26 on our architecture for a
> while and distributing the sources to our customers. ÂWe just sync'ed up
> our sources to 2.6.34 and would like to return it to the community more
> widely, so I'm hoping to take advantage of the merge window for 2.6.35
> to integrate support for our architecture.
>
> The "tile" architecture supports the Tilera chips, both our current
> 32-bit chips and our upcoming 64-bit architecture. ÂThe chips are
> multicore, with 64 (or 36) cores per chip on our current product line,
> and up to 100 cores on the upcoming 64-bit architecture. ÂThey also
> include multiple built-in memory controllers, 10 Gb Ethernet, PCIe,
> and a number of other I/Os. ÂThere's more info at http://www.tilera.com.
>
> The architecture is somewhat MIPS-like, but VLIW, with up to three
> instructions per bundle. ÂThe system architecture is nicely orthogonal,
> with four privilege levels that can be assigned to each of forty-odd
> separate protection domains, many with an associated interrupt, e.g.
> ITLB/DTLB misses, timer, performance counters, various interrupts
> associated with the generic networks that connect the cores, etc.
> A hypervisor (kind of like the Alpha PAL) runs at a higher privilege
> level to support Linux via software-interrupt calls.
>
> The Linux we ship has some additional performance and functionality
> customization in the generic code, but appended is the patch that just
> adds the minimum amount of functionality into the platform-independent
> code to hook in the tile architecture code in arch/tile. ÂWe will
> attempt to push the other changes to the platform-independent code
> piece by piece, after the initial architecture support is in.
> We will also push up the 64-bit TILE-Gx support once that architecture
> is fully frozen (e.g. instruction encodings finalized).
>
> We are using the http://www.tilera.com/scm/ web site to push
> Tilera-modified sources back up to the community. ÂAt the moment, the
> arch/tile hierarchy is there (as a bzipped tarball) as well as a copy
> of the patch appended to this email. ÂIn addition, our gcc, binutils,
> and gdb sources are available on the web site. ÂWe have not yet started
> the community return process for gcc, binutils, and gdb, so they are in
> a preliminary form at this point.
>
> The git://www.tilera.com server is up, but without content yet, since
> we realized this week that we need to upgrade the web server to
> a 64-bit kernel to support a decent git server, so though we plan to
> make the code available via git in the future, it isn't yet.
>
> As far as the platform-independent changes go, two of the changes in the
> appended patch are uncontroversial, one adding a stanza to MAINTAINERS,
> and one adding a line to drivers/pci/Makefile to request "setup-bus.o
> setup-irq.o" for tile PCI.
>
> A slightly more interesting one-line change is to <linux/mm.h>,
> to support lowmem PAs above the 4GB limit. ÂWe use NUMA to manage
> the multiple memory controllers attached to the chip, and map some of
> each controller into kernel LOWMEM to load-balance memory bandwidth for
> kernel-intensive apps. ÂThe controllers can each manage up to 16GB, so we
> use bits above the 4GB limit in the PA to indicate the controller number.
> It turns out that generic Linux almost tolerates this, but requires one
> cast in lowmem_page_address() to avoid shifting the high PA bits out of
> a 32-bit PFN type.
>
> The final change is just a PCI quirk for our TILEmpower platform, which
> explains itself in the comment. ÂThis is not a critical change from our
> point of view, but without it you can't use the SATA disks attached to
> the PCI controller on that platform, so we're hoping it can be accepted
> as part of the initial tile architecture submission as well.
>
> I'd appreciate being cc'ed on any comments on the patch or the tile
> architecture support, since although I try to follow LKML, the volume
> can be somewhat overwhelming.
>
>
> --- linux-2.6.34/MAINTAINERS Â Â2010-05-16 17:17:36.000000000 -0400
> +++ tilera-source/MAINTAINERS Â 2010-05-17 18:00:12.651112000 -0400
> @@ -5436,6 +5436,12 @@
> ÂS: Â Â Maintained
> ÂF: Â Â sound/soc/codecs/twl4030*
>
> +TILE ARCHITECTURE
> +M: Â Â Chris Metcalf <cmetcalf@xxxxxxxxxx>
> +W: Â Â http://www.tilera.com/scm/
> +S: Â Â Supported
> +F: Â Â arch/tile/
> +
> ÂTIPC NETWORK LAYER
> ÂM: Â Â Jon Maloy <jon.maloy@xxxxxxxxxxxx>
> ÂM: Â Â Allan Stephens <allan.stephens@xxxxxxxxxxxxx>
> --- linux-2.6.34/include/linux/mm.h   2010-05-16 17:17:36.000000000 -0400
> +++ tilera-source/include/linux/mm.h  Â2010-05-17 12:54:33.540145000 -0400
> @@ -592,7 +592,7 @@
>
> Âstatic __always_inline void *lowmem_page_address(struct page *page)
> Â{
> - Â Â Â return __va(page_to_pfn(page) << PAGE_SHIFT);
> + Â Â Â return __va((phys_addr_t)page_to_pfn(page) << PAGE_SHIFT);

Here doesn't make sense. you give a u64 type cast, but change the
meaning of pfn. Is pfn phys_addr_t? Anyway, page_to_pfn can be
re-fulfilled in your arch, but not change it in common code.

> Â}
>
> Â#if defined(CONFIG_HIGHMEM) && !defined(WANT_PAGE_VIRTUAL)
> --- linux-2.6.34/drivers/pci/Makefile  2010-05-09 21:36:28.000000000 -0400
> +++ tilera-source/drivers/pci/Makefile Â2010-05-13 15:03:05.615238000 -0400
> @@ -49,6 +49,7 @@
> Âobj-$(CONFIG_X86_VISWS) += setup-irq.o
> Âobj-$(CONFIG_MN10300) += setup-bus.o
> Âobj-$(CONFIG_MICROBLAZE) += setup-bus.o
> +obj-$(CONFIG_TILE) += setup-bus.o setup-irq.o
>
> Â#
> Â# ACPI Related PCI FW Functions
> --- linux-2.6.34/drivers/pci/quirks.c  2010-05-16 17:17:36.000000000 -0400
> +++ tilera-source/drivers/pci/quirks.c Â2010-05-17 13:26:22.347178000 -0400
> @@ -2094,6 +2094,23 @@
> Â Â Â Â Â Â Â Â Â Â Â Âquirk_unhide_mch_dev6);
>
>
> +/*
> + * The Tilera Blade V1.0 platform needs to set the link speed
> + * to 2.5GT(Giga-Transfers)/s (Gen 1). The default link speed
> + * setting is 5GT/s (Gen 2). 0x98 is the Link Control2 PCIe
> + * capability register of the PEX8624 PCIe switch. The switch
> + * supports link speed auto negotiation. This is expected to
> + * be fixed in the next release of the Blade platform.
> + */
> +static void __devinit quirk_tile_blade(struct pci_dev *dev)
> +{
> + Â Â Â if (blade_pci) {
> + Â Â Â Â Â Â Â pci_write_config_dword(dev, 0x98, 0x1);
> + Â Â Â Â Â Â Â mdelay(50);
> + Â Â Â }
> +}
> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_PLX, 0x8624, quirk_tile_blade);

Your patch is not compilable, and the subject doesn't match well with
the content. I think you need re-organize patches.

> +
> Â#ifdef CONFIG_PCI_MSI
> Â/* Some chipsets do not support MSI. We cannot easily rely on setting
> Â* PCI_BUS_FLAGS_NO_MSI in its bus flags because there are actually
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at Âhttp://vger.kernel.org/majordomo-info.html
> Please read the FAQ at Âhttp://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/