<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/include/drm, branch v6.6.36</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.6.36</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.6.36'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2024-06-12T09:12:05Z</updated>
<entry>
<title>drm/edid: Parse topology block for all DispID structure v1.x</title>
<updated>2024-06-12T09:12:05Z</updated>
<author>
<name>Ville Syrjälä</name>
<email>ville.syrjala@linux.intel.com</email>
</author>
<published>2024-04-10T18:01:39Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=6040fcea46055159c5cafc95cd6f63e06028086b'/>
<id>urn:sha1:6040fcea46055159c5cafc95cd6f63e06028086b</id>
<content type='text'>
[ Upstream commit e0a200ab4b72afd581bd6f82fc1ef510a4fb5478 ]

DisplayID spec v1.3 revision history notes do claim that
the toplogy block was added in v1.3 so requiring structure
v1.2 would seem correct, but there is at least one EDID in
edid.tv with a topology block and structure v1.0. And
there are also EDIDs with DisplayID structure v1.3 which
seems to be totally incorrect as DisplayID spec v1.3 lists
structure v1.2 as the only legal value.

Unfortunately I couldn't find copies of DisplayID spec
v1.0-v1.2 anywhere (even on vesa.org), so I'll have to
go on empirical evidence alone.

We used to parse the topology block on all v1.x
structures until the check for structure v2.0 was added.
Let's go back to doing that as the evidence does suggest
that there are DisplayIDs in the wild that would miss
out on the topology stuff otherwise.

Also toss out DISPLAY_ID_STRUCTURE_VER_12 entirely as
it doesn't appear we can really use it for anything.

I *think* we could technically skip all the structure
version checks as the block tags shouldn't conflict
between v2.0 and v1.x. But no harm in having a bit of
extra sanity checks I guess.

So far I'm not aware of any user reported regressions
from overly strict check, but I do know that it broke
igt/kms_tiled_display's fake DisplayID as that one
gets generated with structure v1.0.

Cc: Jani Nikula &lt;jani.nikula@intel.com&gt;
Cc: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Fixes: c5a486af9df7 ("drm/edid: parse Tiled Display Topology Data Block for DisplayID 2.0")
Signed-off-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20240410180139.21352-1-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/mipi-dsi: use correct return type for the DSC functions</title>
<updated>2024-06-12T09:12:04Z</updated>
<author>
<name>Dmitry Baryshkov</name>
<email>dmitry.baryshkov@linaro.org</email>
</author>
<published>2024-04-07T23:53:51Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=dda6efae161dc200b449d9099d0dfadfa75275c9'/>
<id>urn:sha1:dda6efae161dc200b449d9099d0dfadfa75275c9</id>
<content type='text'>
[ Upstream commit de1c705c50326acaceaf1f02bc5bf6f267c572bd ]

The functions mipi_dsi_compression_mode() and
mipi_dsi_picture_parameter_set() return 0-or-error rather than a buffer
size. Follow example of other similar MIPI DSI functions and use int
return type instead of size_t.

Fixes: f4dea1aaa9a1 ("drm/dsi: add helpers for DSI compression mode and PPS packets")
Reviewed-by: Marijn Suijten &lt;marijn.suijten@somainline.org&gt;
Reviewed-by: Jessica Zhang &lt;quic_jesszhan@quicinc.com&gt;
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20240408-lg-sw43408-panel-v5-2-4e092da22991@linaro.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/dp: Don't attempt AUX transfers when eDP panels are not powered</title>
<updated>2024-06-12T09:11:57Z</updated>
<author>
<name>Douglas Anderson</name>
<email>dianders@chromium.org</email>
</author>
<published>2024-02-02T22:11:16Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9429b12dfcbd7eca89795730305cd1400bf97ec9'/>
<id>urn:sha1:9429b12dfcbd7eca89795730305cd1400bf97ec9</id>
<content type='text'>
[ Upstream commit 8df1ddb5bf11ab820ad991e164dab82c0960add9 ]

If an eDP panel is not powered on then any attempts to talk to it over
the DP AUX channel will timeout. Unfortunately these attempts may be
quite slow. Userspace can initiate these attempts either via a
/dev/drm_dp_auxN device or via the created i2c device.

Making the DP AUX drivers timeout faster is a difficult proposition.
In theory we could just poll the panel's HPD line in the AUX transfer
function and immediately return an error there. However, this is
easier said than done. For one thing, there's no hard requirement to
hook the HPD line up for eDP panels and it's OK to just delay a fixed
amount. For another thing, the HPD line may not be fast to probe. On
parade-ps8640 we need to wait for the bridge chip's firmware to boot
before we can get the HPD line and this is a slow process.

The fact that the transfers are taking so long to timeout is causing
real problems. The open source fwupd daemon sometimes scans DP busses
looking for devices whose firmware need updating. If it happens to
scan while a panel is turned off this scan can take a long time. The
fwupd daemon could try to be smarter and only scan when eDP panels are
turned on, but we can also improve the behavior in the kernel.

