<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu, branch v4.19.67</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.67</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.67'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2019-08-16T08:12:51+00:00</updated>
<entry>
<title>drm/i915: Fix wrong escape clock divisor init for GLK</title>
<updated>2019-08-16T08:12:51+00:00</updated>
<author>
<name>Stanislav Lisovskiy</name>
<email>stanislav.lisovskiy@intel.com</email>
</author>
<published>2019-07-12T08:19:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=edc388566a1d25f88e631bd8170462d4f86c5a24'/>
<id>urn:sha1:edc388566a1d25f88e631bd8170462d4f86c5a24</id>
<content type='text'>
commit 73a0ff0b30af79bf0303d557eb82f1d1945bb6ee upstream.

According to Bspec clock divisor registers in GeminiLake
should be initialized by shifting 1(&lt;&lt;) to amount of correspondent
divisor. While i915 was writing all this time that value as is.

Surprisingly that it by accident worked, until we met some issues
with Microtech Etab.

v2: Added Fixes tag and cc
v3: Added stable to cc as well.

Signed-off-by: Stanislav Lisovskiy &lt;stanislav.lisovskiy@intel.com&gt;
Reviewed-by: Vandita Kulkarni &lt;vandita.kulkarni@intel.com&gt;
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108826
Fixes: bcc657004841 ("drm/i915/glk: Program txesc clock divider for GLK")
Cc: Deepak M &lt;m.deepak@intel.com&gt;
Cc: Madhav Chauhan &lt;madhav.chauhan@intel.com&gt;
Cc: Jani Nikula &lt;jani.nikula@intel.com&gt;
Cc: Jani Nikula &lt;jani.nikula@linux.intel.com&gt;
Cc: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Cc: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Cc: intel-gfx@lists.freedesktop.org
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190712081938.14185-1-stanislav.lisovskiy@intel.com
(cherry picked from commit ce52ad5dd52cfaf3398058384e0ff94134bbd89c)
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm: silence variable 'conn' set but not used</title>
<updated>2019-08-16T08:12:46+00:00</updated>
<author>
<name>Qian Cai</name>
<email>cai@lca.pw</email>
</author>
<published>2019-07-22T19:14:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=991c4756be69417f720734ceb32a22071e0aa0af'/>
<id>urn:sha1:991c4756be69417f720734ceb32a22071e0aa0af</id>
<content type='text'>
[ Upstream commit bbb6fc43f131f77fcb7ae8081f6d7c51396a2120 ]

The "struct drm_connector" iteration cursor from
"for_each_new_connector_in_state" is never used in atomic_remove_fb()
which generates a compilation warning,

drivers/gpu/drm/drm_framebuffer.c: In function 'atomic_remove_fb':
drivers/gpu/drm/drm_framebuffer.c:838:24: warning: variable 'conn' set
but not used [-Wunused-but-set-variable]

Silence it by marking "conn" __maybe_unused.

Signed-off-by: Qian Cai &lt;cai@lca.pw&gt;
Signed-off-by: Sean Paul &lt;seanpaul@chromium.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/1563822886-13570-1-git-send-email-cai@lca.pw
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Increase size of audios array</title>
<updated>2019-08-16T08:12:45+00:00</updated>
<author>
<name>Tai Man</name>
<email>taiman.wong@amd.com</email>
</author>
<published>2019-06-28T15:40:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8d641499bf969a284161d2682b71669c96389773'/>
<id>urn:sha1:8d641499bf969a284161d2682b71669c96389773</id>
<content type='text'>
[ Upstream commit 7352193a33dfc9b69ba3bf6a8caea925b96243b1 ]

[Why]
The audios array defined in "struct resource_pool" is only 6 (MAX_PIPES)
but the max number of audio devices (num_audio) is 7. In some projects,
it will run out of audios array.

[How]
Incraese the audios array size to 7.

Signed-off-by: Tai Man &lt;taiman.wong@amd.com&gt;
Reviewed-by: Joshua Aberback &lt;Joshua.Aberback@amd.com&gt;
Acked-by: Leo Li &lt;sunpeng.li@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Only enable audio if speaker allocation exists</title>
<updated>2019-08-16T08:12:45+00:00</updated>
<author>
<name>Alvin Lee</name>
<email>alvin.lee2@amd.com</email>
</author>
<published>2019-07-04T19:17:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f9420bfa29f9ece0b02a5435ae95f1a48bc97723'/>
<id>urn:sha1:f9420bfa29f9ece0b02a5435ae95f1a48bc97723</id>
<content type='text'>
[ Upstream commit 6ac25e6d5b2fbf251e9fa2f4131d42c815b43867 ]

