<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/gpu, branch v4.16.13</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>drm/vmwgfx: Set dmabuf_size when vmw_dmabuf_init is successful</title>
<updated>2018-05-30T06:17:45+00:00</updated>
<author>
<name>Deepak Rawat</name>
<email>drawat@vmware.com</email>
</author>
<published>2018-05-15T13:39:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=8ade5e15bfd265e9a9afc43e0508070b67eab00f'/>
<id>8ade5e15bfd265e9a9afc43e0508070b67eab00f</id>
<content type='text'>
commit 91ba9f28a3de97761c2b5fd5df5d88421268e507 upstream.

SOU primary plane prepare_fb hook depends upon dmabuf_size to pin up BO
(and not call a new vmw_dmabuf_init) when a new fb size is same as
current fb. This was changed in a recent commit which is causing
page_flip to fail on VM with low display memory and multi-mon failure
when cycle monitors from secondary display.

Cc: &lt;stable@vger.kernel.org&gt; # 4.14, 4.16
Fixes: 20fb5a635a0c ("drm/vmwgfx: Unpin the screen object backup buffer when not used")
Signed-off-by: Deepak Rawat &lt;drawat@vmware.com&gt;
Reviewed-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 91ba9f28a3de97761c2b5fd5df5d88421268e507 upstream.

SOU primary plane prepare_fb hook depends upon dmabuf_size to pin up BO
(and not call a new vmw_dmabuf_init) when a new fb size is same as
current fb. This was changed in a recent commit which is causing
page_flip to fail on VM with low display memory and multi-mon failure
when cycle monitors from secondary display.

Cc: &lt;stable@vger.kernel.org&gt; # 4.14, 4.16
Fixes: 20fb5a635a0c ("drm/vmwgfx: Unpin the screen object backup buffer when not used")
Signed-off-by: Deepak Rawat &lt;drawat@vmware.com&gt;
Reviewed-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm: rcar-du: lvds: Fix LVDS startup on R-Car Gen2</title>
<updated>2018-05-30T06:17:44+00:00</updated>
<author>
<name>Sergei Shtylyov</name>
<email>sergei.shtylyov@cogentembedded.com</email>
</author>
<published>2018-01-12T20:12:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=475033814e3304714c61d6bf851c637181cdc3a1'/>
<id>475033814e3304714c61d6bf851c637181cdc3a1</id>
<content type='text'>
[ Upstream commit 8525d04ba8a6a9ecfa4bd619c988ca873a5fc2a4 ]

According to the latest revision 2.00 of the R-Car Gen2 manual, the LVDS
and the bias circuit must be enabled after the LVDS I/O pins are
enabled, not before. Fix the Gen2 LVDS startup sequence accordingly.

While at it, also fix the comment preceding the first LVDCR0 write that
still talks about hardcoding the LVDS mode 0.

Fixes: 90374b5c25c9 ("drm/rcar-du: Add internal LVDS encoder support")
Signed-off-by: Sergei Shtylyov &lt;sergei.shtylyov@cogentembedded.com&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Tested-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Signed-off-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 8525d04ba8a6a9ecfa4bd619c988ca873a5fc2a4 ]

According to the latest revision 2.00 of the R-Car Gen2 manual, the LVDS
and the bias circuit must be enabled after the LVDS I/O pins are
enabled, not before. Fix the Gen2 LVDS startup sequence accordingly.

While at it, also fix the comment preceding the first LVDCR0 write that
still talks about hardcoding the LVDS mode 0.

Fixes: 90374b5c25c9 ("drm/rcar-du: Add internal LVDS encoder support")
Signed-off-by: Sergei Shtylyov &lt;sergei.shtylyov@cogentembedded.com&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Tested-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Signed-off-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm: rcar-du: lvds: Fix LVDS startup on R-Car Gen3</title>
<updated>2018-05-30T06:17:44+00:00</updated>
<author>
<name>Sergei Shtylyov</name>
<email>sergei.shtylyov@cogentembedded.com</email>
</author>
<published>2018-01-12T20:12:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=456aef5ed33319aa9acef14d1abf4a6511c750a9'/>
<id>456aef5ed33319aa9acef14d1abf4a6511c750a9</id>
<content type='text'>
[ Upstream commit 796ceb9269626afaed3b4955c40d2c3d7a8c5d01 ]

