<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/ast, branch v3.12.62</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.12.62</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.12.62'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2016-03-07T15:05:23+00:00</updated>
<entry>
<title>drm/ast: Fix incorrect register check for DRAM width</title>
<updated>2016-03-07T15:05:23+00:00</updated>
<author>
<name>Timothy Pearson</name>
<email>tpearson@raptorengineeringinc.com</email>
</author>
<published>2016-02-26T21:29:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1f3193db2abc73f8eb273445bd6fbd42a8d3dd40'/>
<id>urn:sha1:1f3193db2abc73f8eb273445bd6fbd42a8d3dd40</id>
<content type='text'>
commit 2d02b8bdba322b527c5f5168ce1ca10c2d982a78 upstream.

During DRAM initialization on certain ASpeed devices, an incorrect
bit (bit 10) was checked in the "SDRAM Bus Width Status" register
to determine DRAM width.

Query bit 6 instead in accordance with the Aspeed AST2050 datasheet v1.05.

Signed-off-by: Timothy Pearson &lt;tpearson@raptorengineeringinc.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
</entry>
<entry>
<title>drm/ast: Initialized data needed to map fbdev memory</title>
<updated>2016-03-03T11:45:51+00:00</updated>
<author>
<name>Egbert Eich</name>
<email>eich@suse.de</email>
</author>
<published>2014-06-11T12:59:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fd84aab963018f879e2300c4f1b0378874a1e84a'/>
<id>urn:sha1:fd84aab963018f879e2300c4f1b0378874a1e84a</id>
<content type='text'>
commit 28fb4cb7fa6f63dc2fbdb5f2564dcbead8e3eee0 upstream.

Due to a missing initialization there was no way to map fbdev memory.
Thus for example using the Xserver with the fbdev driver failed.
This fix adds initialization for fix.smem_start and fix.smem_len
in the fb_info structure, which fixes this problem.

Requested-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Signed-off-by: Egbert Eich &lt;eich@suse.de&gt;
[pulled from SuSE tree by me - airlied]
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
</entry>
<entry>
<title>drm/ast: Fix HW cursor image</title>
<updated>2014-11-13T18:02:24+00:00</updated>
<author>
<name>Benjamin Herrenschmidt</name>
<email>benh@kernel.crashing.org</email>
</author>
<published>2014-10-07T08:04:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3055e72f042a7e5566f02ca2be609426ba6f6efa'/>
<id>urn:sha1:3055e72f042a7e5566f02ca2be609426ba6f6efa</id>
<content type='text'>
commit 1e99cfa8de0f0879091e33cd65fd60418d006ad9 upstream.

The translation from the X driver to the KMS one typo'ed a couple
of array indices, causing the HW cursor to look weird (blocky with
leaking edge colors). This fixes it.

Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>drm/ast: AST2000 cannot be detected correctly</title>
<updated>2014-10-13T12:25:36+00:00</updated>
<author>
<name>Y.C. Chen</name>
<email>yc_chen@aspeedtech.com</email>
</author>
<published>2014-09-10T04:07:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=eab07705c238b10ba23a22b53e4e8291c971447f'/>
<id>urn:sha1:eab07705c238b10ba23a22b53e4e8291c971447f</id>
<content type='text'>
commit 83502a5d34386f7c6973bc70e1c423f55f5a2e3a upstream.

Type error and cause AST2000 cannot be detected correctly

Signed-off-by: Y.C. Chen &lt;yc_chen@aspeedtech.com&gt;
Reviewed-by: Egbert Eich &lt;eich@suse.de&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
</entry>
<entry>
<title>drm/mgag200,ast,cirrus: fix regression with drm_can_sleep conversion</title>
<updated>2014-02-13T21:50:24+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2014-02-05T04:47:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=891e3d3ded86caf891e57d8e4f4993b97a96331f'/>
<id>urn:sha1:891e3d3ded86caf891e57d8e4f4993b97a96331f</id>
<content type='text'>
commit 8b7ad1bb3d440da888f2a939dc870eba429b9192 upstream.

I totally sign inverted my way out of this one.

Reported-by: "Sabrina Dubroca" &lt;sd@queasysnail.net&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm: ast,cirrus,mgag200: use drm_can_sleep</title>
<updated>2014-02-13T21:50:24+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2014-01-23T23:50:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3cc1638ee03d9a64948626c5e36da5cd36d92c70'/>
<id>urn:sha1:3cc1638ee03d9a64948626c5e36da5cd36d92c70</id>
<content type='text'>
commit f4b4718b61d1d5a7442a4fd6863ea80c3a10e508 upstream.

