<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/arch/tile/kernel/intvec_32.S, branch v3.2.41</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/arch/tile/kernel/intvec_32.S?h=v3.2.41</id>
<link rel='self' href='https://git.amat.us/linux/atom/arch/tile/kernel/intvec_32.S?h=v3.2.41'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2011-10-13T12:25:01Z</updated>
<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: 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: support TIF_NOTIFY_RESUME</title>
<updated>2011-05-02T22:53:35Z</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2011-05-02T18:50:06Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=313ce674d3cbc2d48ed34a9462427920ac54f4ad'/>
<id>urn:sha1:313ce674d3cbc2d48ed34a9462427920ac54f4ad</id>
<content type='text'>
This support is required for CONFIG_KEYS, NFSv4 kernel DNS, etc.
The change is slightly more complex than the minimal thing, since
I took advantage of having to go into the assembly code to just
move a bunch of stuff into C code: specifically, the schedule(),
do_async_page_fault(), do_signal(), and single_step_once() support,
in addition to the TIF_NOTIFY_RESUME support.

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>
<entry>
<title>arch/tile: fix some comments and whitespace</title>
<updated>2011-03-10T18:14:03Z</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2011-02-28T20:58:39Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=5fb682b0644cd20015d9b0e3ca6921ad5533f4ba'/>
<id>urn:sha1:5fb682b0644cd20015d9b0e3ca6921ad5533f4ba</id>
<content type='text'>
This is a grab bag of changes with no actual change to generated code.
This includes whitespace and comment typos, plus a couple of stale
comments being removed.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
</content>
</entry>
<entry>
<title>arch/tile: stop disabling INTCTRL_1 interrupts during hypervisor downcalls</title>
<updated>2011-03-01T21:20:10Z</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2011-02-28T18:24:37Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b2ce2bdaf942172914a9a39b26065ff7aacdf962'/>
<id>urn:sha1:b2ce2bdaf942172914a9a39b26065ff7aacdf962</id>
<content type='text'>
The problem was that this could lead to IPIs being disabled during
the softirq processing after a hypervisor downcall (e.g. for I/O),
since both IPI and device interrupts use the INCTRL_1 downcall mechanism.
When this happened at the wrong time, it could lead to deadlock.

Luckily, we were already maintaining the per-interrupt state we need,
and using it in the proper way in the hypervisor, so all we had to do
was to change Linux to stop blocking downcall interrupts for the entire
length of the downcall.  (Now they're blocked while we're executing the
downcall routine itself, but not while we're executing any subsequent
softirq routines.)  The hypervisor is doing a very small amount of
work it no longer needs to do (masking INTCTRL_1 on entry to the client
interrupt routine), but doing so means that older versions of Tile Linux
will continue to work with a current hypervisor, so that seems reasonable.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
</content>
</entry>
<entry>
<title>arch/tile: handle rt_sigreturn() more cleanly</title>
<updated>2010-12-17T21:59:29Z</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2010-12-14T21:07:25Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=81711cee933599fa114abb0d258d8bbabef8adfb'/>
<id>urn:sha1:81711cee933599fa114abb0d258d8bbabef8adfb</id>
<content type='text'>
The current tile rt_sigreturn() syscall pattern uses the common idiom
of loading up pt_regs with all the saved registers from the time of
the signal, then anticipating the fact that we will clobber the ABI
"return value" register (r0) as we return from the syscall by setting
the rt_sigreturn return value to whatever random value was in the pt_regs
for r0.

However, this breaks in our 64-bit kernel when running "compat" tasks,
since we always sign-extend the "return value" register to properly
handle returned pointers that are in the upper 2GB of the 32-bit compat
address space.  Doing this to the sigreturn path then causes occasional
random corruption of the 64-bit r0 register.

Instead, we stop doing the crazy "load the return-value register"
hack in sigreturn.  We already have some sigreturn-specific assembly
code that we use to pass the pt_regs pointer to C code.  We extend that
code to also set the link register to point to a spot a few instructions
after the usual syscall return address so we don't clobber the saved r0.
Now it no longer matters what the rt_sigreturn syscall returns, and the
pt_regs structure can be cleanly and completely reloaded.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
</content>
</entry>
<entry>
<title>arch/tile: enable single-step support for TILE-Gx</title>
<updated>2010-10-15T19:38:26Z</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2010-10-14T20:32:41Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=233325b94999d4bb8df227bb39904a57509e4995'/>
<id>urn:sha1:233325b94999d4bb8df227bb39904a57509e4995</id>
<content type='text'>
This is not quite the complete support, since we're not yet shipping
intvec_64.S, but it is the support relevant to the set of files we are
currently shipping, and makes it easier to track changes between
our internal sources and our public GIT repository.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
</content>
</entry>
<entry>
<title>arch/tile: parameterize system PLs to support KVM port</title>
<updated>2010-10-15T19:38:09Z</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2010-10-14T20:23:03Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a78c942df64ef4cf495fd4d8715e48501bd7f8a4'/>
<id>urn:sha1:a78c942df64ef4cf495fd4d8715e48501bd7f8a4</id>
<content type='text'>
While not a port to KVM (yet), this change modifies the kernel
to be able to build either at PL1 or at PL2 with a suitable
config switch.  Pushing up this change avoids handling branch
merge issues going forward with the KVM work.

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