[Why]

In dm_helpers_parse_edid_caps, there is a corner case where no speakers
can be allocated even though the audio mode count is greater than 0.
Enabling audio when no speaker allocations exists can cause issues in
the video stream.

[How]

Add a check to not enable audio unless one or more speaker allocations
exist (since doing this can cause issues in the video stream).

Signed-off-by: Alvin Lee &lt;alvin.lee2@amd.com&gt;
Reviewed-by: Jun Lei &lt;Jun.Lei@amd.com&gt;
Acked-by: Leo Li &lt;sunpeng.li@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Fix dc_create failure handling and 666 color depths</title>
<updated>2019-08-16T08:12:45+00:00</updated>
<author>
<name>Julian Parkin</name>
<email>julian.parkin@amd.com</email>
</author>
<published>2019-06-25T18:55:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3998e684463a7fa1721c171172ca085978d03a00'/>
<id>urn:sha1:3998e684463a7fa1721c171172ca085978d03a00</id>
<content type='text'>
[ Upstream commit 0905f32977268149f06e3ce6ea4bd6d374dd891f ]

[Why]
It is possible (but very unlikely) that constructing dc fails
before current_state is created.

We support 666 color depth in some scenarios, but this
isn't handled in get_norm_pix_clk. It uses exactly the
same pixel clock as the 888 case.

[How]
Check for non null current_state before destructing.

Add case for 666 color depth to get_norm_pix_clk to
avoid assertion.

Signed-off-by: Julian Parkin &lt;julian.parkin@amd.com&gt;
Reviewed-by: Charlene Liu &lt;Charlene.Liu@amd.com&gt;
Acked-by: Leo Li &lt;sunpeng.li@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: use encoder's engine id to find matched free audio device</title>
<updated>2019-08-16T08:12:44+00:00</updated>
<author>
<name>Tai Man</name>
<email>taiman.wong@amd.com</email>
</author>
<published>2019-06-07T21:32:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e7a8a794109c07e0b8d7bd55fbfcb3082991626a'/>
<id>urn:sha1:e7a8a794109c07e0b8d7bd55fbfcb3082991626a</id>
<content type='text'>
[ Upstream commit 74eda776d7a4e69ec7aa1ce30a87636f14220fbb ]

[Why]
On some platforms, the encoder id 3 is not populated. So the encoders
are not stored in right order as index (id: 0, 1, 2, 4, 5) at pool. This
would cause encoders id 4 &amp; id 5 to fail when finding corresponding
audio device, defaulting to the first available audio device. As result,
we cannot stream audio into two DP ports with encoders id 4 &amp; id 5.

[How]
It need to create enough audio device objects (0 - 5) to perform matching.
Then use encoder engine id to find matched audio device.

Signed-off-by: Tai Man &lt;taiman.wong@amd.com&gt;
Reviewed-by: Charlene Liu &lt;Charlene.Liu@amd.com&gt;
Acked-by: Leo Li &lt;sunpeng.li@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Wait for backlight programming completion in set backlight level</title>
<updated>2019-08-16T08:12:44+00:00</updated>
<author>
<name>SivapiriyanKumarasamy</name>
<email>sivapiriyan.kumarasamy@amd.com</email>
</author>
<published>2019-06-14T19:04:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2a5e21adc71b46beec9232cc6418676fd2255bc5'/>
<id>urn:sha1:2a5e21adc71b46beec9232cc6418676fd2255bc5</id>
<content type='text'>
[ Upstream commit c7990daebe71d11a9e360b5c3b0ecd1846a3a4bb ]

[WHY]
Currently we don't wait for blacklight programming completion in DMCU
when setting backlight level. Some sequences such as PSR static screen
event trigger reprogramming requires it to be complete.

[How]
Add generic wait for dmcu command completion in set backlight level.

Signed-off-by: SivapiriyanKumarasamy &lt;sivapiriyan.kumarasamy@amd.com&gt;
Reviewed-by: Anthony Koo &lt;Anthony.Koo@amd.com&gt;
Acked-by: Leo Li &lt;sunpeng.li@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/i915/gvt: fix incorrect cache entry for guest page mapping</title>
<updated>2019-08-06T17:06:56+00:00</updated>
<author>
<name>Xiaolin Zhang</name>
<email>xiaolin.zhang@intel.com</email>
</author>
<published>2019-07-17T17:10:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a7340d31abacf60efb68b299829c85e171878eae'/>
<id>urn:sha1:a7340d31abacf60efb68b299829c85e171878eae</id>
<content type='text'>
commit 7366aeb77cd840f3edea02c65065d40affaa7f45 upstream.

