summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-09-25drm/i915: Add Wa_18028616096Shekhar Chauhan
Drop UGM per set fragment threshold to 3 BSpec: 54833 Signed-off-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> [mattrope: moved above xehpsdv block for consistency] Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230922155356.583595-1-shekhar.chauhan@intel.com
2023-09-25drm/i915/irq: Clear GFX_MSTR_IRQ as part of IRQ resetGustavo Sousa
Starting with Xe_LP+, GFX_MSTR_IRQ contains status bits that have W1C behavior. If we do not properly reset them, we would miss delivery of interrupts if a pending bit is set when enabling IRQs. As an example, the display part of our probe routine contains paths where we wait for vblank interrupts. If a display interrupt was already pending when enabling IRQs, we would time out waiting for the vblank. Avoid the potential issue by clearing GFX_MSTR_IRQ as part of the IRQ reset. v2: - Move logic from gen11_gt_irq_reset() to dg1_irq_reset(). (Matt) BSpec: 50875, 54028 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230920195351.59421-2-gustavo.sousa@intel.com
2023-09-25drm/i915/gem: remove inlines from i915_gem_execbuffer.cJani Nikula
Just let the compiler decide what's best. Turns out absolutely nothing changes in the output with the inlines removed. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230921160637.3862597-1-jani.nikula@intel.com
2023-09-25drm/i915: Zap some empty linesTvrtko Ursulin
Recent refactoring left an unsightly block of empty lines. Remove them. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230920085715.6905-1-tvrtko.ursulin@linux.intel.com
2023-09-25drm/bridge: Add 200ms delay to wait FW HPD status stableXin Ji
For the no-interrupt design (sink device is panel, polling HPD status when chip power on), anx7625 FW has more than 200ms HPD de-bounce time in FW, for the safety to get HPD status, driver better to wait 200ms before HPD detection after OS resume back. Signed-off-by: Xin Ji <xji@analogixsemi.com> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230922093450.3574349-1-xji@analogixsemi.com
2023-09-25drm/i915/gt: remove a static inline that requires including i915_drv.hJani Nikula
It's actively harmful to add static inlines in headers that require you to pull in more headers. Remove the include added in commit f1530f912ed8 ("drm/i915/gt: Apply workaround 22016122933 correctly"). We see that there's already an implicit dependency on the i915_drv.h that we need to address too. Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Fei Yang <fei.yang@intel.com> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230921162456.3889375-1-jani.nikula@intel.com
2023-09-25drm/simpledrm: Add support for multiple "power-domains"Janne Grunau
Multiple power domains need to be handled explicitly in each driver. The driver core can not handle it automatically since it is not aware of power sequencing requirements the hardware might have. This is not a problem for simpledrm since everything is expected to be powered on by the bootloader. simpledrm has just ensure it remains powered on during its lifetime. This is required on Apple silicon M2 and M2 Pro/Max/Ultra desktop systems. The HDMI output initialized by the bootloader requires keeping the display controller and a DP phy power domain on. Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Eric Curtin <ecurtin@redhat.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sven Peter <sven@svenpeter.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230912-simpledrm-multiple-power-domains-v2-1-01b66bfb1980@jannau.net
2023-09-22accel/qaic: Add QAIC_DETACH_SLICE_BO IOCTLPranjal Ramajor Asha Kanojiya
Once a BO is attached with slicing configuration that BO can only be used for that particular setting. With this new feature user can detach slicing configuration off an already sliced BO and attach new slicing configuration using QAIC_ATTACH_SLICE_BO. This will support BO recycling. detach_slice_bo() detaches slicing configuration from a BO. This new helper function can also be used in release_dbc() as we are doing the exact same thing. Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> [jhugo: add documentation for new ioctl] Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901172247.11410-8-quic_jhugo@quicinc.com
2023-09-22accel/qaic: Create a function to initialize BOPranjal Ramajor Asha Kanojiya
This makes sure that we have a single place to initialize and re-initialize BO. Use this new API to cleanup release_dbc() We will need this for next patch to detach slicing to a BO. Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901172247.11410-7-quic_jhugo@quicinc.com
2023-09-22accel/qaic: Clean up BO during flushing of transfer listPranjal Ramajor Asha Kanojiya
Variables that are set while adding the corresponding BO in transfer list should be cleaned when flushing them out of transfer list prematurely. After this patch we do not need some of the cleanup done in release_dbc() This patch would also pave the way to have a central location to clean BO, during an undesired situation. Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901172247.11410-6-quic_jhugo@quicinc.com
2023-09-22accel/qaic: Undo slicing setup done in qaic_attach_slicing_bo()Pranjal Ramajor Asha Kanojiya
qaic_attach_slicing_bo() updates slicing config on BO. Use the existing function qaic_free_slices_bo() to remove slicing config done in qaic_attach_slicing_bo(). Use qaic_free_slices_bo() to cleanup release_dbc() This would be helpful when we introduce a new IOCTL to detach slicing configuration onto a BO. Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901172247.11410-5-quic_jhugo@quicinc.com
2023-09-22accel/qaic: Declare BO 'sliced' after all the operations are completePranjal Ramajor Asha Kanojiya
Once the BO is declared 'sliced' by setting bo->sliced to true we can perform DMA (QAIC_EXECUTE_BO) operation on that BO. Hence we should declare a BO sliced after completing all the operations. Adding BO to its respective DBC list in qaic_attach_slicing_bo() seems out of place as qaic_attach_slicing_bo() should just update BO with slicing configuration. Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901172247.11410-4-quic_jhugo@quicinc.com
2023-09-22accel/qaic: Update BO metadata in a central locationPranjal Ramajor Asha Kanojiya
Update/Clean up BO metadata in a central location, this will help maintain the code and looks cleaner. Use qaic_unprepare_bo() to cleanup release_dbc() Next few patches will be implementing detach IOCTL which will leverage this patch. Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901172247.11410-3-quic_jhugo@quicinc.com
2023-09-22accel/qaic: Remove ->size field from struct qaic_boPranjal Ramajor Asha Kanojiya
->size field in struct qaic_bo stores user requested buffer size for allocate path or size of the dmabuf(PRIME). Now for allocate path driver allocates a BO of size which is PAGE_SIZE aligned, this size is already stored in base BO structure (struct drm_gem_object). So difference is ->size of struct qaic_bo stores the raw value coming from user and ->size in struct drm_gem_object stores the PAGE_SZIE aligned size. Do not use ->size from struct qaic_bo for any validation or operation instead use ->size from struct drm_gem_object since we already have allocated that much memory then why not use it. Only validate if user is trying to use more then the BO size. This make the driver more flexible. After this change ->size field of struct qaic_bo becomes redundant. Remove it. Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901172247.11410-2-quic_jhugo@quicinc.com
2023-09-22drm/i915/display: Print display info inside driver display initializationBalasubramani Vivekanandan
Separate the printing of display version and feature flags from the main driver probe to inside the display initialization. This is in alignment with isolating the display code from the main driver and helps Xe driver to resuse it. v2: Replace drm_info_printer with drm_debug_printer (Jani) Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230921105954.2002469-1-balasubramani.vivekanandan@intel.com
2023-09-22drm/ssd130x: Drop _helper prefix from struct drm_*_helper_funcs callbacksJavier Martinez Canillas
The driver uses a naming convention where functions for struct drm_*_funcs callbacks are named ssd130x_$object_$operation, while the callbacks for struct drm_*_helper_funcs are named ssd130x_$object_helper_$operation. The idea is that this helper_ prefix in the function names denote that are for struct drm_*_helper_funcs callbacks. This convention was copied from other drivers when ssd130x was written, but Maxime pointed out that is the exception rather than the norm. So let's get rid of the _helper prefixes from the function handlers names. Suggested-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230914195138.1518065-1-javierm@redhat.com
2023-09-22Merge tag 'drm-misc-next-2023-09-11-1' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for v6.7-rc1: UAPI Changes: - Nouveau changed to not set NO_PREFETCH flag explicitly. Cross-subsystem Changes: - Update documentation of dma-buf intro and uapi. - fbdev/sbus fixes. - Use initializer macros in a lot of fbdev drivers. - Add Boris Brezillon as Panfrost driver maintainer. - Add Jessica Zhang as drm/panel reviewer. - Make more fbdev drivers use fb_ops helpers for deferred io. - Small hid trailing whitespace fix. - Use fb_ops in hid/picolcd Core Changes: - Assorted small fixes to ttm tests, drm/mst. - Documentation updates to bridge. - Add kunit tests for some drm_fb functions. - Rework drm_debugfs implementation. - Update xe documentation to mark todos as completed. Driver Changes: - Add support to rockchip for rv1126 mipi-dsi and vop. - Assorted small fixes to nouveau, bridge/samsung-dsim, bridge/lvds-codec, loongson, rockchip, panfrost, gma500, repaper, komeda, virtio, ssd130x. - Add support for simple panels Mitsubishi AA084XE01, JDI LPM102A188A, - Documentation updates to accel/ivpu. - Some nouveau scheduling/fence fixes. - Power management related fixes and other fixes to ivpu. - Assorted bridge/it66121 fixes. - Make platform drivers return void in remove() callback. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3da6554b-3b47-fe7d-c4ea-21f4f819dbb6@linux.intel.com
2023-09-21drm/i915/bios: Fixup h/vsync_end instead of h/vtotalVille Syrjälä
We have the same h/vsync_end vs. h/vtotal quirk in the VBT parser that was also present in EDID parser. Adjust the VBT parser the same way as was done for hte EDID parser to fixup h/vsync_end instead of h/vtotal. While I'm not currently aware of any machines that need this for the VBT it seems prudent to keep both parsers in sync. And while at it let's add some debugs here as well. A bit lackluster but didn't feel like plumbing the connector all the way down at this time. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230920211934.14920-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-09-21drm/i915/gt: Fix reservation address in ggtt_reserve_guc_topJavier Pello
There is an assertion in ggtt_reserve_guc_top that the global GTT is of size at least GUC_GGTT_TOP, which is not the case on a 32-bit platform; see commit 562d55d991b39ce376c492df2f7890fd6a541ffc ("drm/i915/bdw: Only use 2g GGTT for 32b platforms"). If GEM_BUG_ON is enabled, this triggers a BUG(); if GEM_BUG_ON is disabled, the subsequent reservation fails and the driver fails to initialise the device: i915 0000:00:02.0: [drm:i915_init_ggtt [i915]] Failed to reserve top of GGTT for GuC i915 0000:00:02.0: Device initialization failed (-28) i915 0000:00:02.0: Please file a bug on drm/i915; see https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for details. i915: probe of 0000:00:02.0 failed with error -28 Make the reservation at the top of the available space, whatever that is, instead of assuming that the top will be GUC_GGTT_TOP. Fixes: 911800765ef6 ("drm/i915/uc: Reserve upper range of GGTT") Link: https://gitlab.freedesktop.org/drm/intel/-/issues/9080 Signed-off-by: Javier Pello <devel@otheo.eu> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Fernando Pacheco <fernando.pacheco@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: stable@vger.kernel.org # v5.3+ Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230902171039.2229126186d697dbcf62d6d8@otheo.eu
2023-09-21drm/edid: Fixup h/vsync_end instead of h/vtotalVille Syrjälä
There are some weird EDIDs floating around that have the sync pulse extending beyond the end of the blanking period. On the currently problemtic machine (HP Omni 120) EDID reports the following mode: "1600x900": 60 108000 1600 1780 1860 1800 900 910 913 1000 0x40 0x5 which is then "corrected" to have htotal=1861 by the current drm_edid.c code. The fixup code was originally added in commit 7064fef56369 ("drm: work around EDIDs with bad htotal/vtotal values"). Googling around we end up in https://bugs.launchpad.net/ubuntu/hardy/+source/xserver-xorg-video-intel/+bug/297245 where we find an EDID for a Dell Studio 15, which reports: (II) VESA(0): clock: 65.0 MHz Image Size: 331 x 207 mm (II) VESA(0): h_active: 1280 h_sync: 1328 h_sync_end 1360 h_blank_end 1337 h_border: 0 (II) VESA(0): v_active: 800 v_sync: 803 v_sync_end 809 v_blanking: 810 v_border: 0 Note that if we use the hblank size (as opposed of the hsync_end) from the DTD to determine htotal we get exactly 60Hz refresh rate in both cases, whereas using hsync_end to determine htotal we get a slightly lower refresh rates. This makes me believe the using the hblank size is what was intended even in those cases. Also note that in case of the HP Onmi 120 the VBIOS boots with these: crtc timings: 108000 1600 1780 1860 1800 900 910 913 1000, type: 0x40 flags: 0x5 ie. it just blindly stuffs the bogus hsync_end and htotal from the DTD into the transcoder timing registers, and the display works. I believe the (at least more modern) hardware will automagically terminate the hsync pulse when the timing generator reaches htotal, which again points that we should use the hblank size to determine htotal. Unfortunatley the old bug reports for the Dell machines are extremely lacking in useful details so we have no idea what kind of timings the VBIOS programmed into the hardware :( Let's just flip this quirk around and reduce the length of the sync pulse instead of extending the blanking period. This at least seems to be the correct thing to do on more modern hardware. And if any issues crop up on older hardware we need to debug them properly. v2: Add debug message breadcrumbs (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8895 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230920211934.14920-1-ville.syrjala@linux.intel.com
2023-09-21drm/hisilicon/kirin: Call drm_atomic_helper_shutdown() at shutdown/unbind timeDouglas Anderson
Based on grepping through the source code this driver appears to be missing a call to drm_atomic_helper_shutdown() at system shutdown time and at driver unbind time. Among other things, this means that if a panel is in use that it won't be cleanly powered off at system shutdown time. The fact that we should call drm_atomic_helper_shutdown() in the case of OS shutdown/restart and at driver remove (or unbind) time comes straight out of the kernel doc "driver instance overview" in drm_drv.c. I have attempted to put this in the right place at unbind time. In most other DRM drivers the call is made right after the call to drm_kms_helper_poll_fini(), so I've put it there. That means that this call will also be made in the case that we hit errors in bind, since kirin_drm_kms_cleanup() is called both in the bind error path and in unbind. I believe this is harmless even though it's not needed in the bind error path. For handling shutdown, we rely on the common technique of seeing if the drvdata is NULL to know whether we need to call drm_atomic_helper_shutdown(). This makes it important to make sure that the drvdata is NULL if bind failed or if unbind was called. We don't need the actual check for NULL and we'll rely on the patch ("drm/atomic-helper: drm_atomic_helper_shutdown(NULL) should be a noop"). Suggested-by: Maxime Ripard <mripard@kernel.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230901163944.RFT.6.I21e0916bbd276033f7d31979c0da171458dedd4d@changeid
2023-09-21drm: Call drm_atomic_helper_shutdown() at shutdown/remove time for misc driversDouglas Anderson
Based on grepping through the source code these drivers appear to be missing a call to drm_atomic_helper_shutdown() at system shutdown time and at driver remove (or unbind) time. Among other things, this means that if a panel is in use that it won't be cleanly powered off at system shutdown time. The fact that we should call drm_atomic_helper_shutdown() in the case of OS shutdown/restart and at driver remove (or unbind) time comes straight out of the kernel doc "driver instance overview" in drm_drv.c. A few notes about these fixes: - I confirmed that these drivers were all DRIVER_MODESET type drivers, which I believe makes this relevant. - I confirmed that these drivers were all DRIVER_ATOMIC. - When adding drm_atomic_helper_shutdown() to the remove/unbind path, I added it after drm_kms_helper_poll_fini() when the driver had it. This seemed to be what other drivers did. If drm_kms_helper_poll_fini() wasn't there I added it straight after drm_dev_unregister(). - This patch deals with drivers using the component model in similar ways as the patch ("drm: Call drm_atomic_helper_shutdown() at shutdown time for misc drivers") - These fixes rely on the patch ("drm/atomic-helper: drm_atomic_helper_shutdown(NULL) should be a noop") to simplify shutdown. Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> # tilcdc Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230901163944.RFT.5.I771eb4bd03d8772b19e7dcfaef3e2c167bce5846@changeid
2023-09-21drm/ssd130x: Call drm_atomic_helper_shutdown() at remove timeDouglas Anderson
Based on grepping through the source code, this driver appears to be missing a call to drm_atomic_helper_shutdown() at remove time. Let's add it. The fact that we should call drm_atomic_helper_shutdown() in the case of OS driver remove comes straight out of the kernel doc "driver instance overview" in drm_drv.c. Suggested-by: Maxime Ripard <mripard@kernel.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230901163944.RFT.4.I4752a39ad9f8fd08b32c2b78a8a3e40491bfb5eb@changeid
2023-09-21drm/vc4: Call drm_atomic_helper_shutdown() at shutdown timeDouglas Anderson
Based on grepping through the source code these drivers appear to be missing a call to drm_atomic_helper_shutdown() at system shutdown time. Among other things, this means that if a panel is in use that it won't be cleanly powered off at system shutdown time. The fact that we should call drm_atomic_helper_shutdown() in the case of OS shutdown/restart comes straight out of the kernel doc "driver instance overview" in drm_drv.c. Suggested-by: Maxime Ripard <mripard@kernel.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230901163944.RFT.3.I10dbe099fb1059d304ba847d19fc45054f7ffe9f@changeid
2023-09-21drm: Call drm_atomic_helper_shutdown() at shutdown time for misc driversDouglas Anderson
Based on grepping through the source code these drivers appear to be missing a call to drm_atomic_helper_shutdown() at system shutdown time. Among other things, this means that if a panel is in use that it won't be cleanly powered off at system shutdown time. The fact that we should call drm_atomic_helper_shutdown() in the case of OS shutdown/restart comes straight out of the kernel doc "driver instance overview" in drm_drv.c. All of the drivers in this patch were fairly straightforward to fix since they already had a call to drm_atomic_helper_shutdown() at remove/unbind time but were just lacking one at system shutdown. The only hitch is that some of these drivers use the component model to register/unregister their DRM devices. The shutdown callback is part of the original device. The typical solution here, based on how other DRM drivers do this, is to keep track of whether the device is bound based on drvdata. In most cases the drvdata is the drm_device, so we can just make sure it is NULL when the device is not bound. In some drivers, this required minor code changes. To make things simpler, drm_atomic_helper_shutdown() has been modified to consider a NULL drm_device as a noop in the patch ("drm/atomic-helper: drm_atomic_helper_shutdown(NULL) should be a noop"). Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Acked-by: Maxime Ripard <mripard@kernel.org> Tested-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Sui Jingfeng <suijingfeng@loongson.cn> Tested-by: Sui Jingfeng <suijingfeng@loongson.cn> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230901163944.RFT.2.I9115e5d094a43e687978b0699cc1fe9f2a3452ea@changeid
2023-09-21drm/armada: Call drm_atomic_helper_shutdown() at shutdown timeDouglas Anderson
Based on grepping through the source code this driver appears to be missing a call to drm_atomic_helper_shutdown() at system shutdown time. Among other things, this means that if a panel is in use that it won't be cleanly powered off at system shutdown time. The fact that we should call drm_atomic_helper_shutdown() in the case of OS shutdown/restart comes straight out of the kernel doc "driver instance overview" in drm_drv.c. This driver was fairly easy to update. The drm_device is stored in the drvdata so we just have to make sure the drvdata is NULL whenever the device is not bound. To make things simpler, drm_atomic_helper_shutdown() has been modified to consider a NULL drm_device as a noop in the patch ("drm/atomic-helper: drm_atomic_helper_shutdown(NULL) should be a noop"). Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230901164111.RFT.1.I3d5598bd73a59b5ded71430736c93f67dc5dea61@changeid
2023-09-21drm/i915/lnl: Start using CDCLK through PLLStanislav Lisovskiy
Introduce correspondent definitions for choosing between CD2X CDCLK and PLL CDCLK as a source. All the entries in cdclk table for xe2lpd are defined with PLL CDCLK as source, so simply set it. Also skl_cdclk_decimal() shouldn't be set in CDCLK_CTL anymore, so skip it for display version 20 and above. v2: - Remove unneeded comment and use REG_BIT() (Matt Roper) - Rename CDCLK_SOURCE_SEL_CDCLK_PLL() to MDCLK_SOURCE_SEL_CDCLK_PLL to match spec (Lucas) Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-22-lucas.demarchi@intel.com
2023-09-21drm/i915/xe2lpd: Add DC state supportMatt Roper
Xe2_LPD supports DC5, DC6, and DC9 (DC3CO no longer exists). The overall programming and requirements to enter DC states are similar to those of Xe_LPD+ although AUX transactions do not require DC5/DC6 exit as they did previously. Bspec: 68851, 68857, 68886, 69115 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-21-lucas.demarchi@intel.com
2023-09-21drm/i915/xe2lpd: Add display power wellRavi Kumar Vodapalli
Add Display Power Well for Xe2_LPD. It's mostly the same as Xe_LPD+, so reuse the code. PGPICA1 contains type-C capable port slices which requires the well to power powered up, so add new power well definition for it. The DC_OFF fake power well will be added in a follow up commit. v2: Do not rmw as bit 31 is the only R/W bit in the register (Matt Roper) BSpec: 68886 Signed-off-by: Ravi Kumar Vodapalli <ravi.kumar.vodapalli@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-20-lucas.demarchi@intel.com
2023-09-21drm/i915/lnl: Add CDCLK tableStanislav Lisovskiy
Add a new CDCLK table for Lunar Lake. v2: - Remove mdclk from the table as it's not needed (Matt Roper) - Update waveform values to the latest from spec (Matt Roper) - Rename functions and calculation to match by pixel rate (Lucas) v3: Keep only the table: as far as intel_pixel_rate_to_cdclk() is concerned, the minimum cdclk should still be half the pixel rate on Xe2 (bspec 68858: "Pipe maximum pixel rate = 2 * CDCLK frequency * Pipe Ratio") (Matt Roper) Bspec: 68861, 68858 Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-19-lucas.demarchi@intel.com
2023-09-21drm/i915/lnl: Add gmbus/ddc supportLucas De Marchi
LNL's south display uses the same table as MTP. Check for LNL's fake PCH to make it consistent with the other checks. The VBT table doesn't contain the VBT -> spec mapping for LNL. Like in other cases, uses the same as the previous platform. Bspec: 68971, 20124 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-18-lucas.demarchi@intel.com
2023-09-21drm/i915/xe2lpd: Extend Wa_15010685871Lucas De Marchi
Xe2_LPD also needs workaround 15010685871. While adding the new display version, also re-order the condition to follow the convention of new version first. v2: Remove redundant HAS_CDCLK_SQUASH(). As the platform or IP version needing the workaround are handpicked, there is no need to also check if tha platform has squashing support (Matt Roper) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-17-lucas.demarchi@intel.com
2023-09-21drm/i915/xe2lpd: Add support for HPDGustavo Sousa
Hotplug setup for Xe2_LPD differs from Xe_LPD+ by the fact that the extra programming for hotplug inversion and DDI HPD filter duration is not necessary anymore. As mtp_hpd_irq_setup() is reasonably small, prefer to fork it into a new function for Xe2_LPD instead of adding a platform check. v2: Add extra bspec reference and fix missing else (Matt Roper) BSpec: 68970, 69940 Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-16-lucas.demarchi@intel.com
2023-09-21drm/i915/xe2lpd: Enable odd size and panning for planar yuvJuha-Pekka Heikkilä
Enable odd size and panning for planar yuv formats. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-15-lucas.demarchi@intel.com
2023-09-21drm/i915/xe2lpd: Read pin assignment from IOMLuca Coelho
Starting from display version 20, we need to read the pin assignment from the IOM TCSS_DDI_STATUS register instead of reading it from the FIA. We use the pin assignment to decide the maximum lane count. So, to support this change, add a new lnl_tc_port_get_max_lane_count() function that reads from the TCSS_DDI_STATUS register and decides the maximum lane count based on that. BSpec: 69594 Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-14-lucas.demarchi@intel.com
2023-09-21drm/i915/xe2lpd: Handle port AUX interruptsGustavo Sousa
Differently from previous version, Xe2_LPD groups all port AUX interrupt bits into PICA interrupt registers. While at it, drop some trailing newlines. BSpec: 68958, 69697 Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-13-lucas.demarchi@intel.com
2023-09-21drm/i915/xe2lpd: Re-order DP AUX regsLucas De Marchi
The address of CTL and DATA registers for DP AUX were changed in Xe2_LPD: now they are all in a single range, with CH_A and CH_B coming right after the USBC instances. Like was done when moving registers to PICA, use a helper macro to remap the ch passed to an index that can be used to calculate the right offset. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-12-lucas.demarchi@intel.com
2023-09-21drm/i915/display: Use _PICK_EVEN_2RANGES() in DP AUX regsLucas De Marchi
XELPDP_DP_AUX_CH_CTL() and XELPDP_DP_AUX_CH_DATA() use 2 ranges. Prefer using _PICK_EVEN_2RANGES() over PICK(). Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-11-lucas.demarchi@intel.com
2023-09-21drm/i915/display: Fix style and conventions for DP AUX regsLucas De Marchi
Fix some whitespace issues for register definitions and keep the defines for DP_AUX_CH_CTL and DP_AUX_CH_DATA in the right place: together with the bit definition. While at it add a TODO entry that those defines shouldn't be using an implicit dev_priv. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-10-lucas.demarchi@intel.com
2023-09-21drm/i915/xe2lpd: Register DE_RRMR has been removedClint Taylor
Do not read DE_RRMR register after display version 20. This register contains display state information during GFX state dumps. Bspec: 69456 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-9-lucas.demarchi@intel.com
2023-09-21drm/i915/xe2lpd: Don't try to program PLANE_AUX_DISTMatt Roper
Since Xe2LPD technically has FlatCCS, it doesn't have AuxCCS registers like PLANE_AUX_DIST. However we currently have HAS_FLAT_CCS hardcoded to 0 since compression isn't ready; we need to make sure this doesn't cause the display code to go back to trying to write this register. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-8-lucas.demarchi@intel.com
2023-09-21drm/i915/xe2lpd: Treat cursor plane as regular plane for DDB allocationStanislav Lisovskiy
We now start calculating relative plane data rate for cursor plane as well, as instructed by BSpec and also treat cursor plane same way as other planes, when doing allocation, i.e not using fixed allocation for cursor anymore. Bspec: 68907 Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-7-lucas.demarchi@intel.com
2023-09-21drm/i915/xe2lpd: Add fake PCHGustavo Sousa
Xe2_LPD doesn't have south display engine on a PCH, it's actually on the SoC die (while north display engine is on compute die). As such it makes no sense to go through the PCI devices looking for an ISA bridge. The approach used by BXT/GLK can't be used here since leaving it with PCH_NONE would mean taking the wrong code paths. For the places we currently use a PCH check, it's enough for now to just check the north display version. Use that to define a fake PCH to be used across the driver. Eventually these PCH checks may need to be re-designed as this is already the third platform using/needing a fake PCH. v2: Match on display IP version rather than on platform (Matt Roper) v3: Extend and clarify commit message (Matt Roper / Ville) Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-6-lucas.demarchi@intel.com
2023-09-21drm/i915: Re-order if/else ladder in intel_detect_pch()Lucas De Marchi
Follow the convention of checking the last platform first and reword the comment to convey there are more platforms than just DG1. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-5-lucas.demarchi@intel.com
2023-09-21drm/i915/display: Remove FBC capability from fused off pipesClint Taylor
If a particular pipe is disabled by fuse also remove the FBC for that pipe. Bspec: 69464 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-4-lucas.demarchi@intel.com
2023-09-21drm/i915/xe2lpd: FBC is now supported on all pipesMatt Roper
FBC is no longer limited by pipe: add the defines for pipes B and C that will be used by platforms supporting FBC on such pipes. Bspec: 68881, 68904 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-3-lucas.demarchi@intel.com
2023-09-21drm/i915/lnl: Add display definitionsBalasubramani Vivekanandan
Add Lunar Lake platform definitions for i915 display. The support for LNL will be added to the xe driver, with i915 only driving the display side. Xe2 display is derived from the Xe_LPD+ IP; additional feature deltas will be introduced in subsequent patches, so here it's just adding a separate xe2_lpd_display struct. v2: Use a LPDP_FEATURES macro (Matt Roper) Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-2-lucas.demarchi@intel.com
2023-09-21drm/i915/xelpdp: Add XE_LPDP_FEATURESLucas De Marchi
Add a FEATURES macro for XE_LPD+ as this is expected to be the baseline for Xe2_LPD and will allow to see the delta more easily. v2: Move everything from xe_lpdp_display to the new macro and remove the version setting: it's not needed with GMD_ID. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-1-lucas.demarchi@intel.com
2023-09-21MAINTAINERS: Update gma500 git repoMaxime Ripard
The GMA500 driver has been handled through drm-misc for a while but the git repo hasn't been updated. Make sure it points to the right place. Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230921110038.2613604-1-mripard@kernel.org
2023-09-21Revert "drm/i915/mst: Populate connector->ddc"Ville Syrjälä
This reverts commit 959fb1a686528df1b8fb0cc7bec8ff851b1594a5. Looks like the core MST code might not call i2c_adapter() for us in time, and thus creating the ddc symlink will fail. This will in fact fail the entire connector registration, but the MST code doesn't really seem to care about that and blindly plows ahead. All we may get in the logs is a nearly back to back register+unregister debug messages: [drm:drm_dp_mst_connector_late_register [drm_display_helper]] registering DPMST remote bus for card0-DP-7 [drm:intel_dp_hpd_pulse [i915]] DPRX ESI: 42 00 00 02 [drm:drm_dp_mst_connector_early_unregister [drm_display_helper]] unregistering DPMST remote bus for card0-DP-7 Untangling the initialization order may take some real work, so let's just revert the ddc symlink addition for now... Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9357 Fixes: 959fb1a68652 ("drm/i915/mst: Populate connector->ddc") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919095659.10742-1-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Karthik B S <karthik.b.s@intel.com>
generated by cgit (git 2.34.1) at 2025-07-15 20:17:44 +0000