- 12 Sep, 2022 1 commit
-
-
Jani Nikula authored
Backmerge to sync the DP MST atomic changes to drm-intel-next. Signed-off-by:Jani Nikula <jani.nikula@intel.com>
-
- 11 Sep, 2022 2 commits
-
-
Melissa Wen authored
Replace vkms_formats macro for fixed-point operations with functions from drm/drm_fixed.h to do the same job and fix 32-bit compilation errors. v2: - don't cast results to s32 (Igor) - add missing drm_fixp2int conversion (Igor) Fixes: a19c2ac9858 ("drm: vkms: Add support to the RGB565 format") Tested-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> (v1) Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1) Reported-by:Sudip Mukherjee <sudipm.mukherjee@gmail.com> Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Melissa Wen <mwen@igalia.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220910190303.682897-1-mwen@igalia.com
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for v6.1-rc1: [airlied - fix sun4i_tv build] UAPI Changes: - Hide unregistered connectors from GETCONNECTOR ioctl. - drm/virtio no longer advertises LINEAR modifier, as it doesn't work. - Cross-subsystem Changes: - Fix GPF in udmabuf failure path. Core Changes: - Rework TTM placement to use intersect/compatible functions. - Drop legacy DP-MST support. - More DP-MST related fixes, and move all state into atomic. - Make DRM_MIPI_DBI select DRM_KMS_HELPER. - Add audio_infoframe packing for DP. - Add logging when some atomic check functions fail. - Assorted documentation updates and fixes. Driver Changes: - Assorted cleanups and fixes in msm, lcdif, nouveau, virtio, panel/ilitek, bridge/icn6211, tve200, gma500, bridge/*, panfrost, via, bochs, qxl, sun4i. - Add add AUO B133UAN02.1, IVO M133NW4J-R3, Innolux N120ACA-EA1 eDP panels. - Improve DP-MST modeset state handling in amdgpu, nouveau, i915. - Drop DP-MST from radeon driver, it was broken and only user of legacy DP-MST. - Handle unplugging better in vc4. - Simplify drm cmdparser tests. - Add DP support to ti-sn65dsi86. - Add MT8195 DP support to mediatek. - Support RGB565, XRGB64, and ARGB64 formats in vkms. - Convert sun4i tv support to atomic. - Refactor vc4/vec TV Modesetting, and fix timings. - Use atomic helpers instead of simple display helpers in ssd130x. Maintainer changes: - Add Douglas Anderson as reviewer for panel-edp. Signed-off-by:
-
- 09 Sep, 2022 4 commits
-
-
Ville Syrjälä authored
Replace the hand rolled stuff with REG_FIELD_GET() for reading out the skl+ watermark latencies. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220908191646.20239-4-ville.syrjala@linux.intel.comReviewed-by:
-
Ville Syrjälä authored
Pull all the skl+ watermark code (and the dbuf/sagv/ipc code since it's all sort of intertwined and I'm too lazy to think of a finer grained split right now) into its own file from the catch-all intel_pm.c. Also sneak in the s/dev_priv/i915/ rename while at it. Signed-off-by:
-
Ville Syrjälä authored
No reaon to have this humongous if ladder in intel_read_wm_latency(). Just split it into nicer per-platforms functions. Also do the s/dev_priv/i915/ while touching all of this code. Signed-off-by:
-
Jani Nikula authored
struct intel_dsb can be an opaque type, hidden in intel_dsb.c. Make it so. Reduce related includes while at it. Signed-off-by:
-
- 08 Sep, 2022 17 commits
-
-
Imre Deak authored
When an MST connector stays enabled during a commit the connector's MST state needs to be added to the atomic state, but the corresponding MST payload allocation shouldn't be set for deletion; fix such modesets by ensuring the above even if the connector was already enabled before the modeset. The issue led to the following: [ 761.992923] i915 0000:00:02.0: drm_WARN_ON(payload->delete) [ 761.992949] WARNING: CPU: 6 PID: 1401 at drivers/gpu/drm/display/drm_dp_mst_topology.c:4221 drm_dp_atomic_find_time_slots+0x236/0x280 [drm_display_helper] [ 761.992955] Modules linked in: snd_hda_intel i915 drm_buddy drm_display_helper drm_kms_helper ttm drm snd_hda_codec_hdmi snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core snd_pcm prime_numbers i2c_algo_bit syscopyarea sysfillrect sysimgblt fb_sys_fops x86_pkg_temp_thermal cdc_ether coretemp crct10dif_pclmul usbnet crc32_pclmul mii ghash_clmulni_intel e1000e mei_me ptp i2c_i801 pps_core mei i2c_smbus intel_lpss_pci fuse [last unloaded: drm] [ 761.992986] CPU: 6 PID: 1401 Comm: testdisplay Tainted: G U 6.0.0-rc4-imre+ #565 [ 761.992989] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR5 RVP, BIOS ADLPFWI1.R00.3135.A00.2203251419 03/25/2022 [ 761.992990] RIP: 0010:drm_dp_atomic_find_time_slots+0x236/0x280 [drm_display_helper] [ 761.992994] Code: 4c 8b 67 50 4d 85 e4 75 03 4c 8b 27 e8 03 28 4e e1 48 c7 c1 8b 26 2c a0 4c 89 e2 48 c7 c7 a8 26 2c a0 48 89 c6 e8 31 d5 88 e1 <0f> 0b 49 8b 85 d0 00 00 00 4c 89 fa 48 c7 c6 a0 41 2c a0 48 8b 78 [ 761.992995] RSP: 0018:ffffc9000177ba60 EFLAGS: 00010286 [ 761.992998] RAX: 0000000000000000 RBX: ffff88810d2f1540 RCX: 0000000000000000 [ 761.992999] RDX: 0000000000000001 RSI: ffffffff82368a25 RDI: 00000000ffffffff [ 761.993000] RBP: ffff888142299d80 R08: ffff8884adbfdfe8 R09: 00000000ffefffff [ 761.993001] R10: ffff8884a6bfe000 R11: ffff8884ac443c30 R12: ffff888102972f90 [ 761.993002] R13: ffff8881163e2cf0 R14: 00000000000003ac R15: ffff88810c501000 [ 761.993003] FS: 00007f81e4c459c0(0000) GS:ffff888496500000(0000) knlGS:0000000000000000 [ 761.993004] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 761.993005] CR2: 0000555dac962a98 CR3: 0000000123a34006 CR4: 0000000000770ee0 [ 761.993006] PKRU: 55555554 [ 761.993007] Call Trace: [ 761.993009] <TASK> [ 761.993012] intel_dp_mst_compute_config+0x19a/0x350 [i915] [ 761.993090] intel_atomic_check+0xf37/0x3180 [i915] [ 761.993168] drm_atomic_check_only+0x5d3/0xa60 [drm] [ 761.993182] drm_atomic_commit+0x56/0xc0 [drm] [ 761.993192] ? drm_plane_get_damage_clips.cold+0x1c/0x1c [drm] [ 761.993204] drm_atomic_helper_set_config+0x78/0xc0 [drm_kms_helper] [ 761.993214] drm_mode_setcrtc+0x1ed/0x750 [drm] [ 761.993232] ? drm_mode_getcrtc+0x180/0x180 [drm] [ 761.993241] drm_ioctl_kernel+0xb5/0x150 [drm] [ 761.993252] drm_ioctl+0x203/0x3d0 [drm] [ 761.993261] ? drm_mode_getcrtc+0x180/0x180 [drm] [ 761.993276] __x64_sys_ioctl+0x8a/0xb0 [ 761.993281] do_syscall_64+0x38/0x90 [ 761.993285] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 761.993287] RIP: 0033:0x7f81e551aaff [ 761.993288] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00 [ 761.993290] RSP: 002b:00007fff4304af10 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 761.993292] RAX: ffffffffffffffda RBX: 00007fff4304afa0 RCX: 00007f81e551aaff [ 761.993293] RDX: 00007fff4304afa0 RSI: 00000000c06864a2 RDI: 0000000000000004 [ 761.993294] RBP: 00000000c06864a2 R08: 0000000000000000 R09: 0000555dac8a9c68 [ 761.993294] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000000008c4 [ 761.993295] R13: 0000000000000004 R14: 0000555dac8a9c68 R15: 00007fff4304b098 [ 761.993301] </TASK> Fixes: 083351e9 ("drm/display/dp_mst: Fix modeset tracking in drm_dp_atomic_release_vcpi_slots()") Testcase: igt@testdisplay Cc: Lyude Paul <lyude@redhat.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220907142542.1681994-1-imre.deak@intel.com
-
Chen-Yu Tsai authored
This panel has the same delay timing as N116BCA-EA1 from the same company, which is also the same as delay_200_500_e80_d50. Add an entry for it. Signed-off-by:
Chen-Yu Tsai <wenst@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Maxime Ripard authored
Our mode_set implementation can be merged into our atomic_enable implementation to simplify things, so let's do this. Acked-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220728-rpi-analog-tv-properties-v2-36-459522d653a7@cerno.tech
-
Ville Syrjälä authored
Use round-to-nearest behavour when calculating the TMDS clock. Matches what we do for most other clock related things. Acked-by:
-
Ville Syrjälä authored
Windows/BIOS always uses fixed N values. Let's match that behaviour. Allows us to also get rid of that constant_n quirk stuff. Reviewed-by:
-
Ville Syrjälä authored
On BDW+ M/N are double buffered and so we can easily reprogram them during a fastset. So for eDP panels that support seamless DRRS we can just change these without a full modeset. For earlier platforms we'd need to play tricks with M1/N1 vs. M2/N2 during the fastset to make sure we do the switch atomically. Not sure the added complexity is worth the hassle, so leave it alone for now. The slight downside is that we have to keep the link running at a link rate capable of supporting the highest refresh rate we want to use. For the moment we just pick the highest mode the panel reports and calculate the link based on that. This might need further refinement (eg. if we run into bandwidth restrictions)... v2: Only use the high link rate if the platform really supports the seamless M/N change uring fastset (ie. bdw+) v3: Rebase due to HAS_DOUBLE_BUFFERED_M_N() Reviewed-by:Mika Kahola <mika.kahola@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Add a function to get the fixed_mode with the highest clock. The plan is to use this for the link bw calculation on seamless DRRS panels so that we alwasy end up with the same link params regardless of the requested refresh rate. This will allow fastset to do seamless refresh rate changes based on userspace request instead of having to go for a full modeset. TODO: the function name isn't great Reviewed-by:
-
Ville Syrjälä authored
No sense in calling intel_modeset_pipe_config_late() for a disabled pipe. Reviewed-by:
-
Ville Syrjälä authored
Now that we no longer do the fuzzy clock and M/N checks we can get rid of the fastset state copy hacks. Reviewed-by:
-
Ville Syrjälä authored
To make the fastboot checks at least somewhat sensible let's mark the expected DPLL as the active one right after we finished the state computation. Otherwise intel_pipe_config_compare() will always be comparing things against NULL/0. TODO: This is still not really right. If the previous commit had to fall back to the other PLL then the comparisong will now fail. I guess intel_pipe_config_compare() should rather be comparing port_dplls[] instead. But to do that we really should just unify every platform to use the port_dplls[] approach whether they have any need for PLL fallbacks or not. Acked-by:
-
Ville Syrjälä authored
Now that we backfeed the actual DPLL frequency into the compute crtc state all our clocks should come out exact. Reviewed-by:
-
Ville Syrjälä authored
Now that we no longer fuzz M/N during fastset these should match exctly. In order to get a match with what the BIOS does we need to round M/N down. And we do the opposite rounding when doing the readback. That gets us pretty much the same thing back. There can still be slight rounding differences between FDI M/N vs. the DPLL output so we allow for tiny deviation in intel_pipe_config_sanity_check(). v2: Tweak rounding/sanity check stuff a bit Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1 Signed-off-by:
-
Ville Syrjälä authored
Do the DPLL computation before fastset checks. This should allow us to get rid of all that horrible fuzzy clock handling for fastsets. Who knows how many bugs there are caused by our state not actually matching what the hardware will generate. Reviewed-by:
-
Ville Syrjälä authored
Fill port_clock and hw.adjusted_mode.crtc_clock with the actual frequency we're going to be getting from the hardware. This will let us accurately compute all derived state that depends on those. v2: Reintroduce iCLKIP WARN v3: Try to deal with VLV/BXT DSI PLL as well Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1 Signed-off-by:
-
Ville Syrjälä authored
Only reassign the pipe's DPLL if it's going through a full .compute_config() cycle. If OTOH it's just getting modeset eg. in order to change cdclk there doesn't seem much point in picking a new DPLL for it. This should also prevent .get_dplls() from seeing a funky port_clock for DP even in cases where the readout produces a non-standard clock and we (for some reason) have decided to not fully recompute the state to remedy the situation. Reviewed-by:
-
Ville Syrjälä authored
Currently we calculate a lot of things (pixel rate, watermarks, cdclk) trusting that the DPLL can generate the exact frequency we ask it. In practice that is not true and there can be certain amount of rounding involved. To allow us to eventually get accurate numbers for all our DPLL clock derived state we need to move the DPLL calculation to hapen much earlier. To that end we hoist it up to the just after the fastset checks. For now we just do the easy code motion, and the actual back feeding of the final DPLL clock into the state will come later. A slight change here is that now .crtc_compute_clock() can get called while the shared_dpll is still assigned. But since .crtc_compute_clock() no longer assignes new shared_dplls this is perfectly fine. TODO: I'd actually like to do this before the fastset check so that if the DPLL state should change we actually do the modeset. Which I think is what the video aficionados want, but it might not be what the fans of fastboot want. Not yet sure how to reconcile those conflicting requirements... v2: s/return/goto/ in error handling Reviewed-by:
-
Javier Martinez Canillas authored
The simple display pipeline is a set of helpers that can be used by DRM drivers to avoid dealing with all the needed components and just define a few functions to operate a simple display device with one full-screen scanout buffer feeding a single output. But it is arguable that this provides the correct level of abstraction for simple drivers, and recently some have been ported from using these simple display helpers to use the regular atomic helpers instead. The rationale for this is that the simple display pipeline helpers don't hide that much of the DRM complexity, while adding an indirection layer that conflates the concepts of CRTCs and planes. This makes the helpers less flexible and harder to be reused among different graphics drivers. Also, for simple drivers, using the full atomic helpers doesn't require a lot of additional code. So adding a simple display pipeline layer may not be worth it. For these reasons, let's follow that trend and make ssd130x a plain DRM driver that creates its own primary plane, CRTC, enconder and connector. Suggested-by:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
-
- 07 Sep, 2022 16 commits
-
-
Ankit Nautiyal authored
Currently, pic_height of vdsc_cfg structure is being used to calculate slice_height, before it is set for DP. So taking out the lines to set pic_height from the helper intel_dp_dsc_compute_params() to individual encoders, and setting pic_height, before it is used to calculate slice_height for DP. Fixes: 5a6d866f ("drm/i915: Get slice height before computing rc params") Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220902103219.1168781-1-ankit.k.nautiyal@intel.com
-
Ville Syrjälä authored
Extract the state->freq computation for VLV/BXT DSI PLL into small helpers. We want to use these during the state computation as well. Reviewed-by:
-
Ville Syrjälä authored
We have a couple of places that want to make distinction between double buffered M/N registers vs. the split M1/N1+M2/N2 registers. Add a helper for that. v2: Turn into a HAS_ macro (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1 Signed-off-by:
-
Ville Syrjälä authored
Shuffle some PLL functions around a bit to avoid ugle forward declarations later on. No functional changes. Reviewed-by:
-
Ville Syrjälä authored
intel_crtc_dotclock() is a bit misplaced. In lieu of a better place let's just move it next to its friends in intel_display.c. Reviewed-by:
-
Jilin Yuan authored
Delete the redundant word 'for'. Signed-off-by:
Jilin Yuan <yuanjilin@cdjrlc.com> Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220907113927.35305-1-yuanjilin@cdjrlc.com
-
Zongmin Zhou authored
Details: Currently, when trying to suspend and resume with qxl device， there are some error messages after resuming, eventually caused to black screen and can't be recovered. The first error message: [ 64.668577][ C3] [drm] driver is in bug mode This error is due to guest qxl driver will call qxl_reinit_memslots(qdev) during system resume, but didn't call qxl_io_reset(qdev) before this, Then will cause the QXL_IO_MEMSLOT_ADD operation to fail on QEMU, qxl->guest_bug flag will be set，As a result, the QXL device can't communicate with guest qxl driver through the IO port. after fix the first error,can success to resume and login to desktop, but shortly after that will observe the second error message : [ 353.095343][ T863] qxl 0000:00:02.0: object_init failed for (262144, 0x00000001) [ 353.096660][ T863] [drm:qxl_gem_object_create [qxl]] *ERROR* Failed to allocate GEM object (260852, 1, 4096, -12) [ 353.097277][ T863] [drm:qxl_alloc_ioctl [qxl]] *ERROR* qxl_alloc_ioctl: failed to create gem ret=-12 [ 368.197538][ T863] qxl 0000:00:02.0: object_init failed for (3149824, 0x00000001) [ 368.197541][ T863] [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to allocate VRAM BO The problem is caused by calling qxl_ring_init_hdr(qdev->release_ring) in qxl_drm_resume() function. When do QXL_IO_RESET,QEMU will call init_qxl_ram(), so params like prod,cons,notify_on_cons and notify_on_prod will be set to default value. Ring push/pop actions for release_ring can be performed normally. But call qxl_ring_init_hdr(qdev->release_ring) will eventually set notify_on_prod to number of QXL_RELEASE_RING_SIZE, affect the value of notify in qxl_push_free_res() function always be false, QEMU will no longer send events of QXL_INTERRUPT_DISPLAY to the guest qxl driver，so qxl_ring_pop() will never been called anymore， and can't do dma_fence_signal(),result to ttm_bo_wait_ctx(bo, ctx) always return EBUSY,fail to call qxl_bo_create(). Test scenario: 1) start virtual machine with qemu command "-device qxl-vga" 2) click suspend botton to enter suspend mode 3) resume and observe the error message in kernel logs,screen will be black Let's fix this by reset io and remove the qxl_ring_init_hdr calling. Signed-off-by: Zongmin Zhou<zhouzongmin@kylinos.cn> Suggested-by: Ming Xie<xieming@kylinos.cn> Link: http://patchwork.freedesktop.org/patch/msgid/20220907094423.93581-1-min_halo@163.comSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Gerd Hoffmann authored
VGA_IS1_RC is the color mode register (VGA_IS1_RM the one for monochrome mode, note C vs. M at the end). So when using VGA_IS1_RC make sure the vga device is actually in color mode and set the corresponding bit in the misc register. Reproducible when booting VMs in UEFI mode with some edk2 versions (edk2 fix is on the way too). Doesn't happen in BIOS mode because in that case the vgabios already flips the bit. Fixes: 250e7439 ("drm/bochs: Add screen blanking support") Signed-off-by:
-
Chia-I Wu authored
Without this, the drm core advertises LINEAR modifier which is incorrect. Also userspace virgl does not support modifiers. For example, it causes chrome on ozone/drm to fail with "Failed to create scanout buffer". Fixes: 2af10429 ("drm: introduce fb_modifiers_not_supported flag in mode_config") Suggested-by:
Shao-Chuan Lee <shaochuan@chromium.org> Signed-off-by:
Chia-I Wu <olvaffe@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220831190601.1295129-1-olvaffe@gmail.comSigned-off-by:
-
Maxime Ripard authored
The reset line is deasserted at bind, and asserted if we ever encounter an error there. However, it's never asserted in unbind which will lead to a resource unbalance. Reviewed-by:
-
Maxime Ripard authored
The other error labels in sun4i_tv_bind() are named after the task they perform (err_disable_clk to call clk_disable_unprepare for example). However, the err_cleanup_connector is named after the calling site (drm_connector_init failing) and will actually cleanup the encoder. Let's rename it to err_cleanup_encoder to be consistent. Reviewed-by:
-
Maxime Ripard authored
Our destroy implementation is just calling the generic helper, so let's just remove our function and directly use the helper. Reviewed-by:
-
Maxime Ripard authored
The drm_connector_to_sun4i_tv() function isn't used anywhere in the driver, so let's remove it. Acked-by:
-
Maxime Ripard authored
The sun4i TV driver still uses legacy enable and disable hook implementation. Let's convert to the atomic variants. Acked-by:
-
Maxime Ripard authored
The mode_valid implementation is pretty much a nop, let's remove it. Reviewed-by:
-
Mateusz Kwiatkowski authored
This commit fixes vertical timings of the VEC (composite output) modes to accurately represent the 525-line ("NTSC") and 625-line ("PAL") ITU-R standards. Previous timings were actually defined as 502 and 601 lines, resulting in non-standard 62.69 Hz and 52 Hz signals being generated, respectively. Signed-off-by:Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Acked-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
-