According to the latest revisions of the R-Car Gen3 manual, the LVDS mode
must be set before the LVDS I/O pins are enabled, not after -- fix the
Gen3 LVDS startup sequence accordingly.

Fixes: e947eccbeba4 ("drm: rcar-du: Add support for LVDS mode selection")
Signed-off-by: Sergei Shtylyov &lt;sergei.shtylyov@cogentembedded.com&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
[Updated comment in rcar_du_lvdsenc_start_gen3()]
[Moved Gen2 startup comment update to separate commit]
[Fixed =| typo]
Tested-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Signed-off-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 796ceb9269626afaed3b4955c40d2c3d7a8c5d01 ]

According to the latest revisions of the R-Car Gen3 manual, the LVDS mode
must be set before the LVDS I/O pins are enabled, not after -- fix the
Gen3 LVDS startup sequence accordingly.

Fixes: e947eccbeba4 ("drm: rcar-du: Add support for LVDS mode selection")
Signed-off-by: Sergei Shtylyov &lt;sergei.shtylyov@cogentembedded.com&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
[Updated comment in rcar_du_lvdsenc_start_gen3()]
[Moved Gen2 startup comment update to separate commit]
[Fixed =| typo]
Tested-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Signed-off-by: Laurent Pinchart &lt;laurent.pinchart+renesas@ideasonboard.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/vblank: Data type fixes for 64-bit vblank sequences.</title>
<updated>2018-05-30T06:17:44+00:00</updated>
<author>
<name>Dhinakaran Pandiyan</name>
<email>dhinakaran.pandiyan@intel.com</email>
</author>
<published>2018-02-03T05:12:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=8f356a1fb2080ee910d1b82332575e276bbd2ef0'/>
<id>8f356a1fb2080ee910d1b82332575e276bbd2ef0</id>
<content type='text'>
[ Upstream commit 3b765c0b765d2cc03ef02276f1af2658a03b3ced ]

drm_vblank_count() has an u32 type returning what is a 64-bit vblank count.
The effect of this is when drm_wait_vblank_ioctl() tries to widen the user
space requested vblank sequence using this clipped 32-bit count(when the
value is &gt;= 2^32) as reference, the requested sequence remains a 32-bit
value and gets queued like that. However, the code that checks if the
requested sequence has passed compares this against the 64-bit vblank
count.

With drm_vblank_count() returning all bits of the vblank count, update
drm_crtc_accurate_vblank_count() so that drm_crtc_arm_vblank_event() queues
the correct sequence. Otherwise, this leads to prolonged waits for a vblank
sequence when the current count is &gt;=2^32.

Finally, fix drm_wait_one_vblank() too.

v2: Commit message fix (Keith)
    Squash commits (Rodrigo)

Fixes: 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]")
Cc: Keith Packard &lt;keithp@keithp.com&gt;
Cc: Michel Dänzer &lt;michel@daenzer.net&gt;
Cc: Daniel Vetter &lt;daniel@ffwll.ch&gt;
Cc: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Dhinakaran Pandiyan &lt;dhinakaran.pandiyan@intel.com&gt;
Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Reviewed-by: Keith Packard &lt;keithp@keithp.com&gt;
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180203051302.9974-1-dhinakaran.pandiyan@intel.com
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 3b765c0b765d2cc03ef02276f1af2658a03b3ced ]

drm_vblank_count() has an u32 type returning what is a 64-bit vblank count.
The effect of this is when drm_wait_vblank_ioctl() tries to widen the user
space requested vblank sequence using this clipped 32-bit count(when the
value is &gt;= 2^32) as reference, the requested sequence remains a 32-bit
value and gets queued like that. However, the code that checks if the
requested sequence has passed compares this against the 64-bit vblank
count.

With drm_vblank_count() returning all bits of the vblank count, update
drm_crtc_accurate_vblank_count() so that drm_crtc_arm_vblank_event() queues
the correct sequence. Otherwise, this leads to prolonged waits for a vblank
sequence when the current count is &gt;=2^32.

Finally, fix drm_wait_one_vblank() too.

v2: Commit message fix (Keith)
    Squash commits (Rodrigo)

