- 16 2月, 2018 3 次提交
-
-
由 Jernej 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: 8242ecbd ("drm/bridge/synopsys: stop clobbering drvdata") Cc: p.zabel@pengutronix.de Cc: Laurent.pinchart@ideasonboard.com Cc: hjc@rock-chips.com Acked-by: NHeiko Stuebner <heiko@sntech.de> Acked-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NArchit Taneja <architt@codeaurora.org> Tested-by: NHeiko Stuebner <heiko@sntech.de> Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214200906.31509-6-jernej.skrabec@siol.net
-
由 Jernej 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: NArchit Taneja <architt@codeaurora.org> Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214200906.31509-5-jernej.skrabec@siol.net
-
由 Jernej Skrabec 提交于
Allwinner SoCs have dw hdmi controller v1.32a which exhibits same magenta line issue as i.MX6Q and i.MX6DL. Enable workaround for it. Tests show that one iteration is enough. Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: NArchit Taneja <architt@codeaurora.org> Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214200906.31509-4-jernej.skrabec@siol.net
-
- 30 11月, 2017 1 次提交
-
-
由 Pierre-Hugues Husson 提交于
Support the "cec" optional clock. The documentation already mentions "cec" optional clock and it is used by several boards, but currently the driver doesn't enable it, thus preventing cec from working on those boards. And even worse: a /dev/cecX device will appear for those boards, but it won't be functioning without configuring this clock. Changes: v4: - Change commit message to stress the importance of this patch v3: - Drop useless braces v2: - Separate ENOENT errors from others - Propagate other errors (especially -EPROBE_DEFER) Signed-off-by: NPierre-Hugues Husson <phh@phh.me> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/20171125201844.11353-1-phh@phh.me
-
- 23 11月, 2017 1 次提交
-
-
由 Ville Syrjälä 提交于
Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from 3D to 2D mode in a timely fashion if the source simply stops sending the HDMI infoframe. The suggested workaround is to keep sending the infoframe even when strictly not necessary (ie. no VIC and no S3D). HDMI 1.4 does allow for this behaviour, stating that sending the infoframe is optional in this case. The infoframe was first specified in HDMI 1.4, so in theory sinks predating that may not appreciate us sending an uknown infoframe their way. To avoid regressions let's try to determine if the sink supports the infoframe or not. Unfortunately there's no direct way to do that, so instead we'll just check if we managed to parse any HDMI 1.4 4k or stereo modes from the EDID, and if so we assume the sink will accept the infoframe. Also if the EDID contains the HDMI 2.0 HDMI Forum VSDB we can assume the sink is prepared to receive the infoframe. v2: Fix getting has_hdmi_infoframe from display_info Always fail constructing the infoframe if the display possibly can't handle it Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NShashank Sharma <shashank.sharma@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171113170427.4150-3-ville.syrjala@linux.intel.com
-
- 07 11月, 2017 1 次提交
-
-
由 Jani Nikula 提交于
drm_add_edid_modes() now fills in the ELD automatically, so the calls to drm_edid_to_eld() are redundant. Remove them. All the other places are obvious, but nv50 has detached drm_edid_to_eld() from the drm_add_edid_modes() call. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Archit Taneja <architt@codeaurora.org> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Russell King <linux@armlinux.org.uk> Cc: CK Hu <ck.hu@mediatek.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Eric Anholt <eric@anholt.net> Acked-by: NEric Anholt <eric@anholt.net> Acked-by: NArchit Taneja <architt@codeaurora.org> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Acked-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/0959ca02b983afc9e74dd9acd190ba6e25f21678.1509545641.git.jani.nikula@intel.com
-
- 08 8月, 2017 2 次提交
-
-
由 Daniel Vetter 提交于
It's dead code, the core handles all this directly now. The only special case is nouveau and tda988x which used one function for both legacy modeset code and -nv50 atomic world instead of 2 vtables. But amounts to exactly the same. v2: Rebase over the panel/brideg refactorings in stm/ltdc. Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Cc: Archit Taneja <architt@codeaurora.org> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Peter Senna Tschudin <peter.senna@collabora.com> Cc: Martin Donnelly <martin.donnelly@ge.com> Cc: Martyn Welch <martyn.welch@collabora.co.uk> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: Inki Dae <inki.dae@samsung.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Kukjin Kim <kgene@kernel.org> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Stefan Agner <stefan@agner.ch> Cc: Alison Wang <alison.wang@freescale.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: CK Hu <ck.hu@mediatek.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Carlo Caione <carlo@caione.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Marek Vasut <marex@denx.de> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Eric Anholt <eric@anholt.net> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: Yannick Fertre <yannick.fertre@st.com> Cc: Philippe Cornu <philippe.cornu@st.com> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Jyri Sarha <jsarha@ti.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: John Stultz <john.stultz@linaro.org> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Cc: Jeffy Chen <jeffy.chen@rock-chips.com> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Yakir Yang <kuankuan.y@gmail.com> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Romain Perier <romain.perier@collabora.com> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: Alexey Brodkin <abrodkin@synopsys.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Hai Li <hali@codeaurora.org> Cc: "Noralf Trønnes" <noralf@tronnes.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Cc: linux-mediatek@lists.infradead.org Cc: linux-amlogic@lists.infradead.org Cc: nouveau@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-rockchip@lists.infradead.org Cc: linux-tegra@vger.kernel.org Cc: virtualization@lists.linux-foundation.org Cc: zain wang <wzz@rock-chips.com> Cc: Baoyou Xie <baoyou.xie@linaro.org> Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170725080122.20548-8-daniel.vetter@ffwll.chAcked-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com> Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de> Acked-by: NArchit Taneja <architt@codeaurora.org> Tested-by: Philippe Cornu <philippe.cornu@st.com> (on stm) Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: NShawn Guo <shawnguo@kernel.org> Acked-by: NShawn Guo <shawnguo@kernel.org> Acked-by: NNoralf Trønnes <noralf@tronnes.org> Acked-by: NVincent Abriou <vincent.abriou@st.com>
-
由 Jose Abreu 提交于
Currently HDMI 2.0 PHYs do not have a default configuration function. As *some* of the HDMI 2.0 PHYs have the same register layout as the 3D PHYs we can provide the same default configuration function for both and still let user overwrite this with custom configuration function if needed. If, for some reason, the PHY is custom or has a register different register layout then custom configuration function *must* be provided in order for the system to work correctly. As we prefer the pdata provided configuration function over the internal one this change will not make any impact in custom platforms. Signed-off-by: NJose Abreu <joabreu@synopsys.com> Tested-by: NMark Yao <mark.yao@rock-chips.com> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: Archit Taneja <architt@codeaurora.org> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Carlos Palminha <palminha@synopsys.com> Cc: Heiko Stübner <heiko@sntech.de> Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/185ccf7d4473fa557044732402ca20b3d4007952.1498209896.git.joabreu@synopsys.com
-
- 07 8月, 2017 2 次提交
-
-
由 Russell King 提交于
Add a CEC driver for the dw-hdmi hardware. Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk> [hans.verkuil: unsigned -> unsigned int] [hans.verkuil: cec_transmit_done -> cec_transmit_attempt_done] [hans.verkuil: add missing CEC_CAP_PASSTHROUGH] Acked-by: NHans Verkuil <hans.verkuil@cisco.com> Tested-by: NHans Verkuil <hans.verkuil@cisco.com> Tested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/20170802184108.7913-4-hverkuil@xs4all.nl
-
由 Hans Verkuil 提交于
The __dw_hdmi_remove() function was missing a call to cec_notifier_put to balance the cec_notifier_get in the probe function. Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/a7688d13-2d61-ed16-f2df-28cbb5007f38@xs4all.nl
-
- 04 8月, 2017 2 次提交
-
-
由 Russell King 提交于
The video setup path aways sets the clock disable register to a specific value, which has the effect of disabling the CEC engine. When we add the CEC driver, this becomes a problem. Fix this by only setting/clearing the bits that the video path needs to. Reviewed-by: NJose Abreu <joabreu@synopsys.com> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk> Tested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: NHans Verkuil <hans.verkuil@cisco.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/E1dcBha-00088l-DE@rmk-PC.armlinux.org.uk
-
由 Russell King 提交于
Add CEC notifier support to the HDMI bridge driver, so that the CEC part of the IP can receive its physical address. Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk> Tested-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com> Tested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: NHans Verkuil <hans.verkuil@cisco.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/E1dcBhV-00088e-8x@rmk-PC.armlinux.org.uk
-
- 15 7月, 2017 1 次提交
-
-
由 Shashank Sharma 提交于
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). For any other mode, the VIC filed in AVI infoframes should be 0. HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is extended to (VIC 1-107). This patch adds a bool input variable, which indicates if the connected sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a HDMI 2.0 VIC to a HDMI 1.4 sink. This patch touches all drm drivers, who are callers of this function drm_hdmi_avi_infoframe_from_display_mode but to make sure there is no change in current behavior, is_hdmi2 is kept as false. In case of I915 driver, this patch: - checks if the connected display is HDMI 2.0. - HDMI infoframes carry one of this two type of information: - VIC for 4K modes for HDMI 1.4 sinks - S3D information for S3D modes As CEA-861-F has already defined VICs for 4K videomodes, this patch doesn't allow sending HDMI infoframes for HDMI 2.0 sinks, until the mode is 3D. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jose Abreu <jose.abreu@synopsys.com> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Daniel Vetter <daniel.vetter@intel.com> PS: This patch touches a few lines in few files, which were already above 80 char, so checkpatch gives 80 char warning again. - gpu/drm/omapdrm/omap_encoder.c - gpu/drm/i915/intel_sdvo.c V2: Rebase, Added r-b from Andrzej V3: Addressed review comment from Ville: - Do not send VICs in both AVI-IF and HDMI-IF send only one of it. V4: Rebase V5: Added r-b from Neil. Addressed review comments from Ville - Do not block HDMI vendor IF, instead check for VIC while handling AVI infoframes V6: Rebase V7: Rebase Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com> Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com> Signed-off-by: NShashank Sharma <shashank.sharma@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-2-git-send-email-shashank.sharma@intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
-
- 06 7月, 2017 1 次提交
-
-
由 Inki Dae 提交于
This patch removes unnecessary checking of return value. Signed-off-by: NInki Dae <inki.dae@samsung.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1499071350-25168-10-git-send-email-inki.dae@samsung.com
-
- 05 6月, 2017 1 次提交
-
-
由 Jose 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: NJose Abreu <joabreu@synopsys.com> Acked-by: NNeil Armstrong <narmstrong@baylibre.com> Acked-by: NPhilipp 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: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/3d8d449e4d13d2535fa292c75f5fa931de4a4fa8.1495720737.git.joabreu@synopsys.com
-
- 20 4月, 2017 2 次提交
-
-
由 Romain Perier 提交于
Currently, the audio sampler clock is enabled from dw_hdmi_setup() at step E. and is kept enabled for later use. This clock should be enabled and disabled along with the actual audio stream and not always on (that is bad for PM). Furthermore, as described by the datasheet, the I2S variant needs to gate/ungate the clock when the stream is enabled/disabled. This commit adds a parameter to hdmi_audio_enable_clk() that controls when the audio sample clock must be enabled or disabled. Then, it adds the call to this function from dw_hdmi_i2s_audio_enable() and dw_hdmi_i2s_audio_disable(). Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com> Signed-off-by: NRomain Perier <romain.perier@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170414083113.4255-3-romain.perier@collabora.comSigned-off-by: NArchit Taneja <architt@codeaurora.org>
-
由 Romain Perier 提交于
Currently, CTS+N is forced to zero as a workaround of the IP block for i.MX platforms. This is requested in the datasheet of the corresponding IP for AHB mode only. However, we have seen that it introduces glitches or delays when playing a sound on HDMI for I2S mode. This proves that we cannot keep the current functions for handling audio stream as-is if these contain workaround that are specific to a mode. This commit introduces two callbacks, one for each variant. dw_hdmi_setup defines the right function depending on the detected variant. Then, the exported functions dw_hdmi_audio_enable and dw_hdmi_audio_disable calls the corresponding callbacks Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com> Signed-off-by: NRomain Perier <romain.perier@collabora.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170414083113.4255-2-romain.perier@collabora.com
-
- 10 4月, 2017 1 次提交
-
-
由 Romain Perier 提交于
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: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NRomain Perier <romain.perier@collabora.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170407121743.4142-1-romain.perier@collabora.com
-
- 07 4月, 2017 1 次提交
-
-
由 Neil Armstrong 提交于
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: def23aa7 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings") Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NArchit 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
-
- 06 4月, 2017 2 次提交
-
-
由 Dan Carpenter 提交于
There was supposed to be a break before the next case statement. Fixes: def23aa7 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings") Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Acked-by: NNeil Armstrong <narmstrong@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170406052132.GA26605@mwanda
-
由 Neil Armstrong 提交于
Remove usused yet hdmi_bus_fmt_is_yuv420 function. Fixes: def23aa7 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings") Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Link: http://patchwork.freedesktop.org/patch/msgid/1491377579-9353-1-git-send-email-narmstrong@baylibre.com
-
- 04 4月, 2017 3 次提交
-
-
由 Neil 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: NJose Abreu <joabreu@synopsys.com> Reviewed-by: NArchit Taneja <architt@codeaurora.org> Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: http://patchwork.freedesktop.org/patch/msgid/1491309119-24220-2-git-send-email-narmstrong@baylibre.com
-
由 Neil 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: NJose Abreu <joabreu@synopsys.com> Reviewed-by: NArchit Taneja <architt@codeaurora.org> Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
-
由 Laurent Pinchart 提交于
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: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: NJose Abreu <joabreu@synopsys.com> [narmstrong: renamed dw_hdmi_fb_registered to dw_hdmi_setup_i2c] Reviewed-by: NArchit Taneja <architt@codeaurora.org> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
-
- 27 3月, 2017 1 次提交
-
-
由 Romain Perier 提交于
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: NRomain Perier <romain.perier@collabora.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/143602/
-
- 21 3月, 2017 2 次提交
-
-
由 Nickey Yang 提交于
Vendor specific infoframe is mandatory for 4K2K resolution. Without this, the HDMI protocol compliance fails. Signed-off-by: NNickey Yang <nickey.yang@rock-chips.com> Reviewed-by: NJose Abreu <joabreu@synopsys.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1490081777-2232-1-git-send-email-nickey.yang@rock-chips.com
-
由 Nickey Yang 提交于
"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: NNickey Yang <nickey.yang@rock-chips.com> Reviewed-by: NDouglas Anderson <dianders@chromium.org> Acked-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1489978651-16647-1-git-send-email-nickey.yang@rock-chips.com
-
- 10 3月, 2017 10 次提交
-
-
由 Laurent Pinchart 提交于
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: NJose Abreu <Jose.Abreu@synopsys.com> Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: NJose Abreu <joabreu@synopsys.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-10-laurent.pinchart+renesas@ideasonboard.com
-
由 Neil 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: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NJose Abreu <Jose.Abreu@synopsys.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-10-laurent.pinchart+renesas@ideasonboard.com
-
由 Kieran 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: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NJose Abreu <joabreu@synopsys.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-9-laurent.pinchart+renesas@ideasonboard.com
-
由 Kieran 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: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NJose Abreu <Jose.Abreu@synopsys.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-8-laurent.pinchart+renesas@ideasonboard.com
-
由 Laurent 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: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NJose Abreu <joabreu@synopsys.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170305233615.11993-1-laurent.pinchart+renesas@ideasonboard.com
-
由 Laurent Pinchart 提交于
When powering the PHY up we need to wait for the PLL to lock. This is done by polling the TX_PHY_LOCK bit in the HDMI_PHY_STAT0 register (interrupt-based wait could be implemented as well but is likely overkill). The bit is asserted when the PLL locks, but the current code incorrectly waits for the bit to be deasserted. Fix it, and while at it, replace the udelay() with a sleep as the code never runs in non-sleepable context. To be consistent with the power down implementation move the poll loop to the power off function. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NJose Abreu <joabreu@synopsys.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170305233557.11945-1-laurent.pinchart+renesas@ideasonboard.com
-
由 Laurent Pinchart 提交于
The PHY requires us to wait for the PHY to switch to low power mode after deasserting TXPWRON and before asserting PDDQ in the power down sequence, otherwise power down will fail. The PHY power down can be monitored though the TX_READY bit, available through I2C in the PHY registers, or the TX_PHY_LOCK bit, available through the HDMI TX registers. As the two are equivalent, let's pick the easier solution of polling the TX_PHY_LOCK bit. The power down code is currently duplicated in multiple places. To avoid spreading multiple calls to a TX_PHY_LOCK poll function, we have to refactor the power down code and group it all in a single function. Tests showed that one poll iteration was enough for TX_PHY_LOCK to become low, without requiring any additional delay. Retrying the read five times with a 1ms to 2ms delay between each attempt should thus be more than enough. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NJose Abreu <joabreu@synopsys.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170305233539.11898-1-laurent.pinchart+renesas@ideasonboard.com
-
由 Neil Armstrong 提交于
If the input pixel format is not RGB, the CSC must be enabled in order to provide valid pixel to DVI sinks. This patch removes the hdmi only dependency on the CSC enabling. Reviewed-by: NJose Abreu <joabreu@synopsys.com> Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Tested-by: NNeil Armstrong <narmstrong@baylibre.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-4-laurent.pinchart+renesas@ideasonboard.com
-
由 Laurent Pinchart 提交于
The color space converter isn't part of the PHY, move its configuration out of PHY code. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NJose Abreu <joabreu@synopsys.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-3-laurent.pinchart+renesas@ideasonboard.com
-
由 Laurent Pinchart 提交于
Most of the hdmi_phy_test_*() functions are unused. Remove them. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: NNeil Armstrong <narmstrong@baylibre.com> Reviewed-by: NJose Abreu <joabreu@synopsys.com> Tested-by: NNickey Yang <nickey.yang@rock-chips.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303172007.26541-2-laurent.pinchart+renesas@ideasonboard.com
-
- 24 1月, 2017 1 次提交
-
-
由 Arnd Bergmann 提交于
The of_node member in struct drm_bridge is hidden when CONFIG_OF is disabled, causing a build error: drivers/gpu/drm/bridge/dw-hdmi.c: In function '__dw_hdmi_probe': drivers/gpu/drm/bridge/dw-hdmi.c:2063:14: error: 'struct drm_bridge' has no member named 'of_node' We could fix this either using a Kconfig dependency on CONFIG_OF or making the one line conditional. The latter gives us better compile test coverage, so this is what I'm doing here. Fixes: 69497eb9 ("drm: bridge: dw-hdmi: Implement DRM bridge registration") Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170123122312.3290934-1-arnd@arndb.de
-
- 18 1月, 2017 2 次提交
-
-
由 Laurent Pinchart 提交于
According to the PHY IP core vendor, the SVSRET signal must be asserted before resetting the PHY. Tests on RK3288 and R-Car Gen3 showed no regression, the change should thus be safe. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: NJose Abreu <joabreu@synopsys.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170117082910.27023-20-laurent.pinchart+renesas@ideasonboard.com
-
由 Laurent Pinchart 提交于
The PHY reset signal is controlled by bit PHYRSTZ in the MC_PHYRSTZ register. The signal is active low on Gen1 PHYs and active high on Gen2 PHYs. The driver toggles the signal high then low, which is correct for all currently supported platforms, but the register values macros are incorrectly named. Replace them with a single macro named after the bit, and add a comment to the source code to explain the behaviour. The driver's behaviour isn't changed by this rename, the code will still need to be fixed to support Gen1 PHYs. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: NJose Abreu <joabreu@synopsys.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170117082910.27023-19-laurent.pinchart+renesas@ideasonboard.com
-