these 3 were checking in_interrupt but we have situations where
calling vunmap under this could cause a BUG to be hit in
smp_call_function_many. Use the drm_can_sleep macro instead,
which should stop this path from been taken in this case.

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/ast: fix the ast open key function</title>
<updated>2013-09-12T05:32:41+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2013-09-12T05:31:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2e8378136f28bea960cec643d3fa5d843c9049ec'/>
<id>urn:sha1:2e8378136f28bea960cec643d3fa5d843c9049ec</id>
<content type='text'>
When porting from UMS I mistyped this from the wrong place, AST noticed
and pointed it out, so we should fix it to be like the X.org driver.

Reported-by: Y.C. Chen &lt;yc_chen@aspeedtech.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'drm-next-3.12' of git://people.freedesktop.org/~agd5f/linux into drm-next</title>
<updated>2013-09-01T23:31:40+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2013-09-01T23:31:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9c725e5bcdae59d5383d4aec33a34c822582dda5'/>
<id>urn:sha1:9c725e5bcdae59d5383d4aec33a34c822582dda5</id>
<content type='text'>
Alex writes:
This is the radeon drm-next request.  Big changes include:
- support for dpm on CIK parts
- support for ASPM on CIK parts
- support for berlin GPUs
- major ring handling cleanup
- remove the old 3D blit code for bo moves in favor of CP DMA or sDMA
- lots of bug fixes

[airlied: fix up a bunch of conflicts from drm_order removal]

* 'drm-next-3.12' of git://people.freedesktop.org/~agd5f/linux: (898 commits)
  drm/radeon/dpm: make sure dc performance level limits are valid (CI)
  drm/radeon/dpm: make sure dc performance level limits are valid (BTC-SI) (v2)
  drm/radeon: gcc fixes for extended dpm tables
  drm/radeon: gcc fixes for kb/kv dpm
  drm/radeon: gcc fixes for ci dpm
  drm/radeon: gcc fixes for si dpm
  drm/radeon: gcc fixes for ni dpm
  drm/radeon: gcc fixes for trinity dpm
  drm/radeon: gcc fixes for sumo dpm
  drm/radeonn: gcc fixes for rv7xx/eg/btc dpm
  drm/radeon: gcc fixes for rv6xx dpm
  drm/radeon: gcc fixes for radeon_atombios.c
  drm/radeon: enable UVD interrupts on CIK
  drm/radeon: fix init ordering for r600+
  drm/radeon/dpm: only need to reprogram uvd if uvd pg is enabled
  drm/radeon: check the return value of uvd_v1_0_start in uvd_v1_0_init
  drm/radeon: split out radeon_uvd_resume from uvd_v4_2_resume
  radeon kms: fix uninitialised hotplug work usage in r100_irq_process()
  drm/radeon/audio: set up the sads on DCE3.2 asics
  drm/radeon: fix handling of variable sized arrays for router objects
  ...

Conflicts:
	drivers/gpu/drm/i915/i915_dma.c
	drivers/gpu/drm/i915/i915_gem_dmabuf.c
	drivers/gpu/drm/i915/intel_pm.c
	drivers/gpu/drm/radeon/cik.c
	drivers/gpu/drm/radeon/ni.c
	drivers/gpu/drm/radeon/r600.c
</content>
</entry>
<entry>
<title>drm: verify vma access in TTM+GEM drivers</title>
<updated>2013-08-27T01:54:58+00:00</updated>
<author>
<name>David Herrmann</name>
<email>dh.herrmann@gmail.com</email>
</author>
<published>2013-08-25T16:28:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=acb4652703f0a452405a3ab9319594eddc41391b'/>
<id>urn:sha1:acb4652703f0a452405a3ab9319594eddc41391b</id>
<content type='text'>
GEM does already a good job in tracking access to gem buffers via handles
and drm_vma access management. However, TTM drivers currently do not
verify this during mmap().

TTM provides the verify_access() callback to test this. So fix all drivers
to actually call into gem+vma to verify access instead of always returning
0.

All drivers assume that user-space can only get access to TTM buffers via
GEM handles. So whenever the verify_access() callback is called from
ttm_bo_mmap(), the buffer must have a valid embedded gem object. This is
true for all TTM+GEM drivers. But that's why this patch doesn't touch pure
TTM drivers (ie, vmwgfx).

v2: Switch to drm_vma_node_verify_access() to correctly return -EACCES if
    access was denied.

