- 09 Apr, 2020 3 commits
-
-
Guido Günther authored
The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs. Signed-off-by:
Guido Günther <agx@sigxcpu.org> Tested-by:
Robert Chiras <robert.chiras@nxp.com> Reviewed-by:
Rob Herring <robh@kernel.org> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
-
Thomas Zimmermann authored
Most of the documentation was in an otherwise empty file, which was probably just left from a previous clean-up effort. So move code and documentation into a single file. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Gerd Hoffmann <kraxel@redhat.com> Acked-by:
-
Thomas Zimmermann authored
Calling the VRAM helper's prepare_fb() helper now sets the plane's fence object. This will be useful for PRIME support. VRAM helpers don't support buffer sharing ATM, so for now there are no drivers requiring this change. v2: * removed a TODO comment about buffer synchronization Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200331092740.29282-1-tzimmermann@suse.de
-
- 08 Apr, 2020 23 commits
-
-
Chris Wilson authored
drm_fbdev_generic_setup() was changed to be a void return, but the stub was left returning 0. ./include/drm/drm_fb_helper.h: In function ‘drm_fbdev_generic_setup’: ./include/drm/drm_fb_helper.h:450:9: warning: ‘return’ with a value, in function returning void [-Wreturn-type] ./include/drm/drm_fb_helper.h:448:1: note: declared here 448 | drm_fbdev_generic_setup(struct drm_device *dev, unsigned int preferred_bpp) Fixes: 1aed9509 ("drm/fb-helper: Remove return value from drm_fbdev_generic_setup()") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200408212407.4309-1-chris@chris-wilson.co.uk
-
David Lu authored
Add entries for BOE TV105WUM-NW0 10.5" WUXGA TFT LCD panel. Signed-off-by:
David Lu <david.lu@bitland.com.cn> Reviewed-by:
Nicolas Boichat <drinkcat@chromium.org> Signed-off-by:
-
David Lu authored
Add bindings documentation for BOE TV105WUM-NW0 10.5" WUXGA TFT LCD panel. Signed-off-by:
-
Arnd Bergmann authored
The arm64 gcc-9 release warns about a change in the calling conventions: drivers/video/fbdev/mx3fb.c: In function 'sdc_init_panel': drivers/video/fbdev/mx3fb.c:506:12: note: parameter passing for argument of type 'struct ipu_di_signal_cfg' changed in GCC 9.1 506 | static int sdc_init_panel(struct mx3fb_data *mx3fb, enum ipu_panel panel, | ^~~~~~~~~~~~~~ drivers/video/fbdev/mx3fb.c: In function '__set_par': drivers/video/fbdev/mx3fb.c:848:7: note: parameter passing for argument of type 'struct ipu_di_signal_cfg' changed in GCC 9.1 Change the file to just pass the struct by reference, which is unambiguous and avoids the warning. Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Thomas Zimmermann authored
Generic fbdev emulation is a DRM client. Drivers should invoke the setup function, but not depend on its success. Hence remove the return value. v3: * document stricter requirements for call sequence v2: * warn if fbdev device has not been registered yet * document the new behavior * convert the existing warning to the new dev_ interface Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Acked-by:
-
Thomas Zimmermann authored
Generic fbdev support is a DRM client. Set it up after registering the new DRM device. Remove the error checks as the driver's probe function should not depend on a DRM client's state. Signed-off-by:
-
Thomas Zimmermann authored
Remove the error check from the fbdev setup function. The driver's probe function should not depend on a DRM client's state. Signed-off-by:
-
Thomas Zimmermann authored
Generic fbdev support is a DRM client. Set it up after fully registering the new DRM device. Signed-off-by:
Jyri Sarha <jsarha@ti.com> Reviewed-by:
-
Thomas Zimmermann authored
Generic fbdev support is a DRM client. Set it up after registering the new DRM device. Remove the error checks as the driver's probe function should not depend on a DRM client's state. Signed-off-by:
-
Thomas Zimmermann authored
Remove the error check from the fbdev setup function. The function will print a warning. v2: * fix subject line Signed-off-by:
-
Thomas Zimmermann authored
Remove the error check from the fbdev setup function. The function will print a warning. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Reviewed-by:
-
Thomas Zimmermann authored
Generic fbdev support is a DRM client. Set it up after fully registering the new DRM device. Signed-off-by:
-
Thomas Zimmermann authored
Generic fbdev support is a DRM client. Remove the error check as the driver's probe function should not depend on a DRM client's state. Signed-off-by:
-
Thomas Zimmermann authored
Generic fbdev support is a DRM client. Set it up after registering the new DRM device. Remove the error checks as the driver's probe function should not depend on a DRM client's state. Signed-off-by:
-
Huang Rui authored
ttm_trace_dma_map/ttm_trace_dma_unmap is never used anymore. v2: remove the file completely Signed-off-by:
Huang Rui <ray.huang@amd.com> Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
-
Paul Cercueil authored
By changing the pixel clock and the length of the back porch, it is possible to obtain a perfect 50 Hz refresh rate. Signed-off-by:
-
Paul Cercueil authored
Add support for multiple drm_display_mode entries. This will allow to add a 50 Hz mode later. Signed-off-by:
-
Jason Yan authored
Fix the following gcc warning: drivers/video/fbdev/mb862xx/mb862xxfb_accel.c:187:6: warning: variable ‘mdr’ set but not used [-Wunused-but-set-variable] int mdr; ^~~ Reported-by:Hulk Robot <hulkci@huawei.com> Signed-off-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
-
Jason Yan authored
Fix the following gcc warning: drivers/video/fbdev/matrox/g450_pll.c:336:15: warning: variable ‘pixel_vco’ set but not used [-Wunused-but-set-variable] unsigned int pixel_vco; ^~~~~~~~~ Reported-by: -
Heiko Stuebner authored
The LTK050H3146W is 5.0" 720x1280 DSI display. There are two variants with essentially the same name, LTK050H3146W and LTK050H3146W-A2. They differ in their init sequence and mode details. changes in v2: - add display variants changes in v3: - fixed indentation and artifacts found by Sam Signed-off-by:
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Signed-off-by:
-
Heiko Stuebner authored
The LTK050H3146W is a 5.0" 720x1280 DSI display. changes in v2: - add display variants Signed-off-by:
-
Johan Jonker authored
In the old txt situation we add/describe only properties that are used by the driver/hardware itself. With yaml it also filters things in a node that are used by other drivers like 'assigned-clocks' and 'assigned-clock-rates' for rk3399 and 'power-domains' for most Rockchip Socs in 'vop' nodes, so add them to 'rockchip-vop.yaml'. Signed-off-by:
Johan Jonker <jbx6244@gmail.com> Reviewed-by:
-
Johan Jonker authored
Current dts files with 'vop' nodes are manually verified. In order to automate this process rockchip-vop.txt has to be converted to yaml. Signed-off-by:
-
- 07 Apr, 2020 11 commits
-
-
Jagan Teki authored
The feiyang,fy07024di26a30d.txt and sitronix,st7701.txt has been converted to YAML schemas, update MAINTAINERS to match them again. Signed-off-by:
Jagan Teki <jagan@amarulasolutions.com> Signed-off-by:
-
Jagan Teki authored
Convert the sitronix,st7701 panel bindings to DT schema. Signed-off-by:
-
Jagan Teki authored
Convert the feiyang,fy07024di26a30d panel bindings to DT schema. Signed-off-by:
-
Jules Irenge authored
Sparse reports warnings at cyber2000fb_enable_ddc() and cyber2000fb_disable_ddc() warning: context imbalance in cyber2000fb_enable_ddc() - wrong count at exit warning: context imbalance in cyber2000fb_disable_ddc() - unexpected unlock The root cause is the missing annotation at cyber2000fb_enable_ddc() and cyber2000fb_disable_ddc() Add the missing __acquires(&cfb->reg_b0_lock) annotation Add the missing __releases(&cfb->reg_b0_lock) annotation Signed-off-by:
Jules Irenge <jbi.octave@gmail.com> Signed-off-by:
-
Markus Elfring authored
The function “platform_get_irq” can log an error already. Thus omit a redundant message for the exception handling in the calling function. This issue was detected by using the Coccinelle software. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
-
Lyude Paul authored
Drive-by fix I noticed the other day - drm_dp_mst_has_audio() only ever made sense back when we still had to validate ports before accessing them in order to (attempt to) avoid NULL dereferences. Since we have proper reference counting that guarantees we always can safely access the MST port, there's no use in keeping this function around as all it does is validate the port pointer before checking the audio status. Note - drm_dp_mst_port->has_audio is technically protected by drm_device->mode_config.connection_mutex, since it's only ever updated from drm_dp_mst_get_edid(). Additionally, we change the declaration for port in struct intel_connector to be properly typed, so we can directly access it. Changes since v1: * Change type of intel_connector->port in a separate patch - Sean Paul Cc: "Lee, Shawn C" <shawn.c.lee@intel.com> Reviewed-by:
Sean Paul <sean@poorly.run> Signed-off-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200406200646.1263435-2-lyude@redhat.com
-
Lyude Paul authored
The only reason for having this cast as void * before was because we originally needed to use drm_dp_mst_get_port_validated() and friends in order to (attempt to) safely access MST ports. However, we've since improved how reference counting works with ports and mstbs such that we can now rely on drm_dp_mst_port structs remaining in memory for as long as the driver needs. This means we don't really need to cast this as void* anymore, and can just access the struct directly. We'll also need this for the next commit, so that we can remove drm_dp_mst_port_has_audio(). Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200406200646.1263435-1-lyude@redhat.com
-
Tang Bin authored
The platform_get_irq() can print error message, so remove the redundant dev_err() here. Signed-off-by:
Tang Bin <tangbin@cmss.chinamobile.com> Acked-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
-
Sam Ravnborg authored
Lyude Paul wrote a very good intro to vblank here: https://lore.kernel.org/dri-devel/faf63d8a9ed23c16af69762f59d0dca6b2bf085f.camel@redhat.com/T/#mce6480be738160e9d07c5d023e88fd78d7a06d27 Add this to the intro chapter in drm_vblank.c so others can benefit from it too. v2: - Reworded to improve readability (Thomas) v3: - Added nice ascii drawing from Lyude (Lyude) - Added referende to high-precision timestamp (Daniel) - Improved grammar (Thomas) - Combined it all and made kernel-doc happy - Dropped any a-b, r-b do to the amount of changes v4: - Add intro to vblank interrupt (Liviu) - Add historical reference for blanking (Alex) Signed-off-by:
-
Sam Ravnborg authored
drm_writeback.h included a lot of nice kernel-doc comments. Wire it up so the header file is included in the kernel-doc generated documentation. Added a few simple comments to the two structs so they get picked up by kernel-doc. Signed-off-by:
-
Sam Ravnborg authored
Document the callbacks: drm_connector_helper_funcs.prepare_writeback_job drm_connector_helper_funcs.cleanup_writeback_job The documentation was pulled from the changelong introducing the callbacks, originally written by Laurent. Adding the missing documentation fixes the following warnings: drm_modeset_helper_vtables.h:1052: warning: Function parameter or member 'prepare_writeback_job' not described in 'drm_connector_helper_funcs' drm_modeset_helper_vtables.h:1052: warning: Function parameter or member 'cleanup_writeback_job' not described in 'drm_connector_helper_funcs' v2: - Fix formatting (Daniel) - Drop changelog text and add reference (Daniel) - Improve grammar. and use "operation" (Laurent) Signed-off-by:Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Liviu Dudau <liviu.dudau@arm.com> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Link: https://patchwork.freedesktop.org/patch/msgid/20200406194746.26433-3-sam@ravnborg.org
-
- 06 Apr, 2020 3 commits
-
-
Lyude Paul authored
It looks like that when we introduced the ability to handle multiple down requests at once, we accidentally started dropping NAK replies - causing sideband messages which got NAK'd to seemingly timeout and cause all sorts of weirdness. So, fix this by making sure we don't return from drm_dp_mst_handle_down_rep() early, but instead treat NAKs like any other message. Signed-off-by:
-
Lyude Paul authored
While we don't need this function to store an mstb anywhere for UP requests since we process them asynchronously, we do need to make sure that we don't try to write to **mstb for UP requests otherwise we'll cause a NULL pointer deref: RIP: 0010:drm_dp_get_one_sb_msg+0x4b/0x460 [drm_kms_helper] Call Trace: ? vprintk_emit+0x16a/0x230 ? drm_dp_mst_hpd_irq+0x133/0x1010 [drm_kms_helper] drm_dp_mst_hpd_irq+0x133/0x1010 [drm_kms_helper] ? __drm_dbg+0x87/0x90 [drm] ? intel_dp_hpd_pulse+0x24b/0x400 [i915] intel_dp_hpd_pulse+0x24b/0x400 [i915] i915_digport_work_func+0xd6/0x160 [i915] process_one_work+0x1a9/0x370 worker_thread+0x4d/0x3a0 kthread+0xf9/0x130 ? process_one_work+0x370/0x370 ? kthread_park+0x90/0x90 ret_from_fork+0x35/0x40 So, fix this. Signed-off-by: -
Markus Elfring authored
The function “platform_get_irq” can log an error already. Thus omit a redundant message for the exception handling in the calling function. This issue was detected by using the Coccinelle software. Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/5a6cf5a7-3f27-5425-4d6a-550a17bc51e3@web.de
-
