v1(Christian):
- Dont handle clear page as TTM flag since when moving the BO back
in from GTT again we don't need that.
- Make a specialized version of amdgpu_fill_buffer() which only
clears the VRAM areas which are not already cleared
- Drop the TTM_PL_FLAG_WIPE_ON_RELEASE check in
amdgpu_object.c
v2:
- Modify the function name amdgpu_ttm_* (Alex)
- Drop the delayed parameter (Christian)
- handle amdgpu_res_cleared(&cursor) just above the size
calculation (Christian)
- Use AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE for clearing the buffers
in the free path to properly wait for fences etc.. (Christian)
v3(Christian):
- Remove buffer clear code in VRAM manager instead change the
AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE handling to set
the DRM_BUDDY_CLEARED flag.
- Remove ! from amdgpu_res_cleared(&cursor) check.
v4(Christian):
- vres flag setting move to vram manager file
- use dma_fence_get_stub in amdgpu_ttm_clear_buffer function
- make fence a mandatory parameter and drop the if and the get/put dance
- Driver should enable the DRM_BUDDY_CLEARED flag if it
successfully clears the blocks in the free path. On the otherhand,
DRM buddy marks each block as cleared.
- Track the available cleared pages size
- If driver requests cleared memory we prefer cleared memory
but fallback to uncleared if we can't find the cleared blocks.
when driver requests uncleared memory we try to use uncleared but
fallback to cleared memory if necessary.
- When a block gets freed we clear it and mark the freed block as cleared,
when there are buddies which are cleared as well we can merge them.
Otherwise, we prefer to keep the blocks as separated.
- Add a function to support defragmentation.
v1:
- Depends on the flag check DRM_BUDDY_CLEARED, enable the block as
cleared. Else, reset the clear flag for each block in the list(Christian)
- For merging the 2 cleared blocks compare as below,
drm_buddy_is_clear(block) != drm_buddy_is_clear(buddy)(Christian)
- Defragment the memory beginning from min_order
till the required memory space is available.
v2: (Matthew)
- Add a wrapper drm_buddy_free_list_internal for the freeing of blocks
operation within drm buddy.
- Write a macro block_incompatible() to allocate the required blocks.
- Update the xe driver for the drm_buddy_free_list change in arguments.
- add a warning if the two blocks are incompatible on
defragmentation
- call full defragmentation in the fini() function
- place a condition to test if min_order is equal to 0
- replace the list with safe_reverse() variant as we might
remove the block from the list.
v3:
- fix Gitlab user reported lockup issue.
- Keep DRM_BUDDY_HEADER_CLEAR define sorted(Matthew)
- modify to pass the root order instead max_order in fini()
function(Matthew)
- change bool 1 to true(Matthew)
- add check if min_block_size is power of 2(Matthew)
- modify the min_block_size datatype to u64(Matthew)
v4:
- rename the function drm_buddy_defrag with __force_merge.
- Include __force_merge directly in drm buddy file and remove
the defrag use in amdgpu driver.
- Remove list_empty() check(Matthew)
- Remove unnecessary space, headers and placement of new variables(Matthew)
- Add a unit test case(Matthew)
v5:
- remove force merge support to actual range allocation and not to bail
out when contains && split(Matthew)
- add range support to force merge function.
v6:
- modify the alloc_range() function clear page non merged blocks
allocation(Matthew)
- correct the list_insert function name(Matthew).
Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Suggested-by: Christian König <christian.koenig@amd.com> Suggested-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240419063538.11957-1-Arunpravin.PaneerSelvam@amd.com Signed-off-by: Christian König <christian.koenig@amd.com>
Ville Syrjälä [Wed, 10 Apr 2024 18:01:39 +0000 (21:01 +0300)]
drm/edid: Parse topology block for all DispID structure v1.x
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 <jani.nikula@intel.com> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Fixes: c5a486af9df7 ("drm/edid: parse Tiled Display Topology Data Block for DisplayID 2.0") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240410180139.21352-1-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
This add Khadas TS050 V2 Panel and make it compatible with old one.
Controller of V2 panel is "Himax HX8399-C" and the old panel is "NT35596".
In driver file, the only different between them is the timing squence.
Dan Carpenter [Mon, 8 Apr 2024 07:36:35 +0000 (10:36 +0300)]
drm/panthor: clean up some types in panthor_sched_suspend()
These variables should be u32 instead of u64 because they're only
storing u32 values. Also static checkers complain when we do:
suspended_slots &= ~upd_ctx.timedout_mask;
In this code "suspended_slots" is a u64 and "upd_ctx.timedout_mask". The
mask clears out the top 32 bits which would likely be a bug if anything
were stored there.
Krzysztof Kozlowski [Sat, 30 Mar 2024 20:27:54 +0000 (21:27 +0100)]
drm/rockchip: cdn-dp: drop driver owner assignment
Core in platform_driver_register() already sets the .owner, so driver
does not need to. Whatever is set here will be anyway overwritten by
main driver calling platform_driver_register().
drm/rockchip: vop2: Do not divide height twice for YUV
For the cbcr format, gt2 and gt4 are computed again after src_h has been
divided by vsub.
As src_h as already been divided by 2 before, introduce cbcr_src_h and
cbcr_src_w to keep a copy of those values to be used for cbcr gt2 and
gt4 computation.
This fixes yuv planes being unaligned vertically when down scaling to
1080 pixels from 2160.
drm/mipi-dsi: use correct return type for the DSC functions
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.
Marek Vasut [Thu, 28 Mar 2024 10:27:38 +0000 (11:27 +0100)]
drm/panel: simple: Add Innolux G121XCE-L01 LVDS display support
G121XCE-L01 is a Color Active Matrix Liquid Crystal Display composed of
a TFT LCD panel, a driver circuit, and LED backlight system. The screen
format is intended to support the 4:3, 1024(H) x 768(V) screen and either
262k/16.7M colors (RGB 6-bits or 8-bits) with LED backlight driver circuit.
All input signals are LVDS interface compatible.
Documentation [1] and [2] indicate that G121X1-L03 and G121XCE-L01 are
effectively identical panels, use the former as RGB 6-bits variant and
add the later as RGB 8-bits variant.
Marek Vasut [Thu, 28 Mar 2024 10:27:37 +0000 (11:27 +0100)]
drm/panel: simple: Convert Innolux G121X1-L03 to display_timing
Use display_timing instead of drm_display_mode to define a range of
possible display timings supported by this panel. This makes the panel
support more flexible and improves compatibility. No functional change
is expected.
The settings are picked from documentation [1] section 6.1 INPUT SIGNAL
TIMING SPECIFICATIONS.
Marek Vasut [Thu, 28 Mar 2024 10:27:36 +0000 (11:27 +0100)]
drm/panel: simple: Add missing Innolux G121X1-L03 format, flags, connector
The .bpc = 6 implies .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG ,
add the missing bus_format. Add missing connector type and bus_flags
as well.
Documentation [1] 1.4 GENERAL SPECIFICATI0NS indicates this panel is
capable of both RGB 18bit/24bit panel, the current configuration uses
18bit mode, .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG , .bpc = 6.
Support for the 24bit mode would require another entry in panel-simple
with .bus_format = MEDIA_BUS_FMT_RGB666_1X7X4_SPWG and .bpc = 8, which
is out of scope of this fix.
Marek Vasut [Thu, 28 Mar 2024 10:27:35 +0000 (11:27 +0100)]
dt-bindings: display: simple: Document support for Innolux G121XCE-L01
Document support for Innolux CheMei 12" G121XCE-L01 XGA LVDS display.
G121XCE-L01 is a Color Active Matrix Liquid Crystal Display composed of
a TFT LCD panel, a driver circuit, and LED backlight system. The screen
format is intended to support the 4:3, 1024(H) x 768(V) screen and either
262k/16.7M colors (RGB 6-bits or 8-bits) with LED backlight driver circuit.
All input signals are LVDS interface compatible.
Documentation [1] and [2] indicate that G121X1-L03 and G121XCE-L01 are
effectively identical panels, use the former as RGB 6-bits variant and
document the later as RGB 8-bits variant.
Jani Nikula [Tue, 16 Apr 2024 09:20:00 +0000 (12:20 +0300)]
drm/edid: make drm_edid_are_equal() more convenient for its single user
Repurpose drm_edid_are_equal() to be more helpful for its single user,
and rename drm_edid_eq(). Functionally deduce the length from the blob
size, not the blob data, making it more robust against any errors.
Prefer the EDID iterators over drm_edid_find_extension() in
drm_edid_has_cta_extension(), even if this leads to more code. The key
is to use the same patterns as much as possible.
The parameter name is 'sb' and not 'drm_scanout_buffer'.
It fixes the following warnings:
drivers/gpu/drm/drm_fb_dma_helper.c:166: warning: Excess function parameter 'drm_scanout_buffer' description in 'drm_fb_dma_get_scanout_buffer'
drivers/gpu/drm/drm_fb_dma_helper.c:166: warning: Function parameter or struct member 'sb' not described in 'drm_fb_dma_get_scanout_buffer'
drivers/gpu/drm/drm_fb_dma_helper.c:166: warning: Excess function parameter 'drm_scanout_buffer' description in 'drm_fb_dma_get_scanout_buffer'
drm/bridge: anx7625: Update audio status while detecting
Previously, the audio status was not updated during detection, leading
to a persistent audio despite hot plugging events. To resolve this
issue, update the audio status during detection.
Nícolas F. R. A. Prado [Mon, 15 Apr 2024 21:49:37 +0000 (17:49 -0400)]
drm/panel: truly-nt35597: Don't log an error when DSI host can't be found
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-9-619a28148e5c@collabora.com
Nícolas F. R. A. Prado [Mon, 15 Apr 2024 21:49:36 +0000 (17:49 -0400)]
drm/panel: novatek-nt35950: Don't log an error when DSI host can't be found
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Fixes: 623a3531e9cf ("drm/panel: Add driver for Novatek NT35950 DSI DriverIC panels") Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-8-619a28148e5c@collabora.com
Nícolas F. R. A. Prado [Mon, 15 Apr 2024 21:49:35 +0000 (17:49 -0400)]
drm/bridge: dpc3433: Don't log an error when DSI host can't be found
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Also move the "failed to attach" error message so that it's only printed
when the devm_mipi_dsi_attach() call fails.
Fixes: 6352cd451ddb ("drm: bridge: Add TI DLPC3433 DSI to DMD bridge") Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-7-619a28148e5c@collabora.com
Nícolas F. R. A. Prado [Mon, 15 Apr 2024 21:49:34 +0000 (17:49 -0400)]
drm/bridge: tc358775: Don't log an error when DSI host can't be found
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVDS driver") Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-6-619a28148e5c@collabora.com
Nícolas F. R. A. Prado [Mon, 15 Apr 2024 21:49:33 +0000 (17:49 -0400)]
drm/bridge: lt9611uxc: Don't log an error when DSI host can't be found
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC bridge") Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-5-619a28148e5c@collabora.com
Nícolas F. R. A. Prado [Mon, 15 Apr 2024 21:49:32 +0000 (17:49 -0400)]
drm/bridge: lt9611: Don't log an error when DSI host can't be found
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge") Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-4-619a28148e5c@collabora.com
Nícolas F. R. A. Prado [Mon, 15 Apr 2024 21:49:31 +0000 (17:49 -0400)]
drm/bridge: lt8912b: Don't log an error when DSI host can't be found
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-3-619a28148e5c@collabora.com
Nícolas F. R. A. Prado [Mon, 15 Apr 2024 21:49:30 +0000 (17:49 -0400)]
drm/bridge: icn6211: Don't log an error when DSI host can't be found
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Fixes: 8dde6f7452a1 ("drm: bridge: icn6211: Add I2C configuration support") Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-2-619a28148e5c@collabora.com
Nícolas F. R. A. Prado [Mon, 15 Apr 2024 21:49:29 +0000 (17:49 -0400)]
drm/bridge: anx7625: Don't log an error when DSI host can't be found
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Fixes: 269332997a16 ("drm/bridge: anx7625: Return -EPROBE_DEFER if the dsi host was not found") Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-1-619a28148e5c@collabora.com
crc checksums are used to validate the output. Normally they're part
of the actual display hardware but on virtual stack there's nothing
to automatically generate them.
Implement crc generation for the vmwgfx stack. This works only on
screen targets, where it's possibly to easily make sure that the
guest side contents of the surface matches the host sides output.
Just like the vblank support, crc generation can only be enabled via:
guestinfo.vmwgfx.vkms_enable = "TRUE"
option in the vmx file.
Makes IGT's kms_pipe_crc_basic pass and allows a huge number of other
IGT tests which require CRC generation of the output to actually run
on vmwgfx. Makes it possible to actually validate a lof of the kms and
drm functionality with vmwgfx.
By default vmwgfx doesn't support vblanking or crc generation which
makes it impossible to use various IGT tests to validate vmwgfx.
Implement virtual kernel mode setting, which is mainly related to
simulated vblank support.
Code is very similar to amd's vkms and the vkms module itself, except
that it's integrated with vmwgfx three different output technologies -
legacy, screen object and screen targets.
Make IGT's kms_vblank pass on vmwgfx and allows a lot of other IGT
tests to run with vmwgfx.
Support for vkms needs to be manually enabled by adding:
guestinfo.vmwgfx.vkms_enable = "TRUE"
somewhere in the vmx file, otherwise it's off by default.
On version 11 of the "drm/panic: Add a drm panic handler" series [1], Thomas
suggested to change the name of the function `drm_panic_gem_get_scanout_buffer`
to `drm_fb_dma_get_scanout_buffer` and this request was applied on version 12,
which is the version that landed [2]. Although the name of the function
changed on the C file, it didn't changed on the header file, leading to a
compilation error as such:
drivers/gpu/drm/imx/ipuv3/ipuv3-plane.c:780:24: error: use of undeclared
identifier 'drm_fb_dma_get_scanout_buffer'; did you mean 'drm_panic_gem_get_scanout_buffer'?
780 | .get_scanout_buffer = drm_fb_dma_get_scanout_buffer,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| drm_panic_gem_get_scanout_buffer
./include/drm/drm_fb_dma_helper.h:23:5: note: 'drm_panic_gem_get_scanout_buffer'
declared here
23 | int drm_panic_gem_get_scanout_buffer(struct drm_plane *plane,
| ^
1 error generated.
Fix the compilation error by changing `drm_panic_gem_get_scanout_buffer` to
`drm_fb_dma_get_scanout_buffer` on the header file.
drm/fb_dma: Add generic get_scanout_buffer() for drm_panic
This was initialy done for imx6, but should work on most drivers
using drm_fb_dma_helper.
v8:
* Replace get_scanout_buffer() logic with drm_panic_set_buffer()
(Thomas Zimmermann)
v9:
* go back to get_scanout_buffer()
* move get_scanout_buffer() to plane helper functions
v12:
* Rename drm_panic_gem_get_scanout_buffer to drm_fb_dma_get_scanout_buffer
(Thomas Zimmermann)
* Remove the #ifdef CONFIG_DRM_PANIC, and build it unconditionnaly, as
it's a small function. (Thomas Zimmermann)
drm/panic: Add support for color format conversion
Add support for the following formats:
DRM_FORMAT_RGB565
DRM_FORMAT_RGBA5551
DRM_FORMAT_XRGB1555
DRM_FORMAT_ARGB1555
DRM_FORMAT_RGB888
DRM_FORMAT_XRGB8888
DRM_FORMAT_ARGB8888
DRM_FORMAT_XBGR8888
DRM_FORMAT_XRGB2101010
DRM_FORMAT_ARGB2101010
v10:
* move and simplify the functions from the drm format helper to drm_panic
v12:
* Use array for map and pitch in struct drm_scanout_buffer
to support multi-planar format later. (Thomas Zimmermann)
This module displays a user friendly message when a kernel panic
occurs. It currently doesn't contain any debug information,
but that can be added later.
v2
* Use get_scanout_buffer() instead of the drm client API.
(Thomas Zimmermann)
* Add the panic reason to the panic message (Nerdopolis)
* Add an exclamation mark (Nerdopolis)
v3
* Rework the drawing functions, to write the pixels line by line and
to use the drm conversion helper to support other formats.
(Thomas Zimmermann)
v4
* Use drm_fb_r1_to_32bit for fonts (Thomas Zimmermann)
* Remove the default y to DRM_PANIC config option (Thomas Zimmermann)
* Add foreground/background color config option
* Fix the bottom lines not painted if the framebuffer height
is not a multiple of the font height.
* Automatically register the device to drm_panic, if the function
get_scanout_buffer exists. (Thomas Zimmermann)
v5
* Change the drawing API, use drm_fb_blit_from_r1() to draw the font.
* Also add drm_fb_fill() to fill area with background color.
* Add draw_pixel_xy() API for drivers that can't provide a linear buffer.
* Add a flush() callback for drivers that needs to synchronize the buffer.
* Add a void *private field, so drivers can pass private data to
draw_pixel_xy() and flush().
v6
* Fix sparse warning for panic_msg and logo.
v7
* Add select DRM_KMS_HELPER for the color conversion functions.
v8
* Register directly each plane to the panic notifier (Sima)
* Add raw_spinlock to properly handle concurrency (Sima)
* Register plane instead of device, to avoid looping through plane
list, and simplify code.
* Replace get_scanout_buffer() logic with drm_panic_set_buffer()
(Thomas Zimmermann)
* Removed the draw_pixel_xy() API, will see later if it can be added back.
v9
* Revert to using get_scanout_buffer() (Sima)
* Move get_scanout_buffer() and panic_flush() to the plane helper
functions (Thomas Zimmermann)
* Register all planes with get_scanout_buffer() to the panic notifier
* Use drm_panic_lock() to protect against race (Sima)
v10
* Move blit and fill functions back in drm_panic (Thomas Zimmermann).
* Simplify the text drawing functions.
* Use kmsg_dumper instead of panic_notifier (Sima).
v12
* Use array for map and pitch in struct drm_scanout_buffer
to support multi-planar format later. (Thomas Zimmermann)
* Better indent struct drm_scanout_buffer declaration. (Thomas Zimmermann)
Daniel Vetter [Tue, 9 Apr 2024 16:30:40 +0000 (18:30 +0200)]
drm/panic: Add drm panic locking
Rough sketch for the locking of drm panic printing code. The upshot of
this approach is that we can pretty much entirely rely on the atomic
commit flow, with the pair of raw_spin_lock/unlock providing any
barriers we need, without having to create really big critical
sections in code.
This also avoids the need that drivers must explicitly update the
panic handler state, which they might forget to do, or not do
consistently, and then we blow up in the worst possible times.
It is somewhat racy against a concurrent atomic update, and we might
write into a buffer which the hardware will never display. But there's
fundamentally no way to avoid that - if we do the panic state update
explicitly after writing to the hardware, we might instead write to an
old buffer that the user will barely ever see.
Note that an rcu protected deference of plane->state would give us the
the same guarantees, but it has the downside that we then need to
protect the plane state freeing functions with call_rcu too. Which
would very widely impact a lot of code and therefore doesn't seem
worth the complexity compared to a raw spinlock with very tiny
critical sections. Plus rcu cannot be used to protect access to
peek/poke registers anyway, so we'd still need it for those cases.
Peek/poke registers for vram access (or a gart pte reserved just for
panic code) are also the reason I've gone with a per-device and not
per-plane spinlock, since usually these things are global for the
entire display. Going with per-plane locks would mean drivers for such
hardware would need additional locks, which we don't want, since it
deviates from the per-console takeoverlocks design.
Longer term it might be useful if the panic notifiers grow a bit more
structure than just the absolute bare
EXPORT_SYMBOL(panic_notifier_list) - somewhat aside, why is that not
EXPORT_SYMBOL_GPL ... If panic notifiers would be more like console
drivers with proper register/unregister interfaces we could perhaps
reuse the very fancy console lock with all it's check and takeover
semantics that John Ogness is developing to fix the console_lock mess.
But for the initial cut of a drm panic printing support I don't think
we need that, because the critical sections are extremely small and
only happen once per display refresh. So generally just 60 tiny locked
sections per second, which is nothing compared to a serial console
running a 115kbaud doing really slow mmio writes for each byte. So for
now the raw spintrylock in drm panic notifier callback should be good
enough.
Another benefit of making panic notifiers more like full blown
consoles (that are used in panics only) would be that we get the two
stage design, where first all the safe outputs are used. And then the
dangerous takeover tricks are deployed (where for display drivers we
also might try to intercept any in-flight display buffer flips, which
if we race and misprogram fifos and watermarks can hang the memory
controller on some hw).
For context the actual implementation on the drm side is by Jocelyn
and this patch is meant to be combined with the overall approach in
v7 (v8 is a bit less flexible, which I think is the wrong direction):
Jani Nikula [Mon, 8 Apr 2024 09:24:02 +0000 (12:24 +0300)]
drm: prefer DRM_MODE_FMT/ARG over drm_mode_debug_printmodeline()
We have DRM_MODE_FMT and DRM_MODE_ARG() macros to allow unified debug
printing of modes in any printk-formatted logging. Prefer them over
drm_mode_debug_printmodeline().
This allows drm device specific logging of modes, in the right drm debug
category, and inline with the rest of the logging instead of split to
multiple lines.
Jani Nikula [Mon, 8 Apr 2024 09:24:01 +0000 (12:24 +0300)]
drm/crtc-helper: switch to drm device based logging and warns
Prefer drm device based drm_dbg_kms(), drm_err(), drm_WARN_ON() over
DRM_DEBUG_KMS(), DRM_ERROR(), and WARN_ON(). Also update encoder,
connector, and crtc logging to include the object id and name, where
possible.
Jani Nikula [Mon, 8 Apr 2024 09:23:59 +0000 (12:23 +0300)]
drm/client: switch to drm device based logging, and more
Switch to drm device based logging and WARNs, and unify connector and
crtc logging formats. Pass drm device around a bit more to be able to do
this. Drop logging for -ENOMEM.
Jani Nikula [Mon, 8 Apr 2024 09:23:58 +0000 (12:23 +0300)]
drm/sysfs: switch to drm device based logging
Prefer drm_dbg_kms() and drm_dbg_lease() over DRM_DEBUG_KMS() and
DRM_DEBUG() to debug log the drm device info. Fix some debug categories
and unify connector logging while at it.
Jani Nikula [Tue, 9 Apr 2024 09:46:11 +0000 (12:46 +0300)]
drm/i915/bios: switch to struct drm_edid and struct drm_edid_product_id
To avoid accessing and parsing the raw EDID with drm_edid_raw(), switch
to the struct drm_edid based function to extract product id, and use the
drm printer function to debug log it.
The underlying assumption is that struct drm_edid_product_id and struct
lvds_pnp_id describe identical data, albeit with slightly different
member definitions.
Jani Nikula [Tue, 9 Apr 2024 09:46:09 +0000 (12:46 +0300)]
drm/edid: add drm_edid_get_product_id()
Add a struct drm_edid based function to get the vendor and product ID
from an EDID. Add a separate struct for defining this part of the EDID,
with defined byte order for manufacturer name, product code and serial
number.
v2: Define manufacturer_name as __be16 instead of u8[2] (Ville)
drm: fix DRM_DISPLAY_DP_HELPER dependencies, part 2
After my fix yesterday, I ran into another problem of the same kind:
aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/analogix_dp_core.o: in function `drm_dp_dpcd_readb':
analogix_dp_core.c:(.text+0x194): undefined reference to `drm_dp_dpcd_read'
aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/analogix_dp_core.o: in function `drm_dp_dpcd_writeb':
analogix_dp_core.c:(.text+0x214): undefined reference to `drm_dp_dpcd_write'
aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/analogix_dp_core.o: in function `analogix_dp_stop_crc':
analogix_dp_core.c:(.text+0x4b0): undefined reference to `drm_dp_stop_crc'
aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/analogix_dp_core.o: in function `analogix_dp_start_crc':
analogix_dp_core.c:(.text+0xbe8): undefined reference to `drm_dp_start_crc'
Add the same dependency again to ROCKCHIP_ANALOGIX_DP after checking that
nothing else selects the analogix driver. Also add a dependency to
DRM_ANALOGIX_DP to make it easier to identifier future problems of
this type when they get introduced.
Sebastian Wick [Wed, 10 Apr 2024 12:20:06 +0000 (14:20 +0200)]
drm: Document requirements for driver-specific KMS props in new drivers
When extending support for a driver-specific KMS property to additional
drivers, we should apply all the requirements for new properties and
make sure the semantics are the same and documented.
v2: devs of the driver which introduced property shall help and ack
drm/lima: fix void pointer to enum lima_gpu_id cast warning
Create a simple data struct to hold compatible data so that we don't
have to do the casts to void pointer to hold data.
Fixes the following warning:
drivers/gpu/drm/lima/lima_drv.c:387:13: error: cast to smaller integer
type 'enum lima_gpu_id' from 'const void *'
drm/lima: fix shared irq handling on driver remove
lima uses a shared interrupt, so the interrupt handlers must be prepared
to be called at any time. At driver removal time, the clocks are
disabled early and the interrupts stay registered until the very end of
the remove process due to the devm usage.
This is potentially a bug as the interrupts access device registers
which assumes clocks are enabled. A crash can be triggered by removing
the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled.
This patch frees the interrupts at each lima device finishing callback
so that the handlers are already unregistered by the time we fully
disable clocks.
drm/lima: mask irqs in timeout path before hard reset
There is a race condition in which a rendering job might take just long
enough to trigger the drm sched job timeout handler but also still
complete before the hard reset is done by the timeout handler.
This runs into race conditions not expected by the timeout handler.
In some very specific cases it currently may result in a refcount
imbalance on lima_pm_idle, with a stack dump such as:
We can prevent that race condition entirely by masking the irqs at the
beginning of the timeout handler, at which point we give up on waiting
for that job entirely.
The irqs will be enabled again at the next hard reset which is already
done as a recovery by the timeout handler.
drm/lima: include pp bcast irq in timeout handler check
In commit 53cb55b20208 ("drm/lima: handle spurious timeouts due to high
irq latency") a check was added to detect an unexpectedly high interrupt
latency timeout.
With further investigation it was noted that on Mali-450 the pp bcast
irq may also be a trigger of race conditions against the timeout
handler, so add it to this check too.
This is needed because we want to reset those devices in device-agnostic
code such as lima_sched.
In particular, masking irqs will be useful before a hard reset to
prevent race conditions.
Jeffrey Hugo [Fri, 22 Mar 2024 03:49:17 +0000 (21:49 -0600)]
accel/qaic: Add Sahara implementation for firmware loading
The AIC100 secondary bootloader uses the Sahara protocol for two
purposes - loading the runtime firmware images from the host, and
offloading crashdumps to the host. The crashdump functionality is only
invoked when the AIC100 device encounters a crash and dumps are enabled.
Also the collection of the dump is optional - the host can reject
collecting the dump.
The Sahara protocol contains many features and modes including firmware
upload, crashdump download, and client commands. For simplicity,
implement the parts of the protocol needed for loading firmware to the
device.
Fundamentally, the Sahara protocol is an embedded file transfer
protocol. Both sides negotiate a connection through a simple exchange of
hello messages. After handshaking through a hello message, the device
either sends a message requesting images, or a message advertising the
memory dump available for the host. For image transfer, the remote device
issues a read data request that provides an image (by ID), an offset, and
a length. The host has an internal mapping of image IDs to filenames. The
host is expected to access the image and transfer the requested chunk to
the device. The device can issue additional read requests, or signal that
it has consumed enough data from this image with an end of image message.
The host confirms the end of image, and the device can proceed with
another image by starting over with the hello exchange again.
Some images may be optional, and only provided as part of a provisioning
flow. The host is not aware of this information, and thus should report
an error to the device when an image is not available. The device will
evaluate if the image is required or not, and take the appropriate
action.
Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Carl Vanderlip <quic_carlv@quicinc.com> Reviewed-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240322034917.3522388-1-quic_jhugo@quicinc.com
Huai-Yuan Liu [Sun, 7 Apr 2024 06:30:53 +0000 (14:30 +0800)]
drm/arm/malidp: fix a possible null pointer dereference
In malidp_mw_connector_reset, new memory is allocated with kzalloc, but
no check is performed. In order to prevent null pointer dereferencing,
ensure that mw_state is checked before calling
__drm_atomic_helper_connector_reset.
Ville Syrjälä [Mon, 18 Mar 2024 20:44:08 +0000 (22:44 +0200)]
drm/i915: Add SIZE_HINTS property for cursors
Advertize more suitable cursor sizes via the new SIZE_HINTS
plane property.
We can't really enumerate all supported cursor sizes on
the platforms where the cursor height can vary freely, so
for simplicity we'll just expose all square+POT sizes between
each platform's min and max cursor limits.
Depending on the platform this will give us one of three
results:
- 64x64,128x128,256x256,512x512
- 64x64,128x128,256x256
- 64x64
Cc: Simon Ser <contact@emersion.fr> Cc: Jonas Ådahl <jadahl@redhat.com> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Sameer Lattannavar <sameer.lattannavar@intel.com> Cc: Sebastian Wick <sebastian.wick@redhat.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240318204408.9687-3-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Ville Syrjälä [Mon, 18 Mar 2024 20:44:07 +0000 (22:44 +0200)]
drm: Introduce plane SIZE_HINTS property
Add a new immutable plane property by which a plane can advertise
a handful of recommended plane sizes. This would be mostly exposed
by cursor planes as a slightly more capable replacement for
the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare
a one size fits all limit for the whole device.
Currently eg. amdgpu/i915/nouveau just advertize the max cursor
size via the cursor size caps. But always using the max sized
cursor can waste a surprising amount of power, so a better
strategy is desirable.
Most other drivers don't specify any cursor size at all, in
which case the ioctl code just claims that 64x64 is a great
choice. Whether that is actually true is debatable.
A poll of various compositor developers informs us that
blindly probing with setcursor/atomic ioctl to determine
suitable cursor sizes is not acceptable, thus the
introduction of the new property to supplant the cursor
size caps. The compositor will now be free to select a
more optimal cursor size from the short list of options.
Note that the reported sizes (either via the property or the
caps) make no claims about things such as plane scaling. So
these things should only really be consulted for simple
"cursor like" use cases.
Userspace consumer in the form of mutter seems ready:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3165
v2: Try to add some docs
v3: Specify that value 0 is reserved for future use (basic idea from Jonas)
Drop the note about typical hardware (Pekka)
v4: Update the docs to indicate the list is "in order of preference"
Add a a link to the mutter MR
v5: Limit to cursors only for now (Simon)
Cc: Jonas Ådahl <jadahl@redhat.com> Cc: Sameer Lattannavar <sameer.lattannavar@intel.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Reviewed-by: Simon Ser <contact@emersion.fr> Acked-by: Daniel Stone <daniels@collabora.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240318204408.9687-2-ville.syrjala@linux.intel.com
remove the unsed the paramter in the function
ttm_bo_bounce_temp_buffer and ttm_bo_add_move_fence.
V2:rebase the patch on top of drm-misc-next (Christian)
Thomas Zimmermann [Wed, 3 Apr 2024 10:31:30 +0000 (12:31 +0200)]
drm/ast: Define struct ast_ddc in ast_ddc.c
Move the definition of struct ast_ddc to ast_ddc.c and return the i2c
adapter from ast_ddc_create(). Update callers accordingly. Avoids
including Linux i2c header files, except where required. No functional
changes.
Thomas Zimmermann [Wed, 3 Apr 2024 10:31:29 +0000 (12:31 +0200)]
drm/ast: Group DDC init code by data structure
Reorder the code to set up the DDC channel by data structure, so
that each data structure's init is in a separate block: first the
bit algo then the i2c adapter. Makes the code more readable. No
functional changes.
Thomas Zimmermann [Wed, 3 Apr 2024 10:31:28 +0000 (12:31 +0200)]
drm/ast: Set DDC timeout in milliseconds
Compute the i2c timeout in jiffies from a value in milliseconds. The
original values of 2 jiffies equals 2 milliseconds if HZ has been
configured to a value of 1000. This corresponds to 2.2 milliseconds
used by most other DRM drivers. Update ast accordingly.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 312fec1405dd ("drm: Initial KMS driver for AST (ASpeed Technologies) 2000 series (v2)") Cc: Dave Airlie <airlied@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v3.5+ Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240403103325.30457-2-tzimmermann@suse.de
I didn't pay close enough attention the last time I tried to fix this
problem - while we currently do correctly take care to make sure we don't
probe a connected eDP port more then once, we don't do the same thing for
eDP ports we found to be disconnected.
So, fix this and make sure we only ever probe eDP ports once and then leave
them at that connector state forever (since without HPD, it's not going to
change on its own anyway). This should get rid of the last few GSP errors
getting spit out during runtime suspend and resume on some machines, as we
tried to reprobe eDP ports in response to ACPI hotplug probe events.
Lyude Paul [Thu, 4 Apr 2024 23:35:53 +0000 (19:35 -0400)]
drm/nouveau/kms/nv50-: Disable AUX bus for disconnected DP ports
GSP has its own state for keeping track of whether or not a given display
connector is plugged in or not, and enforces this state on the driver. In
particular, AUX transactions on a DisplayPort connector which GSP says is
disconnected can never succeed - and can in some cases even cause
unexpected timeouts, which can trickle up to cause other problems. A good
example of this is runtime power management: where we can actually get
stuck trying to resume the GPU if a userspace application like fwupd tries
accessing a drm_aux_dev for a disconnected port. This was an issue I hit a
few times with my Slimbook Executive 16 - where trying to offload something
to the discrete GPU would wake it up, and then potentially cause it to
timeout as fwupd tried to immediately access the dp_aux_dev nodes for
nouveau.
Likewise: we don't really have any cases I know of where we'd want to
ignore this state and try an aux transaction anyway - and failing pointless
aux transactions immediately can even speed things up. So - let's start
enabling/disabling the aux bus in nouveau_dp_detect() to fix this. We
enable the aux bus during connector probing, and leave it enabled if we
discover something is actually on the connector. Otherwise, we just shut it
off.
This should fix some people's runtime PM issues (like myself), and also get
rid of quite of a lot of GSP error spam in dmesg.
Uwe Kleine-König [Mon, 4 Mar 2024 09:10:06 +0000 (10:10 +0100)]
drm/bridge: imx8mp-hdmi-tx: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Uwe Kleine-König [Mon, 4 Mar 2024 09:05:56 +0000 (10:05 +0100)]
drm/bridge: imx8mp-hdmi-pvi: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Krzysztof Kozlowski [Sat, 30 Mar 2024 20:28:04 +0000 (21:28 +0100)]
drm/omap: dmm_tiler: drop driver owner assignment
Core in platform_driver_register() already sets the .owner, so driver
does not need to. Whatever is set here will be anyway overwritten by
main driver calling platform_driver_register().
Aleksandr Mishin [Mon, 8 Apr 2024 12:58:10 +0000 (15:58 +0300)]
drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference
In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is
assigned to mhdp_state->current_mode, and there is a dereference of it in
drm_mode_set_name(), which will lead to a NULL pointer dereference on
failure of drm_mode_duplicate().
Fix this bug add a check of mhdp_state->current_mode.
Douglas Anderson [Mon, 25 Mar 2024 21:56:27 +0000 (14:56 -0700)]
drm-panel: If drm_panel_dp_aux_backlight() fails, don't fail panel probe
If we're using the AUX channel for eDP backlight and it fails to probe
for some reason, let's _not_ fail the panel probe.
At least one case where we could fail to init the backlight is because
of a dead or physically missing panel. As talked about in detail in
the earlier patch in this series, ("drm/panel-edp: If we fail to
powerup/get EDID, use conservative timings"), this can cause the
entire system's display pipeline to fail to come up and that's
non-ideal.
If we fail to init the backlight for some transitory reason, we should
dig in and see if there's a way to fix this (perhaps retries?). Even
in that case, though, having a panel whose backlight is stuck at 100%
(the default, at least in the panel Samsung ATNA33XC20 I tested) is
better than having no panel at all.
Douglas Anderson [Mon, 25 Mar 2024 21:56:26 +0000 (14:56 -0700)]
drm/panel-edp: If we fail to powerup/get EDID, use conservative timings
If at boot we fail to power up the eDP panel (most often happens if
the eDP panel never asserts HPD to us) or if we are unable to read the
EDID at bootup to figure out the panel's ID then let's use the
conservative eDP panel powerup/powerdown timings but _not_ fail the
probe.
It might seem strange to _not_ fail the probe in this case since we
were unable to powerup the panel and confirm it's there. However,
there is a reason to do this. Specifically, if we fail to probe the
panel then it really throws the whole display pipeline for loop. Most
DRM subsystems are written so that they wait until all components
(including the panel) have probed before they set everything up. When
the panel doesn't come up then this never happens. As a side effect of
not setting everything up then other display adapters don't get
initialized. As a practical example, I can see that if I open up a
sc7180-trogdor based Chromebook that's using the generic "edp-panel"
and unplug the eDP panel that it causes the _external_ DP monitor not
to function. This is obviously bad because it means that a device with
a dead eDP panel becomes e-waste when it could instead still be given
useful life with an external display.
NOTES:
- When we fail to probe like this, boot is a bit slow because we try
several times to power the panel up. This doesn't feel horrible
because it'll eventually work and the retries are known to help
bring some panels up.
- In the case where we hit the condition of failing to power up, the
display will likely _never_ have a chance to work again until
reboot. Once the panel-edp pm_runtime resume function fails it
doesn't ever seem to retry. This is probably for the best given that
we don't have any real timing/modes. eDP isn't expected to be
"hotplugged" so this makes some sense.
- It turns out that this makes panel-edp behave more similarly for
users of the generic "edp-panel" compatible string and the old fixed
panel compatible string. With the old fixed panel compatible string
we don't talk to the panel during probe so we'd actually behave much
the same way that we'll now behave for the generic "edp-panel".
projects / users / jedix / linux-maple.git / log