<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/arch/tile/kernel/Makefile, branch imx-android-r12</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>pci root complex: support for tile architecture</title>
<updated>2010-11-24T18:13:49+00:00</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2010-11-02T16:05:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f02cbbe657939489347cbda598401a56913ffcbd'/>
<id>f02cbbe657939489347cbda598401a56913ffcbd</id>
<content type='text'>
This change enables PCI root complex support for TILEPro.  Unlike
TILE-Gx, TILEPro has no support for memory-mapped I/O, so the PCI
support consists of hypervisor upcalls for PIO, DMA, etc.  However,
the performance is fine for the devices we have tested with so far
(1Gb Ethernet, SATA, etc.).

The &lt;asm/io.h&gt; header was tweaked to be a little bit more aggressive
about disabling attempts to map/unmap IO port space.  The hacky
&lt;asm/pci-bridge.h&gt; header was rolled into the &lt;asm/pci.h&gt; header
and the result was simplified.  Both of the latter two headers were
preliminary versions not meant for release before now - oh well.

There is one quirk for our TILEmpower platform, which accidentally
negotiates up to 5GT and needs to be kicked down to 2.5GT.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This change enables PCI root complex support for TILEPro.  Unlike
TILE-Gx, TILEPro has no support for memory-mapped I/O, so the PCI
support consists of hypervisor upcalls for PIO, DMA, etc.  However,
the performance is fine for the devices we have tested with so far
(1Gb Ethernet, SATA, etc.).

The &lt;asm/io.h&gt; header was tweaked to be a little bit more aggressive
about disabling attempts to map/unmap IO port space.  The hacky
&lt;asm/pci-bridge.h&gt; header was rolled into the &lt;asm/pci.h&gt; header
and the result was simplified.  Both of the latter two headers were
preliminary versions not meant for release before now - oh well.

There is one quirk for our TILEmpower platform, which accidentally
negotiates up to 5GT and needs to be kicked down to 2.5GT.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arch/tile: Add driver to enable access to the user dynamic network.</title>
<updated>2010-07-06T17:34:15+00:00</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2010-06-25T21:00:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9f9c0382cda2334b35b40b00f4ed9d6f89f37a7b'/>
<id>9f9c0382cda2334b35b40b00f4ed9d6f89f37a7b</id>
<content type='text'>
This network (the "UDN") connects all the cpus on the chip in a
wormhole-routed dynamic network.  Subrectangles of the chip can
be allocated by a "create" ioctl on /dev/hardwall, and then to access the
UDN in that rectangle, tasks must perform an "activate" ioctl on that
same file object after affinitizing themselves to a single cpu in
the region.  Sending a wormhole-routed message that tries to leave
that subrectangle causes all activated tasks to receive a SIGILL
(just as they would if they tried to access the UDN without first
activating themselves to a hardwall rectangle).

The original submission of this code to LKML had the driver
instantiated under /proc/tile/hardwall.  Now we just use a character
device for this, conventionally /dev/hardwall.  Some futures planning
for the TILE-Gx chip suggests that we may want to have other types of
devices that share the general model of "bind a task to a cpu, then
'activate' a file descriptor on a pseudo-device that gives access to
some hardware resource".  As such, we are using a device rather
than, for example, a syscall, to set up and activate this code.

As part of this change, the compat_ptr() declaration was fixed and used
to pass the compat_ioctl argument to the normal ioctl.  So far we limit
compat code to 2GB, so the difference between zero-extend and sign-extend
(the latter being correct, eventually) had been overlooked.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This network (the "UDN") connects all the cpus on the chip in a
wormhole-routed dynamic network.  Subrectangles of the chip can
be allocated by a "create" ioctl on /dev/hardwall, and then to access the
UDN in that rectangle, tasks must perform an "activate" ioctl on that
same file object after affinitizing themselves to a single cpu in
the region.  Sending a wormhole-routed message that tries to leave
that subrectangle causes all activated tasks to receive a SIGILL
(just as they would if they tried to access the UDN without first
activating themselves to a hardwall rectangle).

The original submission of this code to LKML had the driver
instantiated under /proc/tile/hardwall.  Now we just use a character
device for this, conventionally /dev/hardwall.  Some futures planning
for the TILE-Gx chip suggests that we may want to have other types of
devices that share the general model of "bind a task to a cpu, then
'activate' a file descriptor on a pseudo-device that gives access to
some hardware resource".  As such, we are using a device rather
than, for example, a syscall, to set up and activate this code.

As part of this change, the compat_ptr() declaration was fixed and used
to pass the compat_ioctl argument to the normal ioctl.  So far we limit
compat code to 2GB, so the difference between zero-extend and sign-extend
(the latter being correct, eventually) had been overlooked.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arch/tile: core support for Tilera 32-bit chips.</title>
<updated>2010-06-04T21:11:18+00:00</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2010-05-29T03:09:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=867e359b97c970a60626d5d76bbe2a8fadbf38fb'/>
<id>867e359b97c970a60626d5d76bbe2a8fadbf38fb</id>
<content type='text'>
This change is the core kernel support for TILEPro and TILE64 chips.
No driver support (except the console driver) is included yet.

This includes the relevant Linux headers in asm/; the low-level
low-level "Tile architecture" headers in arch/, which are
shared with the hypervisor, etc., and are build-system agnostic;
and the relevant hypervisor headers in hv/.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: FUJITA Tomonori &lt;fujita.tomonori@lab.ntt.co.jp&gt;
Reviewed-by: Paul Mundt &lt;lethal@linux-sh.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This change is the core kernel support for TILEPro and TILE64 chips.
No driver support (except the console driver) is included yet.

This includes the relevant Linux headers in asm/; the low-level
low-level "Tile architecture" headers in arch/, which are
shared with the hypervisor, etc., and are build-system agnostic;
and the relevant hypervisor headers in hv/.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: FUJITA Tomonori &lt;fujita.tomonori@lab.ntt.co.jp&gt;
Reviewed-by: Paul Mundt &lt;lethal@linux-sh.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
