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>
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
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>
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>
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>
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>
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
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>
