summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-09-21drm/rockchip: add DRM_BRIDGE_ATTACH_NO_CONNECTOR flag to drm_bridge_attachAlex Bee
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 Bee
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 Norris
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-20drm/i915: Check SFC fusing before recording/dumping SFC_DONEMatt Roper
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-20drm/i915/xehp: Check new fuse bits for SFC availabilityMatt Roper
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 Brost
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 Brost
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 Spurio
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 Spurio
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 Dhanalakota
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 Deucher
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 Anderson
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 Anderson
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 Anderson
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 Anderson
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 Anderson
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 Anderson
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 Anderson
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 Anderson
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 Anderson
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 Anderson
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 Anderson
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 Anderson
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 Anderson
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 Anderson
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 Anderson
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 Nikula
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 Nikula
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 Nikula
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 Nikula
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
2021-09-20drm/i915/dp: select 128b/132b channel encoding for UHBR ratesJani Nikula
UHBR rates and 128b/132b channel encoding go hand in hand. v2: Fix check for >= UHBR rates using intel_dp_is_uhbr() (Ville) 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/b4ffd0187b306c0abaa08b89ed35c993ad8145c7.1631191763.git.jani.nikula@intel.com
2021-09-20drm/i915/dp: use 128b/132b TPS2 for UHBR+ link ratesJani Nikula
128b/132b channel encoding has separate TPS1 and TPS2, although the DPCD register values coincide with 8b/10b TPS1 and TPS2 values. Use 128b/132b TPS2 for channel equalization. v2: Use intel_dp_is_uhbr Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> # v1 Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/723b29223dc570c8b63c3c6fe5fb772d9db06c0d.1631191763.git.jani.nikula@intel.com
2021-09-20drm/i915/dp: add helper for checking for UHBR link rateJani Nikula
Helpful abstraction to avoid duplication. 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/fe9a222ad900da797c989de9f7fa13928d2c9861.1631191763.git.jani.nikula@intel.com
2021-09-20drm/i915/dg2: add DG2+ TRANS_DDI_FUNC_CTL DP 2.0 128b/132b modeJani Nikula
Unfortunately, the DP 2.0 128b/132b DDI mode selection in the register conflicts with FDI. Since we have to deal with both meanings in the same code, for different platforms, clarify the macro name so we don't forget. 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/260e4da302d47ae50122eb8d517be6ac3ccb15f2.1631191763.git.jani.nikula@intel.com
2021-09-20drm/dp: add helper for extracting adjust 128b/132b TX FFE presetJani Nikula
The DP 2.0 128b/132b channel coding uses TX FFE presets instead of vswing and pre-emphasis. Cc: dri-devel@lists.freedesktop.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/4ba129c51aeb01a5f210de7026abe704a554a178.1631191763.git.jani.nikula@intel.com
2021-09-20drm/dp: add LTTPR DP 2.0 DPCD addressesJani Nikula
DP 2.0 brings some new DPCD addresses for PHY repeaters. Cc: dri-devel@lists.freedesktop.org Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/def17e2329722f22c35807be26b35590ccb93bfd.1631191763.git.jani.nikula@intel.com
2021-09-20drm/dp: use more of the extended receiver capJani Nikula
Extend the use of extended receiver cap at 0x2200 to cover MAIN_LINK_CHANNEL_CODING_CAP in 0x2206, in case an implementation hides the DP 2.0 128b/132b channel encoding cap. v2: Extend to DP_RECEIVER_CAP_SIZE (Ville) Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/649051cb896821147feee91aab1f2abc523c1353.1631191763.git.jani.nikula@intel.com
2021-09-20drm/dp: add DP 2.0 UHBR link rate and bw code conversionsJani Nikula
The bw code equals link_rate / 0.27 Gbps only for 8b/10b link rates. Handle DP 2.0 UHBR rates as special cases, though this is not pretty. Cc: dri-devel@lists.freedesktop.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/cab4edda8834d6b4db610fabb5e1f1f18ae33c2c.1631191763.git.jani.nikula@intel.com
2021-09-20drm/i915/gt: Add "intel_" as prefix in set_mocs_index()Ayaz A Siddiqui
Adding missing "intel_" prefix in set_mocs_index(). Fixes: b62aa57e3c78 ("drm/i915/gt: Add support of mocs propagation") Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Ayaz A Siddiqui <ayaz.siddiqui@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210916062736.1733587-1-ayaz.siddiqui@intel.com
2021-09-20drm/i915: Make wa list per-gtVenkata Sandeep Dhanalakota
Support for multiple GT's within a single i915 device will be arriving soon. Since each GT may have its own fusing and require different workarounds, we need to make the GT workaround functions and multicast steering setup per-gt. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@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/20210917170845.836358-1-matthew.d.roper@intel.com
2021-09-20drm/panfrost: simplify getting .driver_dataWolfram Sang
We should get 'driver_data' from 'struct device' directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210920090522.23784-6-wsa+renesas@sang-engineering.com
2021-09-20panfrost: make mediatek_mt8183_supplies and mediatek_mt8183_pm_domains staticJiapeng Chong
This symbol is not used outside of panfrost_drv.c, so marks it static. Fix the following sparse warning: drivers/gpu/drm/panfrost/panfrost_drv.c:641:12: warning: symbol 'mediatek_mt8183_supplies' was not declared. Should it be static? drivers/gpu/drm/panfrost/panfrost_drv.c:642:12: warning: symbol 'mediatek_mt8183_pm_domains' 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> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/1631956414-85412-1-git-send-email-jiapeng.chong@linux.alibaba.com
2021-09-20Merge remote-tracking branch 'tip/locking/wwmutex' into drm-intel-gt-nextJoonas Lahtinen
Needed by Maarten's series "drm/i915: Short-term pinning and async eviction". Link: https://lists.freedesktop.org/archives/intel-gfx/2021-September/277870.html Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2021-09-20drm/v3d: Make use of the helper function devm_platform_ioremap_resource_byname()Cai Huoqing
Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210901112941.31320-1-caihuoqing@baidu.com
2021-09-20drm: bridge: it66121: Fix return value it66121_probeAlex Bee
Currently it66121_probe returns -EPROBE_DEFER if the there is no remote endpoint found in the device tree which doesn't seem helpful, since this is not going to change later and it is never checked if the next bridge has been initialized yet. It will fail in that case later while doing drm_bridge_attach for the next bridge in it66121_bridge_attach. Since the bindings documentation for it66121 bridge driver states there has to be a remote endpoint defined, its safe to return -EINVAL in that case. This additonally adds a check, if the remote endpoint is enabled and returns -EPROBE_DEFER, if the remote bridge hasn't been initialized (yet). Fixes: 988156dc2fc9 ("drm: bridge: add it66121 driver") Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210918140420.231346-1-knaerzche@gmail.com
2021-09-19Linux 5.15-rc2v5.15-rc2Linus Torvalds
2021-09-19pci_iounmap'2: Electric Boogaloo: try to make sense of it allLinus Torvalds
Nathan Chancellor reports that the recent change to pci_iounmap in commit 9caea0007601 ("parisc: Declare pci_iounmap() parisc version only when CONFIG_PCI enabled") causes build errors on arm64. It took me about two hours to convince myself that I think I know what the logic of that mess of #ifdef's in the <asm-generic/io.h> header file really aim to do, and rewrite it to be easier to follow. Famous last words. Anyway, the code has now been lifted from that grotty header file into lib/pci_iomap.c, and has fairly extensive comments about what the logic is. It also avoids indirecting through another confusing (and badly named) helper function that has other preprocessor config conditionals. Let's see what odd architecture did something else strange in this area to break things. But my arm64 cross build is clean. Fixes: 9caea0007601 ("parisc: Declare pci_iounmap() parisc version only when CONFIG_PCI enabled") Reported-by: Nathan Chancellor <nathan@kernel.org> Cc: Helge Deller <deller@gmx.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Ulrich Teichert <krypton@ulrich-teichert.org> Cc: James Bottomley <James.Bottomley@hansenpartnership.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-09-19Merge tag 'x86_urgent_for_v5.15_rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Borislav Petkov: - Prevent a infinite loop in the MCE recovery on return to user space, which was caused by a second MCE queueing work for the same page and thereby creating a circular work list. - Make kern_addr_valid() handle existing PMD entries, which are marked not present in the higher level page table, correctly instead of blindly dereferencing them. - Pass a valid address to sanitize_phys(). This was caused by the mixture of inclusive and exclusive ranges. memtype_reserve() expect 'end' being exclusive, but sanitize_phys() wants it inclusive. This worked so far, but with end being the end of the physical address space the fail is exposed. - Increase the maximum supported GPIO numbers for 64bit. Newer SoCs exceed the previous maximum. * tag 'x86_urgent_for_v5.15_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/mce: Avoid infinite loop for copy from user recovery x86/mm: Fix kern_addr_valid() to cope with existing but not present entries x86/platform: Increase maximum GPIO number for X86_64 x86/pat: Pass valid address to sanitize_phys()
2021-09-19Merge tag 'perf-urgent-2021-09-19' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf event fix from Thomas Gleixner: "A single fix for the perf core where a value read with READ_ONCE() was checked and then reread which makes all the checks invalid. Reuse the already read value instead" * tag 'perf-urgent-2021-09-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: events: Reuse value read using READ_ONCE instead of re-reading it
2021-09-19Merge tag 'locking-urgent-2021-09-19' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull locking fixes from Thomas Gleixner: "A set of updates for the RT specific reader/writer locking base code: - Make the fast path reader ordering guarantees correct. - Code reshuffling to make the fix simpler" [ This plays ugly games with atomic_add_return_release() because we don't have a plain atomic_add_release(), and should really be cleaned up, I think - Linus ] * tag 'locking-urgent-2021-09-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: locking/rwbase: Take care of ordering guarantee for fastpath reader locking/rwbase: Extract __rwbase_write_trylock() locking/rwbase: Properly match set_and_save_state() to restore_state()
generated by cgit (git 2.34.1) at 2025-09-16 01:41:41 +0000