summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-09-22drm/i915: Fix g4x cxsr enable conditionVille Syrjälä1-3/+2
The intention was to check whether the primary plane is enabled without any sprites planes being enabled. Instead we ended up checking whether just any one of the planes is enabled. g4x isn't vlv/chv and cxsr only works with the primary plane. Fix the check to examine the bitmask of active planes rather than the number of bits set in said bitmask. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514125751.17075-3-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2021-09-22drm/i915: Use u8 consistently for active_planes bitmaskVille Syrjälä1-3/+3
Be consistent in that active_planes bitmask fits in a u8. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514125751.17075-4-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2021-09-22drm/i915: s/crtc_state/new_crtc_state/ etc.Ville Syrjälä1-19/+19
intel_plane_atomic_calc_changes() deals with both the old and new crtc/plane states. Make the variable names reflect that more clearly. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514125751.17075-2-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2021-09-22drm/i915/display: Add HDR mode helper functionTejas Upadhyay1-3/+7
Add helper function with returns if HDR mode in on Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210907113658.1351456-1-tejaskumarx.surendrakumar.upadhyay@intel.com [vsyrjala: fix up alignment to match codingstyle] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2021-09-22drm/bridge: Move devm_drm_of_get_bridge to bridge/panel.cMaxime Ripard2-34/+37
By depending on devm_drm_panel_bridge_add(), devm_drm_of_get_bridge() introduces a circular dependency between the modules drm (where devm_drm_of_get_bridge() ends up) and drm_kms_helper (where devm_drm_panel_bridge_add() is). Fix this by moving devm_drm_of_get_bridge() to bridge/panel.c and thus drm_kms_helper. Fixes: 87ea95808d53 ("drm/bridge: Add a function to abstract away panels") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210917180925.2602266-1-maxime@cerno.tech
2021-09-22drm/i915/debugfs: Do not report currently active engine when describing objectsTvrtko Ursulin2-22/+0
It is not very useful to have code which tries to report a rapidly transient state which will not report anything majority of the time, especially since it is currently only used from <debugfs>/i915_gem_framebuffers. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by: Christian König <christian.koenig@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210915114153.951670-1-tvrtko.ursulin@linux.intel.com
2021-09-22Merge tag 'drm-misc-next-2021-09-16' of ↵Dave Airlie145-5441/+2080
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for $kernel-version: UAPI Changes: Cross-subsystem Changes: - dma-buf: Avoid a warning with some allocations, Remove DMA_FENCE_TRACE macros Core Changes: - bridge: New helper to git rid of panels in drivers - fence: Improve dma_fence_add_callback documentation, Improve dma_fence_ops->wait documentation - ioctl: Unexport drm_ioctl_permit - lease: Documentation improvements - fourcc: Add new macro to determine the modifier vendor - quirks: Add the Steam Deck, Chuwi HiBook, Chuwi Hi10 Pro, Samsung Galaxy Book 10.6, KD Kurio Smart C15200 2-in-1, Lenovo Ideapad D330 - resv: Improve the documentation - shmem-helpers: Allocate WC pages on x86, Switch to vmf_insert_pfn - sched: Fix for a timer being canceled too soon, Avoid null pointer derefence if the fence is null in drm_sched_fence_free, Convert drivers to rely on its dependency tracking - ttm: Switch to kerneldoc, new helper to clear all DMA mappings, pool shrinker optitimization, Remove ttm_tt_destroy_common, Fix for unbinding on multiple drivers Driver Changes: - bochs: New PCI IDs - msm: Fence ordering impromevemnts - stm: Add layer alpha support, zpos - v3d: Fix for a Vulkan CTS failure - vc4: Conversion to the new bridge helpers - vgem: Use shmem helpers - virtio: Support mapping exported vram - zte: Remove obsolete driver - bridge: Probe improvements for it66121, enable DSI EOTP for anx7625, errors propagation improvements for anx7625 - panels: 60fps mode for otm8009a, New driver for Samsung S6D27A1 Signed-off-by: Dave Airlie <airlied@redhat.com> # gpg: Signature made Thu 16 Sep 2021 17:30:50 AEST # gpg: using EDDSA key 5C1337A45ECA9AEB89060E9EE3EF0D6F671851C5 # gpg: Can't check signature: No public key From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210916073132.ptbbmjetm7v3ufq3@gilmour
2021-09-22drm/i915/dg2: Add DG2-specific shadow register tableMatt Roper2-1/+41
We thought the DG2 table of shadowed registers would be the same as the gen12/xehp table, but it turns out that there are a few minor differences that require us to define a new DG2-specific table: * One register is removed (0xC4D4) * One register is added (0xC4E0) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210910201030.3436066-7-matthew.d.roper@intel.com
2021-09-22drm/i915/uncore: Drop gen11 mmio read handlersMatt Roper1-23/+17
Consolidate down to just a single 'fwtable' implementation. For reads we don't need to worry about shadow tables. While consolidating the functions, gen11/gen12 pick up a NEEDS_FORCE_WAKE() check that they didn't have before, allowing them to bypass a lot of forcewake/shadow checking for non-GT registers (e.g., display). v2: - Restore NEEDS_FORCE_WAKE() check. (Chris, Tvrtko) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210910201030.3436066-6-matthew.d.roper@intel.com
2021-09-22drm/i915/uncore: Drop gen11/gen12 mmio write handlersMatt Roper1-39/+21
Now that the reference to the shadow table is stored within the uncore, we don't need to generate separate fwtable, gen11_fwtable, and gen12_fwtable variants of the register write functions; a single 'fwtable' implementation will work for all of those platforms now. While consolidating the functions, gen11/gen12 pick up a NEEDS_FORCE_WAKE() check that they didn't have before, allowing them to bypass a lot of forcewake/shadow checking for non-GT registers (e.g., display). However since these later platforms also introduce media engines at higher MMIO offsets, the definition of NEEDS_FORCE_WAKE() is extended to also consider register offsets above GEN11_BSD_RING_BASE. v2: - Restore NEEDS_FORCE_WAKE(), but extend it for compatibility with the gen11+ platforms by also passing offsets above GEN11_BSD_RING_BASE. (Chris, Tvrtko) Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210910201030.3436066-5-matthew.d.roper@intel.com
2021-09-22drm/i915/uncore: Replace gen8 write functions with general fwtableMatt Roper1-12/+1
Now that we have both a standard forcewake table (albeit a single-entry table) and the shadow table stored in the uncore, we can drop the gen8-specific write handlers in favor of the general fwtable version. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210910201030.3436066-4-matthew.d.roper@intel.com
2021-09-22drm/i915/uncore: Associate shadow table with uncoreMatt Roper2-14/+33
Store a reference to a platform's shadow table inside the uncore, the same as we do with the forcewake table. This will allow us to use a single set of functions that operate on the shadow table reference rather than generating lots of nearly-identical functions via macros that differ only in terms of the table that they reference. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210910201030.3436066-3-matthew.d.roper@intel.com
2021-09-22drm/i915/uncore: Convert gen6/gen7 read operations to fwtableMatt Roper1-13/+8
On gen6-gen8 (except vlv/chv) we don't use a forcewake lookup table; we simply check whether the register offset is < 0x40000, and return FORCEWAKE_RENDER if it is. To prepare for upcoming refactoring, let's define a single-entry forcewake table from [0x0, 0x3ffff] and switch these platforms over to use the fwtable reader functions. v2: - Drop __gen6_reg_read_fw_domains which is no longer used. (Tvrtko) Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210910201030.3436066-2-matthew.d.roper@intel.com
2021-09-21MAINTAINERS: fix typo in DRM DRIVER FOR SAMSUNG S6D27A1 PANELSLukas Bulwahn1-1/+1
Commit ebd8cbf1fb96 ("drm/panel: s6d27a1: Add driver for Samsung S6D27A1 display panel") introduces a new section DRM DRIVER FOR SAMSUNG S6D27A1 PANELS with a minor typo in one of its file entries. Hence, ./scripts/get_maintainer.pl --self-test=patterns complains: warning: no file matches F: driver/gpu/drm/panel/panel-samsung-s6d27a1.c So, repair the entry and make get_maintainer.pl happy. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210921122146.13132-1-lukas.bulwahn@gmail.com
2021-09-21drm/rockchip: remove of_match_ptr() from analogix dp driverSouptick Joarder1-1/+1
Kernel test robot throws below warning when CONFIG_OF is not set. >> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c:457:34: warning: unused variable 'rockchip_dp_dt_ids' [-Wunused-const-variable] static const struct of_device_id rockchip_dp_dt_ids[] = { Fixed it by removing of_match_ptr(). Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210607184836.3502-1-jrdr.linux@gmail.com
2021-09-21drm/rockchip: remove of_match_ptr() from vop_driver_dt_matchSouptick Joarder1-1/+1
kernel test robot throws warning when CONFIG_OF not set. >> drivers/gpu/drm/rockchip/rockchip_vop_reg.c:1038:34: warning: unused variable 'vop_driver_dt_match' [-Wunused-const-variable] static const struct of_device_id vop_driver_dt_match[] = { Fixed it by removing of_match_ptr(). Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210607190800.3992-1-jrdr.linux@gmail.com
2021-09-21drm/rockchip: Check iommu itself instead of it's parent for device_is_availableAndy Yan1-1/+1
When iommu itself is disabled in dts, we should fallback to non-iommu buffer, check iommu parent is meanless here. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210627084737.309163-1-andy.yan@rock-chips.com
2021-09-21drm/rockchip: dsi: make hstt_table staticJiapeng Chong1-1/+1
This symbol is not used outside of dw-mipi-dsi-rockchip.c, so marks it static. Fix the following sparse warning: drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c:646:13: warning: symbol 'hstt_table' was not declared. Should it be static? Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/1628218664-14230-1-git-send-email-jiapeng.chong@linux.alibaba.com
2021-09-21drm/rockchip: dsi: Fix duplicate included linux/phy/phy.hJiapeng Chong1-1/+0
Clean up the following includecheck warning: ./drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c: linux/phy/phy.h is included more than once. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Fixes: 71f68fe7f121 ("drm/rockchip: dsi: add ability to work as a phy instead of full dsi") Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/1629454729-108701-1-git-send-email-jiapeng.chong@linux.alibaba.com
2021-09-21drm/rockchip: Make use of the helper function devm_platform_ioremap_resource()Cai Huoqing3-9/+3
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210831135721.4726-1-caihuoqing@baidu.com
2021-09-21drm/rockchip: add DRM_BRIDGE_ATTACH_NO_CONNECTOR flag to drm_bridge_attachAlex Bee2-10/+45
Commit a25b988ff83f ("drm/bridge: Extend bridge API to disable connector creation") added DRM_BRIDGE_ATTACH_NO_CONNECTOR bridge flag and all bridges handle this flag in some way since then. Newly added bridge drivers must no longer contain the connector creation and will fail probing if this flag isn't set. In order to be able to connect to those newly added bridges as well, make use of drm_bridge_connector API and have the connector initialized by the display controller. Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210913125108.195704-1-knaerzche@gmail.com
2021-09-21drm/rockchip: handle non-platform devices in rockchip_drm_endpoint_is_subdriverAlex Bee1-1/+8
As discussed at [1] rockchip_drm_endpoint_is_subdriver will currently always return -ENODEV for non-platform-devices (e.g. external i2c bridges), what makes them never being considered in rockchip_rgb_init. As suggested at [1] this additionally adds a of_device_is_available for the node found, which will work for both platform and non-platform devices. Also we can return early for non-platform-devices if they are enabled, as rockchip_sub_drivers contains exclusively platform-devices. [1] https://lore.kernel.org/all/20210316182753.GA25685@earth.li/ Suggested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210914150756.85190-1-knaerzche@gmail.com
2021-09-21drm/rockchip: remove unused psr_list{,_lock}Brian Norris2-5/+0
Some leftover cleanup from commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"). Cc: Heiko Stuebner <heiko@sntech.de> Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210915135007.1.I926ef5cef287047c35a17e363c919599c6ee6e4c@changeid
2021-09-21drm/i915: Check SFC fusing before recording/dumping SFC_DONEMatt Roper1-2/+4
On Xe_HP and beyond the SFC unit may be fused off, even if the corresponding media engines are present. Check the SFC-specific fusing before trying to dump the SFC_DONE instances. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210917161203.812251-3-matthew.d.roper@intel.com
2021-09-21drm/i915/xehp: Check new fuse bits for SFC availabilityMatt Roper4-10/+27
Xe_HP adds some new bits to the FUSE1 register to let us know whether a given SFC unit is present. We should take this into account while initializing SFC availability to our VCS and VECS engines. While we're at it, update the FUSE1 register definition to use REG_GENMASK / REG_FIELD_GET notation. Note that, the bspec confusingly names the fuse bits "disable" despite the register reflecting the *enable* status of the SFC units. The original architecture documents which the bspec is based on do properly name this field "SFC_ENABLE." Bspec: 52543 Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210917161203.812251-2-matthew.d.roper@intel.com
2021-09-20drm/i915: Take pinning into account in __i915_gem_object_is_lmemMatthew Brost1-3/+4
Don't blow up on a GEM_WARN_ON in __i915_gem_object_is_lmem if the object is pinned (not evictable). Signed-off-by: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210916162819.27848-6-matthew.brost@intel.com
2021-09-20drm/i915/guc: Enable GuC submission by default on DG1Matthew Brost1-1/+1
Enable GuC submission by default on DG1 Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210916162819.27848-5-matthew.brost@intel.com
2021-09-20drm/i915/guc: Add DG1 GuC / HuC firmware defsDaniele Ceraolo Spurio1-0/+1
Add DG1 GuC / HuC firmware defs Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210916162819.27848-4-matthew.brost@intel.com
2021-09-20drm/i915/guc: put all guc objects in lmem when availableDaniele Ceraolo Spurio6-13/+128
The firmware binary has to be loaded from lmem and the recommendation is to put all other objects in there as well. Note that we don't fall back to system memory if the allocation in lmem fails because all objects are allocated during driver load and if we have issues with lmem at that point something is seriously wrong with the system, so no point in trying to handle it. Cc: Matthew Auld <matthew.auld@intel.com> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210916162819.27848-3-matthew.brost@intel.com
2021-09-20drm/i915: Do not define vma on stackVenkata Sandeep Dhanalakota2-9/+18
Defining vma on stack can cause stack overflow, if vma gets populated with new fields. v2: (Daniel Vetter) - Add kerneldoc for new field Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210916162819.27848-2-matthew.brost@intel.com
2021-09-20MAINTAINERS: add Andrey as the DRM GPU scheduler maintainerAlex Deucher1-0/+8
Now that the scheduler is being used by more and more drivers, we need someone to maintain it. Andrey has stepped up to maintain the scheduler. Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Cc: airlied@gmail.com Cc: daniel.vetter@ffwll.ch Reviewed-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210917161540.822282-2-alexander.deucher@amd.com
2021-09-20drm/panel-edp: Implement generic "edp-panel"s probed by EDIDDouglas Anderson1-14/+201
As discussed in the patch ("dt-bindings: drm/panel-simple: Introduce generic eDP panels") we can actually support probing eDP panels at runtime instead of hardcoding what panel is connected. Add support to the panel-edp driver for this. We'll implement a solution like this: * We'll read in two delays from the device tree that are used for powering up the panel the initial time (to read the EDID). * In the EDID we can find a 32-bit ID that identifies what panel we've found. From this ID we can look up the full set of delays. After this change we'll still need to add per-panel delays into the panel-simple driver but we will no longer need to specify exactly which panel is connected to which board in the device tree. Nicely, any panels that are only supported this way also don't need to hardcode mode data since it's guaranteed that we can get that through the EDID. This patch will seed the ID-to-delay table with a few panels that I have access to, many of which are on sc7180-trogdor devices. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210914132020.v5.15.Id9c96cba4eba3e5ee519bfb09cd64b39f2490293@changeid
2021-09-20drm/panel-edp: Don't re-read the EDID every time we power off the panelDouglas Anderson1-3/+3
The simple-panel driver is for panels that are not hot-pluggable at runtime. Let's keep our cached EDID around until driver unload. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210914132020.v5.14.Ib810fb3bebd0bd6763e4609e1a6764d06064081e@changeid
2021-09-20drm/panel-edp: Fix "prepare_to_enable" if panel doesn't handle HPDDouglas Anderson1-2/+22
While cleaning up the descriptions of the delay for eDP panels I realized that we'd have a bug if any panels need the "prepare_to_enable" but HPD handling isn't happening in the panel driver. Let's put in a stopgap to at least make us not violate timings. This is not perfectly optimal but trying to do better is hard. At the moment only 2 panels specify this delay and only 30 ms is at stake. These panels are also currently hooked up with "hpd-gpios" so effectively this "fix" is just a theoretical fix and won't actually do anything for any devices currently supported in mainline. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210914132020.v5.13.Ia8288d36df4b12770af59ae3ff73ef7e08fb4e2e@changeid
2021-09-20drm/panel-edp: hpd_reliable shouldn't be subtraced from hpd_absentDouglas Anderson1-5/+3
Now that the delays are named / described with eDP-centric names, it becomes clear that we should really specify the "hpd_reliable" and "hpd_absent" separately without taking the other into account. Let's fix it. This should be a no-op change and just adjust how we specify things. The actual delays should be the same before and after for the one panel that currently species both "hpd_reliable" and "hpd_absent". Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210914132020.v5.12.I2522235fca3aa6790ede0bf22a93d79a1f694e6b@changeid
2021-09-20drm/panel-edp: Better describe eDP panel delaysDouglas Anderson1-29/+53
Now that the eDP panel driver only handles eDP panels we can make better sense of the delays here. Let's describe them in terms of the standard eDP timing diagram from the eDP spec. As part of this, it becomes pretty clear that some eDP panels have too long of a "hpd_reliable_delay". This used to be the "prepare" delay. It's the fixed delay that we do in the panel driver after powering on our panel before we look at the HPD signal. To understand this better, first realize that there could be 3 paths we follow depending on how HPD is hooked up. Let's walk through them: 1. HPD is handled by the eDP controller driver. Until "recently" (commit 48834e6084f1 ("drm/panel-simple: Support hpd-gpios for delaying prepare()") in May 2020) this was the only supported way. This is supposed to be when the controller driver gets HPD straight to a dedicated pin. In this case the controller driver should be waiting for HPD in its pre_enable() routine which should be called right after the panel's prepare() function is called. That means that the old "prepare" delay was only needed as a delay after powering the panel but before looking at HPD. 2. HPD is handled via hpd-gpios in the panel. This is much like #1 but much easier to follow since all the handling is in the panel driver. 3. The no-hpd case. This is also easy to follow. In any case, even though it seems like some old panel data was using this incorrectly, let's not touch the old data structures but we'll add a note indicating that something seems off. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210914132020.v5.11.I2d798dd015332661c5895ef744bc8ec5cd2e06ca@changeid
2021-09-20drm/panel-edp: Split the delay structure outDouglas Anderson1-77/+82
In the case where we can read an EDID for a panel the only part of the panel description that can't be found directly from the EDID is the description of the delays. Let's break the delay structure out so that we can specify just the delays for panels that are detected by EDID. This is simple code motion. No functional change is intended. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210914132020.v5.10.I24f3646dd09954958645cc05c538909f169bf362@changeid
2021-09-20drm/panel-simple: Non-eDP panels don't need "HPD" handlingDouglas Anderson1-130/+4
All of the "HPD" handling added to panel-simple recently was for eDP panels. Remove it from panel-simple now that panel-edp handles eDP panels. The "prepare_to_enable" delay only makes sense in the context of HPD, so remove it too. No non-eDP panels used it anyway. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210914132020.v5.9.I77d7a48df0a6585ef2cc2ff140fbe8f236a9a9f7@changeid
2021-09-20drm/panel-edp: Move some wayward panels to the eDP driverDouglas Anderson2-365/+363
Not all panels in panel-simple were marked what type of panel they were. I searched through ARM/ARM64 Chromebooks or Chromebook-related reference boards that I was aware of and found some panels that needed to be moved. I also skimmed for panels that had no mode and were "big" since it's quite rare to see a small eDP panel. Here's what I found: * auo,b101ean01 - rk3288-veyron-minnie * auo,b133htn01 - exynos5800-peach-pi * auo,b133xtn01 - tegra124-nyan-big * boe,nv101wxmn51 - rk3399-gru-bob * innolux,p120zdg-bf1 - sdm845-cheza * lg,lp079qx1-sp0v - rk3399-evb and similar * lg,lp097qx1-spa1 - According to commit 0355dde26e52 ("drm/panel: simple: Add support for LG LP097QX1-SPA1 panel") this is an eDP panel. * lg,lp129qe - tegra124-venice2 * samsung,lsn122dl01-c01 - According to commit 0330eaf39082 ("drm/panel: simple: Add support for Samsung LSN122DL01-C01 panel") this is an eDP panel. * samsung,ltn140at29-301 - tegra124-nyan-blaze * sharp,ld-d5116z01b - According to commit cd5e1cbe1f0a ("drm/panel: simple: Add support for Sharp LD-D5116Z01B panel") this is an eDP panel. * sharp,lq123p1jx31 - rk3399-gru-kevin * starry,kr122ea0sra - rk3399-gru-gru (reference board, not upstream) I won't promise that I didn't miss a single panel, but that's fairly complete I think. I'm not sure the full impact of the fact that they didn't have the connector type specified, but at least as of commit 9f069c6fbc72 ("drm/panel: panel-simple: add default connector_type") we may have been accidentally thinking of them as DPI panels. We also would certainly have had a warning. In any case since we don't want to support anything eDP in the old simple-panel driver, we should move these. Cc: Yakir Yang <ykk@rock-chips.com> Cc: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210914132020.v5.8.I84e36f9f86d5d693fce0641a55ddb264a518a947@changeid
2021-09-20drm/panel-edp: Split eDP panels out of panel-simpleDouglas Anderson4-566/+1322
The panel-simple driver handles way too much. Let's start trying to get a handle on it by splitting out the eDP panels. This patch does this: 1. Start by copying simple-panel verbatim over to a new driver, simple-panel-edp. 2. Rename "panel_simple" to "panel_edp" in the new driver. 3. Keep only panels marked with `DRM_MODE_CONNECTOR_eDP` in the new driver. Remove those panels from the old driver. 4. Remove all recent "DP AUX bus" stuff from the old driver. The DP AUX bus is only possible on DP panels. 5. Remove all DSI / MIPI related functions from the new driver. 6. Remove bus_format / bus_flags from eDP driver. These things don't seem to make any sense for eDP panels so let's stop filling in made up stuff. In the end we end up with a bunch of duplicated code for now. Future patches will try to address _some_ of this duplicated code though some of it will be unavoidable. NOTE: This may not actually move all eDP panels over to the new driver since not all panels were properly marked with `DRM_MODE_CONNECTOR_eDP`. A future patch will attempt to move wayward panels I could identify but even so there may be some missed. Suggested-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210914132020.v5.7.I0a2f75bb822d17ce06f5b147734764eeb0c3e3df@changeid
2021-09-20arm64: defconfig: Everyone who had PANEL_SIMPLE now gets PANEL_EDPDouglas Anderson1-0/+1
In the patch ("drm/panel-simple-edp: Split eDP panels out of panel-simple") we split the PANEL_SIMPLE driver in 2. Let's enable the new config. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210914132020.v5.6.Ied5c4da3ea36f8c49343176eda342027b6f19586@changeid
2021-09-20ARM: configs: Everyone who had PANEL_SIMPLE now gets PANEL_EDPDouglas Anderson15-0/+15
In the patch ("drm/panel-simple-edp: Split eDP panels out of panel-simple") we will split the PANEL_SIMPLE driver in two. By default let's give everyone who had the old driver enabled the new driver too. If folks want to opt-out of one or the other they always can later. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210914132020.v5.5.I02250cd7d4799661b068bcc65849a456ed411734@changeid
2021-09-20drm/edid: Use new encoded panel id style for quirks matchingDouglas Anderson1-86/+70
In the patch ("drm/edid: Allow the querying/working with the panel ID from the EDID") we introduced a different way of working with the panel ID stored in the EDID. Let's use this new way for the quirks code. Advantages of the new style: * Smaller data structure size. Saves 4 bytes per panel. * Iterate through quirks structure with just "==" instead of strncmp() * In-kernel storage is more similar to what's stored in the EDID itself making it easier to grok that they are referring to the same value. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210914132020.v5.4.I6103ce2b16e5e5a842b14c7022a034712b434609@changeid
2021-09-20drm/edid: Allow querying/working with the panel ID from the EDIDDouglas Anderson2-0/+112
EDIDs have 32-bits worth of data which is intended to be used to uniquely identify the make/model of a panel. This has historically been used only internally in the EDID processing code to identify quirks with panels. We'd like to use this panel ID in panel drivers to identify which panel is hooked up and from that information figure out power sequence timings. Let's expose this information from the EDID code and also allow it to be accessed early, before a connector has been created. To make matching in the panel drivers code easier, we'll return the panel ID as a 32-bit value. We'll provide some functions for converting this value back and forth to something more human readable. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210914132020.v5.3.I4a672175ba1894294d91d3dbd51da11a8239cf4a@changeid
2021-09-20drm/edid: Break out reading block 0 of the EDIDDouglas Anderson1-18/+45
A future change wants to be able to read just block 0 of the EDID, so break it out of drm_do_get_edid() into a sub-function. This is intended to be a no-op change--just code movement. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210914132020.v5.2.I62e76a034ac78c994d40a23cd4ec5aeee56fa77c@changeid
2021-09-20dt-bindings: drm/panel-simple-edp: Introduce generic eDP panelsDouglas Anderson1-0/+188
eDP panels generally contain almost everything needed to control them in their EDID. This comes from their DP heritage were a computer needs to be able to properly control pretty much any DP display that's plugged into it. The one big issue with eDP panels and the reason that we need a panel driver for them is that the power sequencing can be different per panel. While it is true that eDP panel sequencing can be arbitrarily complex, in practice it turns out that many eDP panels are compatible with just some slightly different delays. See the contents of the bindings file introduced in this patch for some details. The fact that eDP panels are 99% probable and that the power sequencing (especially power up) can be compatible between many panels means that there's a constant desire to plug multiple different panels into the same board. This could be for second sourcing purposes or to support multiple SKUs (maybe a 11" and a 13", for instance). As discussed [1], it should be OK to support this by adding two properties to the device tree to specify the delays needed for powering up the panel the first time. We'll create a new "edp-panel" bindings file and define the two delays that might need to be specified. NOTE: in the vast majority of the cases (HPD is hooked up and isn't glitchy or is debounced) even these delays aren't needed. [1] https://lore.kernel.org/r/CAD=FV=VZYOMPwQZzWdhJGh5cjJWw_EcM-wQVEivZ-bdGXjPrEQ@mail.gmail.com Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210914132020.v5.1.I1116e79d34035338a45c1fc7cdd14a097909c8e0@changeid
2021-09-20drm/i915/dg2: configure TRANS_DP2_VFREQ{HIGH,LOW} for 128b/132bJani Nikula1-0/+11
There's a new register pair for 128b/132b mode where you need to set the pixel clock in Hz. v2: Fix UHBR rate check, use intel_dp_is_uhbr() helper Bspec: 54128 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/a2902cc188973f022f282f2a77e693afdecefb5a.1631191763.git.jani.nikula@intel.com
2021-09-20drm/i915/dg2: use 128b/132b transcoder DDI modeJani Nikula1-7/+20
128b/132b has a separate transcoder DDI mode, which also requires the MST transport select to be set. Note that we'll use DP MST also for single-stream 128b/132b. Having the FDI and 128b/132b modes share the register mode value complicates things a bit. v2: - Use HAS_DP20 abstraction for 128b/132b mode (Ville) - Use intel_dp_is_uhbr() helper Bspec: 50493 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/279bfbd979e0256fae13a5231e07e2f4fb665c07.1631191763.git.jani.nikula@intel.com
2021-09-20drm/i915/dp: add HAS_DP20 macroJani Nikula1-0/+1
Let's abstract the DP 2.0 feature. Initially just DG2. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3746e700641bc17eff270569387fe869707d92ed.1631191763.git.jani.nikula@intel.com
2021-09-20drm/i915/dg2: configure TRANS_DP2_CTL for DP 2.0Jani Nikula1-1/+16
Set the DP 2.0 128b/132b channel encoding for UHBR rates. v2: Fix UHBR port clock check, use intel_dp_is_uhbr() Bspec: 54128 Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c88b08d80a96d1229ae941b296590633be4d8711.1631191763.git.jani.nikula@intel.com
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-03 18:56:41 +0300