Fixes: 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]")
Cc: Keith Packard &lt;keithp@keithp.com&gt;
Cc: Michel Dänzer &lt;michel@daenzer.net&gt;
Cc: Daniel Vetter &lt;daniel@ffwll.ch&gt;
Cc: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Dhinakaran Pandiyan &lt;dhinakaran.pandiyan@intel.com&gt;
Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Reviewed-by: Keith Packard &lt;keithp@keithp.com&gt;
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180203051302.9974-1-dhinakaran.pandiyan@intel.com
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/rockchip: Respect page offset for PRIME mmap calls</title>
<updated>2018-05-30T06:17:43+00:00</updated>
<author>
<name>Ørjan Eide</name>
<email>orjan.eide@arm.com</email>
</author>
<published>2018-01-30T20:28:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=5cce4275056eae4078f8444d0d4a3f33d6edaec5'/>
<id>5cce4275056eae4078f8444d0d4a3f33d6edaec5</id>
<content type='text'>
[ Upstream commit 57de50af162b67612da99207b061ade3239e57db ]

When mapping external DMA-bufs through the PRIME mmap call, we might be
given an offset which has to be respected. However for the internal DRM
GEM mmap path, we have to ignore the fake mmap offset used to identify
the buffer only. Currently the code always zeroes out vma-&gt;vm_pgoff,
which breaks the former.

This patch fixes the problem by moving the vm_pgoff assignment to a
function that is used only for GEM mmap path, so that the PRIME path
retains the original offset.

Cc: Daniel Kurtz &lt;djkurtz@chromium.org&gt;
Signed-off-by: Ørjan Eide &lt;orjan.eide@arm.com&gt;
Signed-off-by: Tomasz Figa &lt;tfiga@chromium.org&gt;
Signed-off-by: Sean Paul &lt;seanpaul@chromium.org&gt;
Signed-off-by: Thierry Escande &lt;thierry.escande@collabora.com&gt;
Tested-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Signed-off-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180130202913.28724-4-thierry.escande@collabora.com
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 57de50af162b67612da99207b061ade3239e57db ]

When mapping external DMA-bufs through the PRIME mmap call, we might be
given an offset which has to be respected. However for the internal DRM
GEM mmap path, we have to ignore the fake mmap offset used to identify
the buffer only. Currently the code always zeroes out vma-&gt;vm_pgoff,
which breaks the former.

This patch fixes the problem by moving the vm_pgoff assignment to a
function that is used only for GEM mmap path, so that the PRIME path
retains the original offset.

Cc: Daniel Kurtz &lt;djkurtz@chromium.org&gt;
Signed-off-by: Ørjan Eide &lt;orjan.eide@arm.com&gt;
Signed-off-by: Tomasz Figa &lt;tfiga@chromium.org&gt;
Signed-off-by: Sean Paul &lt;seanpaul@chromium.org&gt;
Signed-off-by: Thierry Escande &lt;thierry.escande@collabora.com&gt;
Tested-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Signed-off-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180130202913.28724-4-thierry.escande@collabora.com
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: Set vsc pack revision when DPCD revision is &gt;= 1.2</title>
<updated>2018-05-30T06:17:42+00:00</updated>
<author>
<name>Tao</name>
<email>xtao@amd.com</email>
</author>
<published>2018-02-08T21:04:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=944fc3fe9c0ca62052670975f366fd87e12c3675'/>
<id>944fc3fe9c0ca62052670975f366fd87e12c3675</id>
<content type='text'>
[ Upstream commit 3b94a4007dcfd4ac5780cd3d8a2d99979c966073 ]

Brightness couldn't change when booting up in DC mode.
It was because "psr_enabled" flag was not set to true before
setting vsc packet revision, causing packet rev setup was skipped.
Now instead of checking the psr flag, it checks if the DPCD_REV &gt;= 1.2
and set the vsc packet revision.

Signed-off-by: Tao &lt;xtao@amd.com&gt;
Reviewed-by: Tony Cheng &lt;Tony.Cheng@amd.com&gt;
Acked-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 3b94a4007dcfd4ac5780cd3d8a2d99979c966073 ]

Brightness couldn't change when booting up in DC mode.
It was because "psr_enabled" flag was not set to true before
setting vsc packet revision, causing packet rev setup was skipped.
Now instead of checking the psr flag, it checks if the DPCD_REV &gt;= 1.2
and set the vsc packet revision.

