- 12 Apr, 2020 1 commit
-
-
Sam Ravnborg authored
Laurent Pinchart <laurent.pinchart@ideasonboard.com> and Jani Nikula <jani.nikula@intel.com> both suggested to make the pointer to struct ipu_di_signal_cfg const. Fix this. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Fixes: 3f6c93ec ("fbdev: mx3fb: avoid warning about psABI change") Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Enrico Weigelt <info@metux.net> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: linux-fbdev@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200408182926.GA21997@ravnborg.org
-
- 09 Apr, 2020 11 commits
-
-
Chris Wilson authored
A few very simple testcases to exercise the dma-fence-chain API. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200409110101.18400-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
Whenever we walk along the dma-fence-chain, we prune signaled links to keep the chain nice and tidy. This leads to situations where we can prune a link and report the earlier fence as the target seqno -- violating our own consistency checks that the seqno is not more advanced than the last element in a dma-fence-chain. Report a NULL fence and success if the seqno has already been signaled. Signed-off-by:
-
Chris Wilson authored
Inside dma-fence-chain, we use a cmpxchg on an RCU-protected pointer. To avoid the sparse warning for using the RCU pointer directly, we have to cast away the __rcu annotation. However, we don't need to use void* everywhere and can stick to the dma_fence*. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200409110101.18400-1-chris@chris-wilson.co.uk
-
Lyude Paul authored
Although it's not unexpected for drm_dp_check_act_status() to fail due to DPCD read failures (as the hub may have just been unplugged suddenly), timeouts are a bit more worrying as they either mean we need a longer timeout value, or we aren't setting up payload allocations properly. So, let's start printing errors on timeouts. Signed-off-by:
Lyude Paul <lyude@redhat.com> Cc: Sean Paul <sean@poorly.run> Reviewed-by:
Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20200406221253.1307209-5-lyude@redhat.com
-
Lyude Paul authored
Currently we only poll for an ACT up to 30 times, with a busy-wait delay of 100µs between each attempt - giving us a timeout of 2900µs. While this might seem sensible, it would appear that in certain scenarios it can take dramatically longer then that for us to receive an ACT. On one of the EVGA MST hubs that I have available, I observed said hub sometimes taking longer then a second before signalling the ACT. These delays mostly seem to occur when previous sideband messages we've sent are NAKd by the hub, however it wouldn't be particularly surprising if it's possible to reproduce times like this simply by introducing branch devices with large LCTs since payload allocations have to take effect on every downstream device up to the payload's target. So, instead of just retrying 30 times we poll for the ACT for up to 3ms, and additionally use usleep_range() to avoid a very long and rude busy-wait. Note that the previous retry count of 30 appears to have been arbitrarily chosen, as I can't find any mention of a recommended timeout or retry count for ACTs in the DisplayPort 2.0 specification. This also goes for the range we were previously using for udelay(), although I suspect that was just copied from the recommended delay for link training on SST devices. Changes since v1: * Use readx_poll_timeout() instead of open-coding timeout loop - Sean Paul Changes since v2: * Increase poll interval to 200us - Sean Paul * Print status in hex when we timeout waiting for ACT - Sean Paul Signed-off-by:
-
Lyude Paul authored
Just add a bit more line wrapping, get rid of some extraneous whitespace, remove an unneeded goto label, and move around some variable declarations. No functional changes here. Signed-off-by:
-
Lyude Paul authored
No functional changes. Signed-off-by:
-
Guido Günther authored
This adds initial support for the NWL MIPI DSI Host controller found on i.MX8 SoCs. It adds support for the i.MX8MQ but the same IP can be found on e.g. the i.MX8QXP. It has been tested on the Librem 5 devkit using mxsfb. Signed-off-by:
Guido Günther <agx@sigxcpu.org> Co-developed-by:
Robert Chiras <robert.chiras@nxp.com> Signed-off-by:
Martin Kepplinger <martin.kepplinger@puri.sm> Reviewed-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
-
Guido Günther authored
The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs. Signed-off-by:
Rob Herring <robh@kernel.org> Acked-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:
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 5 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:
-
