- 31 Mar, 2021 6 commits
-
-
Jani Nikula authored
Neatly reduce displayid boilerplate in code. Remove excessive debug logging while at it, no other functional changes. The old displayid iterator becomes unused; remove it as well as make drm_find_displayid_extension() static. 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/fa4b5c790b5bdd82063545a6f209f8e9d78a63a7.1617024940.git.jani.nikula@intel.com
-
Jani Nikula authored
Neatly reduce displayid boilerplate in code. No functional changes. Reviewed-by:
-
Jani Nikula authored
Neatly reduce displayid boilerplate in code. No functional changes. Reviewed-by:
-
Jani Nikula authored
Iterating DisplayID blocks across sections (in EDID extensions) is unnecessarily complicated for the caller. Implement DisplayID iterators to go through all blocks in all sections. Usage example: const struct displayid_block *block; struct displayid_iter iter; displayid_iter_edid_begin(edid, &iter); displayid_iter_for_each(block, &iter) { /* operate on block */ } displayid_iter_end(&iter); When DisplayID is stored in EDID extensions, the DisplayID sections map to extensions as described in VESA DisplayID v1.3 Appendix B: DisplayID as an EDID Extension. This is implemented here. When DisplayID is stored in its dedicated DDC device 0xA4, according to VESA E-DDC v1.3, different rules apply for the structure. This is not implemented here, as we don't currently use it, but the idea is you'd have a different call for beginning the iteration, for example simply: displayid_iter_begin(displayid, &iter); instead of displayid_iter_edid_begin(), and everything else would be hidden away in the iterator functions. v2: - sizeof(struct displayid_block) -> sizeof(*block) (Ville) - remove __ prefix from displayid_iter_block Reviewed-by: -
Jani Nikula authored
We'll be adding more DisplayID specific functions going forward, so start off by splitting out a few functions to a separate file. We don't bother with exporting the functions; at least for now they should be needed solely within drm.ko. No functional changes. Reviewed-by:
-
Jani Nikula authored
If there's no need to change it, it should be const. There's more to be done, but start off with changes that make follow-up work easier. No functional changes. Reviewed-by:
-
- 29 Mar, 2021 4 commits
-
-
Paul Cercueil authored
Since the encoders have been devm-allocated, they will be freed way before drm_mode_config_cleanup() is called. To avoid use-after-free conditions, we then must ensure that drm_encoder_cleanup() is called before the encoders are freed. v2: Use the new __drmm_simple_encoder_alloc() function v3: Use the new drmm_plain_simple_encoder_alloc() macro v4: Use drmm_plain_encoder_alloc() macro Fixes: c369cb27 ("drm/ingenic: Support multiple panels/bridges") Cc: <stable@vger.kernel.org> # 5.8+ Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210327115742.18986-4-paul@crapouillou.net
-
Paul Cercueil authored
This performs the same operation as drmm_encoder_alloc(), but only allocates and returns a struct drm_encoder instance. v4: Rename macro drmm_plain_encoder_alloc() and move to <drm/drm_encoder.h>. Since it's not "simple" anymore it will now take funcs/name arguments as well. Signed-off-by: -
Paul Cercueil authored
If we don't call drm_connector_cleanup() manually in panel_bridge_detach(), the connector will be cleaned up with the other DRM objects in the call to drm_mode_config_cleanup(). However, since our drm_connector is devm-allocated, by the time drm_mode_config_cleanup() will be called, our connector will be long gone. Therefore, the connector must be cleaned up when the bridge is detached to avoid use-after-free conditions. v2: Cleanup connector only if it was created v3: Add FIXME v4: (Use connector->dev) directly in if() block Fixes: 13dfc054 ("drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.") Cc: <stable@vger.kernel.org> # 4.12+ Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by:
-
Christian König authored
The shrinker based approach still has some flaws. Especially that we need temporary pages to free up the pages allocated to the driver is problematic in a shrinker. Signed-off-by:
Christian König <christian.koenig@amd.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210324134845.2338-1-christian.koenig@amd.com
-
- 26 Mar, 2021 8 commits
-
-
Eryk Brol authored
[why] MST topology print was missing fec logging and pdt printed as an int wasn't clear. vcpi and payload info was printed as an arbitrary series of ints which requires user to know the ordering of the prints, making the logs difficult to use. [how] -add fec logging -add pdt parsing into strings -format vcpi and payload info into tables with headings -clean up topology prints Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
Eryk Brol <eryk.brol@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210325180614.37060-1-eryk.brol@amd.com
-
Christian König authored
The BO might be NULL in this function, use the bdev directly. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
-
Adrien Grassein authored
Lontium LT8912B is a DSI to HDMI bridge. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Adrien Grassein <adrien.grassein@gmail.com> Reviewed-by:
Robert Foss <robert.foss@linaro.org> Signed-off-by:
-
Adrien Grassein authored
Lontium LT8912B is a DSI to HDMI bridge. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Dafna Hirschfeld authored
Fix the following typos: 1. When mentioning a list of functions, the function drm_atomic_helper_disable_plane is mentioned twice. 2. drop the word 'afterwards': s/afterwards after that/after that/' 3. drop extra 'the': s/but do not the support the full/but do not support the full/ Signed-off-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Reviewed-by:
Simon Ser <contact@emersion.fr> Signed-off-by:
-
Wan Jiabing authored
struct dss_device has been declared. Remove the duplicate. And sort these forward declarations alphabetically. Signed-off-by:
Wan Jiabing <wanjiabing@vivo.com> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210325111028.864628-1-wanjiabing@vivo.com
-
Yang Li authored
fixed the following coccicheck: ./drivers/gpu/drm/omapdrm/dss/dsi.c:4329:7-27: ERROR: Threaded IRQ with no primary handler requested without IRQF_ONESHOT Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Reviewed-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Fixes: 4c1b935f ("drm/omap: dsi: move TE GPIO handling into core") Signed-off-by:
-
Arnd Bergmann authored
An old patch added a 'return' statement after each BUG() in this driver, which was necessary at the time, but has become redundant after the BUG() definition was updated to handle this properly. gcc-11 now warns about one such instance, where the 'return' statement was incorrectly indented: drivers/gpu/drm/omapdrm/dss/dispc.c: In function ‘pixinc’: drivers/gpu/drm/omapdrm/dss/dispc.c:2093:9: error: this ‘else’ clause does not guard... [-Werror=misleading-indentation] 2093 | else | ^~~~ drivers/gpu/drm/omapdrm/dss/dispc.c:2095:17: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘else’ 2095 | return 0; | ^~~~~~ Address this by removing the return again and changing the BUG() to be unconditional to make this more intuitive. Fixes: c6eee968 ("OMAPDSS: remove compiler warnings when CONFIG_BUG=n") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
- 25 Mar, 2021 6 commits
-
-
Jagan Teki authored
ICN6211 is MIPI-DSI to RGB Converter bridge from Chipone. It has a flexible configuration of MIPI DSI signal input and produce RGB565, RGB666, RGB888 output format. Add bridge driver for it. Signed-off-by:
Jagan Teki <jagan@amarulasolutions.com> Reviewed-by:
-
Jagan Teki authored
ICN6211 is MIPI-DSI to RGB Converter bridge from Chipone. It has a flexible configuration of MIPI DSI signal input and produces RGB565, RGB666, RGB888 output format. Add dt-bingings for it. Signed-off-by:
-
Jiapeng Chong authored
Fix the following coccicheck warning: drivers/gpu/drm/bridge/lontium-lt9611uxc.c:858:8-16: WARNING: use scnprintf or sprintf. Reported-by: Abaci Robot<abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Reviewed-by:
-
Robert Foss authored
4k requires two dsi pipes, so don't report MODE_OK when only a single pipe is configured. But rather report MODE_PANEL to signal that requirements of the panel are not being met. Reported-by:
Peter Collingbourne <pcc@google.com> Suggested-by:
John Stultz <john.stultz@linaro.org> Tested-by:
Anibal Limon <anibal.limon@linaro.org> Tested-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by:
Vinod Koul <vkoul@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201217140933.1133969-1-robert.foss@linaro.org
-
Robert Foss authored
Add myself as co-maintainer of DRM Bridge Drivers. Repository commit access has already been granted. https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/338Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Acked-by:
Maxime Ripard <maxime@cerno.tech> Acked-by:
Andrzej Hajda <a.hajda@samsung.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Jernej Škrabec <jernej.skrabec@siol.net> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210325145154.1433060-1-robert.foss@linaro.org
-
Dmitry Vyukov authored
vkms_vblank_simulate() uses WARN_ON for timing-dependent condition (timer overrun). This is a mis-use of WARN_ON, WARN_ON must be used to denote kernel bugs. Use pr_warn() instead. Signed-off-by:
Dmitry Vyukov <dvyukov@google.com> Reported-by: syzbot+4fc21a003c8332eb0bdd@syzkaller.appspotmail.com Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Melissa Wen <melissa.srw@gmail.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Acked-by:
Melissa Wen <melissa.srw@gmail.com> Signed-off-by:
-
- 24 Mar, 2021 8 commits
-
-
Christian König authored
Instead of having a global lock for potentially less contention. Signed-off-by:
Nirmoy Das <nirmoy.das@amd.com> Reviewed-by:
Huang Rui <ray.huang@amd.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/424010/
-
Christian König authored
Instead evict round robin from each devices SYSTEM and TT domain. v2: reorder num_pages access reported by Dan's script v3: fix rebase fallout, num_pages should be 32bit Signed-off-by:
-
Christian König authored
Move the iteration of the global lru into the new function ttm_global_swapout() and use that instead in drivers. v2: consistently return int v3: fix build fail Signed-off-by:
-
Dario Binacchi authored
The warning message did not printed the LCD pixel clock rate but the LCD clock divisor input rate. As a consequence, the required and real pixel clock rates are now passed to the tilcdc_pclk_diff(). Signed-off-by:
Dario Binacchi <dariobin@libero.it> Reviewed-by:
Jyri Sarha <jyri.sarha@iki.fi> Reviewed-by:
-
Dario Binacchi authored
The tilcdc_pclk_diff() compares the requested pixel clock rate to the real one, so passing it clk_rate instead of clk_rate / clkdiv caused it to fail even if the clk_rate was properly set. Adding the real_pclk_rate variable makes the code more readable. Signed-off-by:
-
Dario Binacchi authored
The req_rate name is a little misleading, so let's rename to pclk_rate (pixel clock rate). Signed-off-by:
-
Yang Li authored
./drivers/gpu/drm/tilcdc/tilcdc_panel.c:402:3-8: No need to set .owner here. The core will do it. Remove .owner field if calls are used which set it automatically Reported-by:
-
Maxime Ripard authored
Commit 977697e2 ("drm/atomic: Pass the full state to planes atomic disable and update") added the old_state variable instead of what used to be a parameter, but it also removed the sole user of that variable in the vop_plane_atomic_update function leading to an usused variable. Remove it. Fixes: 977697e2 ("drm/atomic: Pass the full state to planes atomic disable and update") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
- 23 Mar, 2021 8 commits
-
-
Lyude Paul authored
Just another drive-by fix I noticed while going through the tree to cleanup DP aux adapter registration - make sure we unregister the DP AUX dev if analogix_dp_probe() fails. Signed-off-by:
-
Lyude Paul authored
Another drive-by fix I found when fixing DP AUX adapter across the kernel tree - make sure we don't leak resources (and by proxy-AUX adapters) on failures in anx6345_bridge_attach() by unrolling on errors. Signed-off-by:
-
Lyude Paul authored
Another case of linking an encoder to a connector after the connector's been registered. The proper place to do this is before connector registration, so let's fix that. Signed-off-by:
-
Lyude Paul authored
Another driver I found that seems to forget to unregister it's DP AUX device. Let's fix this by adding anx6345_bridge_detach(). Signed-off-by:
-
Lyude Paul authored
Just another issue I noticed while correcting usages of drm_dp_aux_init()/drm_dp_aux_register() around the tree. If any of the steps in anx78xx_bridge_attach() fail, we end up leaking resources. So, let's fix that (and fix leaking a DP AUX adapter in the process) by unrolling on errors. Signed-off-by:
-
Lyude Paul authored
Since encoder mappings for connectors are exposed to userspace, we should be attaching the encoder before exposing the connector to userspace. Just a drive-by fix for an issue I noticed while fixing up usages of drm_dp_aux_init()/drm_dp_aux_register() across the tree. Signed-off-by:
-
Lyude Paul authored
Surprisingly, this bridge actually registers it's AUX adapter at the correct time already. Nice job! However, it does forget to actually unregister the AUX adapter, so let's add a bridge function to handle that. Signed-off-by:
-
Lyude Paul authored
Since we're about to add a back-pointer to drm_dev in drm_dp_aux, let's move the AUX adapter registration to the first point where we know which DRM device we'll be working with - when the drm_bridge is attached. Likewise, we unregister the AUX adapter on bridge detachment by adding a ti_sn_bridge_detach() callback. Signed-off-by:
-
