- 24 Sep, 2021 6 commits
-
-
Douglas Anderson authored
Apparently some compilers [1] cannot handle doing math on dereferenced string constants at compile time. This has led to reports [2] of compile errors like: In file included from drivers/gpu/drm/drm_edid.c:42:0: ./include/drm/drm_edid.h:525:2: error: initializer element is not constant ((((u32)((vend)[0]) - '@') & 0x1f) << 26 | \ Go back to the syntax I used in v4 of the patch series [3] that added this code instead of what landed (v5). This syntax is slightly uglier but should be much more compatible with varied compilers. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960#c18 [2] https://lore.kernel.org/r/874kaabdt5.fsf@intel.com/ [3] https://lore.kernel.org/r/20210909135838.v4.4.I6103ce2b16e5e5a842b14c7022a034712b434609@changeid/ Fixes: d9f91a10 ("drm/edid: Allow querying/working with the panel ID from the EDID") Reported-by:Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reported-by:
Srikanth Myakam <smyakam@microsoft.com> Signed-off-by:
Douglas Anderson <dianders@chromium.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Acked-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210924075317.1.I1e58d74d501613f1fe7585958f451160d11b8a98@changeid
-
Yang Yingliang authored
PTR_ERR() should access the value just tested by IS_ERR(), otherwise the wrong error code will be returned. Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Hulk Robot <hulkci@huawei.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210924094040.3631675-1-yangyingliang@huawei.com
-
Maxime Ripard authored
MIPI-DSI devices need to call mipi_dsi_attach() when their probe is done to attach against their host. However, at removal or when an error occurs, that attachment needs to be undone through a call to mipi_dsi_detach(). Let's create a device-managed variant of the attachment function that will automatically detach the device at unbind. Reviewed-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210910101218.1632297-5-maxime@cerno.tech
-
Maxime Ripard authored
Devices that take their data through the MIPI-DSI bus but are controlled through a secondary bus like I2C have to register a secondary device on the MIPI-DSI bus through the mipi_dsi_device_register_full() function. At removal or when an error occurs, that device needs to be removed through a call to mipi_dsi_device_unregister(). Let's create a device-managed variant of the registration function that will automatically unregister the device at unbind. Reviewed-by:
-
Maxime Ripard authored
Interactions between bridges, panels, MIPI-DSI host and the component framework are not trivial and can lead to probing issues when implementing a display driver. Let's document the various cases we need too consider, and the solution to support all the cases. Signed-off-by:
-
Maxime Ripard authored
The bridge documentation overview is quite packed already, and we'll add some more documentation that isn't part of an overview at all. Let's add some sections to the documentation to separate each bits. Reviewed-by:
-
- 23 Sep, 2021 12 commits
-
-
Philip Chen authored
Implement the first version of AUX support, which will be useful as we expand the driver to support varied use cases. Signed-off-by:
Philip Chen <philipchen@chromium.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> [dianders: whitespace fixes reported by dim apply-branch] Signed-off-by:
-
Philip Chen authored
Replace the direct i2c access (i2c_smbus_* functions) with regmap APIs, which will simplify the future update on ps8640 driver. Signed-off-by:
-
Thomas Zimmermann authored
Set up a clean-up action to automatically release device resources during driver shutdown. Remove manual release code. Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210920141051.30988-6-tzimmermann@suse.de
-
Thomas Zimmermann authored
The value of dev_priv in psb_driver_unload() is always non-zero. Remove the respective test. Signed-off-by:
-
Thomas Zimmermann authored
Embed struct drm_device in struct drm_psb_private. Replace the use of dev_private by an upcast operation. Switch to managed release of struct drm_psb_private. Signed-off-by:
-
Thomas Zimmermann authored
Use managed disablement of PCI devices via pcim_device_enable(). Disables the PCI device and simplifies error rollback in probe function. Signed-off-by:
-
Thomas Zimmermann authored
Replace most references to struct drm_device.dev_private with the new helper function to_drm_psb_private(). The only references left are in assignments and the helper itself. Signed-off-by:
-
Thomas Zimmermann authored
Replace arch_phys_wc_add() with the rsp managed function. Allows for removing the cleanup code for memory management Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210916181601.9146-6-tzimmermann@suse.de
-
Thomas Zimmermann authored
Replace arch_phys_wc_add() and arch_io_reserve_memtype_wc() with the rsp managed functions. Allows for removing the cleanup code for memory management Signed-off-by:
-
Thomas Zimmermann authored
Replace arch_phys_wc_add() and arch_io_reserve_memtype_wc() with the rsp managed functions. Allows for removing the cleanup code for memory management Signed-off-by:
-
Thomas Zimmermann authored
Add devm_arch_io_reserve_memtype_wc() as managed wrapper around arch_io_reserve_memtype_wc(). Useful for several graphics drivers that set framebuffer memory to write combining. v2: * fix typo in commit description Signed-off-by:
-
Thomas Zimmermann authored
Add devm_arch_phys_wc_add() as managed wrapper around arch_phys_wc_add(). Useful for several graphics drivers that set framebuffer memory to write combining. v2: * fix typo in commit description Signed-off-by:
-
- 22 Sep, 2021 2 commits
-
-
Ville Syrjälä authored
Fix the bad copy-pasta in the scaling_mode docs. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210915142300.15631-1-ville.syrjala@linux.intel.comReviewed-by:
Simon Ser <contact@emersion.fr>
-
Maxime Ripard authored
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: 87ea9580 ("drm/bridge: Add a function to abstract away panels") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Acked-by:
-
- 21 Sep, 2021 10 commits
-
-
Lukas Bulwahn authored
Commit ebd8cbf1 ("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
-
Souptick Joarder authored
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:
-
Souptick Joarder authored
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: -
Andy Yan authored
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:
-
Jiapeng Chong authored
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:
-
Jiapeng Chong authored
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:
-
Cai Huoqing authored
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:
-
Alex Bee authored
Commit a25b988f ("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:
-
Alex Bee authored
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:
-
Brian Norris authored
Some leftover cleanup from commit 6c836d96 ("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:
-
- 20 Sep, 2021 10 commits
-
-
Alex Deucher authored
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
-
Douglas Anderson authored
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 authored
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 authored
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 authored
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 authored
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 48834e60 ("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 authored
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 authored
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 authored
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 0355dde2 ("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 0330eaf3 ("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 cd5e1cbe ("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 9f069c6f ("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 authored
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:
-
