summaryrefslogtreecommitdiff
path: root/include/drm/bridge
AgeCommit message (Collapse)Author
2019-02-01drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling supportNeil Armstrong
Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS Scrambling when supported or mandatory. This patch also adds an helper to setup the control bit to support the high TMDS Bit Period/TMDS Clock-Period Ratio as required with TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes. These changes were based on work done by Huicong Xu <xhc@rock-chips.com> and Nickey Yang <nickey.yang@rock-chips.com> to support HDMI2.0 modes on the Rockchip 4.4 BSP kernel at [1] [1] https://github.com/rockchip-linux/kernel/tree/release-4.4 Cc: Nickey Yang <nickey.yang@rock-chips.com> Cc: Huicong Xu <xhc@rock-chips.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1549022873-40549-2-git-send-email-narmstrong@baylibre.com
2019-01-18Merge tag 'drm-misc-next-2019-01-16' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 5.1: UAPI Changes: - New fourcc identifier for ARM Framebuffer Compression v1.3 Cross-subsystem Changes: Core Changes: - Reorganisation of drm_device and drm_framebuffer headers - Cleanup of the drmP inclusion - Fix leaks in the fb-helpers - Allow for depth different from bpp in fb-helper fbdev emulation - Remove drm_mode_object from drm_display_mode Driver Changes: - Add reflection properties to rockchip - a bunch of fixes for virtio - a bunch of fixes for dp_mst and drivers using it, and introduction of a new refcounting scheme - Convertion of bochs to atomic and generic fbdev emulation - Allow meson to remove the firmware framebuffers [airlied: patch rcar-du to add drm_modes.h] Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190116200428.u2n4jbk4mzza7n6e@flea
2019-01-14drm: bridge: Constify mode arguments to bridge .mode_set() operationLaurent Pinchart
The mode and ajusted_mode passed to the bridge .mode_set() operation should never be modified by the bridge (and are not in any of the existing bridge drivers). Make them const to make this clear. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2019-01-09drm: remove include of drmP.h from bridge/dw_hdmi.hSam Ravnborg
drmP.h is an relic from the days when there was a single header file. To enable the removal of drmP.h from all users drop include of drmP.h from bridge/dw_hdmi.h. A few files relied on the file included in drmP.h - add explicit include statements or forward declarations to these files. Build tested with arm and x86. v2: - prefer forward declarations when possible (Laurent Pinchart) - sort include files (Laurent Pinchart) Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Archit Taneja <architt@codeaurora.org> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190108192939.15255-7-sam@ravnborg.org
2018-10-30drm/bridge/synopsys: dsi: add dual-dsi supportNickey Yang
Allow to also drive a slave dw-mipi-dsi controller in a dual-dsi setup. This will require additional implementation-specific code to look up the slave instance and do specific setup. Also will probably need code in the specific crtcs as dual-dsi does not equal two separate dsi outputs. To activate, the implementation-specific code should set the slave using dw_mipi_dsi_set_slave() before calling __dw_mipi_dsi_bind(). v2: - expect real interface number of lanes - keep links to both master and slave v3: - remove unneeded separate variables - remove unneeded second slave settings - disable slave before master - lane-sum calculation comments Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Philippe Cornu <philippe.cornu@st.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181001123845.11818-7-heiko@sntech.de
2018-10-30drm/bridge/synopsys: dsi: add ability to have glue-specific attach and detachHeiko Stuebner
With the regular means of adding the dsi-component in probe it creates a race condition with the panel probing, as the panel device only gets created after the dsi-bus got created. When the panel-driver is build as a module it currently fails hard as the panel cannot be probed directly: dw_mipi_dsi_bind() __dw_mipi_dsi_probe() creates dsi bus creates panel device triggers panel module load panel not probed (module not loaded or panel probe slow) drm_bridge_attach fails with -EINVAL due to empty panel_bridge Additionally the panel probing can run concurrently with dsi bringup making it possible that the panel can already be found but dsi-attach hasn't finished running. To solve that cleanly we may want to only create the component after the panel has finished probing, by calling component_add from the host-attach dsi callback. As that is specific to glue drivers, add a new struct for host_ops so that glue drivers can tell the bridge to call specific functions after the common host-attach and before the common host-detach run. Suggested-by: Andrzej Hajda <a.hajda@samsung.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181001123845.11818-4-heiko@sntech.de
2018-10-30drm/bridge/synopsys: dsi: don't call __dw_mipi_dsi_probe from dw_mipi_dsi_bindHeiko Stuebner
__dw_mipi_dsi_probe() does all the grabbing of resources and does it using devm-helpers. So this is happening on each try of master bringup possibly slowing down things a lot. Drivers using the component framework may instead want to call dw_mipi_dsi_probe separately in their probe function to setup resources early. That way the dsi bus also gets created earlier and also not recreated on each bind-try, so that attached panels can load their modules and be probed way before the bridge-attach in the bind call. So drop the call to __dw_mipi_dsi_probe and modify the function to take a struct dw_mipi_dsi instead of the platform-device. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181001123845.11818-3-heiko@sntech.de
2018-09-28drm/bridge: dw-hdmi: allow forcing vendor phy-typeHeiko Stuebner
In some IP implementations the reading of the phy-type may be broken. One example are the Rockchip rk3228 and rk3328 socs that use a separate vendor-type phy from Innosilicon but still report the HDMI20_TX type. So allow the glue driver to force the vendor-phy for these cases. In the future it may be necessary to allow forcing other types, but for now we'll keep it simply to the case actually seen in the wild. changes in v3: - only allow forcing vendor type, as suggested by Laurent Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Reviewed-by: Zheng Yang <zhengyang@rock-chips.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180912124740.20343-2-heiko@sntech.de Link: https://patchwork.freedesktop.org/patch/msgid/20180912124740.20343-3-heiko@sntech.de
2018-06-06Merge tag 'drm-next-2018-06-06-1' of git://anongit.freedesktop.org/drm/drmLinus Torvalds
Pull drm updates from Dave Airlie: "This starts to support NVIDIA volta hardware with nouveau, and adds amdgpu support for the GPU in the Kabylake-G (the intel + radeon single package chip), along with some initial Intel icelake enabling. Summary: New Drivers: - v3d - driver for broadcom V3D V3.x+ hardware - xen-front - XEN PV display frontend core: - handle zpos normalization in the core - stop looking at legacy pointers in atomic paths - improved scheduler documentation - improved aspect ratio validation - aspect ratio support for 64:27 and 256:135 - drop unused control node code. i915: - Icelake (ICL) enabling - GuC/HuC refactoring - PSR/PSR2 enabling and fixes - DPLL management refactoring - DP MST fixes - NV12 enabling - HDCP improvements - GEM/Execlist/reset improvements - GVT improvements - stolen memory first 4k fix amdgpu: - Vega 20 support - VEGAM support (Kabylake-G) - preOS scanout buffer reservation - power management gfxoff support for raven - SR-IOV fixes - Vega10 power profiles and clock voltage control - scatter/gather display support on CZ/ST amdkfd: - GFX9 dGPU support - userptr memory mapping nouveau: - major refactoring for Volta GV100 support tda998x: - HDMI i2c CEC support etnaviv: - removed unused logging code - license text cleanups - MMU handling improvements - timeout fence fix for 50 days uptime tegra: - IOMMU support in gr2d/gr3d drivers - zpos support vc4: - syncobj support - CTM, plane alpha and async cursor support analogix_dp: - HPD and aux chan fixes sun4i: - MIPI DSI support tilcdc: - clock divider fixes for OMAP-l138 LCDK board rcar-du: - R8A77965 support - dma-buf fences fixes - hardware indexed crtc/du group handling - generic zplane property support atmel-hclcdc: - generic zplane property support mediatek: - use generic video mode function exynos: - S5PV210 FIMD variant support - IPP v2 framework - more HW overlays support" * tag 'drm-next-2018-06-06-1' of git://anongit.freedesktop.org/drm/drm: (1286 commits) drm/amdgpu: fix 32-bit build warning drm/exynos: fimc: signedness bug in fimc_setup_clocks() drm/exynos: scaler: fix static checker warning drm/amdgpu: Use dev_info() to report amdkfd is not supported for this ASIC drm/amd/display: Remove use of division operator for long longs drm/amdgpu: Update GFX info structure to match what vega20 used drm/amdgpu/pp: remove duplicate assignment drm/sched: add rcu_barrier after entity fini drm/amdgpu: move VM BOs on LRU again drm/amdgpu: consistenly use VM moved flag drm/amdgpu: kmap PDs/PTs in amdgpu_vm_update_directories drm/amdgpu: further optimize amdgpu_vm_handle_moved drm/amdgpu: cleanup amdgpu_vm_validate_pt_bos v2 drm/amdgpu: rework VM state machine lock handling v2 drm/amdgpu: Add runtime VCN PG support drm/amdgpu: Enable VCN static PG by default on RV drm/amdgpu: Add VCN static PG support on RV drm/amdgpu: Enable VCN CG by default on RV drm/amdgpu: Add static CG control for VCN on RV drm/exynos: Fix default value for zpos plane property ...
2018-05-30drm/bridge/synopsys: dw-hdmi: fix dw_hdmi_setup_rx_senseNeil Armstrong
The dw_hdmi_setup_rx_sense exported function should not use struct device to recover the dw-hdmi context using drvdata, but take struct dw_hdmi directly like other exported functions. This caused a regression using Meson DRM on S905X since v4.17-rc1 : Internal error: Oops: 96000007 [#1] PREEMPT SMP [...] CPU: 0 PID: 124 Comm: irq/32-dw_hdmi_ Not tainted 4.17.0-rc7 #2 Hardware name: Libre Technology CC (DT) [...] pc : osq_lock+0x54/0x188 lr : __mutex_lock.isra.0+0x74/0x530 [...] Process irq/32-dw_hdmi_ (pid: 124, stack limit = 0x00000000adf418cb) Call trace: osq_lock+0x54/0x188 __mutex_lock_slowpath+0x10/0x18 mutex_lock+0x30/0x38 __dw_hdmi_setup_rx_sense+0x28/0x98 dw_hdmi_setup_rx_sense+0x10/0x18 dw_hdmi_top_thread_irq+0x2c/0x50 irq_thread_fn+0x28/0x68 irq_thread+0x10c/0x1a0 kthread+0x128/0x130 ret_from_fork+0x10/0x18 Code: 34000964 d00050a2 51000484 9135c042 (f864d844) ---[ end trace 945641e1fbbc07da ]--- note: irq/32-dw_hdmi_[124] exited with preempt_count 1 genirq: exiting task "irq/32-dw_hdmi_" (124) is an active IRQ thread (irq 32) Fixes: eea034af90c6 ("drm/bridge/synopsys: dw-hdmi: don't clobber drvdata") Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Tested-by: Koen Kooi <koen@dominion.thruhere.net> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1527673438-20643-1-git-send-email-narmstrong@baylibre.com
2018-04-24drm/bridge: analogix_dp: Split the platform-specific poweron in two partsDouglas Anderson
Some of the platform-specific stuff in rockchip_dp_poweron() needs to happen before the generic code. Some needs to happen after. Let's split the callback in two. Specifically we can't start doing PSR work until _after_ the whole controller is up, so don't set the enable until the end. Cc: Kristian H. Kristensen <hoegsberg@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> [seanpaul added exynos change] Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-23-enric.balletbo@collabora.com
2018-03-14drm/bridge: analogix_dp: Don't change psr while bridge is disabledzain wang
There is a race between AUX CH bring-up and enabling bridge which will cause link training to fail. To avoid hitting it, don't change psr state while enabling the bridge. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by: zain wang <wzz@rock-chips.com> Signed-off-by: Caesar Wang <wxt@rock-chips.com> [seanpaul fixed up the commit message a bit and renamed *_supported to *_enabled] Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180309222327.18689-4-enric.balletbo@collabora.com
2018-03-07drm/bridge: analogix_dp: Don't create useless connectorsMarek Szyprowski
If there is another bridge after analogix_dp, then the connector object should not be created. This fixes following timeouts on Exynos5420-based Chromebook2 Peach-PIT board during boot: exynos-dp 145b0000.dp-controller: AUX CH cmd reply timeout! exynos-dp 145b0000.dp-controller: AUX CH enable timeout! exynos-dp 145b0000.dp-controller: AUX CH enable timeout! exynos-dp 145b0000.dp-controller: AUX CH enable timeout! exynos-dp 145b0000.dp-controller: AUX CH enable timeout! Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180305085741.18896-4-m.szyprowski@samsung.com
2018-03-01drm/bridge: analogix: Do not use device's drvdataJeffy Chen
The driver that instantiates the bridge should own the drvdata, as all driver model callbacks (probe, remove, shutdown, PM ops, etc.) are also owned by its driver struct. Moreover, storing two different pointer types in driver data depending on driver initialization status is barely a good practice and in fact has led to many bugs in this driver. Let's clean up this mess and change Analogix entry points to simply accept some opaque struct pointer, adjusting their users at the same time to avoid breaking the compilation. Signed-off-by: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Acked-by: Jingoo Han <jingoohan1@gmail.com> Acked-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180110162348.22765-2-thierry.escande@collabora.com
2018-02-16drm/bridge/synopsys: dw-hdmi: don't clobber drvdataJernej Skrabec
dw_hdmi shouldn't set drvdata since some drivers might need to store it's own data there. Rework dw_hdmi in a way to return struct dw_hdmi instead to store it in drvdata. This way drivers are responsible to store and pass structure when needed. Idea was taken from the following commit: 8242ecbd597d ("drm/bridge/synopsys: stop clobbering drvdata") Cc: p.zabel@pengutronix.de Cc: Laurent.pinchart@ideasonboard.com Cc: hjc@rock-chips.com Acked-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214200906.31509-6-jernej.skrabec@siol.net
2018-02-16drm/bridge/synopsys: dw-hdmi: Export some PHY related functionsJernej Skrabec
Parts of PHY code could be useful also for custom PHYs. For example, Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY with few additional memory mapped registers, so most of the Synopsys PHY related code could be reused. Functions exported here are actually not specific to Synopsys PHYs but to DWC HDMI controller PHY interface. This means that even if the PHY is completely custom, i.e. not designed by Synopsys, exported functions can be useful. Reviewed-by: Archit Taneja <architt@codeaurora.org> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214200906.31509-5-jernej.skrabec@siol.net
2018-01-09drm/bridge/synopsys: stop clobbering drvdataBrian Norris
Bridge drivers/helpers shouldn't be clobbering the drvdata, since a parent driver might need to own this. Instead, let's return our 'dw_mipi_dsi' object and have callers pass that back to us for removal. Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Archit Taneja <architt@codeaurora.org> Acked-by: Philippe Cornu <philippe.cornu@st.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171128010538.119114-1-briannorris@chromium.org
2017-10-11drm/bridge/sii8620: add remote control supportMaciej Purski
MHL specification defines Remote Control Protocol(RCP) to send input events between MHL devices. The driver now recognizes RCP messages and reacts to them by reporting key events to input subsystem, allowing a user to control a device using TV remote control. Signed-off-by: Maciej Purski <m.purski@samsung.com> Acked-by: Sean Young <sean@mess.org> Acked-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1503565087-19730-1-git-send-email-m.purski@samsung.com
2017-07-26Merge airlied/drm-next into drm-misc-nextDaniel Vetter
I need this to be able to apply the deferred fbdev setup patches, I need the relevant prep work that landed through the drm-intel tree. Also squash in conflict fixup from Laurent Pinchart. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-18drm/bridge/synopsys: Add MIPI DSI host controller bridgePhilippe CORNU
Add a Synopsys Designware MIPI DSI host DRM bridge driver, based on the Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs. Signed-off-by: Philippe CORNU <philippe.cornu@st.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/1500277223-29553-5-git-send-email-philippe.cornu@st.com
2017-06-26DRM: Fix an incorrectly formatted tableJonathan Corbet
The "supported input formats" table in dw_hdmi.h was incorrectly formatted, using "+" signs where "|" needs to be. That, in turn, causes the PDF build to fail. Fixes: def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings") Signed-off-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170623140013.0703107a@lwn.net
2017-06-05drm/bridge/synopsys: dw-hdmi: Use bridge->mode_valid() callbackJose Abreu
Now that we have a callback to check if bridge supports a given mode we can use it in Synopsys Designware HDMI bridge so that we restrict the number of probbed modes to the ones we can actually display. Also, there is no need to use mode_fixup() callback as mode_valid() will handle the mode validation. NOTE: I also had to change the pdata declaration of mode_valid custom callback so that the passed modes are const. I also changed in the platforms I found. Not even compiled it though. Signed-off-by: Jose Abreu <joabreu@synopsys.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Philipp Zabel <p.zabel@pengutronix.de> Cc: Carlos Palminha <palminha@synopsys.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Archit Taneja <architt@codeaurora.org> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: David Airlie <airlied@linux.ie> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Carlo Caione <carlo@caione.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/3d8d449e4d13d2535fa292c75f5fa931de4a4fa8.1495720737.git.joabreu@synopsys.com
2017-04-04drm: bridge: dw-hdmi: Move HPD handling to PHY operationsNeil Armstrong
The HDMI TX controller support HPD and RXSENSE signaling from the PHY via it's STAT0 PHY interface, but some vendor PHYs can manage these signals independently from the controller, thus these STAT0 handling should be moved to PHY specific operations and become optional. The existing STAT0 HPD and RXSENSE handling code is refactored into a supplementaty set of default PHY operations that are used automatically when the platform glue doesn't provide its own operations. Reviewed-by: Jose Abreu <joabreu@synopsys.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: http://patchwork.freedesktop.org/patch/msgid/1491309119-24220-2-git-send-email-narmstrong@baylibre.com
2017-04-04drm: bridge: dw-hdmi: Switch to V4L bus format and encodingsNeil Armstrong
Switch code to use the newly introduced V4L bus formats IDs instead of custom defines. Also use the V4L encoding defines. Some display pipelines can only provide non-RBG input pixels to the HDMI TX Controller, this patch takes the pixel format from the plat_data if provided. Reviewed-by: Jose Abreu <joabreu@synopsys.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
2017-03-10drm: bridge: dw-hdmi: Switch to regmap for register accessNeil Armstrong
The Synopsys Designware HDMI TX Controller does not enforce register access on platforms instanciating it. The current driver supports two different types of memory-mapped flat register access, but in order to support the Amlogic Meson SoCs integration, and provide a more generic way to handle all sorts of register mapping, switch the register access to use the regmap infrastructure. In the case of registers that are not flat memory-mapped or do not conform to the current driver implementation, a regmap struct can be given in the plat_data and be used at probe or bind. Since the AHB audio driver is only available with direct memory access, only allow the I2S audio driver to be registered is directly memory-mapped. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-10-laurent.pinchart+renesas@ideasonboard.com
2017-03-10drm: bridge: dw-hdmi: Remove device type from platform dataKieran Bingham
The device type isn't used anymore now that workarounds and PHY-specific operations are performed based on version information read at runtime. Remove it. Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-9-laurent.pinchart+renesas@ideasonboard.com
2017-03-10drm: bridge: dw-hdmi: Add support for custom PHY configurationKieran Bingham
The DWC HDMI TX controller interfaces with a companion PHY. While Synopsys provides multiple standard PHYs, SoC vendors can also integrate a custom PHY. Modularize PHY configuration to support vendor PHYs through platform data. The existing PHY configuration code was originally written to support the DWC HDMI 3D TX PHY, and seems to be compatible with the DWC MLP PHY. The HDMI 2.0 PHY will require a separate configuration function. Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-8-laurent.pinchart+renesas@ideasonboard.com
2017-03-10drm: bridge: dw-hdmi: Create PHY operationsLaurent Pinchart
The HDMI TX controller support different PHYs whose programming interface can vary significantly, especially with vendor PHYs that are not provided by Synopsys. To support them, create a PHY operation structure that can be provided by the platform glue layer. The existing PHY handling code (limited to Synopsys PHY support) is refactored into a set of default PHY operations that are used automatically when the platform glue doesn't provide its own operations. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170305233615.11993-1-laurent.pinchart+renesas@ideasonboard.com
2017-03-06drm/bridge: analogix_dp: add helpers for capture of frame CRCsTomeu Vizoso
Add two simple functions that just take the drm_dp_aux from our struct and calls the corresponding DP helpers with it. v6: Pass to the DP helper the drm_crtc of the current connector (Sean Paul) Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303133936.14964-4-tomeu.vizoso@collabora.com
2017-02-02drm/bridge/mhl: add MHL3 infoframe related definitionsAndrzej Hajda
MHL3 protocol uses vendor specific infoframes to transmit additional information to the sink. This patch adds definitions of structures and constants used to create such frames. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1485935272-17337-20-git-send-email-a.hajda@samsung.com
2017-02-02drm/bridge/mhl: add write burst related definitionsAndrzej Hajda
Burst transmissions are required in MHL3 modes. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1485935272-17337-7-git-send-email-a.hajda@samsung.com
2017-01-18drm: bridge: dw-hdmi: Detect PHY type at runtimeLaurent Pinchart
Detect the PHY type and use it to handle the PHY type-specific SVSRET signal. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170117082910.27023-17-laurent.pinchart+renesas@ideasonboard.com
2017-01-18drm: bridge: dw-hdmi: Implement DRM bridge registrationLaurent Pinchart
As an option for drivers not based on the component framework, register the bridge with the DRM core with the DRM bridge API. Existing drivers based on dw_hdmi_bind() and dw_hdmi_unbind() are not affected as those functions are preserved with their current behaviour. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170117082910.27023-11-laurent.pinchart+renesas@ideasonboard.com
2017-01-18drm: bridge: dw-hdmi: Move IRQ and IO resource allocation to common codeLaurent Pinchart
There's no need to duplicate identical code in multiple drivers (two at the moment, one more to come soon). Move it to the dw-hdmi core where it can be shared. If resource allocation ever becomes device-specific later we'll always have the option of splitting it out again. While it at pass the platform device to the bind function to avoid having to cast struct device to struct platform_device. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170117082910.27023-8-laurent.pinchart+renesas@ideasonboard.com
2017-01-18drm: bridge: dw-hdmi: Remove unneeded arguments to bind/unbind functionsLaurent Pinchart
The master argument isn't used. The data argument, a void pointer, is used by the bind function only where it's cast to a drm_device pointer, which can easily be obtained from the encoder argument instead. Remove them. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170117082910.27023-3-laurent.pinchart+renesas@ideasonboard.com
2016-10-26video: add header file for Mobile High-Definition Link (MHL) interfaceAndrzej Hajda
This header adds definitions specific to MHL protocol. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1475823762-16237-2-git-send-email-a.hajda@samsung.com
2016-10-04drm/bridge: analogix_dp: Add analogix_dp_psr_supportedTomeu Vizoso
So users know whether PSR should be enabled or not. Cc: Yakir Yang <ykk@rock-chips.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1474639600-30090-1-git-send-email-tomeu.vizoso@collabora.com
2016-08-23drm/bridge: analogix_dp: add the PSR function supportYakir Yang
The full name of PSR is Panel Self Refresh, panel device could refresh itself with the hardware framebuffer in panel, this would make lots of sense to save the power consumption. This patch have exported two symbols for platform driver to implement the PSR function in hardware side: - analogix_dp_active_psr() - analogix_dp_inactive_psr() Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Yakir Yang <ykk@rock-chips.com> Signed-off-by: Sean Paul <seanpaul@chromium.org>
2016-07-05drm/bridge: analogix_dp: passing the connector as an argument in .get_modes()Yakir Yang
It's better to pass the connector to platform driver in .get_modes() callback, just like what the .get_modes() helper function designed. Signed-off-by: Yakir Yang <ykk@rock-chips.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Tomasz Figa <tomasz.figa@chromium.com>
2016-07-05drm/rockchip: analogix_dp: add rk3399 eDP supportYakir Yang
RK3399 and RK3288 shared the same eDP IP controller, only some light difference with VOP configure and GRF configure. Signed-off-by: Yakir Yang <ykk@rock-chips.com> Acked-by: Mark Yao <mark.yao@rock-chips.com> Reviewed-by: Tomasz Figa <tomasz.figa@chromium.com> Reviewed-by: Sean Paul <seanpaul@chromium.org>
2016-07-05drm/bridge: analogix_dp: some rockchip chips need to flip REF_CLK bit settingYakir Yang
As vendor document indicate, when REF_CLK bit set 0, then DP phy's REF_CLK should switch to 24M source clock. But due to IC PHY layout mistaken, some chips need to flip this bit(like RK3288), and unfortunately they didn't indicate in the DP version register. That's why we have to make this little hack. Signed-off-by: Yakir Yang <ykk@rock-chips.com> Reviewed-by: Tomasz Figa <tomasz.figa@chromium.com> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> Reviewed-by: Sean Paul <seanpaul@chromium.org>
2016-04-05drm: rockchip: dp: add rockchip platform dp driverYakir Yang
Rockchip have three clocks for dp controller, we leave pclk_edp to analogix_dp driver control, and keep the sclk_edp_24m and sclk_edp in platform driver. Acked-by: Mark Yao <mark.yao@rock-chips.com> Tested-by: Caesar Wang <wxt@rock-chips.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Yakir Yang <ykk@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2016-04-05drm: bridge: analogix/dp: split exynos dp driver to bridge directoryYakir Yang
Split the dp core driver from exynos directory to bridge directory, and rename the core driver to analogix_dp_*, rename the platform code to exynos_dp. Beside the new analogix_dp driver would export six hooks. "analogix_dp_bind()" and "analogix_dp_unbind()" "analogix_dp_suspned()" and "analogix_dp_resume()" "analogix_dp_detect()" and "analogix_dp_get_modes()" The bind/unbind symbols is used for analogix platform driver to connect with analogix_dp core driver. And the detect/get_modes is used for analogix platform driver to init the connector. They reason why connector need register in helper driver is rockchip drm haven't implement the atomic API, but Exynos drm have implement it, so there would need two different connector helper functions, that's why we leave the connector register in helper driver. Acked-by: Inki Dae <inki.dae@samsung.com> Tested-by: Caesar Wang <wxt@rock-chips.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Yakir Yang <ykk@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2015-08-27Merge branch 'drm-dwhdmi-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-arm ↵Dave Airlie
into drm-next Here are some development updates for the Synopsis Designware HDMI driver, which clean up some of the code, and start preparing to add audio support to the driver. This series of patches are based on a couple of dependent commits from the ALSA tree. Briefly, the updates are: - move comments which should have moved with the phy values to the IMX part of the driver. - clean up the phy configuration: to all lookups before starting to program the phy. - clean up the HDMI clock regenerator code - use the drm_hdmi_avi_infoframe_from_display_mode() helper which allows the code to be subsequently simplified - remove the unused 'regmap' pointer in struct dw_hdmi - use the bridge drm device rather than the connector (we're the bridge code) - remove private hsync/vsync/interlaced flags, getting them from the DRM mode structure instead. - implement interface functions to support audio - setting the audio sample rate, and enabling the audio clocks. - removal of broken pixel repetition support - cleanup DVI vs HDMI sink handling - enable audio only if connected device supports audio - avoid double-enabling bridge in the sink path (once in mode_set, and again in commit) - rename mis-named dw_hdmi_phy_enable_power() - fix bridge enable/disable handing, so a plug-in event doesn't reconfigure the bridge if DRM has disabled the output - fix from Vladimir Zapolskiy for the I2CM_ADDRESS macro name These are primerily preparitory patches for the AHB audio driver and the I2S audio driver (from Rockchip) for this IP. * 'drm-dwhdmi-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-arm: drm: bridge/dw_hdmi: fix register I2CM_ADDRESS register name drm: bridge/dw_hdmi: fix phy enable/disable handling drm: bridge/dw_hdmi: rename dw_hdmi_phy_enable_power() drm: bridge/dw_hdmi: avoid enabling interface in mode_set drm: bridge/dw_hdmi: enable audio only if sink supports audio drm: bridge/dw_hdmi: clean up HDMI vs DVI mode handling drm: bridge/dw_hdmi: don't support any pixel doubled modes drm: bridge/dw_hdmi: remove pixel repetition setting for all VICs drm: bridge/dw_hdmi: introduce interfaces to enable and disable audio drm: bridge/dw_hdmi: introduce interface to setting sample rate drm: bridge/dw_hdmi: remove mhsyncpolarity/mvsyncpolarity/minterlaced drm: bridge/dw_hdmi: use our own drm_device drm: bridge/dw_hdmi: remove unused 'regmap' struct member drm: bridge/dw_hdmi: simplify hdmi_config_AVI() a little drm: bridge/dw_hdmi: use drm_hdmi_avi_infoframe_from_display_mode() drm: bridge/dw_hdmi: clean up hdmi_set_clk_regenerator() drm: bridge/dw_hdmi: clean up phy configuration drm: imx/dw_hdmi: move phy comments drm/edid: add function to help find SADs
2015-08-18drm: bridge/dw_hdmi: introduce interfaces to enable and disable audioRussell King
iMX6 devices suffer from an errata (ERR005174) where the audio FIFO can be emptied while it is partially full, resulting in misalignment of the audio samples. To prevent this, the errata workaround recommends writing N as zero until the audio FIFO has been loaded by DMA. Writing N=0 prevents the HDMI bridge from reading from the audio FIFO, effectively disabling audio. This means we need to provide the audio driver with a pair of functions to enable/disable audio. These are dw_hdmi_audio_enable() and dw_hdmi_audio_disable(). A spinlock is introduced to ensure that setting the CTS/N values can't race, ensuring that the audio driver calling the enable/disable functions (which are called in an atomic context) can't race with a modeset. Tested-by: Yakir Yang <ykk@rock-chips.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-08-18drm: bridge/dw_hdmi: introduce interface to setting sample rateRussell King
Introduce dw_hdmi_set_sample_rate(), which allows us to configure the audio sample rate, setting the CTS/N values appropriately. Tested-by: Yakir Yang <ykk@rock-chips.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-06-05drm/bridge: Remove stale ptn3460.h includeThierry Reding
This header file declares prototypes of functions that are no longer used. Remove this file and all references to it. Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-04-01drm: bridge/dw_hdmi: separate VLEVCTRL settting into platform driverYakir Yang
Because of iMX6 & Rockchip have differnet mpll config parameter, the VLEVCTRL parameter would be different. In this case we should separate VLEVCTRL setting from the common dw_hdmi driver, config this parameter in platform driver(dw_hdmi-imx and dw_hdmi-rockchip) Signed-off-by: Yakir Yang <ykk@rock-chips.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-01-28drm/bridge: make bridge registration independent of drm flowAjay Kumar
Currently, third party bridge drivers(ptn3460) are dependent on the corresponding encoder driver init, since bridge driver needs a drm_device pointer to finish drm initializations. The encoder driver passes the drm_device pointer to the bridge driver. Because of this dependency, third party drivers like ptn3460 doesn't adhere to the driver model. In this patch, we reframe the bridge registration framework so that bridge initialization is split into 2 steps, and bridge registration happens independent of drm flow: --Step 1: gather all the bridge settings independent of drm and add the bridge onto a global list of bridges. --Step 2: when the encoder driver is probed, call drm_bridge_attach for the corresponding bridge so that the bridge receives drm_device pointer and continues with connector and other drm initializations. The old set of bridge helpers are removed, and a set of new helpers are added to accomplish the 2 step initialization. The bridge devices register themselves onto global list of bridges when they get probed by calling "drm_bridge_add". The parent encoder driver waits till the bridge is available in the lookup table(by calling "of_drm_find_bridge") and then continues with its initialization. The encoder driver should also call "drm_bridge_attach" to pass on the drm_device to the bridge object. drm_bridge_attach inturn calls "bridge->funcs->attach" so that bridge can continue with drm related initializations. Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com> Acked-by: Inki Dae <inki.dae@samsung.com> Tested-by: Rahul Sharma <rahul.sharma@samsung.com> Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Tested-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Tested-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk> Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-01-07drm: bridge/dw_hdmi: add rockchip rk3288 supportAndy Yan
Rockchip RK3288 hdmi is compatible with dw_hdmi Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Tested-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>