| Age | Commit message (Collapse) | Author |
|---|
|
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 <daniel.vetter@ffwll.ch>
Signed-off-by: Romain Perier <romain.perier@collabora.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170407121743.4142-1-romain.perier@collabora.com
|
|
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 <dan.carpenter@oracle.com>
Fixes: def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Archit Taneja <architt@codeaurora.org>
[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
|
|
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 <dan.carpenter@oracle.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170406052132.GA26605@mwanda
|
|
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 <narmstrong@baylibre.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1491377579-9353-1-git-send-email-narmstrong@baylibre.com
|
|
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
|
|
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>
|
|
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 <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Jose Abreu <joabreu@synopsys.com>
[narmstrong: renamed dw_hdmi_fb_registered to dw_hdmi_setup_i2c]
Reviewed-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
|
|
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 <romain.perier@collabora.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/143602/
|
|
Vendor specific infoframe is mandatory for 4K2K resolution.
Without this, the HDMI protocol compliance fails.
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
Reviewed-by: Jose Abreu <joabreu@synopsys.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1490081777-2232-1-git-send-email-nickey.yang@rock-chips.com
|
|
"I2C Master Interface Extended Read Mode" implements a segment
pointer-based read operation using the Special Register configuration.
This patch fix https://patchwork.kernel.org/patch/7098101/ mentioned
"The current implementation does not support "I2C Master Interface
Extended Read Mode" to read data addressed by non-zero segment
pointer, this means that if EDID has more than 1 extension blocks,
EDID reading operation won't succeed"
With this patch, dw-hdmi can read EDID data with 1/2/4 blocks.
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1489978651-16647-1-git-send-email-nickey.yang@rock-chips.com
|
|
The driver is already made of 5 separate source files. Move it to a
newly created directory named synopsys where more Synopsys bridge
drivers can be added later (for the DisplayPort controller for
instance).
Suggested-by: Jose Abreu <Jose.Abreu@synopsys.com>
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/20170303172007.26541-10-laurent.pinchart+renesas@ideasonboard.com
|
