<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/gpu/drm/msm/msm_gpu.c, branch v3.12</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>drm/msm: fix potential NULL pointer dereference</title>
<updated>2013-09-12T14:32:12+00:00</updated>
<author>
<name>Wei Yongjun</name>
<email>yongjun_wei@trendmicro.com.cn</email>
</author>
<published>2013-09-11T14:09:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=aea6a64c38725b6fb30738a31695ef81af3079c3'/>
<id>aea6a64c38725b6fb30738a31695ef81af3079c3</id>
<content type='text'>
The dereference to 'pdata' should be moved below the NULL test.

Signed-off-by: Wei Yongjun &lt;yongjun_wei@trendmicro.com.cn&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The dereference to 'pdata' should be moved below the NULL test.

Signed-off-by: Wei Yongjun &lt;yongjun_wei@trendmicro.com.cn&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/msm: workaround for missing irq</title>
<updated>2013-09-11T21:37:48+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@gmail.com</email>
</author>
<published>2013-09-11T21:14:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6b8819c811c2a80a7e5896b4d1e2580be825d590'/>
<id>6b8819c811c2a80a7e5896b4d1e2580be825d590</id>
<content type='text'>
Occasionally we seem to miss an IRQ from the ME (microengine).  I'm not
entirely sure the root cause, but for now we can unwedge things by
retiring from the hangcheck timer.

Signed-off-by: Rob Clark &lt;robdclark@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Occasionally we seem to miss an IRQ from the ME (microengine).  I'm not
entirely sure the root cause, but for now we can unwedge things by
retiring from the hangcheck timer.

Signed-off-by: Rob Clark &lt;robdclark@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/msm: hangcheck harder</title>
<updated>2013-09-10T17:56:59+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@gmail.com</email>
</author>
<published>2013-09-03T11:12:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=26791c48e1dcdc17c6c952585806b0ecc493f939'/>
<id>26791c48e1dcdc17c6c952585806b0ecc493f939</id>
<content type='text'>
If gpu locks up with the rptr shortly beyond the wrap-around point in
the ringbuffer, because the rptr was not reset (but wptr is, by virtue
of resetting rb-&gt;cur), we could end up in a scenario where we think
there is not enough space in the ringbuffer for the next cmds.  And
since the CP won't reset rptr until after processing an IB, this leaves
things in a sort of deadlock.

So reset rptr too.  And a bit more spiffing up of hangcheck to make
things easier to debug.

Signed-off-by: Rob Clark &lt;robdclark@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If gpu locks up with the rptr shortly beyond the wrap-around point in
the ringbuffer, because the rptr was not reset (but wptr is, by virtue
of resetting rb-&gt;cur), we could end up in a scenario where we think
there is not enough space in the ringbuffer for the next cmds.  And
since the CP won't reset rptr until after processing an IB, this leaves
things in a sort of deadlock.

So reset rptr too.  And a bit more spiffing up of hangcheck to make
things easier to debug.

Signed-off-by: Rob Clark &lt;robdclark@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/msm: handle read vs write fences</title>
<updated>2013-09-10T17:56:58+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@gmail.com</email>
</author>
<published>2013-09-01T17:25:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=bf6811f304795e7697985449ee870b29a8cbc6c7'/>
<id>bf6811f304795e7697985449ee870b29a8cbc6c7</id>
<content type='text'>
The userspace API already had everything needed to handle read vs write
synchronization.  This patch actually bothers to hook it up properly, so
that we don't need to (for example) stall on userspace read access to a
buffer that gpu is also still reading.

Signed-off-by: Rob Clark &lt;robdclark@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The userspace API already had everything needed to handle read vs write
synchronization.  This patch actually bothers to hook it up properly, so
that we don't need to (for example) stall on userspace read access to a
buffer that gpu is also still reading.

Signed-off-by: Rob Clark &lt;robdclark@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/msm: add basic hangcheck/recovery mechanism</title>
<updated>2013-08-24T18:57:19+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@gmail.com</email>
</author>
<published>2013-08-24T18:20:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=bd6f82d8289422f618b98451a43887f452b3423e'/>
<id>bd6f82d8289422f618b98451a43887f452b3423e</id>
<content type='text'>
A basic, no-frills recovery mechanism in case the gpu gets wedged.  We
could try to be a bit more fancy and restart the next submit after the
one that got wedged, but for now keep it simple.  This is enough to
recover things if, for example, the gpu hangs mid way through a piglit
run.

Signed-off-by: Rob Clark &lt;robdclark@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A basic, no-frills recovery mechanism in case the gpu gets wedged.  We
could try to be a bit more fancy and restart the next submit after the
one that got wedged, but for now keep it simple.  This is enough to
recover things if, for example, the gpu hangs mid way through a piglit
run.

Signed-off-by: Rob Clark &lt;robdclark@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/msm: add a3xx gpu support</title>
<updated>2013-08-24T18:57:18+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@gmail.com</email>
</author>
<published>2013-07-19T16:59:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=7198e6b03155f6dadecadba004eb83b81a6ffe4c'/>
<id>7198e6b03155f6dadecadba004eb83b81a6ffe4c</id>
<content type='text'>
Add initial support for a3xx 3d core.

So far, with hardware that I've seen to date, we can have:
 + zero, one, or two z180 2d cores
 + a3xx or a2xx 3d core, which share a common CP (the firmware
   for the CP seems to implement some different PM4 packet types
   but the basics of cmdstream submission are the same)

Which means that the eventual complete "class" hierarchy, once
support for all past and present hw is in place, becomes:
 + msm_gpu
   + adreno_gpu
     + a3xx_gpu
     + a2xx_gpu
   + z180_gpu

This commit splits out the parts that will eventually be common
between a2xx/a3xx into adreno_gpu, and the parts that are even
common to z180 into msm_gpu.

Note that there is no cmdstream validation required.  All memory access
from the GPU is via IOMMU/MMU.  So as long as you don't map silly things
to the GPU, there isn't much damage that the GPU can do.

Signed-off-by: Rob Clark &lt;robdclark@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add initial support for a3xx 3d core.

So far, with hardware that I've seen to date, we can have:
 + zero, one, or two z180 2d cores
 + a3xx or a2xx 3d core, which share a common CP (the firmware
   for the CP seems to implement some different PM4 packet types
   but the basics of cmdstream submission are the same)

Which means that the eventual complete "class" hierarchy, once
support for all past and present hw is in place, becomes:
 + msm_gpu
   + adreno_gpu
     + a3xx_gpu
     + a2xx_gpu
   + z180_gpu

This commit splits out the parts that will eventually be common
between a2xx/a3xx into adreno_gpu, and the parts that are even
common to z180 into msm_gpu.

Note that there is no cmdstream validation required.  All memory access
from the GPU is via IOMMU/MMU.  So as long as you don't map silly things
to the GPU, there isn't much damage that the GPU can do.

Signed-off-by: Rob Clark &lt;robdclark@gmail.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
