- 07 Oct, 2022 1 commit
-
-
Thomas Zimmermann authored
Remove the _drm_ infix from struct udl_drm_connector and introduce a macro for upcasting from struct drm_connector. No functional changes. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221006095355.23579-2-tzimmermann@suse.de
-
- 06 Oct, 2022 1 commit
-
-
Lucas Stach authored
The tile status modifiers can be combined with all of the usual color buffer modifiers. When they are present an additional plane is added to the surfaces to share the tile status buffer. The TS modifiers describe the interpretation of the tag bits in this buffer. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Reviewed-by:
Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by:
Guido Günther <agx@sigxcpu.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220909093000.3458413-1-l.stach@pengutronix.de
-
- 05 Oct, 2022 5 commits
-
-
Javier Martinez Canillas authored
The drm_atomic_helper_damage_merged() helper merges all the damage clips into one rectangle. If there are multiple damage clips that aren't close to each other, the resulting rectangle could be quite big. Instead of using that function helper, iterate over all the damage clips and update them one by one. Suggested-by:
Jocelyn Falempe <jfalempe@redhat.com> Signed-off-by:
-
Jocelyn Falempe authored
The current ast driver only supports legacy gamma interface. This also fixes a Gnome3/Wayland error which incorrectly adds gamma to atomic commit: "Page flip discarded: CRTC property (GAMMA_LUT) not found" I only tested remotely, so I wasn't able to check that it had an effect on the VGA output. But when activating "Night Light" in Gnome, ast_crtc_load_lut() is called. v2: use the same functions as mgag200. handle 16bits color mode. v3: Check gamma_lut size in atomic check. v4: revert 16bits mode, v1 was correct. make sure gamma table are set when primary plane format changes. remove rgb888 format that is not used. Signed-off-by: -
Jason Yen authored
This chip can not handle aux defer if the host directly program its aux registers to access edid/dpcd. So we need let software to handle the aux defer situation. Signed-off-by:
Jason Yen <jason.yen@paradetech.corp-partner.google.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Christian König authored
Otherwise we would crash if the job is not resubmitted. v2: fix second usage of s_fence->parent as well. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221004132831.134986-1-christian.koenig@amd.com
-
Christian König authored
We leaked dependency fences when processes were beeing killed. Additional to that grab a reference to the last scheduled fence. Signed-off-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220929180151.139751-1-christian.koenig@amd.com
-
- 04 Oct, 2022 16 commits
-
-
Ville Syrjälä authored
Get rid of the confusing version_greater() stuff and simply compare edid->revision directly everwhere. Half the places already did it this way, and since we actually reject any EDID with edid->version!=1 it's a perfectly sane thing to do. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220927170006.27855-9-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
For EDID 1.4 the first detailed timing is always preferred, for older EDIDs there was a feature flag to indicate the same. While correct, the code setting that up is rather confusing. Restate it in a slightly more straightforward manner. Reviewed-by:
-
Ville Syrjälä authored
Prefer the timing formula indicated by the range descriptor for generating the non-DMT standard timings. Previously we just used CVT for all EDID 1.4 continuous frequency displays without even checking if the range descriptor indicates otherwise. Now we check the range descriptor first, and fall back to CVT if nothing else was indicated. EDID 1.4 more or less deprecates GTF/GTF2 but there are still a lot of 1.4 EDIDs out there that don't advertise CVT support, so seems safer to use the formula the EDID actually reports as supported. For EDID 1.3 we use GTF2 if indicated (as before), and for EDID 1.2+ we now just use GTF without even checking the feature flag. There seem to be quite a few EDIDs out there that don't set the GTF feature flag but still include a GTF range descriptor and non-DMT standard timings. This to me seems to be roughly what appendix B of EDID 1.4 suggests should be done. Reviewed-by:
-
Ville Syrjälä authored
For some reason we only use the secondary GTF curve for the standard timings. Use it for inferred modes as well. Reviewed-by:
-
Ville Syrjälä authored
Extract the GTF vs. GTF2 logic into a separate function. We'll have a second user soon. Reviewed-by:
-
Ville Syrjälä authored
Since we only use the parsed vrefresh range to determine if VRR should be supported we should only accept continuous frequency displays here. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: amd-gfx@lists.freedesktop.org Reviewed-by:
-
Ville Syrjälä authored
Replace a bunch of hex constants with proper definitions. Reviewed-by:
-
Ville Syrjälä authored
The current comment fails to clarify why we only accept the "range limits only" variant of the range descriptor. Reword it to make some actual sense. Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: amd-gfx@lists.freedesktop.org Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Ankit Nautiyal authored
Replace multiple log lines with a single log line at the end of parsing HF-VSDB. Also use drm_dbg_kms instead of DRM_DBG_KMS, and add log for DSC1.2 support. v2: Fixed the formatting issues in the logging (Jani). Signed-off-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by:
-
Ankit Nautiyal authored
DSC capabilities are given in bytes 11-13 of VSDB (i.e. bytes 8-10 of SCDS). Since minimum length of Data block is 7, all bytes greater than 7 must be read only after checking the length of the data block. This patch adds check for data block length before reading relavant DSC bytes. Signed-off-by:
-
Ankit Nautiyal authored
Move the DSC parsing logic into separate function. v2: Rebase. Signed-off-by:
-
Ankit Nautiyal authored
HF-VSDB/SCDB has bits to advertise support for 16, 12 and 10 bpc. If none of the bits are set, the minimum bpc supported with DSC is 8. This patch corrects the min bpc supported to be 8, instead of 0. Fixes: 76ee7b90 ("drm/edid: Parse DSC1.2 cap fields from HFVSDB block") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> v2: s/DSC1.2/DSC 1.2 Signed-off-by:
-
Simon Ser authored
Document flags accepted by the page-flip and atomic IOCTLs. v2 (Pekka): - Mention DRM_EVENT_FLIP_COMPLETE in DRM_MODE_PAGE_FLIP_EVENT docs. - Expand DRM_MODE_ATOMIC_NONBLOCK and DRM_MODE_ATOMIC_ALLOW_MODESET description. v3: - Fix struct field ref syntax (Daniel) - Clarify when artifacts are no longer displayed (Daniel) - Add note about sinks deciding to show artifacts on their own (Pekka, Daniel) v4: - Fix typo (Pekka) Signed-off-by:
Simon Ser <contact@emersion.fr> Reviewed-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/505107/
-
Jilin Yuan authored
Delete the redundant word 'on'. Signed-off-by:
Jilin Yuan <yuanjilin@cdjrlc.com> Signed-off-by:
-
Pin-yen Lin authored
Add atomic_pre_enable and atomic_post_disable callback to make sure the bridge is not powered off until atomic_post_disable is called. This prevents a power leakage when it6505 is powered off, but the upstream DRM bridge is still sending display signals. Fixes: b5c84a9e ("drm/bridge: add it6505 driver") Signed-off-by:
Pin-yen Lin <treapking@chromium.org> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221004044943.2407781-3-treapking@chromium.org
-
Pin-yen Lin authored
Use pm_runtime_(get|put)_sync to control the bridge power, and add SET_SYSTEM_SLEEP_PM_OPS with pm_runtime_force_(suspend|resume) to it6505 driver. Without SET_SYSTEM_SLEEP_PM_OPS, the bridge will be powered on unnecessarily when no external display is connected. Fixes: b5c84a9e ("drm/bridge: add it6505 driver") Signed-off-by:
-
- 03 Oct, 2022 3 commits
-
-
Wei Yongjun authored
Add spi_device_id entries to silent following SPI warning: SPI driver ws2401-panel has no spi_device_id for samsung,lms380kf01 Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220915163437.2519754-1-weiyongjun@huaweicloud.com
-
Wei Yongjun authored
Add spi_device_id entries to silent following SPI warning: SPI driver tpo-tpg110-panel has no spi_device_id for tpo,tpg110 Signed-off-by:
-
Wei Yongjun authored
Add spi_device_id entries to silent following SPI warning: SPI driver db7430-panel has no spi_device_id for samsung,lms397kf04 Signed-off-by:
-
- 30 Sep, 2022 1 commit
-
-
Andrey Grodzovsky authored
When many entities are competing for the same run queue on the same scheduler, we observe an unusually long wait times and some jobs get starved. This has been observed on GPUVis. The issue is due to the Round Robin policy used by schedulers to pick up the next entity's job queue for execution. Under stress of many entities and long job queues within entity some jobs could be stuck for very long time in it's entity's queue before being popped from the queue and executed while for other entities with smaller job queues a job might execute earlier even though that job arrived later then the job in the long queue. Fix: Add FIFO selection policy to entities in run queue, chose next entity on run queue in such order that if job on one entity arrived earlier then job on another entity the first job will start executing earlier regardless of the length of the entity's job queue. v2: Switch to rb tree structure for entities based on TS of oldest job waiting in the job queue of an entity. Improves next entity extraction to O(1). Entity TS update O(log N) where N is the number of entities in the run-queue Drop default option in module control parameter. v3: Various cosmetical fixes and minor refactoring of fifo update function. (Luben) v4: Switch drm_sched_rq_select_entity_fifo to in order search (Luben) v5: Fix up drm_sched_rq_select_entity_fifo loop (Luben) v6: Add missing drm_sched_rq_remove_fifo_locked v7: Fix ts sampling bug and more cosmetic stuff (Luben) v8: Fix module parameter string (Luben) Cc: Luben Tuikov <luben.tuikov@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Direct Rendering Infrastructure - Development <dri-devel@lists.freedesktop.org> Cc: AMD Graphics <amd-gfx@lists.freedesktop.org> Signed-off-by:
Yunxiang Li (Teddy) <Yunxiang.Li@amd.com> Signed-off-by:
Luben Tuikov <luben.tuikov@amd.com> Reviewed-by:
-
- 29 Sep, 2022 4 commits
-
-
Yuan Can authored
In the probe path, dev_err() can be replaced with dev_err_probe() which will check if error code is -EPROBE_DEFER and prints the error name. It also sets the defer probe reason which can be checked later through debugfs. Signed-off-by:
Yuan Can <yuancan@huawei.com> Reviewed-by:
-
Yuan Can authored
In the probe path, dev_err() can be replaced with dev_err_probe() which will check if error code is -EPROBE_DEFER and prints the error name. It also sets the defer probe reason which can be checked later through debugfs. Signed-off-by:
-
Christoph Niedermaier authored
Add Multi-Inno Technology MI0800FT-9 8" 800x600 DPI panel support. Signed-off-by:
Christoph Niedermaier <cniedermaier@dh-electronics.com> Cc: Sam Ravnborg <sam@ravnborg.org> To: dri-devel@lists.freedesktop.org Signed-off-by:
Marek Vasut <marex@denx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220812114832.4946-1-cniedermaier@dh-electronics.com
-
Christoph Niedermaier authored
Add Multi-Inno Technology MI0800FT-9 8" 800x600 DPI panel compatible string. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
- 28 Sep, 2022 5 commits
-
-
Francesco Dolcini authored
Correct I2C address for the register list in lt8912_write_lvds_config(), these registers are on the first I2C address (0x48), the current function is just writing garbage to the wrong registers and this creates multiple issues (artifacts and output completely corrupted) on some HDMI displays. Correct I2C address comes from Lontium documentation and it is the one used on other out-of-tree LT8912B drivers [1]. [1] https://github.com/boundarydevices/linux/blob/boundary-imx_5.10.x_2.0.0/drivers/video/lt8912.c#L296 Fixes: 30e2ae94 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Signed-off-by:
Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by:
Philippe Schenker <philippe.schenker@toradex.com> Acked-by:
Adrien Grassein <adrien.grassein@gmail.com> Signed-off-by:
-
Philippe Schenker authored
The Lontium LT8912 does have a setting for DVI or HDMI. This patch reads from EDID what the display needs and sets it accordingly. Fixes: 30e2ae94 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Signed-off-by:
-
Philippe Schenker authored
Currently the bridge driver does not take care whether or not the display needs positive/negative vertical/horizontal syncs. Pass these two flags to the bridge from the EDID that was read out from the display. Fixes: 30e2ae94 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Signed-off-by:
-
Khaled Almahallawy authored
The sequence for Source DP PHY CTS automation is [2][1]: 1- Emulate successful Link Training(LT) 2- Short HPD and change link rates and number of lanes by LT. (This is same flow for Link Layer CTS) 3- Short HPD and change PHY test pattern and swing/pre-emphasis levels (This step should not trigger LT) The problem is with DP PHY compliance setup as follow: [DPTX + on board LTTPR]------Main Link--->[Scope] ^ | | | | | ----------Aux Ch------>[Aux Emulator] At step 3, before writing TRAINING_LANEx_SET/LINK_QUAL_PATTERN_SET to declare the pattern/swing requested by scope, we write link config in LINK_BW_SET/LANE_COUNT_SET on a port that has LTTPR. As LTTPR snoops aux transaction, LINK_BW_SET/LANE_COUNT_SET writes indicate a LT will start [Check DP 2.0 E11 -Sec 3.6.8.2 & 3.6.8.6.3], and LTTPR will reset the link and stop sending DP signals to DPTX/Scope causing the measurements to fail. Note that step 3 will not trigger LT and DP link will never recovered by the Aux Emulator/Scope. The reset of link can be tested with a monitor connected to LTTPR port simply by writing to LINK_BW_SET or LANE_COUNT_SET as follow igt/tools/dpcd_reg write --offset=0x100 --value 0x14 --device=2 OR printf '\x14' | sudo dd of=/dev/drm_dp_aux2 bs=1 count=1 conv=notrunc seek=$((0x100)) This single aux write causes the screen to blank, sending short HPD to DPTX, setting LINK_STATUS_UPDATE = 1 in DPCD 0x204, and triggering LT. As stated in [1]: "Before any TX electrical testing can be performed, the link between a DPTX and DPRX (in this case, a piece of test equipment), including all LTTPRs within the path, shall be trained as defined in this Standard." In addition, changing Phy pattern/Swing/Pre-emphasis (Step 3) uses the same link rate and lane count applied on step 2, so no need to redo LT. The fix is to not rewrite link config in step 3, and just writes TRAINING_LANEx_SET and LINK_QUAL_PATTERN_SET [1]: DP 2.0 E11 - 3.6.11.1 LTTPR DPTX_PHY Electrical Compliance [2]: Configuring UnigrafDPTC Controller - Automation Test Sequence https://www.keysight.com/us/en/assets/9922-01244/help-files/ D9040DPPC-DisplayPort-Test-Software-Online-Help-latest.chm Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Or Cochvi <or.cochvi@intel.com> Signed-off-by:Khaled Almahallawy <khaled.almahallawy@intel.com> Signed-off-by:
-
Simon Ser authored
Replace DRM_DEBUG_KMS() with drm_dbg_kms() which allows specifying the DRM device to provide more context. Signed-off-by:
-
- 27 Sep, 2022 4 commits
-
-
José Expósito authored
Extend the existing test cases to test the conversion from XRGB8888 to grayscale. Tested-by:
Maíra Canal <mairacanal@riseup.net> Reviewed-by:
David Gow <davidgow@google.com> Acked-by:
Maxime Ripard <maxime@cerno.tech> Signed-off-by:
José Expósito <jose.exposito89@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220926080837.65734-4-jose.exposito89@gmail.com
-
José Expósito authored
Extend the existing test cases to test the conversion from XRGB8888 to XRGB2101010. In order to be able to call drm_fb_xrgb8888_to_xrgb2101010() when compiling CONFIG_DRM_KMS_HELPER as a module export the symbol. Tested-by:
-
José Expósito authored
Extend the existing test cases to test the conversion from XRGB8888 to RGB888. Tested-by:
-
Sean Hong authored
Add support for the BOE - NT116WHM-N4C (HW: V8.1) panel. Signed-off-by:
Sean Hong <sean.hong@quanta.corp-partner.google.com> Reviewed-by:
-
