<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/amd, branch v4.19.68</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.68</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.68'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2019-08-25T08:47:55+00:00</updated>
<entry>
<title>drm/amdgpu: fix a potential information leaking bug</title>
<updated>2019-08-25T08:47:55+00:00</updated>
<author>
<name>Wang Xiayang</name>
<email>xywang.sjtu@sjtu.edu.cn</email>
</author>
<published>2019-07-27T09:30:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=68340db992f6704b86a27e3f9f91d44ce1c8cb31'/>
<id>urn:sha1:68340db992f6704b86a27e3f9f91d44ce1c8cb31</id>
<content type='text'>
[ Upstream commit 929e571c04c285861e0bb049a396a2bdaea63282 ]

Coccinelle reports a path that the array "data" is never initialized.
The path skips the checks in the conditional branches when either
of callback functions, read_wave_vgprs and read_wave_sgprs, is not
registered. Later, the uninitialized "data" array is read
in the while-loop below and passed to put_user().

Fix the path by allocating the array with kcalloc().

The patch is simplier than adding a fall-back branch that explicitly
calls memset(data, 0, ...). Also it does not need the multiplication
1024*sizeof(*data) as the size parameter for memset() though there is
no risk of integer overflow.

Signed-off-by: Wang Xiayang &lt;xywang.sjtu@sjtu.edu.cn&gt;
Reviewed-by: Chunming Zhou &lt;david1.zhou@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;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/amd/display: fix compilation error</title>
<updated>2019-07-31T05:27:00+00:00</updated>
<author>
<name>Hariprasad Kelam</name>
<email>hariprasad.kelam@gmail.com</email>
</author>
<published>2019-06-13T02:32:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6a7047471073c2cf8e375b2fe5a71bacf9799973'/>
<id>urn:sha1:6a7047471073c2cf8e375b2fe5a71bacf9799973</id>
<content type='text'>
[ Upstream commit 88099f53cc3717437f5fc9cf84205c5b65118377 ]

this patch fixes below compilation error

drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c: In
function ‘dcn10_apply_ctx_for_surface’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:2378:3:
error: implicit declaration of function ‘udelay’
[-Werror=implicit-function-declaration]
   udelay(underflow_check_delay_us);

Signed-off-by: Hariprasad Kelam &lt;hariprasad.kelam@gmail.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: Always allocate initial connector state state</title>
<updated>2019-07-31T05:27:00+00:00</updated>
<author>
<name>Nicholas Kazlauskas</name>
<email>nicholas.kazlauskas@amd.com</email>
</author>
<published>2019-06-04T19:21:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=11b4e9f3695c155f71cb2bc56d761284bf5e65b1'/>
<id>urn:sha1:11b4e9f3695c155f71cb2bc56d761284bf5e65b1</id>
<content type='text'>
[ Upstream commit f04bee34d6e35df26cbb2d65e801adfd0d8fe20d ]

[Why]
Unlike our regular connectors, MST connectors don't start off with
an initial connector state. This causes a NULL pointer dereference to
occur when attaching the bpc property since it tries to modify the
connector state.

We need an initial connector state on the connector to avoid the crash.

[How]
Use our reset helper to allocate an initial state and reset the values
to their defaults. We were already doing this before, just not for
MST connectors.

Signed-off-by: Nicholas Kazlauskas &lt;nicholas.kazlauskas@amd.com&gt;
Reviewed-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/amdkfd: Fix sdma queue map issue</title>
<updated>2019-07-31T05:26:58+00:00</updated>
<author>
<name>Oak Zeng</name>
<email>Oak.Zeng@amd.com</email>
</author>
<published>2019-02-08T21:44:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=210dfe6309112dd028bf06561b828a749b6e1169'/>
<id>urn:sha1:210dfe6309112dd028bf06561b828a749b6e1169</id>
<content type='text'>
[ Upstream commit 065e4bdfa1f3ab2884c110394d8b7e7ebe3b988c ]

Previous codes assumes there are two sdma engines.
This is not true e.g., Raven only has 1 SDMA engine.
Fix the issue by using sdma engine number info in
device_info.

Signed-off-by: Oak Zeng &lt;Oak.Zeng@amd.com&gt;
Reviewed-by: Felix Kuehling &lt;Felix.Kuehling@amd.com&gt;
Signed-off-by: Felix Kuehling &lt;Felix.Kuehling@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/amdkfd: Fix a potential memory leak</title>
<updated>2019-07-31T05:26:58+00:00</updated>
<author>
<name>Oak Zeng</name>
<email>ozeng@amd.com</email>
</author>
<published>2018-11-28T04:08:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=db64bc13944013357d231cbf9d1aee798d7b9892'/>
<id>urn:sha1:db64bc13944013357d231cbf9d1aee798d7b9892</id>
<content type='text'>
[ Upstream commit e73390d181103a19e1111ec2f25559a0570e9fe0 ]

Free mqd_mem_obj it GTT buffer allocation for MQD+control stack fails.

Signed-off-by: Oak Zeng &lt;ozeng@amd.com&gt;
Reviewed-by: Felix Kuehling &lt;Felix.Kuehling@amd.com&gt;
Signed-off-by: Felix Kuehling &lt;Felix.Kuehling@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>
</feed>