Signed-off-by: Tao &lt;xtao@amd.com&gt;
Reviewed-by: Tony Cheng &lt;Tony.Cheng@amd.com&gt;
Acked-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amdgpu: adjust timeout for ib_ring_tests(v2)</title>
<updated>2018-05-30T06:17:40+00:00</updated>
<author>
<name>Monk Liu</name>
<email>Monk.Liu@amd.com</email>
</author>
<published>2018-01-23T10:26:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=f65122de0d3a8f243543108fdd2a0bba7fc02122'/>
<id>f65122de0d3a8f243543108fdd2a0bba7fc02122</id>
<content type='text'>
[ Upstream commit dbf797655a43c6318ebb90b899e6583fcadc6472 ]

issue:
sometime GFX/MM ib test hit timeout under SRIOV env, root cause
is that engine doesn't come back soon enough so the current
IB test considered as timed out.

fix:
for SRIOV GFX IB test wait time need to be expanded a lot during
SRIOV runtimei mode since it couldn't really begin before GFX engine
come back.

for SRIOV MM IB test it always need more time since MM scheduling
is not go together with GFX engine, it is controled by h/w MM
scheduler so no matter runtime or exclusive mode MM IB test
always need more time.

v2:
use ring type instead of idx to judge

Signed-off-by: Monk Liu &lt;Monk.Liu@amd.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit dbf797655a43c6318ebb90b899e6583fcadc6472 ]

issue:
sometime GFX/MM ib test hit timeout under SRIOV env, root cause
is that engine doesn't come back soon enough so the current
IB test considered as timed out.

fix:
for SRIOV GFX IB test wait time need to be expanded a lot during
SRIOV runtimei mode since it couldn't really begin before GFX engine
come back.

for SRIOV MM IB test it always need more time since MM scheduling
is not go together with GFX engine, it is controled by h/w MM
scheduler so no matter runtime or exclusive mode MM IB test
always need more time.

v2:
use ring type instead of idx to judge

Signed-off-by: Monk Liu &lt;Monk.Liu@amd.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amdgpu: disable GFX ring and disable PQ wptr in hw_fini</title>
<updated>2018-05-30T06:17:40+00:00</updated>
<author>
<name>Monk Liu</name>
<email>Monk.Liu@amd.com</email>
</author>
<published>2018-01-29T11:24:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=2a87e7f31050550a3d001dfc2aeaea60351540a9'/>
<id>2a87e7f31050550a3d001dfc2aeaea60351540a9</id>
<content type='text'>
[ Upstream commit 9f0178fb67699992d38601cb923b434f9986dd68 ]

otherwise there will be DMAR reading error comes out from CP since
GFX is still alive and CPC's WPTR_POLL is still enabled, which would
lead to DMAR read error.

fix:
we can hault CPG after hw_fini, but cannot halt CPC becaues KIQ
stil need to be alive to let RLCV invoke, but its WPTR_POLL could
be disabled.

Signed-off-by: Monk Liu &lt;Monk.Liu@amd.com&gt;
Acked-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 9f0178fb67699992d38601cb923b434f9986dd68 ]

otherwise there will be DMAR reading error comes out from CP since
GFX is still alive and CPC's WPTR_POLL is still enabled, which would
lead to DMAR read error.

fix:
we can hault CPG after hw_fini, but cannot halt CPC becaues KIQ
stil need to be alive to let RLCV invoke, but its WPTR_POLL could
be disabled.

Signed-off-by: Monk Liu &lt;Monk.Liu@amd.com&gt;
Acked-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm: omapdrm: dss: Move initialization code from component bind to probe</title>
<updated>2018-05-30T06:17:40+00:00</updated>
<author>
<name>Laurent Pinchart</name>
<email>laurent.pinchart@ideasonboard.com</email>
</author>
<published>2018-02-11T13:07:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=9e279ef189c31a9d819df2875253910708e2478c'/>
<id>9e279ef189c31a9d819df2875253910708e2478c</id>
<content type='text'>
[ Upstream commit 215003b4ae1d47035092fef73b6a22aa82037091 ]

There's no reason to delay initialization of most of the driver (such as
mapping memory I/O, getting clocks or enabling runtime PM) to the
component master bind handler.

This additionally fixes a real PM issue caused enabling runtime PM in
the bind handler.