Let's let eDP panels drivers specify that a panel is turned off and
then modify the common AUX transfer code not to attempt a transfer in
this case.

Tested-by: Steev Klimaszewski &lt;steev@kali.org&gt;
Reviewed-by: Hsin-Yi Wang &lt;hsinyi@chromium.org&gt;
Tested-by: Eizan Miyamoto &lt;eizan@chromium.org&gt;
Acked-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Signed-off-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20240202141109.1.I24277520ac754ea538c9b14578edc94e1df11b48@changeid
Stable-dep-of: 5e842d55bad7 ("drm/panel: atna33xc20: Fix unbalanced regulator in the case HPD doesn't assert")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mm, treewide: introduce NR_PAGE_ORDERS</title>
<updated>2024-05-02T14:32:41Z</updated>
<author>
<name>Kirill A. Shutemov</name>
<email>kirill.shutemov@linux.intel.com</email>
</author>
<published>2023-12-28T14:47:03Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ded1ffea52132e58eaaa7d4ea39477f911796a40'/>
<id>urn:sha1:ded1ffea52132e58eaaa7d4ea39477f911796a40</id>
<content type='text'>
[ Upstream commit fd37721803c6e73619108f76ad2e12a9aa5fafaf ]

NR_PAGE_ORDERS defines the number of page orders supported by the page
allocator, ranging from 0 to MAX_ORDER, MAX_ORDER + 1 in total.

NR_PAGE_ORDERS assists in defining arrays of page orders and allows for
more natural iteration over them.

[kirill.shutemov@linux.intel.com: fixup for kerneldoc warning]
  Link: https://lkml.kernel.org/r/20240101111512.7empzyifq7kxtzk3@box
Link: https://lkml.kernel.org/r/20231228144704.14033-1-kirill.shutemov@linux.intel.com
Signed-off-by: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Reviewed-by: Zi Yan &lt;ziy@nvidia.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Stable-dep-of: b6976f323a86 ("drm/ttm: stop pooling cached NUMA pages v2")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm: add drm_gem_object_is_shared_for_memory_stats() helper</title>
<updated>2024-05-02T14:32:41Z</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2024-02-12T21:04:24Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a4ae24cd04a8e2c1f61586a2e129b1cbd44a78db'/>
<id>urn:sha1:a4ae24cd04a8e2c1f61586a2e129b1cbd44a78db</id>
<content type='text'>
[ Upstream commit b31f5eba32ae8cc28e7cfa5a55ec8670d8c718e2 ]

Add a helper so that drm drivers can consistently report
shared status via the fdinfo shared memory stats interface.

In addition to handle count, show buffers as shared if they
are shared via dma-buf as well (e.g., shared with v4l or some
other subsystem).

v2: switch to inline function

Link: https://lore.kernel.org/all/20231207180225.439482-1-alexander.deucher@amd.com/
Reviewed-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt; (v1)
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Reviewed-by: Christian König &lt;christian.keonig@amd.com&gt;
Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Stable-dep-of: a6ff969fe9cb ("drm/amdgpu: fix visible VRAM handling during faults")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/bridge: add -&gt;edid_read hook and drm_bridge_edid_read()</title>
<updated>2024-04-03T13:28:38Z</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2024-01-23T19:37:07Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2b6aaf7b193be2bfa4e1af90c0d96e78a80aef69'/>
<id>urn:sha1:2b6aaf7b193be2bfa4e1af90c0d96e78a80aef69</id>
<content type='text'>
[ Upstream commit d807ad80d811ba0c22adfd871e2a46491f80d6e2 ]

Add new struct drm_edid based -&gt;edid_read hook and
drm_bridge_edid_read() function to call the hook.

v2: Include drm/drm_edid.h

Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Reviewed-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/9d08d22eaffcb9c59a2b677e45d7e61fc689bc2f.1706038510.git.jani.nikula@intel.com
Stable-dep-of: 171b711b26cc ("drm/bridge: lt8912b: do not return negative values from .get_modes()")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/ttm: Make sure the mapped tt pages are decrypted when needed</title>
<updated>2024-04-03T13:28:38Z</updated>
<author>
<name>Zack Rusin</name>
<email>zack.rusin@broadcom.com</email>
</author>
<published>2024-01-05T13:51:05Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=de125efb3bae7720d10364a9ab6785466e4e2461'/>
<id>urn:sha1:de125efb3bae7720d10364a9ab6785466e4e2461</id>
<content type='text'>
[ Upstream commit 71ce046327cfd3aef3f93d1c44e091395eb03f8f ]

Some drivers require the mapped tt pages to be decrypted. In an ideal
world this would have been handled by the dma layer, but the TTM page
fault handling would have to be rewritten to able to do that.

