- 15 Aug, 2020 6 commits
-
-
Paul Cercueil authored
Add a perfect 50.00 Hz frame rate mode to the list of available modes for the Sharp LS020B1DD01D panel. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200811002240.55194-6-paul@crapouillou.net
-
Paul Cercueil authored
Modify the video mode in order to obtain a perfect 60.00 Hz frame rate using a 3 MHz pixel clock. Signed-off-by:
-
Paul Cercueil authored
Convert the Sharp LS020B1DD01D panel entry from using a struct display_timing to using a struct drm_display_mode, as display_timing seems to be the old and legacy format. Signed-off-by:
-
Paul Cercueil authored
If you pass a string that is not terminated with a carriage return to dev_err(), it will eventually be printed with a carriage return, but not right away, since the kernel will wait for a pr_cont(). Signed-off-by:
-
Paul Cercueil authored
Instead of manipulating the backlight directly in this driver, register it in the probe using drm_panel_of_backlight() and let the drm_panel framework code handle it. Signed-off-by:
-
Linus Walleij authored
The vendor driver makes a few retries on read DSI transactions, something that is needed especially in case of read (such as reading the panel MTP ID) while the panel is running in video mode. This happens on the Samsung s6e63m0 panel on the Golden device. Retry reads and writes alike three times. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Stephan Gerhold <stephan@gerhold.net> Cc: Stephan Gerhold <stephan@gerhold.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200814194451.3494294-1-linus.walleij@linaro.org
-
- 13 Aug, 2020 8 commits
-
-
Laurent Pinchart authored
The OrtusTech COM43H4M85ULC panel is a 18-bit RGB panel, set the bus format to MEDIA_BUS_FMT_RGB666_1X18. Fixes: 725c9d40 ("drm/panel: Add support for OrtusTech COM43H4M85ULC panel") Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Sam Ravnborg <sam.ravnborg@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200812220244.24500-1-laurent.pinchart@ideasonboard.com
-
Linus Walleij authored
The MCDE DSI link hardware which is modeled like a bridge in DRM, connected further to the panel bridge, creating a pipeline. We have been using the .pre_enable(), .enable(), .disable() and .post_disable() callbacks from the bridge to set this up in a chained manner: first the display controller goes online and then in successive order each bridge in the pipeline. Inside DRM it works like this: drm_atomic_helper_commit_tail() drm_atomic_helper_commit_modeset_enables() struct drm_crtc_helper_funcs .atomic_enable() struct drm_simple_display_pipe_funcs .enable() MCDE display enable call drm_atomic_bridge_chain_enable() struct drm_bridge_funcs .pre_enable() mcde_dsi_bridge_pre_enable() panel_bridge_pre_enable() struct drm_panel_funcs .prepare() struct drm_bridge_funcs .enable() mcde_dsi_bridge_enable() panel_bridge_enable() struct drm_panel_funcs .enable() A similar sequence is executed for disabling. Unfortunately this is not what the hardware needs: at a certain stage in the enablement of the display controller the DSI link needs to come up to support video mode, else something (like a FIFO flow) locks up the hardware and we never get picture. Fix this by simply leaving the pre|enable and post|disable callbacks unused, and establish two cross-calls from the display controller to bring up the DSI link at the right place in the display bring-up sequence and vice versa in the shutdown sequence. For command mode displays, it works just fine to also enable the display flow early. The only time we hold it back right now is in one-shot mode, on-demand display updates. When combined with the previous patch and some patches for the S6E63M0 display controller to support DSI mode, this gives working display on the Samsung GT-I8190 (Golden) phone. It has also been tested working on the Samsung GT-S7710 (Skomer) phone. Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch> Cc: newbytee@protonmail.com Cc: Stephan Gerhold <stephan@gerhold.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200808223122.1492124-4-linus.walleij@linaro.org
-
Linus Walleij authored
To make sure that the MCDE is in a reasonable state during set-up, perform a reset by power cycling the block by dropping the on-chip regulator reference after probe. The display subsystem (DSS) has no dedicated reset line so dropping the EPOD regulator is the only real way of resetting it. We introduce code to enable and disable the regulator in the display enable/disable callbacks. We move the generic MCDE setup such as muxing of DPI signals and masking of interrupts to the display handling. When we drop the power to the whole display subsystem, not only MCDE but also the DSI links lose their state. Therefore we move the DSI block reset and hardware initialization code to the mcde_dsi_bridge_pre_enable() callback so this happens every time we start up the bridge, as we may have lost the power. We move the final disablement of the interrupts and clocks to the mcde_dsi_bridge_post_disable() callback rather than have it in the mcde_dsi_bridge_disable() callback, as some control messages may still be sent over the DSI host after the bridge has been shut down. This (together with a patch for the corresponding panel) makes the Samsung GT-S7710 successfully disable and re-enable its display, cutting all power while disabled and re-initializing the hardware when coming back up. Acked-by:
-
Linus Walleij authored
It is possible to set a flag in the struct mipi_dsi_device so the panel is handled in low power (LP) mode. Some displays only support this mode and it is also good for testing. Signed-off-by:
-
Linus Walleij authored
The pixel fetcher FIFO depth was just hardcoded to 48 which works fine as long as the framebuffer is 32BPP and the DSI output is RGB888. We will need more elaborate handling for some buffer formats and displays, so start to improve this function by setting reasonable defaults for 32, 24 and 16 BPP framebuffers. Signed-off-by:
-
Linus Walleij authored
Revamp the way that the flow of data to the display is defined. I realized that the hardware supports something like 5 different modes of flow: oneshot, command with TE IRQ, command with BTA (bus turn around) and TE IRQ, video with TE IRQ and video without TE IRQ instead synchronizing to the output of the MCDE DSI formatter. Like before the selection of the type of flow is done from the DSI driver when we attach it to the MCDE and we get to know what the display wants. The new video mode synchronization method from the MCDE DSI formatter is used on some upstream devices such as Golden. This is the new default for video mode: stateless panels do not as a rule generate TE IRQs. Another semantic change is that we stop sending a TE request before every command when sending data to a display in command mode: this should only be explicitly requested when using BTA, according to the vendor driver. This has been tested and works fine with the command mode displays I have. (All that are supported upstream.) Reported-by:
-
Linus Walleij authored
The function mcde_display_send_one_frame() has a historical name that stems from being implemented when the driver only supported single frame updates. Rename it mcde_start_flow() so that it reflects the current usage. Signed-off-by:
-
Tian Tao authored
Add missing include to fix build error: hibmc_drm_drv.c:385:1: warning: data definition has no type or storage class [enabled by default] hibmc_drm_drv.c:385:1: error: type defaults to ‘int’ in declaration of ‘module_init’ [-Werror=implicit-int] hibmc_drm_drv.c:385:1: warning: parameter names (without types) in function of ‘module_exit’ [-Werror=implicit-int] hibmc_drm_drv.c:385:292:1: warning: parameter names (without types) in function declaration [enabled by default] Signed-off-by:
Tian Tao <tiantao6@hisilicon.com> Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/1597289955-27381-1-git-send-email-tiantao6@hisilicon.com
-
- 12 Aug, 2020 10 commits
-
-
Marek Vasut authored
Add very basic driver for Toshiba TC358762 DSI-to-DPI bridge, derived from tc358764 driver and panel-raspberrypi-touchscreen. This driver is meant to replace the panel-raspberrypi-touchscreen too, as the bridge connection can be described in DT too. Signed-off-by:
Marek Vasut <marex@denx.de> Cc: dri-devel@lists.freedesktop.org Cc: Eric Anholt <eric@anholt.net> Cc: Rob Herring <robh+dt@kernel.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: devicetree@vger.kernel.org Reviewed-by:
-
Marek Vasut authored
Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge, this one is used in the Raspberry Pi 7" touchscreen display unit. Signed-off-by:
Rob Herring <robh@kernel.org> Cc: dri-devel@lists.freedesktop.org Cc: Eric Anholt <eric@anholt.net> Cc: Rob Herring <robh+dt@kernel.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: devicetree@vger.kernel.org Signed-off-by:
-
Thomas Zimmermann authored
Backmerging drm-next into drm-misc-next for nouveau and panel updates. Resolves a conflict between ttm and nouveau, where struct ttm_mem_res got renamed to struct ttm_resource. Signed-off-by: -
Christian König authored
The object flags created in radeon_ttm_placement_from_domain take care that we use the correct caching for AGP, this is just superflous. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/384336/?series=80346&rev=1
-
Christian König authored
This is a separate object we work within TTM. Signed-off-by:
-
Christian König authored
The names get/put are associated with reference counting in the Linux kernel, use alloc/free instead. Signed-off-by:
-
Tian Tao authored
The memory used to be allocated with devres helpers and released automatically. In rare circumstances, the memory's release could have happened before the DRM device got released, which would have caused memory corruption of some kind. Now we're embedding the data structures in struct hibmc_drm_private. The whole release problem has been resolved, because struct hibmc_drm_private is allocated with drmm_kzalloc and always released with the DRM device. Signed-off-by:
-
Tian Tao authored
Remove some unused include statements. Signed-off-by:
-
Christian König authored
This reverts commit 2ddef176. As it turned out VMWGFX needs a much wider audit to fix this. Signed-off-by:
-
git://people.freedesktop.org/~sroland/linuxDave Airlie authored
The drm_mode_config_reset patches are very important fixing a recently introduced kernel crash, the others fix various older issues which are a bit less serious in practice. Signed-off-by:
-
- 11 Aug, 2020 16 commits
-
-
Linus Walleij authored
In order to successfully read ID of the MTP panel the panel MTP control page must be unlocked. Previously this wasn't encountered because in the setup with this panel the power wasn't ever really dropped. When power gets dropped from the panel, MTP needs to be unlocked. Acked-by:
-
Oleg Vasilev authored
Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. Display Core already has the subconnector information, we only need to expose it through DRM property. v2:rebase v3: renamed a function call Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: David (ChunMing) Zhou <David1.Zhou@amd.com> Cc: amd-gfx@lists.freedesktop.org Signed-off-by:
Jeevan B <jeevan.b@intel.com> Signed-off-by:
Oleg Vasilev <oleg.vasilev@intel.com> Tested-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1587732655-17544-5-git-send-email-jeevan.b@intel.com
-
Oleg Vasilev authored
Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. v2: rebase v3: renamed a function call Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: David (ChunMing) Zhou <David1.Zhou@amd.com> Cc: amd-gfx@lists.freedesktop.org Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Acked-by:
-
Oleg Vasilev authored
Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. v2: updates to match previous commit changes v3: rebase v4: renamed a function call Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Signed-off-by:
-
Oleg Vasilev authored
Currently, downstream port type is only reported in debugfs. This information should be considered important since it reflects the actual physical connector type. Some userspace (e.g. window compositors) may want to show this info to a user. The 'subconnector' property is already utilized for DVI-I and TV-out for reporting connector subtype. The initial motivation for this feature came from i2c test [1]. It is supposed to be skipped on VGA connectors, but it cannot detect VGA over DP and fails instead. v2: - Ville: utilized drm_dp_is_branch() - Ville: implement DP 1.0 downstream type info - Replaced create_dp_properties with add_dp_subconnector_property - Added dp_set_subconnector_property helper v4: - Ville: add DP1.0 best assumption about subconnector - Ville: assume DVI is DVI-D - Ville: reuse Writeback enum value for Virtual subconnector - Renamed #defines: HDMI -> HDMIA, DP -> DisplayPort v5: rebase v6: - Jani Nikula: renamed a function name - Jani Nikula: addressed the issues with documentation [1]: https://bugs.freedesktop.org/show_bug.cgi?id=104097 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Signed-off-by:
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
amd-drm-fixes-5.9-2020-08-07: amdgpu: - Re-add spelling typo fix - Sienna Cichlid fixes - Navy Flounder fixes - DC fixes - SMU i2c fix - Power fixes Signed-off-by:
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
* backmerge from drm-fixes at v5.8-rc7 * add orientation quirk for ASUS T103HAF * drm/omap: force runtime PM suspend on system suspend * drm/tidss: fix modeset init for DPI panels * re-added docs for drm_gem_flink_ioctl() * ttm: fix page-offset calculation within TTM Signed-off-by:
-
Dave Airlie authored
I need to backmerge 5.8 as I've got a bunch of fixes sitting on an rc7 base that I want to land. Signed-off-by: -
Dave Airlie authored
I fixed the init path, but missed the cleanup path. Fixes: e0830704 ("drm/vmwgfx: takedown vram manager") Reviewed-by:
-
Colin Ian King authored
There is a spelling mistake in a DRM_ERROR message. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Roland Scheidegger <sroland@vmware.com>
-
Colin Ian King authored
There is a spelling mistake in a DRM_ERROR message. Fix it. Signed-off-by:
-
Roland Scheidegger authored
Same problem as in stdu, same fix. Fixes: 51f644b4 ("drm/atomic-helper: reset vblank on crtc reset") Acked-by:
Charmaine Lee <charmainel@vmware.com> Reviewed-by:
Zack Rusin <zackr@vmware.com> Signed-off-by:
-
Roland Scheidegger authored
Same problem as in stdu, same fix. Fixes: 51f644b4 ("drm/atomic-helper: reset vblank on crtc reset") Acked-by:
-
Daniel Vetter authored
When converting to atomic the state reset was done by directly calling the functions, and before the modeset object was fully initialized. This means the various ->dev pointers weren't set up. After commit 51f644b4 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jun 12 18:00:49 2020 +0200 drm/atomic-helper: reset vblank on crtc reset this started to oops because now we're trying to derefence drm_crtc->dev. Fix this up by entirely switching over to drm_mode_config_reset, called once everything is set up. Fixes: 51f644b4 ("drm/atomic-helper: reset vblank on crtc reset") Reported-by:
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Tested-by:
-
Dan Carpenter authored
These if statements are supposed to be true if we ended the list_for_each_entry() loops without hitting a break statement but they don't work. In the first loop, we increment "i" after the "if (i == unit)" condition so we don't necessarily know that "i" is not equal to unit at the end of the loop. In the second loop we exit when mode is not pointing to a valid drm_display_mode struct so it doesn't make sense to check "mode->type". Fixes: a278724a ("drm/vmwgfx: Implement fbdev on kms v2") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Dan Carpenter authored
The "entry" pointer is an offset from the list head and it doesn't point to a valid vmw_legacy_display_unit struct. Presumably the intent was to point to the last entry. Also the "i++" wasn't used so I have removed that as well. Fixes: d7e1958d ("drm/vmwgfx: Support older hardware.") Signed-off-by:
-
