summary refs log tree commit diff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2020-12-30drm/tve200: remove unused including <linux/version.h>Tian Tao
Remove including <linux/version.h> that don't need it. Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/1609291023-46889-1-git-send-email-tiantao6@hisilicon.com
2020-12-23drm/hisilicon: Remove drm_dev_put in hibmcTian Tao
Hibmc use the devm_drm_dev_alloc function in hibmc_pci_probe, if hibmc_pci_probe returns non-zero, devm_drm_dev_alloc will call devm_drm_dev_init, which will call devm_drm_dev_init_release to release drm_dev_put. There is no need for hibmc to call drm_dev_put separately. Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1608638156-7879-1-git-send-email-tiantao6@hisilicon.com
2020-12-22drm/hisilicon: Use pcim_enable_device()Tian Tao
Using the managed function simplifies the error handling. After unloading the driver, the PCI device should now get disabled as well. Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1608511522-3100-1-git-send-email-tiantao6@hisilicon.com
2020-12-22drm/virtio: align blob resources to page sizesChia-I Wu
They trigger the BUG_ON() in drm_gem_private_object_init otherwise. Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201219031959.92932-1-olvaffe@gmail.com Cc: Gurchetan Singh <gurchetansingh@chromium.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-12-22drm/qxl: use flexible-array member instead of zero-length arrayTian Tao
Use flexible-array member introduced in C99 instead of zero-length array. Most of zero-length array was already taken care in previous patch [1]. Now modified few more cases which were not handled earlier. [1]. https://patchwork.kernel.org/patch/11394197/ Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Link: http://patchwork.freedesktop.org/patch/msgid/1607650349-28513-1-git-send-email-tiantao6@hisilicon.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-12-22drivers: gpu: drm: virtio: fix dependency of DRM_VIRTIO_GPU on VIRTIOEnrico Weigelt, metux IT consult
VIRTIO itself has no dependencies and therefore can easily be just select'ed, instead of depending on it. The current depends on causes any others trying to select VIRTIO to fail like this: drivers/gpu/drm/Kconfig:74:error: recursive dependency detected! drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by DRM_VIRTIO_GPU drivers/gpu/drm/virtio/Kconfig:2: symbol DRM_VIRTIO_GPU depends on VIRTIO drivers/virtio/Kconfig:2: symbol VIRTIO is selected by GPIO_VIRTIO drivers/gpio/Kconfig:1618: symbol GPIO_VIRTIO depends on GPIOLIB drivers/gpio/Kconfig:14: symbol GPIOLIB is selected by I2C_MUX_LTC4306 drivers/i2c/muxes/Kconfig:47: symbol I2C_MUX_LTC4306 depends on I2C drivers/i2c/Kconfig:8: symbol I2C is selected by FB_DDC drivers/video/fbdev/Kconfig:63: symbol FB_DDC depends on FB drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER It seems that having both 'depends on' as well as 'select' on the same symbol sends us into big trouble, and Kconfig can't break up the circular dependency (note that in the tested configuration, neither I2C, FB or DRM are enabled at all). Perhaps we could consider this a bug in Kconfig, but the trouble can easily be circumvented by changing 'depends on' into 'select'. DRM_VIRTIO_GPU also depends on VIRTIO_MENU, so even after this change, that option will only show up if the user already enabled virtio in the config. This change didn't cause any changes in the .config after menuconfig run, so we should be completely safe here. Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net> Reviewed-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201204131221.2827-1-info@metux.net Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-12-22drm/fb-helper: Add a FIXME that generic_setup is very confusingDaniel Vetter
I tried to fix this for real, but it's very sprawling and lots of drivers get this mildly wrong one way or the other. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Acked-by: Simon Ser <contact@emersion.fr> 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> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201211161113.3350061-2-daniel.vetter@ffwll.ch
2020-12-17drm: require each CRTC to have a unique primary planeSimon Ser
User-space expects to be able to pick a primary plane for each CRTC exposed by the driver. Make sure this assumption holds in drm_mode_config_validate. Use the legacy drm_crtc.primary field to check this, because it's simpler and we require drivers to set it anyways. Accumulate a set of primary planes which are already used for a CRTC in a bitmask. Error out if a primary plane is re-used. v2: new patch v3: - Use u64 instead of __u64 (Jani) - Use `unsigned int` instead of `unsigned` (Jani) v4: - Use u32 instead of u64 for plane mask (Ville) - Use drm_plane_mask instead of BIT (Ville) - Fix typos (Ville) Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Acked-by: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Pekka Paalanen <ppaalanen@gmail.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201211184634.74534-4-contact@emersion.fr
2020-12-17drm/doc: fix reference to drm_format_modifier_blobSimon Ser
The documentation build system recognizes "struct XXX" references and generates links for them. Signed-off-by: Simon Ser <contact@emersion.fr> Cc: Pekka Paalanen <ppaalanen@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201217113220.102271-4-contact@emersion.fr
2020-12-17drm/doc: introduce new section for standard plane propertiesSimon Ser
Introduce a new "Standard Plane Properties" section for properties defined in drm_plane.c. Move the mis-placed IN_FORMATS docs there. Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Cc: Pekka Paalanen <ppaalanen@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201217113220.102271-3-contact@emersion.fr
2020-12-16drm/vc4: hdmi: Enable 10/12 bpc outputMaxime Ripard
The BCM2711 supports higher bpc count than just 8, so let's support it in our driver. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215154243.540115-10-maxime@cerno.tech
2020-12-16drm/vc4: hdmi: Limit the BCM2711 to the max without scramblingMaxime Ripard
Unlike the previous generations, the HSM clock limitation is way above what we can reach without scrambling, so let's move the maximum frequency we support to the maximum clock frequency without scrambling. Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20201215154243.540115-9-maxime@cerno.tech
2020-12-16drm/vc4: hdmi: Use the connector state pixel rate for the PHYMaxime Ripard
The PHY initialisation parameters are not based on the pixel clock but the TMDS clock rate which can be the pixel clock in the standard case, but could be adjusted based on some parameters like the bits per color. Since the TMDS clock rate is stored in our custom connector state already, let's reuse it from there instead of computing it again. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20201215154243.540115-8-maxime@cerno.tech
2020-12-16drm/vc4: hdmi: Store pixel frequency in the connector stateMaxime Ripard
The pixel rate is for now quite simple to compute, but with more features (30 and 36 bits output, YUV output, etc.) will depend on a bunch of connectors properties. Let's store the rate we have to run the pixel clock at in our custom connector state, and compute it in atomic_check. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20201215154243.540115-7-maxime@cerno.tech
2020-12-16drm/vc4: hdmi: Create a custom connector stateMaxime Ripard
When run with a higher bpc than 8, the clock of the HDMI controller needs to be adjusted. Let's create a connector state that will be used at atomic_check and atomic_enable to compute and store the clock rate associated to the state. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215154243.540115-6-maxime@cerno.tech
2020-12-16drm/vc4: hdmi: Don't access the connector state in reset if kmalloc failsMaxime Ripard
drm_atomic_helper_connector_reset uses kmalloc which, from an API standpoint, can fail, and thus setting connector->state to NULL. However, our reset hook then calls drm_atomic_helper_connector_tv_reset that will access connector->state without checking if it's a valid pointer or not. Make sure we don't end up accessing a NULL pointer. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Suggested-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20201215154243.540115-5-maxime@cerno.tech
2020-12-16drm/vc4: hdmi: Take into account the clock doubling flag in atomic_checkMaxime Ripard
Commit 63495f6b4aed ("drm/vc4: hdmi: Make sure our clock rate is within limits") was intended to compute the pixel rate to make sure we remain within the boundaries of what the hardware can provide. However, unlike what mode_valid was checking for, we forgot to take into account the clock doubling flag that can be set for modes. Let's honor that flag if it's there. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reported-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Fixes: 63495f6b4aed ("drm/vc4: hdmi: Make sure our clock rate is within limits") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20201215154243.540115-4-maxime@cerno.tech
2020-12-16drm/vc4: Pass the atomic state to encoder hooksMaxime Ripard
We'll need to access the connector state in our encoder setup, so let's just pass the whole DRM state to our private encoder hooks. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20201215154243.540115-3-maxime@cerno.tech
2020-12-16drm/vc4: hvs: Align the HVS atomic hooks to the new APIMaxime Ripard
Since the CRTC setup in vc4 is split between the PixelValves/TXP and the HVS, only the PV/TXP atomic hooks were updated in the previous commits, but it makes sense to update the HVS ones too. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20201215154243.540115-2-maxime@cerno.tech
2020-12-16drm/hisilicon: Fix rmmod hibmc_drm failedTian Tao
drm_irq_uninstall should be called before pci_disable_msi, if use devm_drm_irq_install to register the interrupt, the system will call pci_disable_msi first and then call drm_irq_uninstall, which will result in the following callstack. This reverts commit e4401247070a37c2fce62b2773a4eb7757983938. kernel BUG at drivers/pci/msi.c:376! Internal error: Oops - BUG: 0 [#1] SMP CPU: 93 PID: 173814 Comm: rmmod Tainted: pstate: a0400009 (NzCv daif +PAN -UAO -TCO BTYPE=--) pc : free_msi_irqs+0x17c/0x1a0 lr : free_msi_irqs+0x16c/0x1a0 sp : ffff2028157f7bd0 x29: ffff2028157f7bd0 x28: ffff202849edab00 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: ffff0020851da000 x22: ffff0020851da2d8 x21: ffff0020cc829000 x20: 0000000000000000 x19: ffff0020d6714800 x18: 0000000000000010 x17: 0000000000000000 x16: 0000000000000000 x15: ffffffffffffffff x14: ffff2028957f77df x13: ffff2028157f77ed x12: 0000000000000000 x11: 0000000000000040 x10: ffff800011b2f8e0 x9 : ffff800011b2f8d8 x8 : ffff2020203fc458 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff2020203fc430 x4 : ffff2020203fc4a0 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 00000000000002c9 x0 : ffff0020d6719500 Call trace: free_msi_irqs+0x17c/0x1a0 pci_disable_msi+0xe4/0x118 hibmc_unload+0x44/0x80 [hibmc_drm] hibmc_pci_remove+0x2c/0x38 [hibmc_drm] pci_device_remove+0x48/0x108 device_release_driver_internal+0x118/0x1f0 driver_detach+0x6c/0xe0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x60 pci_unregister_driver+0x24/0xd8 hibmc_pci_driver_exit+0x14/0xe768 [hibmc_drm] __arm64_sys_delete_module+0x1fc/0x2d0 el0_svc_common.constprop.3+0xa8/0x188 do_el0_svc+0x80/0xa0 el0_sync_handler+0x8c/0xb0 el0_sync+0x15c/0x180 Code: f940b400 b4ffff00 a903e7b8 f90013b5 (d4210000) ---[ end trace 310d94ee8abef44f ]--- Kernel panic - not syncing: Oops - BUG: Fatal exception v2: update the commit log to indicate the patch that needs to be revert. Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1608034739-699-1-git-send-email-tiantao6@hisilicon.com
2020-12-15drm/ttm: cleanup LRU handling furtherChristian König
We only completely delete the BO from the LRU on destruction. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Link: https://patchwork.freedesktop.org/patch/404618/
2020-12-15drm/ttm: use pin_count more extensivelyChristian König
Check the pin_count instead of the lru list is empty here. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Link: https://patchwork.freedesktop.org/patch/404617/
2020-12-15drm: require a non_NULL drm_crtc.primarySimon Ser
If a CRTC is missing a legacy primary plane pointer, a lot of things will be broken for user-space: fbdev stops working and the entire legacy uAPI stops working. Require all drivers to populate drm_crtc.primary to prevent these issues. Warn if it's NULL. Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201211184634.74534-3-contact@emersion.fr
2020-12-15drm: validate possible_crtcs for primary and cursor planesSimon Ser
If a primary or cursor plane is not compatible with a CRTC it's attached to via the legacy primary/cursor field, things will be broken for legacy user-space. v4: use drm_crtc_mask instead of BIT (Ville) Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201211184634.74534-2-contact@emersion.fr
2020-12-15drm: rework description of primary and cursor planesSimon Ser
The previous wording could be understood by user-space evelopers as "a primary/cursor plane is only compatible with a single CRTC" [1]. Reword the planes description to make it clear the DRM-internal drm_crtc.primary and drm_crtc.cursor planes are for legacy uAPI. [1]: https://github.com/swaywm/wlroots/pull/2333#discussion_r456788057 Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201211184634.74534-1-contact@emersion.fr
2020-12-15drm/omap: Delete useless kfree codeZheng Yongjun
The parameter of kfree function is NULL, so kfree code is useless, delete it. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201214134628.4937-1-zhengyongjun3@huawei.com
2020-12-15drm/omap: dsi: allow DSI commands to be sent earlyTomi Valkeinen
Panel drivers can send DSI commands in panel's prepare(), which happens before the bridge's enable() is called. The OMAP DSI driver currently only sets up the DSI interface at bridge's enable(), so prepare() cannot be used to send DSI commands. This patch fixes the issue by making it possible to enable the DSI interface any time a command is about to be sent. Disabling the interface is be done via delayed work. Clarifications for the delayed disable work and the panel doing DSI transactions: bridge_enable: If the disable callback is called just before bridge_enable takes the dsi_bus_lock, no problem, bridge_enable just enables the interface again. If the callback is ran just after bridge_enable's dsi_bus_unlock, no problem, dsi->video_enabled == true so the callback does nothing. bridge_disable: similar to bridge-enable, the callback won't do anything if video_enabled == true, and after bridge-disable has turned the video and the interface off, there's nothing to do for the callback. omap_dsi_host_detach: this is called when the panel does mipi_dsi_detach(), and we expect the panel to _not_ do any DSI transactions after (or during) mipi_dsi_detatch(), so there are no race conditions. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-85-tomi.valkeinen@ti.com
2020-12-15drm/omap: dsi: fix DCS_CMD_ENABLETomi Valkeinen
We only need to set VC_CTRL:DCS_CMD_ENABLE for command mode panels when the HW has DSI_QUIRK_DCS_CMD_CONFIG_VC quirk. The old code did this right by accident, but now we set DCS_CMD_ENABLE for video mode panels too. Fix this by skipping the set for video mode. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-84-tomi.valkeinen@ti.com
2020-12-15drm/omap: dsi: remove ulps supportTomi Valkeinen
ULPS is a niche power-saving feature which only really affects command mode panels showing a static picture. I know the ULPS code used to work very long time ago, but I could not get it working with the current driver. As the ULPS code is not trivial and includes delayed work (so lots of chances for race issues), and just keeping DSI video and command mode panels working has been challenging enough even without ULPS, lets remove ULPS support. When the DSI driver works reliably for command and video mode displays, someone interested can work on ULPS and add it back if the power saving is substantial enough. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-83-tomi.valkeinen@ti.com
2020-12-15drm/omap: dsi: fix and cleanup ddr_clk_always_onTomi Valkeinen
The driver ignores MIPI_DSI_CLOCK_NON_CONTINUOUS, and always uses non-continuous clock. Fix this by using MIPI_DSI_CLOCK_NON_CONTINUOUS and at the same time, drop ddr_clk_always_on field which seems pretty useless. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-82-tomi.valkeinen@ti.com
2020-12-15drm/omap: dsi: split video mode enable/disable into separate funcTomi Valkeinen
Clean up the code by separating video-mode enable/disable code into functions of their own. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-81-tomi.valkeinen@ti.com
2020-12-15drm/omap: dsi: cleanup initial vc setupTomi Valkeinen
As we now have a fixed setup for VCs (VC0 for video stream, VC1 for commands), we can simplify the VC setup. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-80-tomi.valkeinen@ti.com
2020-12-15drm/omap: dsi: rename dsi_display_* functionsTomi Valkeinen
The function names have evolved to be very confusing, and bunch of them have "display" in them even if the function doesn't deal with display as such (e.g. dsi_display_enable which just enables the DSI interface). Rename them by dropping the "display". Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-79-tomi.valkeinen@ti.com
2020-12-15drm/omap: dsi: display_disable cleanupTomi Valkeinen
We can drop dsi_display_disable() which just calls _dsi_display_disable(), and rename _dsi_display_disable() to dsi_display_disable(). The WARN_ON(!dsi_bus_is_locked(dsi)) in dsi_display_disable is extra and can be dropped, as _dsi_display_disable() has the same WARN_ON(). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-78-tomi.valkeinen@ti.com
2020-12-15drm/omap: dsi: display_enable cleanupTomi Valkeinen
We can drop dsi_display_enable(), which just calls _dsi_display_enable(), and rename _dsi_display_enable() to dsi_display_enable(). The WARN_ON(!dsi_bus_is_locked(dsi)) in dsi_display_enable is extra and can be dropped, as _dsi_display_enable() has the same WARN_ON(). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-77-tomi.valkeinen@ti.com
2020-12-15drm/omap: dsi: move enable/disable to bridge enable/disableTomi Valkeinen
Clean up the code by inlining dsi_enable_video_outputs and dsi_disable_video_outputs functions. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-76-tomi.valkeinen@ti.com
2020-12-15drm/omap: dsi: move structs & defines to dsi.hTomi Valkeinen
Move structs and defines to a private dsi.h header file to make dsi.c a bit easier to navigate. Also move the (now) private structs and defines from omapdss.h to dsi.h. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-75-tomi.valkeinen@ti.com
2020-12-15drm/panel: panel-dsi-cm: drop unneeded includesTomi Valkeinen
Drop unneeded includes. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-74-tomi.valkeinen@ti.com
2020-12-15drm/panel: panel-dsi-cm: add panel database to driverTomi Valkeinen
Add a panel database to the driver instead of reading propertes from DT data. This is similar to panel-simple, and I believe it's more future safe way to handle the panels. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-73-tomi.valkeinen@ti.com
2020-12-15drm/panel: panel-dsi-cm: remove extra 'if'Tomi Valkeinen
We have a useless 'if' in the dsicm_bl_update_status(), a left over from the conversion to DRM model. Drop the if. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-72-tomi.valkeinen@ti.com
2020-12-15drm/omap: dsi: use separate VCs for cmd and videoTomi Valkeinen
For command mode panels we can use a single VC for sending command and video data, even if we have to change the data source for that VC when going from command to video or vice versa. However, with video mode panels we want to keep the pixel data VC enabled, and use another VC for command data, and the commands will get interleaved into the pixel data. This patch makes the driver use VC0 for commands and VC1 for video. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-71-tomi.valkeinen@ti.com
2020-12-15drm/omap: dsi: enable HS before sending the frameTomi Valkeinen
We currently use a single VC for sending commands and pixel data. The LP/HS mode for pixel data is correctly set to HS by accident, as we have set the VC to HS already earlier. However, if we use a different VC for video data, the VC is in LP mode. Fix this by always enabling HS mode before starting a frame update. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-70-tomi.valkeinen@ti.com
2020-12-15drm/omap: dsi: skip dsi_vc_enable_hs when already in correct modeTomi Valkeinen
Simplify and optimize dsi_vc_enable_hs() so that it can be called without checking the current HS/LP mode. Make dsi_vc_enable_hs() return if the VC is already in the correct mode. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-69-tomi.valkeinen@ti.com
2020-12-15drm/omap: dsi: untangle vc & channelTomi Valkeinen
DSI virtual channel and hardware VC blocks have gotten tangled as described in the previous commits. This has not caused any issues, as the value for both is 0, so it happens to work. To fix the issue, change the code to use the correct one of the two. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-68-tomi.valkeinen@ti.com
2020-12-15drm/omap: dsi: pass vc and channel to various functionsTomi Valkeinen
To start fixing the issues related to channels and vcs described in the previous commit, pass vc and/or channel to various functions which will need it do properly handle different DSI channels and VCs. No functional changes. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-67-tomi.valkeinen@ti.com
2020-12-15drm/omap: dsi: rename 'channel' to 'vc'Tomi Valkeinen
The "channel" usage in omap dsi driver is confusing. We have three different "channels": 1) DSI virtual channel ID. This is a number from 0 to 3, included in the packet payload. 2) VC. This is a register block in the DSI IP. There are four of those blocks. A VC is a DSI "pipeline", with defined fifo settings, data source (cpu or dispc), and some other settings. It has no relation to the 1). 3) dispc channel. It's the "pipeline" number dispc uses to send pixel data. The previous patch handled the third case. To start fixing 1) and 2), we first rename all uses of 'channel' to 'vc', as in most of the cases that is the correct thing to use. However, in some places 1) and 2) have gotten mixed up (i.e. the code uses msg->channel when it should use vc), which will be fixed in the following patch. Note that mixing 1) and 2) currently is "fine", as at the moment we only support DSI peripherals with DSI virtual channel 0, and we always use VC0 to send data. So both 1) and 2) are always 0. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-66-tomi.valkeinen@ti.com
2020-12-15drm/omap: dsi: cleanup dispc channel usageTomi Valkeinen
The "channel" usage in omap dsi driver is confusing. As the first step, change "channel" to "dispc_channel" when dealing with the dispc channel. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-65-tomi.valkeinen@ti.com
2020-12-15drm/omap: dsi: drop useless channel checksTomi Valkeinen
A DSI peripheral can have virtual channel ID of 0-3. This should be always the case, and there's no need in the driver to validate the channel. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-64-tomi.valkeinen@ti.com
2020-12-15drm/omap: dsi: simplify VC handlingTomi Valkeinen
The VC handling has gotten quite tangled up. As the first step to clean it up, lets define that we only support a single DSI peripheral (which was really already the case), and we always use VC0 (define VC_DEFAULT 0) register block to send data to the peripheral. We can thus have a single mipi_dsi_device pointer and remove the for-loops which made passes over all the four VCs (just the first one was ever used). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-63-tomi.valkeinen@ti.com
2020-12-15drm/omap: dsi: send nop instead of page & columnTomi Valkeinen
The OMAP DSI command mode panel driver used to send page & column address before each frame update, and this code was moved into the DSI host driver when converting it to the DRM bridge model. However, it's not really required to send the page & column address before each frame. It's also something that doesn't really belong to the DSI host driver, so we should drop the code. That said, frame updates break if we don't send _something_ between the frames. A NOP command does the trick. It is not clear if this behavior is as expected from a DSI command mode frame transfer, or is it a feature/issue with OMAP DSI driver, or a feature/issue in the command mode panel used. Most likely this is related to the following from the DSI spec: "To enable PHY synchronization the host processor should periodically end HS transmission and drive the Data Lanes to the LP state. This transition should take place at least once per frame." Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-62-tomi.valkeinen@ti.com
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-09-22 01:49:33 +0000