aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-09-23drm/amd/pm: fix runpm hang when amdgpu loaded prior to sound driverEvan Quan4-4/+47
Current RUNPM mechanism relies on PMFW to master the timing for BACO in/exit. And that needs cooperation from sound driver for dstate change notification for function 1(audio). Otherwise(on sound driver missing), BACO cannot be kicked in correctly and hang will be observed on RUNPM exit. By switching back to legacy message way on sound driver missing, we are able to fix the runpm hang observed for the scenario below: amdgpu driver loaded -> runpm suspend kicked -> sound driver loaded Signed-off-by: Evan Quan <[email protected]> Reported-and-tested-by: Pierre-Eric Pelloux-Prayer <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Reviewed-by: Guchun Chen <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-09-22drm: Fix scaling_mode docsVille Syrjälä1-2/+2
Fix the bad copy-pasta in the scaling_mode docs. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Simon Ser <[email protected]>
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 <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> # 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 <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20210916073132.ptbbmjetm7v3ufq3@gilmour
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 <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Signed-off-by: Souptick Joarder <[email protected]> Cc: Robin Murphy <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Signed-off-by: Souptick Joarder <[email protected]> Cc: Robin Murphy <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Signed-off-by: Jiapeng Chong <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> 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 <[email protected]> Fixes: 71f68fe7f121 ("drm/rockchip: dsi: add ability to work as a phy instead of full dsi") Signed-off-by: Jiapeng Chong <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> 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 <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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/[email protected]/ Suggested-by: Heiko Stuebner <[email protected]> Signed-off-by: Alex Bee <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Cc: Sean Paul <[email protected]> Signed-off-by: Brian Norris <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20210915135007.1.I926ef5cef287047c35a17e363c919599c6ee6e4c@changeid
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 <[email protected]> Cc: [email protected] Cc: [email protected] Reviewed-by: Christian König <[email protected]> Acked-by: Daniel Vetter <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Acked-by: Linus Walleij <[email protected]> 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 <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Acked-by: Linus Walleij <[email protected]> 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 <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Acked-by: Linus Walleij <[email protected]> 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 <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Acked-by: Linus Walleij <[email protected]> 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 <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Acked-by: Linus Walleij <[email protected]> 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 <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Acked-by: Linus Walleij <[email protected]> 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 <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Acked-by: Linus Walleij <[email protected]> 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 <[email protected]> Cc: Jeffrey Hugo <[email protected]> Cc: Thierry Reding <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Acked-by: Linus Walleij <[email protected]> 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 <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Acked-by: Linus Walleij <[email protected]> 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 <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Acked-by: Linus Walleij <[email protected]> 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 <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Acked-by: Linus Walleij <[email protected]> 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 <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Acked-by: Linus Walleij <[email protected]> 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 <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Acked-by: Linus Walleij <[email protected]> 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 <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Acked-by: Linus Walleij <[email protected]> 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 <[email protected]> Reviewed-by: Rob Herring <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Acked-by: Linus Walleij <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20210914132020.v5.1.I1116e79d34035338a45c1fc7cdd14a097909c8e0@changeid
2021-09-20drm/panfrost: simplify getting .driver_dataWolfram Sang1-4/+2
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 <[email protected]> Reviewed-by: Alyssa Rosenzweig <[email protected]> Reviewed-by: Steven Price <[email protected]> Signed-off-by: Steven Price <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-09-20panfrost: make mediatek_mt8183_supplies and mediatek_mt8183_pm_domains staticJiapeng Chong1-2/+2
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 <[email protected]> Signed-off-by: Jiapeng Chong <[email protected]> Reviewed-by: Steven Price <[email protected]> Signed-off-by: Steven Price <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/1631956414-85412-1-git-send-email-jiapeng.chong@linux.alibaba.com
2021-09-20drm/v3d: Make use of the helper function devm_platform_ioremap_resource_byname()Cai Huoqing1-4/+1
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 <[email protected]> Reviewed-by: Melissa Wen <[email protected]> Signed-off-by: Melissa Wen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-09-20drm: bridge: it66121: Fix return value it66121_probeAlex Bee1-2/+14
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 <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-09-19Linux 5.15-rc2Linus Torvalds1-1/+1
2021-09-19pci_iounmap'2: Electric Boogaloo: try to make sense of it allLinus Torvalds2-23/+46
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 <[email protected]> Cc: Helge Deller <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Guenter Roeck <[email protected]> Cc: Ulrich Teichert <[email protected]> Cc: James Bottomley <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-09-19Merge tag 'x86_urgent_for_v5.15_rc2' of ↵Linus Torvalds5-15/+47
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 Torvalds1-1/+1
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 Torvalds1-20/+45
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()
2021-09-19Merge tag 'powerpc-5.15-2' of ↵Linus Torvalds7-55/+159
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Michael Ellerman: - Fix crashes when scv (System Call Vectored) is used to make a syscall when a transaction is active, on Power9 or later. - Fix bad interactions between rfscv (Return-from scv) and Power9 fake-suspend mode. - Fix crashes when handling machine checks in LPARs using the Hash MMU. - Partly revert a recent change to our XICS interrupt controller code, which broke the recently added Microwatt support. Thanks to Cédric Le Goater, Eirik Fuller, Ganesh Goudar, Gustavo Romero, Joel Stanley, Nicholas Piggin. * tag 'powerpc-5.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/xics: Set the IRQ chip data for the ICS native backend powerpc/mce: Fix access error in mce handler KVM: PPC: Book3S HV: Tolerate treclaim. in fake-suspend mode changing registers powerpc/64s: system call rfscv workaround for TM bugs selftests/powerpc: Add scv versions of the basic TM syscall tests powerpc/64s: system call scv tabort fix for corrupt irq soft-mask state
2021-09-19Merge tag 'kbuild-fixes-v5.15' of ↵Linus Torvalds6-20/+27
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - Fix bugs in checkkconfigsymbols.py - Fix missing sys import in gen_compile_commands.py - Fix missing FORCE warning for ARCH=sh builds - Fix -Wignored-optimization-argument warnings for Clang builds - Turn -Wignored-optimization-argument into an error in order to stop building instead of sprinkling warnings * tag 'kbuild-fixes-v5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kbuild: Add -Werror=ignored-optimization-argument to CLANG_FLAGS x86/build: Do not add -falign flags unconditionally for clang kbuild: Fix comment typo in scripts/Makefile.modpost sh: Add missing FORCE prerequisites in Makefile gen_compile_commands: fix missing 'sys' package checkkconfigsymbols.py: Remove skipping of help lines in parse_kconfig_file checkkconfigsymbols.py: Forbid passing 'HEAD' to --commit
2021-09-19Merge tag 'perf-tools-fixes-for-v5.15-2021-09-18' of ↵Linus Torvalds7-51/+100
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux Pull perf tools fixes from Arnaldo Carvalho de Melo: - Fix ip display in 'perf script' when output type != attr->type. - Ignore deprecation warning when using libbpf'sg btf__get_from_id(), fixing the build with libbpf v0.6+. - Make use of FD() robust in libperf, fixing a segfault with 'perf stat --iostat list'. - Initialize addr_location:srcline pointer to NULL when resolving callchain addresses. - Fix fused instruction logic for assembly functions in 'perf annotate'. * tag 'perf-tools-fixes-for-v5.15-2021-09-18' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: perf bpf: Ignore deprecation warning when using libbpf's btf__get_from_id() libperf evsel: Make use of FD robust. perf machine: Initialize srcline string member in add_location struct perf script: Fix ip display when type != attr->type perf annotate: Fix fused instr logic for assembly functions
2021-09-19drm/v3d: fix sched job resources cleanup when a job is abortedMelissa Wen1-6/+5
In a cl submission, when bin job initialization fails, sched job resources were already allocated for the render job. At this point, drm_sched_job_init(render) was done in v3d_job_init but the render job is aborted before drm_sched_job_arm (in v3d_job_push) happens; therefore, not only v3d_job_put but also drm_sched_job_cleanup should be called (by v3d_job_cleanup). A similar issue is addressed for csd and tfu submissions. The issue was noticed from a review by Iago Toral in a patch that touches the same part of the code. Fixes: 916044fac8623 ("drm/v3d: Move drm_sched_job_init to v3d_job_init") Signed-off-by: Melissa Wen <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]> Signed-off-by: Melissa Wen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-09-19dmascc: use proper 'virt_to_bus()' rather than casting to 'int'Linus Torvalds1-3/+3
The old dmascc driver depends on the legacy ISA_DMA_API, and blindly just casts the kernel virtual address to 'int' for set_dma_addr(). That works only incidentally, and because the high bits of the address will be ignored anyway. And on 64-bit architectures it causes warnings. Admittedly, 64-bit architectures with ISA are basically dead - I think the only example of this is alpha, and nobody would ever use the dmascc driver there. But hey, the fix is easy enough, the end result is cleaner, and it's yet another configuration that now builds without warnings. If somebody actually uses this driver on an alpha and this fixes it for you, please email me. Because that is just incredibly bizarre. Signed-off-by: Linus Torvalds <[email protected]>
2021-09-19alpha: enable GENERIC_PCI_IOMAP unconditionallyLinus Torvalds1-1/+1
With the previous commit (9caea0007601: "parisc: Declare pci_iounmap() parisc version only when CONFIG_PCI enabled") we can now enable GENERIC_PCI_IOMAP unconditionally on alpha, and if PCI is not enabled we will just get the nice empty helper functions that allow mixed-bus drivers to build. Example driver: the old 3com/3c59x.c driver works with either the PCI or the EISA version of the 3x59x card, but wouldn't build in an EISA-only configuration because of missing pci_iomap() and pci_iounmap() dummy wrappers. Most of the other PCI infrastructure just becomes empty wrappers even without GENERIC_PCI_IOMAP, and it's not obvious that the pci_iomap functionality shouldn't do the same, but this works. Cc: Ulrich Teichert <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-09-19parisc: Declare pci_iounmap() parisc version only when CONFIG_PCI enabledHelge Deller3-11/+6
Linus noticed odd declaration rules for pci_iounmap() in iomap.h and pci_iomap.h, where it dependend on either NO_GENERIC_PCI_IOPORT_MAP or GENERIC_IOMAP when CONFIG_PCI was disabled. Testing on parisc seems to indicate that we need pci_iounmap() only when CONFIG_PCI is enabled, so the declaration of pci_iounmap() can be moved cleanly into pci_iomap.h in sync with the declarations of pci_iomap(). Link: https://lore.kernel.org/all/CAHk-=wjRrh98pZoQ+AzfWmsTZacWxTJKXZ9eKU2X_0+jM=O8nw@mail.gmail.com/ Signed-off-by: Helge Deller <[email protected]> Suggested-by: Linus Torvalds <[email protected]> Fixes: 97a29d59fc22 ("[PARISC] fix compile break caused by iomap: make IOPORT/PCI mapping functions conditional") Cc: Arnd Bergmann <[email protected]> Cc: Guenter Roeck <[email protected]> Cc: Ulrich Teichert <[email protected]> Cc: James Bottomley <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-09-19Revert "drm/vc4: hdmi: Remove drm_encoder->crtc usage"Linus Torvalds1-27/+13
This reverts commit 27da370e0fb343a0baf308f503bb3e5dcdfe3362. Sudip Mukherjee reports that this broke pulseaudio with a NULL pointer dereference in vc4_hdmi_audio_prepare(), bisected it to this commit, and confirmed that a revert fixed the problem. Revert the problematic commit until fixed. Link: https://lore.kernel.org/all/CADVatmPB9-oKd=ypvj25UYysVo6EZhQ6bCM7EvztQBMyiZfAyw@mail.gmail.com/ Link: https://lore.kernel.org/all/CADVatmN5EpRshGEPS_JozbFQRXg5w_8LFB3OMP1Ai-ghxd3w4g@mail.gmail.com/ Reported-and-tested-by: Sudip Mukherjee <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Emma Anholt <[email protected]> Cc: Dave Airlie <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-09-19Revert drm/vc4 hdmi runtime PM changesLinus Torvalds1-34/+10
This reverts commits 9984d6664ce9 ("drm/vc4: hdmi: Make sure the controller is powered in detect") 411efa18e4b0 ("drm/vc4: hdmi: Move the HSM clock enable to runtime_pm") as Michael Stapelberg reports that the new runtime PM changes cause his Raspberry Pi 3 to hang on boot, probably due to interactions with other changes in the DRM tree (because a bisect points to the merge in commit e058a84bfddc: "Merge tag 'drm-next-2021-07-01' of git://.../drm"). Revert these two commits until it's been resolved. Link: https://lore.kernel.org/all/871r5mp7h2.fsf@midna.i-did-not-set--mail-host-address--so-tickle-me/ Reported-and-tested-by: Michael Stapelberg <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Dave Stevenson <[email protected]> Cc: Dave Airlie <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-09-19kbuild: Add -Werror=ignored-optimization-argument to CLANG_FLAGSNathan Chancellor1-0/+5
Similar to commit 589834b3a009 ("kbuild: Add -Werror=unknown-warning-option to CLANG_FLAGS"). Clang ignores certain GCC flags that it has not implemented, only emitting a warning: $ echo | clang -fsyntax-only -falign-jumps -x c - clang-14: warning: optimization flag '-falign-jumps' is not supported [-Wignored-optimization-argument] When one of these flags gets added to KBUILD_CFLAGS unconditionally, all subsequent cc-{disable-warning,option} calls fail because -Werror was added to these invocations to turn the above warning and the equivalent -W flag warning into errors. To catch the presence of these flags earlier, turn -Wignored-optimization-argument into an error so that the flags can either be implemented or ignored via cc-option and there are no more weird errors. Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2021-09-19x86/build: Do not add -falign flags unconditionally for clangNathan Chancellor1-3/+9
clang does not support -falign-jumps and only recently gained support for -falign-loops. When one of the configuration options that adds these flags is enabled, clang warns and all cc-{disable-warning,option} that follow fail because -Werror gets added to test for the presence of this warning: clang-14: warning: optimization flag '-falign-jumps=0' is not supported [-Wignored-optimization-argument] To resolve this, add a couple of cc-option calls when building with clang; gcc has supported these options since 3.2 so there is no point in testing for their support. -falign-functions was implemented in clang-7, -falign-loops was implemented in clang-14, and -falign-jumps has not been implemented yet. Link: https://lore.kernel.org/r/[email protected]/ Link: https://lore.kernel.org/r/[email protected]/ Reported-by: kernel test robot <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Acked-by: Borislav Petkov <[email protected]> Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.