<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/gpu/drm/amd/display/modules, branch v5.8</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v5.8</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v5.8'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2020-06-10T22:00:24Z</updated>
<entry>
<title>drm/amd/display: Use kfree() to free rgb_user in calculate_user_regamma_ramp()</title>
<updated>2020-06-10T22:00:24Z</updated>
<author>
<name>Denis Efremov</name>
<email>efremov@linux.com</email>
</author>
<published>2020-06-05T17:37:44Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=43a562774fceba867e8eebba977d7d42f8a2eac7'/>
<id>urn:sha1:43a562774fceba867e8eebba977d7d42f8a2eac7</id>
<content type='text'>
Use kfree() instead of kvfree() to free rgb_user in
calculate_user_regamma_ramp() because the memory is allocated with
kcalloc().

Signed-off-by: Denis Efremov &lt;efremov@linux.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Use kvfree() to free coeff in build_regamma()</title>
<updated>2020-06-10T22:00:24Z</updated>
<author>
<name>Denis Efremov</name>
<email>efremov@linux.com</email>
</author>
<published>2020-06-05T17:37:43Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=81921a828b94ce2816932c19a5ec74d302972833'/>
<id>urn:sha1:81921a828b94ce2816932c19a5ec74d302972833</id>
<content type='text'>
Use kvfree() instead of kfree() to free coeff in build_regamma()
because the memory is allocated with kvzalloc().

Fixes: e752058b8671 ("drm/amd/display: Optimize gamma calculations")
Cc: stable@vger.kernel.org
Signed-off-by: Denis Efremov &lt;efremov@linux.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: correct rn NUM_VMID</title>
<updated>2020-05-21T16:48:43Z</updated>
<author>
<name>Dmytro Laktyushkin</name>
<email>Dmytro.Laktyushkin@amd.com</email>
</author>
<published>2020-05-04T19:34:30Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=fdcf62fbfb288f4cb050c02c5ab9bc58fc53a872'/>
<id>urn:sha1:fdcf62fbfb288f4cb050c02c5ab9bc58fc53a872</id>
<content type='text'>
Save the correct num vmid during resource creation and fix RN gpuvm
level from 1 to 16 vmid entries.

Signed-off-by: Dmytro Laktyushkin &lt;Dmytro.Laktyushkin@amd.com&gt;
Reviewed-by: Eric Bernstein &lt;Eric.Bernstein@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: move location of dmub_srv.h file</title>
<updated>2020-05-05T17:12:33Z</updated>
<author>
<name>Anthony Koo</name>
<email>Anthony.Koo@amd.com</email>
</author>
<published>2020-04-22T02:01:58Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=cdca3f218d9bbe086b0df9bc95b4f0c0d1011415'/>
<id>urn:sha1:cdca3f218d9bbe086b0df9bc95b4f0c0d1011415</id>
<content type='text'>
[Why]
Make a separation of what belongs in the differen dmub
headers

dmub_srv.h is for exposing dmub srv interface to rest of
driver.

other headers inside dmub/inc exposes cmds and definitions
that are owned by the firmware

[How]
keep firmware owned definitions in dmub/inc

move stuff that is purely driver interface headers to dmub/
since those are interface calls that are defined for rest of
driver to use

Signed-off-by: Anthony Koo &lt;Anthony.Koo@amd.com&gt;
Reviewed-by: Aric Cyr &lt;Aric.Cyr@amd.com&gt;
Acked-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Acked-by: Aurabindo Pillai &lt;aurabindo.pillai@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: remove unused module/stats</title>
<updated>2020-05-05T17:12:26Z</updated>
<author>
<name>Aurabindo Pillai</name>
<email>aurabindo.pillai@amd.com</email>
</author>
<published>2020-04-30T15:55:36Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=b5decb5c66d28ebdef2eb2a1898bfd2b257f85f3'/>
<id>urn:sha1:b5decb5c66d28ebdef2eb2a1898bfd2b257f85f3</id>
<content type='text'>
Signed-off-by: Aurabindo Pillai &lt;aurabindo.pillai@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: add addition dc type to translate to dmub fw type</title>
<updated>2020-05-05T17:11:49Z</updated>
<author>
<name>Anthony Koo</name>
<email>Anthony.Koo@amd.com</email>
</author>
<published>2020-04-22T02:01:30Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=1cfbbddead0abd8551ad2da5630cefea0a4289a6'/>
<id>urn:sha1:1cfbbddead0abd8551ad2da5630cefea0a4289a6</id>
<content type='text'>
[Why]
For a type like PSR version, it makes sense for most of the code
to include a dc type, instead of having this a fw type define since
this is a capability and type exposed by dc.