A side-effect of the TTM page fault handling is using a dma allocation
per order (via ttm_pool_alloc_page) which makes it impossible to just
trivially use dma_mmap_attrs. As a result ttm has to be very careful
about trying to make its pgprot for the mapped tt pages match what
the dma layer thinks it is. At the ttm layer it's possible to
deduce the requirement to have tt pages decrypted by checking
whether coherent dma allocations have been requested and the system
is running with confidential computing technologies.

This approach isn't ideal but keeping TTM matching DMAs expectations
for the page properties is in general fragile, unfortunately proper
fix would require a rewrite of TTM's page fault handling.

Fixes vmwgfx with SEV enabled.

v2: Explicitly include cc_platform.h
v3: Use CC_ATTR_GUEST_MEM_ENCRYPT instead of CC_ATTR_MEM_ENCRYPT to
limit the scope to guests and log when memory decryption is enabled.

Signed-off-by: Zack Rusin &lt;zack.rusin@broadcom.com&gt;
Fixes: 3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based iomem")
Reviewed-by: Thomas Hellström &lt;thomas.hellstrom@linux.intel.com&gt;
Acked-by: Christian König &lt;christian.koenig@amd.com&gt;
Cc: Huang Rui &lt;ray.huang@amd.com&gt;
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: &lt;stable@vger.kernel.org&gt; # v5.14+
Link: https://patchwork.freedesktop.org/patch/msgid/20230926040359.3040017-1-zack@kde.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/probe-helper: warn about negative .get_modes()</title>
<updated>2024-04-03T13:28:32Z</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2024-03-08T16:03:39Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=12bbe2c25cdb571190d523fd814e7696964a84d9'/>
<id>urn:sha1:12bbe2c25cdb571190d523fd814e7696964a84d9</id>
<content type='text'>
[ Upstream commit 7af03e688792293ba33149fb8df619a8dff90e80 ]

The .get_modes() callback is supposed to return the number of modes,
never a negative error code. If a negative value is returned, it'll just
be interpreted as a negative count, and added to previous calculations.

Document the rules, but handle the negative values gracefully with an
error message.

Cc: stable@vger.kernel.org
Acked-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/50208c866facc33226a3c77b82bb96aeef8ef310.1709913674.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm: Fix drm_fixp2int_round() making it add 0.5</title>
<updated>2024-03-26T22:20:10Z</updated>
<author>
<name>Arthur Grillo</name>
<email>arthurgrillo@riseup.net</email>
</author>
<published>2024-03-16T16:25:20Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=296e6678a432aaff0b8c6a6a17b9b2b193556c71'/>
<id>urn:sha1:296e6678a432aaff0b8c6a6a17b9b2b193556c71</id>
<content type='text'>
[ Upstream commit 807f96abdf14c80f534c78f2d854c2590963345c ]

As well noted by Pekka[1], the rounding of drm_fixp2int_round is wrong.
To round a number, you need to add 0.5 to the number and floor that,
drm_fixp2int_round() is adding 0.0000076. Make it add 0.5.

[1]: https://lore.kernel.org/all/20240301135327.22efe0dd.pekka.paalanen@collabora.com/

Fixes: 8b25320887d7 ("drm: Add fixed-point helper to get rounded integer values")
Suggested-by: Pekka Paalanen &lt;pekka.paalanen@collabora.com&gt;
Reviewed-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Reviewed-by: Melissa Wen &lt;mwen@igalia.com&gt;
Signed-off-by: Arthur Grillo &lt;arthurgrillo@riseup.net&gt;
Signed-off-by: Melissa Wen &lt;melissa.srw@gmail.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20240316-drm_fixed-v2-1-c1bc2665b5ed@riseup.net
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/tests: helpers: Include missing drm_drv header</title>
<updated>2024-03-26T22:19:53Z</updated>
<author>
<name>Maxime Ripard</name>
<email>mripard@kernel.org</email>
</author>
<published>2024-02-22T18:13:47Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4f14cbcd0b5c9bb198753baad8d9243393fe7554'/>
<id>urn:sha1:4f14cbcd0b5c9bb198753baad8d9243393fe7554</id>
<content type='text'>
[ Upstream commit 73984daf07a1a89ace8f0db6dd2d640654ebbbee ]

We have a few functions declared in our kunit helpers header, some of
them dereferencing the struct drm_driver.

However, we don't include the drm_drv.h header file defining that
structure, leading to compilation errors if we don't include both
headers.

Fixes: d98780310719 ("drm/tests: helpers: Allow to pass a custom drm_driver")
Reviewed-by: Maíra Canal &lt;mcanal@igalia.com&gt;
Signed-off-by: Maxime Ripard &lt;mripard@kernel.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20240222-kms-hdmi-connector-state-v7-1-8f4af575fce2@kernel.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