Cc: Dave Airlie &lt;airlied@redhat.com&gt;
Cc: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Cc: Maarten Lankhorst &lt;maarten.lankhorst@canonical.com&gt;
Cc: Jerome Glisse &lt;jglisse@redhat.com&gt;
Signed-off-by: David Herrmann &lt;dh.herrmann@gmail.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm: rip out drm_core_has_MTRR checks</title>
<updated>2013-08-19T04:11:44+00:00</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2013-08-08T13:41:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=281856477cdaba70032af502ee7192fe7aa54f69'/>
<id>urn:sha1:281856477cdaba70032af502ee7192fe7aa54f69</id>
<content type='text'>
The new arch_phys_wc_add/del functions do the right thing both with
and without MTRR support in the kernel. So we can drop these
additional checks.

David Herrmann suggest to also kill the DRIVER_USE_MTRR flag since
it's now unused, which spurred me to do a bit a better audit of the
affected drivers. David helped a lot in that. Quoting our mail
discussion:

On Wed, Jul 10, 2013 at 5:41 PM, David Herrmann &lt;dh.herrmann@gmail.com&gt; wrote:
&gt; On Wed, Jul 10, 2013 at 5:22 PM, Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt; wrote:
&gt;&gt; On Wed, Jul 10, 2013 at 3:51 PM, David Herrmann &lt;dh.herrmann@gmail.com&gt; wrote:
&gt;&gt;&gt;&gt; -#if __OS_HAS_MTRR
&gt;&gt;&gt;&gt; -static inline int drm_core_has_MTRR(struct drm_device *dev)
&gt;&gt;&gt;&gt; -{
&gt;&gt;&gt;&gt; -       return drm_core_check_feature(dev, DRIVER_USE_MTRR);
&gt;&gt;&gt;&gt; -}
&gt;&gt;&gt;&gt; -#else
&gt;&gt;&gt;&gt; -#define drm_core_has_MTRR(dev) (0)
&gt;&gt;&gt;&gt; -#endif
&gt;&gt;&gt;&gt; -
&gt;&gt;&gt;
&gt;&gt;&gt; That was the last user of DRIVER_USE_MTRR (apart from drivers setting
&gt;&gt;&gt; it in .driver_features). Any reason to keep it around?
&gt;&gt;
&gt;&gt; Yeah, I guess we could rip things out. Which will also force me to
&gt;&gt; properly audit drivers for the eventual behaviour change this could
&gt;&gt; entail (in case there's an x86 driver which did not ask for an mtrr,
&gt;&gt; but iirc there isn't).
&gt;
&gt; david@david-mb ~/dev/kernel/linux $ for i in drivers/gpu/drm/* ; do if
&gt; test -d "$i" ; then if ! grep -q USE_MTRR -r $i ; then echo $i ; fi ;
&gt; fi ; done
&gt; drivers/gpu/drm/exynos
&gt; drivers/gpu/drm/gma500
&gt; drivers/gpu/drm/i2c
&gt; drivers/gpu/drm/nouveau
&gt; drivers/gpu/drm/omapdrm
&gt; drivers/gpu/drm/qxl
&gt; drivers/gpu/drm/rcar-du
&gt; drivers/gpu/drm/shmobile
&gt; drivers/gpu/drm/tilcdc
&gt; drivers/gpu/drm/ttm
&gt; drivers/gpu/drm/udl
&gt; drivers/gpu/drm/vmwgfx
&gt; david@david-mb ~/dev/kernel/linux $
&gt;
&gt; So for x86 gma500,nouveau,qxl,udl,vmwgfx don't set DRIVER_USE_MTRR.
&gt; But I cannot tell whether they break if we call arch_phys_wc_add/del,
&gt; anyway. At least nouveau seemed to work here, but it doesn't use AGP
&gt; or drm_bufs, I guess.

Cool, thanks a lot for stitching together the list of drivers to look
at. So for real KMS drivers it's the drives responsibility to add an
mtrr if it needs one. nouvea, radeon, mgag200, i915 and vmwgfx do that
already. Somehow the savage driver also ends up doing that, I have no
idea why.

Note that gma500 as a pure KMS driver doesn't need MTRR setup since
the platforms that it supports all support PAT. So no MTRRs needed to
get wc iomappings.

The mtrr support in the drm core is all for legacy mappings of garts,
framebuffers and registers. All legacy drivers set the USE_MTRR flag,
so we're good there.

All in all I think we can really just ditch this

/endquote

v2: Also kill DRIVER_USE_MTRR as suggested by David Herrmann

v3: Rebase on top of David Herrmann's agp setup/cleanup changes.

Cc: David Herrmann &lt;dh.herrmann@gmail.com&gt;
Cc: Andy Lutomirski &lt;luto@amacapital.net&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Acked-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Reviewed-by: David Herrmann &lt;dh.herrmann@gmail.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
</feed>