Especially if it doesn't even need to communicate with the fw.

The code that is packing the firmware command message
should be the one who needs to translate the psr version
into a command that the firmware understands.

[How]
Add a dc_psr_version enum.

Signed-off-by: Anthony Koo &lt;Anthony.Koo@amd.com&gt;
Reviewed-by: Aric Cyr &lt;Aric.Cyr@amd.com&gt;
Acked-by: Aurabindo Pillai &lt;aurabindo.pillai@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Internal refactoring to abstract color caps</title>
<updated>2020-04-28T20:19:48Z</updated>
<author>
<name>Krunoslav Kovac</name>
<email>Krunoslav.Kovac@amd.com</email>
</author>
<published>2020-04-22T22:08:02Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a8bf7164908827178fe31fb21d2646c404c1990d'/>
<id>urn:sha1:a8bf7164908827178fe31fb21d2646c404c1990d</id>
<content type='text'>
[Why&amp;How]
modules/color calculates various colour operations which are translated
to abstracted HW. DCE 5-12 had almost no important changes, but
starting with DCN1, every new generation comes with fairly major
differences in color pipeline.
We would hack it with some DCN checks, but a better approach is to
abstract color pipe capabilities so modules/DM can decide mapping to
HW block based on logical capabilities,

Signed-off-by: Krunoslav Kovac &lt;Krunoslav.Kovac@amd.com&gt;
Reviewed-by: Aric Cyr &lt;Aric.Cyr@amd.com&gt;
Acked-by: Anthony Koo &lt;Anthony.Koo@amd.com&gt;
Acked-by: Aurabindo Pillai &lt;aurabindo.pillai@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Convert memory from cpu to fw endianness correctly</title>
<updated>2020-04-22T22:11:48Z</updated>
<author>
<name>Wyatt Wood</name>
<email>wyatt.wood@amd.com</email>
</author>
<published>2020-04-17T18:10:23Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a42c1ed50aafc29efa54ddb0524c86b1697ff13a'/>
<id>urn:sha1:a42c1ed50aafc29efa54ddb0524c86b1697ff13a</id>
<content type='text'>
[Why]
Current code does not guarantee the correct endianness of memory being
copied to fw, specifically in the case where cpu isn't little endian.

[How]
Windows and Diags are always little endian, so we define a macro that
does nothing. Linux already defines this macro and will do the correct
endianness conversion.

Signed-off-by: Wyatt Wood &lt;wyatt.wood@amd.com&gt;
Reviewed-by: Harry Wentland &lt;Harry.Wentland@amd.com&gt;
Acked-by: Anthony Koo &lt;Anthony.Koo@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Change infopacket type programming</title>
<updated>2020-04-22T22:11:47Z</updated>
<author>
<name>Haiyi Zhou</name>
<email>haiyi.zhou@amd.com</email>
</author>
<published>2020-04-03T14:00:58Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d2bacc38f6caa96e6d67d2e3e2bd0aee36de6954'/>
<id>urn:sha1:d2bacc38f6caa96e6d67d2e3e2bd0aee36de6954</id>
<content type='text'>
[Why]
Certain displays may experience blanking if infopacket max range does
not equal nominal refresh rate.

[How]
Add additional infopacket versions to program range to full or forced
range in freesync states.
This does not change the vrr logic.

Signed-off-by: Haiyi Zhou &lt;haiyi.zhou@amd.com&gt;
Reviewed-by: Anthony Koo &lt;Anthony.Koo@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Check ramp != NULL before applying lut1d for degamma</title>
<updated>2020-04-22T22:11:47Z</updated>
<author>
<name>Nicholas Kazlauskas</name>
<email>nicholas.kazlauskas@amd.com</email>
</author>
<published>2020-03-31T20:45:31Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d652509e7a244761755403a2ae3fb6c96183226e'/>
<id>urn:sha1:d652509e7a244761755403a2ae3fb6c96183226e</id>
<content type='text'>
[Why]
A NULL ramp is a valid configuration for passing into
mod_color_calculate_degamma_params but we'll hit a NULL pointer if we do
so.

We need this in order to get the right transfer function to do degamma
on NV12 formats where we aren't supplied with a custom user degamma.

[How]
Add the NULL check.

Signed-off-by: Nicholas Kazlauskas &lt;nicholas.kazlauskas@amd.com&gt;
Reviewed-by: Zhan Liu &lt;Zhan.Liu@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
</feed>
