<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/arch/tile/lib, branch v3.2.41</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/arch/tile/lib?h=v3.2.41</id>
<link rel='self' href='https://git.amat.us/linux/atom/arch/tile/lib?h=v3.2.41'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2011-12-03T20:31:41Z</updated>
<entry>
<title>arch/tile: add a few #includes and an EXPORT to catch up with kernel changes.</title>
<updated>2011-12-03T20:31:41Z</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2011-12-01T16:37:20Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3989efb77046ad334518b6cddcf817184affe7c9'/>
<id>urn:sha1:3989efb77046ad334518b6cddcf817184affe7c9</id>
<content type='text'>
The empty_zero_page[] export is required for ZERO_PAGE() module references.
The #includes are due to changes in implicit inclusion, and should of
course have been in the sources from the beginning.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
</content>
</entry>
<entry>
<title>arch/tile: avoid exporting a symbol no longer used by gcc</title>
<updated>2011-11-03T20:58:42Z</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2011-11-03T02:23:41Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f319d6e238a25d84af530a6a2526525c7041463f'/>
<id>urn:sha1:f319d6e238a25d84af530a6a2526525c7041463f</id>
<content type='text'>
An earlier Tilera compiler generated calls to an "__ll_mul"
function for long long multiplication.  Our libgcc supported that
as an alias for the normal __muldi3 routine, so we made it available
to kernel modules as well.  However, for a while now the compiler
has internally been generating only the standard __muldi3 symbol,
and the version we are giving back to the community does not have
the __ll_mul alias, so we are removing it from the kernel too.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
</content>
</entry>
<entry>
<title>tile: revert change from &lt;asm/atomic.h&gt; to &lt;linux/atomic.h&gt; in asm files</title>
<updated>2011-10-13T12:25:01Z</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2011-10-05T21:09:29Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d52104b29a3735f2b4dceefcb01b19d370a783ea'/>
<id>urn:sha1:d52104b29a3735f2b4dceefcb01b19d370a783ea</id>
<content type='text'>
The 32-bit TILEPro support uses some #defines in &lt;asm/atomic_32.h&gt;
for atomic support routines in assembly.  To make this more explicit,
I've turned those includes into includes of &lt;asm/atomic_32.h&gt;, which
should hopefully make it clear that they shouldn't be bombed into
&lt;linux/atomic.h&gt; in any cleanups.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
</content>
</entry>
<entry>
<title>atomic: use &lt;linux/atomic.h&gt;</title>
<updated>2011-07-26T23:49:47Z</updated>
<author>
<name>Arun Sharma</name>
<email>asharma@fb.com</email>
</author>
<published>2011-07-26T23:09:06Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=60063497a95e716c9a689af3be2687d261f115b4'/>
<id>urn:sha1:60063497a95e716c9a689af3be2687d261f115b4</id>
<content type='text'>
This allows us to move duplicated code in &lt;asm/atomic.h&gt;
(atomic_inc_not_zero() for now) to &lt;linux/atomic.h&gt;

Signed-off-by: Arun Sharma &lt;asharma@fb.com&gt;
Reviewed-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: David Miller &lt;davem@davemloft.net&gt;
Cc: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Acked-by: Mike Frysinger &lt;vapier@gentoo.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>arch/tile: finish enabling support for TILE-Gx 64-bit chip</title>
<updated>2011-05-12T19:52:12Z</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2011-05-04T18:38:26Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=18aecc2b645bbb07851b196452a2af314222069b'/>
<id>urn:sha1:18aecc2b645bbb07851b196452a2af314222069b</id>
<content type='text'>
This support was partially present in the existing code (look for
"__tilegx__" ifdefs) but with this change you can build a working
kernel using the TILE-Gx toolchain and ARCH=tilegx.

Most of these files are new, generally adding a foo_64.c file
where previously there was just a foo_32.c file.

The ARCH=tilegx directive redirects to arch/tile, not arch/tilegx,
using the existing SRCARCH mechanism in the top-level Makefile.

Changes to existing files:

- &lt;asm/bitops.h&gt; and &lt;asm/bitops_32.h&gt; changed to factor the
  include of &lt;asm-generic/bitops/non-atomic.h&gt; in the common header.

- &lt;asm/compat.h&gt; and arch/tile/kernel/compat.c changed to remove
  the "const" markers I had put on compat_sys_execve() when trying
  to match some recent similar changes to the non-compat execve.
  It turns out the compat version wasn't "upgraded" to use const.

- &lt;asm/opcode-tile_64.h&gt; and &lt;asm/opcode_constants_64.h&gt; were
  previously included accidentally, with the 32-bit contents.  Now
  they have the proper 64-bit contents.