GPU hang observed during the guest OCL conformance test which is caused
by THP GTT feature used durning the test.

It was observed the same GFN with different size (4K and 2M) requested
from the guest in GVT. So during the guest page dma map stage, it is
required to unmap first with orginal size and then remap again with
requested size.

Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M huge gtt support")
Cc: stable@vger.kernel.org
Reviewed-by: Zhenyu Wang &lt;zhenyuw@linux.intel.com&gt;
Signed-off-by: Xiaolin Zhang &lt;xiaolin.zhang@intel.com&gt;
Signed-off-by: Zhenyu Wang &lt;zhenyuw@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/nouveau: fix memory leak in nouveau_conn_reset()</title>
<updated>2019-08-06T17:06:53+00:00</updated>
<author>
<name>Yongxin Liu</name>
<email>yongxin.liu@windriver.com</email>
</author>
<published>2019-07-01T01:46:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4c6500b5328f313e0d0427568a7691ee3865ce64'/>
<id>urn:sha1:4c6500b5328f313e0d0427568a7691ee3865ce64</id>
<content type='text'>
[ Upstream commit 09b90e2fe35faeace2488234e2a7728f2ea8ba26 ]

In nouveau_conn_reset(), if connector-&gt;state is true,
__drm_atomic_helper_connector_destroy_state() will be called,
but the memory pointed by asyc isn't freed. Memory leak happens
in the following function __drm_atomic_helper_connector_reset(),
where newly allocated asyc-&gt;state will be assigned to connector-&gt;state.

So using nouveau_conn_atomic_destroy_state() instead of
__drm_atomic_helper_connector_destroy_state to free the "old" asyc.

Here the is the log showing memory leak.

unreferenced object 0xffff8c5480483c80 (size 192):
  comm "kworker/0:2", pid 188, jiffies 4294695279 (age 53.179s)
  hex dump (first 32 bytes):
    00 f0 ba 7b 54 8c ff ff 00 00 00 00 00 00 00 00  ...{T...........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;000000005005c0d0&gt;] kmem_cache_alloc_trace+0x195/0x2c0
    [&lt;00000000a122baed&gt;] nouveau_conn_reset+0x25/0xc0 [nouveau]
    [&lt;000000004fd189a2&gt;] nouveau_connector_create+0x3a7/0x610 [nouveau]
    [&lt;00000000c73343a8&gt;] nv50_display_create+0x343/0x980 [nouveau]
    [&lt;000000002e2b03c3&gt;] nouveau_display_create+0x51f/0x660 [nouveau]
    [&lt;00000000c924699b&gt;] nouveau_drm_device_init+0x182/0x7f0 [nouveau]
    [&lt;00000000cc029436&gt;] nouveau_drm_probe+0x20c/0x2c0 [nouveau]
    [&lt;000000007e961c3e&gt;] local_pci_probe+0x47/0xa0
    [&lt;00000000da14d569&gt;] work_for_cpu_fn+0x1a/0x30
    [&lt;0000000028da4805&gt;] process_one_work+0x27c/0x660
    [&lt;000000001d415b04&gt;] worker_thread+0x22b/0x3f0
    [&lt;0000000003b69f1f&gt;] kthread+0x12f/0x150
    [&lt;00000000c94c29b7&gt;] ret_from_fork+0x3a/0x50

Signed-off-by: Yongxin Liu &lt;yongxin.liu@windriver.com&gt;
Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/msm: Depopulate platform on probe failure</title>
<updated>2019-07-31T05:27:01+00:00</updated>
<author>
<name>Sean Paul</name>
<email>seanpaul@chromium.org</email>
</author>
<published>2019-06-17T20:12:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e7f206f42fb64adc8a4b9b0ea24d4e2c666c9cb9'/>
<id>urn:sha1:e7f206f42fb64adc8a4b9b0ea24d4e2c666c9cb9</id>
<content type='text'>
[ Upstream commit 4368a1539c6b41ac3cddc06f5a5117952998804c ]

add_display_components() calls of_platform_populate, and we depopluate
on pdev remove, but not when probe fails. So if we get a probe deferral
in one of the components, we won't depopulate the platform. This causes
the core to keep references to devices which should be destroyed, which
causes issues when those same devices try to re-initialize on the next
probe attempt.

I think this is the reason we had issues with the gmu's device-managed
resources on deferral (worked around in commit 94e3a17f33a5).

Reviewed-by: Rob Clark &lt;robdclark@chromium.org&gt;
Signed-off-by: Sean Paul &lt;seanpaul@chromium.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190617201301.133275-3-sean@poorly.run
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
