kernel/linux.git/drivers/gpu/drm/bridge/synopsys, branch v4.12.12

drm: dw-hdmi: Fix compilation breakage by selecting REGMAP_MMIO

2017-06-12T03:35:04+00:00

The dw-hdmi driver switched to regmap-mmio, but lacks the dependency in Kconfig. This can result in compilation breakages. Fix it by selecting REGMAP_MMIO. Fixes: 80e2f97968b5 ("drm: bridge: dw-hdmi: Switch to regmap for register access") Reported-by: kbuild test robot Signed-off-by: Laurent Pinchart Signed-off-by: Archit Taneja Link: http://patchwork.freedesktop.org/patch/msgid/20170610085943.15788-1-laurent.pinchart+renesas@ideasonboard.com

drm: dw-hdmi: Implement the mode_fixup drm helper

2017-04-10T09:23:10+00:00

This helper is supposed to validate or reject the modeline before it applied by the mode setting. Currently this function has been dropped, it was previously set to a dummy function that always returned true. For both cases, this means that userspace can ask for a bad modeline that will be always accepted. On some platforms, like Rockchip, the drm dw_hdmi-rockchip variant driver already implements the atomic_check drm helper, so mode_fixup cannot be handled and implemented there (as drm_atomic_helper relies on either atomic_check or mode_fixup). This commit implements this helper. It only checks that this mode is correct from the connector point of view. Acked-by: Daniel Vetter Signed-off-by: Romain Perier Signed-off-by: Archit Taneja Link: http://patchwork.freedesktop.org/patch/msgid/20170407121743.4142-1-romain.perier@collabora.com

drm: bridge: dw-hdmi: fix input format/encoding from plat_data

2017-04-07T09:06:53+00:00

The plat_data->input_bus_format and plat_data->input_bus_encoding are unsigned long and are always >=0, but the value 0 was still considered as RGB888 for input_bus_format and default color space for input_bus_encoding in the reworked code. This patch changes the if statement check for a non-zero value to either use the default input bus_format and/or bus_encoding for a zero value and the provided bus_format and/or bus_encoding for a non zero value. Thanks to Dan Carpenter for his bug report at [1]. Tested on Amlogic P230 (with CSC enabled for YUV444 to RGB) and Rockchip RK3288 ACT8846 EVB Board (no CSC involved, direct RGB passthrough). [1] http://lkml.kernel.org/r/20170406052120.GA26578@mwanda Cc: Dan Carpenter Fixes: def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings") Signed-off-by: Neil Armstrong Reviewed-by: Archit Taneja [narmstrong@baylibre.com: reworded commit message and added Fixes tag] Link: http://patchwork.freedesktop.org/patch/msgid/1491471244-24989-1-git-send-email-narmstrong@baylibre.com

drm: bridge: dw-hdmi: Add a missing break statement

2017-04-06T08:44:34+00:00

There was supposed to be a break before the next case statement. Fixes: def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings") Signed-off-by: Dan Carpenter Acked-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: http://patchwork.freedesktop.org/patch/msgid/20170406052132.GA26605@mwanda

drm: bridge: dw-hdmi: remove unused hdmi_bus_fmt_is_yuv420

2017-04-06T08:44:25+00:00

Remove usused yet hdmi_bus_fmt_is_yuv420 function. Fixes: def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings") Signed-off-by: Neil Armstrong Acked-by: Laurent Pinchart Link: http://patchwork.freedesktop.org/patch/msgid/1491377579-9353-1-git-send-email-narmstrong@baylibre.com

drm: bridge: dw-hdmi: Move HPD handling to PHY operations

2017-04-04T15:48:21+00:00

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 Reviewed-by: Archit Taneja Reviewed-by: Laurent Pinchart Signed-off-by: Neil Armstrong Link: http://patchwork.freedesktop.org/patch/msgid/1491309119-24220-2-git-send-email-narmstrong@baylibre.com

drm: bridge: dw-hdmi: Switch to V4L bus format and encodings

2017-04-04T15:48:21+00:00

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 Reviewed-by: Archit Taneja Reviewed-by: Laurent Pinchart Signed-off-by: Neil Armstrong

drm: bridge: dw-hdmi: Extract PHY interrupt setup to a function

2017-04-04T15:48:21+00:00

In preparation for adding PHY operations to handle RX SENSE and HPD, group all the PHY interrupt setup code in a single location and extract it to a separate function. Signed-off-by: Laurent Pinchart Reviewed-by: Jose Abreu [narmstrong: renamed dw_hdmi_fb_registered to dw_hdmi_setup_i2c] Reviewed-by: Archit Taneja Signed-off-by: Neil Armstrong

drm: dw_hdmi: Don't rely on the status of the bridge for updating HPD

2017-03-27T06:20:48+00:00

Currently, the irq handler that monitors changes for HPD and RX_SENSE relies on the status of the bridge for updating the status of the HPD. The update is done only when the bridge is enabled. However, on Rockchip platforms we have found use cases where it could be a problem. When HDMI is being used, turning off/on the screen or unplugging/re-plugging the cable, the following simplified code path will happen: - dw_hdmi_irq() will be triggered by an HPD event, as the bridge is on hdmi->disabled is false, then the handler will update the rxsense flag accordingly. - dw_hdmi_update_power() will be invoked with the mode DRM_FORCE_UNSPECIFIED and rxsense == 1, so dw_hdmi_poweroff() will be called and the PHY will be desactivated (its pixel clocks and TMDS) [...] - dw_hdmi_bridge_disable() will be invoked, the bridge will be marked as disabled. - dw_hdmi_irq() will be triggered by an HPD event, as the bridge is currently disabled the HPD status won't be updated, so hdmi->rxsense won't be changed. Even if the data part of the PHY is disabled, this information coming from the HDMI Transmitter is correct and should be saved. [...] - dw_hdmi_bridge_enable() will be invoked, the bridge will be marked as enabled. - dw_hdmi_update_power() will be called. When hdmi->force is equal to DRM_FORCE_UNSPECIFIED the function will rely on hdmi->rxsense. If this field has not been updated by the irq handler, it will be false and DRM_FORCE_ON won't be put to hdmi->force. Consequently, most of the time dw_hdmi_poweron() won't be called in this use case, TMDS won't be re-enabled the PHY won't be re-initialized, resulting in a "Signal not found". This commit fixes the issue by removing the check for "!hdmi->disabled". As already explained, even if the PHY is partially disabled, information coming from HDMI Transmitter about HPD should be saved for a later use. Signed-off-by: Romain Perier Signed-off-by: Archit Taneja Link: https://patchwork.freedesktop.org/patch/143602/

drm: bridge: dw-hdmi: add HDMI vendor specific infoframe config

2017-03-21T07:46:32+00:00

Vendor specific infoframe is mandatory for 4K2K resolution. Without this, the HDMI protocol compliance fails. Signed-off-by: Nickey Yang Reviewed-by: Jose Abreu Signed-off-by: Archit Taneja Link: http://patchwork.freedesktop.org/patch/msgid/1490081777-2232-1-git-send-email-nickey.yang@rock-chips.com