Finally, I had to hack the existing hacky drivers/input/input-compat.h
to add yet another "#ifdef" for INPUT_COMPAT_TEST (same as x86_64).

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
Acked-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt; [drivers/input]
</content>
</entry>
<entry>
<title>arch/tile: disable GX prefetcher during cache flush</title>
<updated>2011-05-04T18:40:46Z</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2011-05-02T19:54:32Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=dbb434214e34014dc7acb0e7811c37471df26a72'/>
<id>urn:sha1:dbb434214e34014dc7acb0e7811c37471df26a72</id>
<content type='text'>
Otherwise, it's possible to end up with the prefetcher pulling
data into cache that the code believes has been flushed.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
</content>
</entry>
<entry>
<title>arch/tile: allow nonatomic stores to interoperate with fast atomic syscalls</title>
<updated>2011-05-04T18:40:07Z</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2011-05-02T19:13:13Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=df29ccb6c06dcb65867d4fd3c2fa473017f60ecc'/>
<id>urn:sha1:df29ccb6c06dcb65867d4fd3c2fa473017f60ecc</id>
<content type='text'>
This semantic was already true for atomic operations within the kernel,
and this change makes it true for the fast atomic syscalls (__NR_cmpxchg
and __NR_atomic_update) as well.  Previously, user-space had to use
the fast atomic syscalls exclusively to update memory, since raw stores
could lose a race with the atomic update code even when the atomic update
hadn't actually modified the value.

With this change, we no longer write back the value to memory if it
hasn't changed.  This allows certain types of idioms in user space to
work as expected, e.g. "atomic exchange" to acquire a spinlock, followed
by a raw store of zero to release the lock.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
</content>
</entry>
<entry>
<title>arch/tile: fix futex sanitization definition/prototype mismatch</title>
<updated>2011-03-20T04:08:21Z</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2011-03-19T15:45:34Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=5b4787719f8870104fada924ef65ee9fd5eb2514'/>
<id>urn:sha1:5b4787719f8870104fada924ef65ee9fd5eb2514</id>
<content type='text'>
Commit 8d7718aa082aaf30a0b4989e1f04858952f941bc changed "int"
to "u32" in the prototypes but not the definition.
I missed this when I saw the patch go by on LKML.

We cast "u32 *" to "int *" since we are tying into the underlying
atomics framework, and atomic_t uses int as its value type.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
Reviewed-by: Michel Lespinasse &lt;walken@google.com&gt;
</content>
</entry>
<entry>
<title>arch/tile: fix deadlock bugs in rwlock implementation</title>
<updated>2011-03-10T21:10:41Z</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2011-03-01T18:30:15Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3c5ead52ed68406c0ee789024c4ae581be8bcee4'/>
<id>urn:sha1:3c5ead52ed68406c0ee789024c4ae581be8bcee4</id>
<content type='text'>
The first issue fixed in this patch is that pending rwlock write locks
could lock out new readers; this could cause a deadlock if a read lock was
held on cpu 1, a write lock was then attempted on cpu 2 and was pending,
and cpu 1 was interrupted and attempted to re-acquire a read lock.
The write lock code was modified to not lock out new readers.

The second issue fixed is that there was a narrow race window where a tns
instruction had been issued (setting the lock value to "1") and the store
instruction to reset the lock value correctly had not yet been issued.
In this case, if an interrupt occurred and the same cpu then tried to
manipulate the lock, it would find the lock value set to "1" and spin
forever, assuming some other cpu was partway through updating it.  The fix
is to enforce an interrupt critical section around the tns/store pair.

In addition, this change now arranges to always validate that after
a readlock we have not wrapped around the count of readers, which
is only eight bits.

Since these changes make the rwlock "fast path" code heavier weight,
I decided to move all the rwlock code all out of line, leaving only the
conventional spinlock code with fastpath inlines.  Since the read_lock
and read_trylock implementations ended up very similar, I just expressed
read_lock in terms of read_trylock.

As part of this change I also eliminate support for the now-obsolete
tns_atomic mode.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
</content>
</entry>
<entry>
<title>arch/tile: support 4KB page size as well as 64KB</title>
<updated>2011-03-10T18:17:53Z</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2011-02-28T21:37:34Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=76c567fbba50c3da2f4d40e2e551bab26cfd4381'/>
<id>urn:sha1:76c567fbba50c3da2f4d40e2e551bab26cfd4381</id>
<content type='text'>
The Tilera architecture traditionally supports 64KB page sizes
to improve TLB utilization and improve performance when the
hardware is being used primarily to run a single application.

For more generic server scenarios, it can be beneficial to run
with 4KB page sizes, so this commit allows that to be specified
(by modifying the arch/tile/include/hv/pagesize.h header).

As part of this change, we also re-worked the PTE management
slightly so that PTE writes all go through a __set_pte() function
where we can do some additional validation.  The set_pte_order()
function was eliminated since the "order" argument wasn't being used.

One bug uncovered was in the PCI DMA code, which wasn't properly
flushing the specified range.  This was benign with 64KB pages,
but with 4KB pages we were getting some larger flushes wrong.

The per-cpu memory reservation code also needed updating to
conform with the newer percpu stuff; before it always chose 64KB,
and that was always correct, but with 4KB granularity we now have
to pay closer attention and reserve the amount of memory that will
be requested when the percpu code starts allocating.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
</content>
</entry>
</feed>