The bind handler performs the following sequence of PM operations:

	pm_runtime_enable(dev);
	pm_runtime_get_sync(dev);

	... (access the hardware to read the device revision) ...

	pm_runtime_put_sync(dev);

If a failure occurs at this point, the error path calls
pm_runtime_disable() to balance the pm_runtime_enable() call.

To understand the problem, it should be noted that the bind handler is
called when one of the component registers itself, which happens in the
component's probe handler. Furthermore, as the components are children
of the DSS, the device core calls pm_runtime_get_sync() on the DSS
platform device before calling the component's probe handler. This
increases the DSS power usage count but doesn't runtime resume the
device, as runtime PM is disabled at that point.

The bind handler is thus called with runtime PM disabled, with the
device runtime suspended, but with the power usage count larger than 0.
The pm_runtime_get_sync() call will thus further increase the power
usage count and runtime resume the device. The pm_runtime_put_sync()
handler will decrease the power usage count to a non-zero value and will
thus not suspend the device. Finally, the pm_runtime_disable() call will
disable runtime PM, preventing the pm_runtime_put() call in the device
core from runtime suspending the device. The DSS device is thus left
powered on.

To fix this, move the initialization code from the bind handler to the
probe handler.

Signed-off-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Reviewed-by: Sebastian Reichel &lt;sebastian.reichel@collabora.co.uk&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 215003b4ae1d47035092fef73b6a22aa82037091 ]

There's no reason to delay initialization of most of the driver (such as
mapping memory I/O, getting clocks or enabling runtime PM) to the
component master bind handler.

This additionally fixes a real PM issue caused enabling runtime PM in
the bind handler.

The bind handler performs the following sequence of PM operations:

	pm_runtime_enable(dev);
	pm_runtime_get_sync(dev);

	... (access the hardware to read the device revision) ...

	pm_runtime_put_sync(dev);

If a failure occurs at this point, the error path calls
pm_runtime_disable() to balance the pm_runtime_enable() call.

To understand the problem, it should be noted that the bind handler is
called when one of the component registers itself, which happens in the
component's probe handler. Furthermore, as the components are children
of the DSS, the device core calls pm_runtime_get_sync() on the DSS
platform device before calling the component's probe handler. This
increases the DSS power usage count but doesn't runtime resume the
device, as runtime PM is disabled at that point.

The bind handler is thus called with runtime PM disabled, with the
device runtime suspended, but with the power usage count larger than 0.
The pm_runtime_get_sync() call will thus further increase the power
usage count and runtime resume the device. The pm_runtime_put_sync()
handler will decrease the power usage count to a non-zero value and will
thus not suspend the device. Finally, the pm_runtime_disable() call will
disable runtime PM, preventing the pm_runtime_put() call in the device
core from runtime suspending the device. The DSS device is thus left
powered on.

To fix this, move the initialization code from the bind handler to the
probe handler.

Signed-off-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Reviewed-by: Sebastian Reichel &lt;sebastian.reichel@collabora.co.uk&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amdgpu: Clean sdma wptr register when only enable wptr polling</title>
<updated>2018-05-30T06:17:38+00:00</updated>
<author>
<name>Emily Deng</name>
<email>Emily.Deng@amd.com</email>
</author>
<published>2018-03-07T01:47:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=4ad141b198ca7e6c805f0d71e03f53aee7824069'/>
<id>4ad141b198ca7e6c805f0d71e03f53aee7824069</id>
<content type='text'>
[ Upstream commit 4062119b9d958df33bcda703dc3ac646908fa861 ]

The sdma wptr polling memory is not fast enough, then the sdma
wptr register will be random, and not equal to sdma rptr, which
will cause sdma engine hang when load driver, so clean up the sdma
wptr directly to fix this issue.

v2:add comment above the code and correct coding style

Reviewed-by: Xiangliang Yu &lt;Xiangliang.Yu@amd.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Emily Deng &lt;Emily.Deng@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 4062119b9d958df33bcda703dc3ac646908fa861 ]

The sdma wptr polling memory is not fast enough, then the sdma
wptr register will be random, and not equal to sdma rptr, which
will cause sdma engine hang when load driver, so clean up the sdma
wptr directly to fix this issue.

v2:add comment above the code and correct coding style

Reviewed-by: Xiangliang Yu &lt;Xiangliang.Yu@amd.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Emily Deng &lt;Emily.Deng@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
