- 22 Oct, 2021 2 commits
-
-
Christian König authored
Simplifying the code a bit. The new implementation unifies the handling between drivers and so results in waiting for all shared fernces in all cases. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211005113742.1101-26-christian.koenig@amd.com
-
Christian König authored
Those members where renamed, update the kerneldoc as well. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Acked-by:
Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211021141945.84023-1-christian.koenig@amd.com
-
- 21 Oct, 2021 3 commits
-
-
Thomas Zimmermann authored
Moving the driver-specific mmap code into a GEM object function allows for using DRM helpers for various mmap callbacks. The respective rockchip functions are being removed. The file_operations structure fops is now being created by the helper macro DEFINE_DRM_GEM_FOPS(). Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> [On rk3288 (pinky), rk3399 (gru-kevin, puma) and rk3328 (rock64)] Tested-by:
Heiko Stuebner <heiko@sntech.de> [On RK3188/RK3066 (without iommu)] Tested-by:
Alex Bee <knaerzche@gmail.com> Signed-off-by:
-
Jernej Skrabec authored
Driver never uses virtual address of DRM CMA buffers. Switch to CMA helpers which don't deal with virtual mapping. This was actually already the case before commit ad408c76 ("drm/sun4i: Use DRM_GEM_CMA_VMAP_DRIVER_OPS for GEM operations"), but only convenient macro at the time used helpers with virtual mapping. Signed-off-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211019181028.4190737-1-jernej.skrabec@gmail.com
-
Thomas Zimmermann authored
Gma500 currently removes generic fbdev drivers, but ignores generic DRM drivers. Use aperture helpers to remove all generic graphics drivers before loading gma500. Makes gma500 compatible with simpledrm. Signed-off-by:
-
- 20 Oct, 2021 3 commits
-
-
Christian König authored
Simplifying the code a bit. Signed-off-by:
-
Christian König authored
Simplifying the code a bit. Also drop the RCU read side lock since the object is locked anyway. Untested since I can't get the driver to compile on !ARM. Signed-off-by:
-
Christian König authored
No need to actually allocate an array of fences here. Signed-off-by:
-
- 19 Oct, 2021 20 commits
-
-
Maxime Ripard authored
Merge tag 'topic/drm-dp-training-delay-helpers-2021-10-19' of git://anongit.freedesktop.org/drm/drm-intel into drm-misc-next Core Changes: - drm dp helpers for figuring out link training delays Signed-off-by:
-
Christian König authored
Trivial fix since we now need to grab a reference to the fence we have added. Previously the dma_resv function where doing that for us. Signed-off-by:
Nicolas Frattaroli <frattaroli.nicolas@gmail.com> References: https://lore.kernel.org/dri-devel/2023306.UmlnhvANQh@archbook/Tested-by:
-
Stephen Rothwell authored
Commit cd06ab2f ("drm/locking: add backtrace for locking contended locks without backoff") added functions named __stack_depot_* in drm which conflict with stack depot. Rename to __drm_stack_depot_*. v2 by Jani: - Also rename __stack_depot_print References: https://lore.kernel.org/r/20211015202648.258445ef@canb.auug.org.au Fixes: cd06ab2f ("drm/locking: add backtrace for locking contended locks without backoff") Cc: Daniel Vetter <daniel@ffwll.ch> Reviewed-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018085113.27033-1-jani.nikula@intel.com
-
Dmitry Osipenko authored
TXTAGOCNT and RXTASURECNT bitfields of BTACNTRL1 register are swapped in the code, correct them. Driver doesn't implement low power mode for now, so this change doesn't make a practical difference yet. Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # Asus TF700T Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> #TF700T Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Reviewed-by:
Robert Foss <robert.foss@linaro.org> Signed-off-by:
-
Dmitry Osipenko authored
Non-continuous clock mode doesn't work because driver doesn't support it properly. The bridge driver programs wrong bitfields that are required by the non-continuous mode (BTACNTRL1 register bitfields are swapped in the code), but fixing them doesn't help. Display panel of ASUS Transformer TF700T tablet supports non-continuous mode and display doesn't work at all using that mode. There are no device-trees that are actively using this DSI bridge in upstream yet, so clearly the broken mode wasn't ever tested properly. It's a bit too difficult to get LP mode working, hence let's disable the offending mode for now and fall back to continuous mode. Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # Asus TF700T Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> #TF700T Signed-off-by:
-
Dmitry Osipenko authored
Calculate video start delay based on the display timing instead of hardcoding it to a default value. This fixes "trembling" display output on Asus Transformer TF700T which uses Panasonic VVX10F004B00 display panel. Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # Asus TF700T Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> #TF700T Signed-off-by:
-
Dmitry Osipenko authored
Support pulse-mode synchronization which is supported and used by simple DSI panels like Panasonic VVX10F004B00. Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # Asus TF700T Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> #TF700T Signed-off-by:
-
Dmitry Osipenko authored
The driver assumes that reference clock is always-enabled, but this is hardware-dependent and not true for ASUS Transformer TF700T. Make driver enable / disable the reference clock. Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # Asus TF700T Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> #TF700T Signed-off-by:
-
Thomas Zimmermann authored
struct gtt_range represents a GEM object. Rename the structure to struct psb_gem_object and update all users. No functional changes. Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211015084053.13708-11-tzimmermann@suse.de
-
Thomas Zimmermann authored
struct gtt_range represents a GEM object and should not be used for GTT setup. Change psb_gtt_insert() and psb_gtt_remove() to receive all necessary parameters from their caller. This also eliminates possible failure from psb_gtt_insert(). There's one exception in psb_gtt_restore(), which requires an upcast from struct resource to struct gtt_range when restoring the GTT after hibernation. A possible solution would track the GEM objects that need restoration separately from the GTT resource. Rename the functions to psb_gtt_insert_pages() and psb_gtt_remove_pages() to reflect their similarity to MMU interfaces. v3: * restore the comments about locking rules (Patrik) Signed-off-by:
-
Thomas Zimmermann authored
Caching of the GEM object's backing pages are unrelated to GTT management. Move the respective calls from GTT code to GEM code. Signed-off-by:
-
Thomas Zimmermann authored
psb_gtt_alloc_range() allocates struct gtt_range, create the GTT resource and performs some half-baked initialization. Inline the function into its only caller psb_gem_create(). For creating the GTT resource, introduce a new helper, psb_gtt_alloc_resource() that hides the details of the GTT. For psb_gtt_free_range(), inline the function into its only caller psb_gem_free_object(). While at it, remove the explicit invocation of drm_gem_free_mmap_offset(). The mmap offset is already released by drm_gem_object_release(). v3: * replace offset[static 1] with pointer notation (Patrik) Signed-off-by:
-
Thomas Zimmermann authored
psb_gtt_attach_pages() are not GTT functions but deal with the GEM object's SHMEM pages. The only callers of psb_gtt_attach_pages() and psb_gtt_detach_pages() are the GEM pin helpers. Inline the calls and cleanup the resulting code. v2: * unlock gtt_mutex in pin-error handling (Patrik) Signed-off-by:
-
Thomas Zimmermann authored
Rename psb_gtt_pin() to psb_gem_pin() to reflect the semantics of the function. Same for psb_gtt_unpin(). No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Support private objects for stolen memory in psb_gem_create() and convert users to psb_gem_create(). For stolen memory, psb_gem_create() now initializes the GEM object via drm_gem_private_object_init(). In the fbdev setup, replace the open-coded initialization of struct gtt_range with a call to psb_gem_create(). Use drm_gem_object_put() for release. In the cursor setup, use psb_gem_create() and get a real GEM object. Previously the allocated instance of struct gtt_range was only partially initialized. Release the cursor GEM object in gma_crtc_destroy(). The release was missing from the original code. With the conversion of all callers to psb_gem_create(), the extern declarations of psb_gtt_alloc_range, psb_gtt_free_range and psb_gem_object_func are not required any longer. Declare them as static. Signed-off-by:
-
Thomas Zimmermann authored
Implement psb_gem_create() for general use. Create the GEM handle in psb_gem_create_dumb(). Allows to use psb_gem_create() for creating all of the GEM objects. While at it, clean-up drm_gem_dumb_create() to make it more readable. Signed-off-by:
-
Thomas Zimmermann authored
Convert upcasts from struct drm_gem_object to struct gtt_range to to_gtt_range(). Some places used container_of() directly. Signed-off-by:
-
Thomas Zimmermann authored
Allocation and pinning helpers for struct gtt_range are GEM functions, so move them to gem.c. No functional changes. v2: * keep docs for psb_gtt_{attach,detach}_pages() (Patrik) Signed-off-by: -
Jani Nikula authored
Reuse the 8b/10b link training delay helpers. Functionally this skips the check for invalid values for DPCD 1.4 and later at clock recovery delay (as it's a fixed delay and bypasses the rd_interval) but the same value will be checked and invalid values reported at channel equalization. Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
The link training delays are different and/or available in different DPCD offsets depending on: - Clock recovery vs. channel equalization - DPRX vs. LTTPR - 128b/132b vs. 8b/10b - DPCD 1.4+ vs. earlier Add helpers to get the correct delays in us, reading DPCD if necessary. This is more straightforward than trying to retrofit the existing helpers to take 128b/132b into account. Having to pass in the DPCD receiver cap field seems unavoidable, because reading it involves checking the revision and reading extended receiver cap. So unfortunately the interface is mixed cached and read as needed. v2: Remove delay_us < 0 check and the whole local var (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
- 18 Oct, 2021 1 commit
-
-
Shunsuke Mie authored
A comment for the dma_buf_vmap/vunmap() is not catching up a corresponding implementation. Signed-off-by:
Shunsuke Mie <mie@igel.co.jp> Link: https://patchwork.freedesktop.org/patch/msgid/20211008112009.118996-1-mie@igel.co.jpReviewed-by:
-
- 17 Oct, 2021 11 commits
-
-
Brian Norris authored
Fix some error handling here noticed in review of other changes. Fixes: 2d4f7bda ("drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge driver") Signed-off-by:
Brian Norris <briannorris@chromium.org> Reported-by:
Chen-Yu Tsai <wenst@chromium.org> Reviewed-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by:
-
Brian Norris authored
Our probe() function never enabled this clock, so we shouldn't disable it if we fail to probe the bridge. Noted by inspection. Fixes: 2d4f7bda ("drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge driver") Signed-off-by:
-
Brian Norris authored
Since commit 43c2de10 ("drm/rockchip: dsi: move all lane config except LCDC mux to bind()"), we perform most HW configuration in the bind() function. This configuration may be lost on suspend/resume, so we need to call it again. That may lead to errors like this after system suspend/resume: dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO panel-kingdisplay-kd097d04 ff960000.mipi.0: failed write init cmds: -110 Tested on Acer Chromebook Tab 10 (RK3399 Gru-Scarlet). Note that early mailing list versions of this driver borrowed Rockchip's downstream/BSP solution, to do HW configuration in mode_set() (which *is* called at the appropriate pre-enable() times), but that was discarded along the way. I've avoided that still, because mode_set() documentation doesn't suggest this kind of purpose as far as I can tell. Fixes: 43c2de10 ("drm/rockchip: dsi: move all lane config except LCDC mux to bind()") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Brian Norris authored
In commit 43c2de10 ("drm/rockchip: dsi: move all lane config except LCDC mux to bind()"), we moved most HW configuration to bind(), but we didn't move the runtime PM management. Therefore, depending on initial boot state, runtime-PM workqueue delays, and other timing factors, we may disable our power domain in between the hardware configuration (bind()) and when we enable the display. This can cause us to lose hardware state and fail to configure our display. For example: dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO panel-innolux-p079zca ff960000.mipi.0: failed to write command 0 or: dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO panel-kingdisplay-kd097d04 ff960000.mipi.0: failed write init cmds: -110 We should match the runtime PM to the lifetime of the bind()/unbind() cycle. Tested on Acer Chrometab 10 (RK3399 Gru-Scarlet), with panel drivers built either as modules or built-in. Side notes: it seems one is more likely to see this problem when the panel driver is built into the kernel. I've also seen this problem bisect down to commits that simply changed Kconfig dependencies, because it changed the order in which driver init functions were compiled into the kernel, and therefore the ordering and timing of built-in device probe. Fixes: 43c2de10 ("drm/rockchip: dsi: move all lane config except LCDC mux to bind()") Link: https://lore.kernel.org/linux-rockchip/9aedfb528600ecf871885f7293ca4207c84d16c1.camel@gmail.com/ Reported-by: <aleksandr.o.makarov@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Brian Norris authored
If hardware is malfunctioning (e.g., misconfigured clocks?), we can get stuck here forever, holding various DRM locks and eventually locking up the entire system. It's better to complain loudly and move on, than to lock up the system. In local tests, this operation takes less than 20ms. Signed-off-by:
-
Yang Li authored
Currently a plain integer is being used to nullify the pointer struct v3d_submit_ext *se. Use NULL instead. Cleans up sparse warnings: drivers/gpu/drm/v3d/v3d_gem.c:777:53: warning: Using plain integer as NULL pointer drivers/gpu/drm/v3d/v3d_gem.c:1010:45: warning: Using plain integer as NULL pointer Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Reviewed-by:
Melissa Wen <mwen@igalia.com> Signed-off-by:
Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/1634282081-72255-1-git-send-email-yang.lee@linux.alibaba.com
-
Shawn Guo authored
It adds a DRM panel driver for Sony Tulip Truly NT35521 5.24" 1280x720 DSI panel, which can be found on Sony Xperia M4 Aqua phone. The panel backlight is managed through DSI link. The driver is built using linux-mdss-dsi-panel-driver-generator[1], and additionally modeling the 5V control GPIOs with regulators and adding Backlight GPIO support. [1] https://github.com/msm8916-mainline/linux-mdss-dsi-panel-driver-generatorSigned-off-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210809051008.6172-3-shawn.guo@linaro.org
-
Shawn Guo authored
The Sony Tulip Truly NT35521 is a 5.24" 1280x720 DSI panel, which can be found on Sony Xperia M4 Aqua phone. The backlight is managed through DSI link. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
AngeloGioacchino Del Regno authored
This adds support for the BOE BF060Y8M-AJ0 5.99" AMOLED module that can be found in some F(x)Tec Pro1 and Elephone U1 devices. Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Signed-off-by:
-
AngeloGioacchino Del Regno authored
Document the boe,bf060y8m-aj0 panel. Signed-off-by:
-
AngeloGioacchino Del Regno authored
Add a driver for panels using the Novatek NT35950 Display Driver IC, including support for the Sharp LS055D1SX04, found in some Sony Xperia Z5 Premium and XZ Premium smartphones. Signed-off-by:
Marijn Suijten <marijn.suijten@somainline.org> Signed-off-by:
-
