aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/bridge
Commit message (Collapse)AuthorAge
...
| * drm: bridge: analogix/dp: try force hpd after plug in lookup failedYakir Yang2016-04-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some edp screen do not have hpd signal, so we can't just return failed when hpd plug in detect failed. This is an hardware property, so we need add a devicetree property "analogix,need-force-hpd" to indicate this sutiation. Acked-by: Rob Herring <robh@kernel.org> 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>
| * drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288Yakir Yang2016-04-04
| | | | | | | | | | | | | | | | | | | | There are some IP limit on rk3288 that only support 4 physical lanes of 2.7/1.6 Gbps/lane, so seprate them out by device_type flag. 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>
| * drm: bridge: analogix/dp: add some rk3288 special registers settingYakir Yang2016-04-04
| | | | | | | | | | | | | | | | | | | | RK3288 need some special registers setting, we can separate them out by the dev_type of plat_data. 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>
| * drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_rangeYakir Yang2016-04-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Both hsync/vsync polarity and interlace mode can be parsed from drm display mode, and dynamic_range and ycbcr_coeff can be judge by the video code. But presumably Exynos still relies on the DT properties, so take good use of mode_fixup() in to achieve the compatibility hacks. Reviewed-by: Krzysztof Kozlowski <k.kozlowski@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>
| * drm: bridge: analogix/dp: remove duplicate configuration of link rate and ↵Yakir Yang2016-04-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | link count link_rate and lane_count already configured in analogix_dp_set_link_train(), so we don't need to config those repeatly after training finished, just remove them out. Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}. 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>
| * drm: bridge: analogix/dp: fix some obvious code styleYakir Yang2016-04-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix some obvious alignment problems, like alignment and line over 80 characters problems, make this easy to be maintained later. Acked-by: Jingoo Han <jingoohan1@gmail.com> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@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>
| * drm: bridge: analogix/dp: rename register constantsHeiko Stuebner2016-04-04
| | | | | | | | | | | | | | | | | | | | | | | | In the original split we kept the register constants intact to keep the diff small. Still the constants are Analogix-specific, so rename them now. Tested-by: Caesar Wang <wxt@rock-chips.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
| * drm: bridge: analogix/dp: split exynos dp driver to bridge directoryYakir Yang2016-04-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | drm: bridge/dw-hdmi: Remove pre_enable/post_disable dummy funcsArchit Taneja2016-03-30
|/ | | | | | | | | | We don't need to keep empty callbacks for the (pre/post) enable/disable drm_bridge ops anymore. Remove the nop callback used here for pre_enable and post_disable ops. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1459329804-10488-1-git-send-email-architt@codeaurora.org
* drm/bridge: removed dummy mode_fixup function from dw-hdmi.Carlos Palminha2016-02-11
| | | | | | | | | Other bridge drivers don't implement this optional function. Removed dummy code from dw-hdmi brigde driver. Signed-off-by: Carlos Palminha <palminha@synopsys.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455120639-29934-1-git-send-email-palminha@synopsys.com
* Merge tag 'topic/drm-misc-2016-01-17' of ↵Dave Airlie2016-01-17
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next Since your main drm-next pull isn't out of the door yet I figured I might as well flush out drm-misc instead of delaying for 4.6. It's really just random stuff all over, biggest thing probably connector_mask tracking from Maarten. * tag 'topic/drm-misc-2016-01-17' of git://anongit.freedesktop.org/drm-intel: (24 commits) drm/fb_cma_helper: Remove implicit call to disable_unused_functions drm/sysfs: use kobj_to_dev() drm/i915: Init power domains early in driver load drm: Do not set connector->encoder in drivers apple-gmux: Add initial documentation drm: move MODULE_PARM_DESC to other file drm/edid: index CEA/HDMI mode tables using the VIC drm/atomic: Remove drm_atomic_connectors_for_crtc. drm/i915: Update connector_mask during readout, v2. drm: Remove opencoded drm_gem_object_release_handle() drm: Do not set outparam on error during GEM handle allocation drm/docs: more leftovers from the big vtable documentation pile drm/atomic-helper: Reject legacy flips on a disabled pipe drm/atomic: add connector mask to drm_crtc_state. drm/tegra: Use __drm_atomic_helper_reset_connector for subclassing connector state, v2. drm/atomic: Add __drm_atomic_helper_connector_reset, v2. drm/i915: Set connector_state->connector using the helper. drm: Use a normal idr allocation for the obj->name drm: Only bump object-reference count when adding first handle drm: Balance error path for GEM handle allocation ...
| * drm: Do not set connector->encoder in driversThierry Reding2016-01-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An encoder is associated with a connector by the DRM core as a result of setting up a configuration. Drivers using the atomic or legacy helpers should never set up this link, even if it is a static one. While at it, try to catch this kind of error in the future by adding a WARN_ON() in drm_mode_connector_attach_encoder(). Note that this doesn't cover all the cases, since drivers could set this up after attaching. Drivers that use the atomic helpers will get a warning later on, though, so hopefully the two combined cover enough to help people avoid this in the future. Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Liviu Dudau <Liviu.Dudau@arm.com> Cc: Mark yao <mark.yao@rock-chips.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1447694393-24700-1-git-send-email-thierry.reding@gmail.com
* | drm: bridge/dw_hdmi: add atomic API supportMark Yao2015-12-27
| | | | | | | | | | | | | | | | | | | | | | | | Fill atomic needed funcs with default atomic helper library. Rockchip use dw_hdmi, and drm/rockchip will covert to atomic api, we need dw_hdmi support atomic funcs. Now another drm driver use dw_hdmi is imx, not yet atomic, so check DRIVER_ATOMIC at runtime to spilt atomic and not atomic. Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
* | Merge tag 'topic/drm-misc-2015-12-18' of ↵Dave Airlie2015-12-18
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next Seems I lied in my last drm-misc pull request and suddenly there's a big pile of random stuff. Boris dug out Thierry's drm-trivial branch and resubmitted everything since that branch didn't really work out. On top of that Nicolas' changes to drm_dev_set_unique - this might conflict with new driver pulls (I double checked and current drm-next should be fine), so please beware. The -next/-fixes conflict in vmwgfx will change slightly with this here too. * tag 'topic/drm-misc-2015-12-18' of git://anongit.freedesktop.org/drm-intel: (36 commits) drm: use dev_name as default unique name in drm_dev_alloc() drm: make drm_dev_set_unique() not use a format string drm/vmwgfx: Constify function pointer structs drm/udl: Constify function pointer structs drm/tegra: Constify function pointer structs drm/rockchip: Constify function pointer structs drm/nouveau: Constify function pointer structs drm/mgag200: Constify function pointer structs drm/imx: Constify function pointer structs drm/i2c/sil164: Constify function pointer structs drm/i2c/adv7511: Constify function pointer structs drm/exynos: Constify function pointer structs drm/cirrus: Constify function pointer structs drm/i2c/ch7006: Constify function pointer structs drm/bridge/nxp-ptn3460: Constify function pointer structs drm/bridge/dw_hdmi: Constify function pointer structs drm/bochs: Constify function pointer structs drm/atmel-hlcdc: Constify function pointer structs drm/armada: Constify function pointer structs drm: Constify drm_encoder_slave_funcs ...
| * drm/bridge/nxp-ptn3460: Constify function pointer structsVille Syrjälä2015-12-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Moves a bunch of junk to .rodata from .data. drivers/gpu/drm/bridge/nxp-ptn3460.ko: -.rodata 440 +.rodata 536 -.data 208 +.data 112 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-16-git-send-email-boris.brezillon@free-electrons.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/bridge/dw_hdmi: Constify function pointer structsVille Syrjälä2015-12-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Moves a bunch of junk to .rodata from .data. drivers/gpu/drm/bridge/dw_hdmi.ko: -.rodata 120 +.rodata 216 -.data 96 +.data 0 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-15-git-send-email-boris.brezillon@free-electrons.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/bridge: Remove gratuitous blank lineThierry Reding2015-11-24
| | | | | | | | | | | | A single blank line is enough to separate Kconfig entries. Signed-off-by: Thierry Reding <treding@nvidia.com>
* | drm/bridge: dw-hdmi: Use dashes in filenamesThierry Reding2015-11-24
|/ | | | | | | For consistency with other drivers, use dashes instead of underscores in filenames. Signed-off-by: Thierry Reding <treding@nvidia.com>
* Merge tag 'drm/panel/for-4.4-rc1' of ↵Dave Airlie2015-11-04
|\ | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/tegra/linux into drm-next drm/panel: Changes for v4.4-rc1 Just two small cleanup patches to fix coccinelle warnings. * tag 'drm/panel/for-4.4-rc1' of git://anongit.freedesktop.org/tegra/linux: drm/bridge: ptn3460: Fix coccinelle warnings drm/bridge: ps8622: Fix coccinelle warnings
| * drm/bridge: ptn3460: Fix coccinelle warningskbuild test robot2015-10-30
| | | | | | | | | | | | | | | | | | | | | | | | | | The platform_no_drv_owner.cocci coccinelle script generates the following warning: drivers/gpu/drm/bridge/nxp-ptn3460.c:403:3-8: No need to set .owner here. The core will do it. Remove .owner field if calls are used which set it automatically. Patch generated by scripts/coccinelle/api/platform_no_drv_owner.cocci. Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
| * drm/bridge: ps8622: Fix coccinelle warningskbuild test robot2015-10-30
| | | | | | | | | | | | | | | | | | | | | | | | | | The platform_no_drv_owner.cocci coccinelle script generates the following warning: drivers/gpu/drm/bridge/parade-ps8622.c:671:3-8: No need to set .owner here. The core will do it. Remove .owner field if calls are used which set it automatically. Patch generated by scripts/coccinelle/api/platform_no_drv_owner.cocci. Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
* | drm: bridge/dw_hdmi: replace CTS calculation for the ACRRussell King2015-10-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Given the TDMS clock, audio sample rate, and the N parameter, we can calculate the CTS value for the audio clock regenerator (ACR) using the following calculation given in the HDMI specification: CTS = ftdms * N / (128 * fs) The specification says that the CTS value is an average value, which is true if the source hardware measures it. Where source hardware needs it to be programmed, it is particularly difficult to alternate between two values correctly to ensure that we achieve a correct "average" fractional value at the sink. Also, there's the problem that our "ftdms" is not a fully accurate value; it is rounded to a kHz value. This introduces an unnecessary (and harmless) fractional value into the above equation for combinations like 148.5MHz/1.001 for 44100Hz - we still calculate the correct CTS value. Tested-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* | drm: bridge/dw_hdmi: remove ratio support from ACR codeRussell King2015-10-09
| | | | | | | | | | | | | | | | | | | | | | We never set the ratio for CTS/N calculation for the audio clock regenerator (ACR) to anything but 100, so this adds pointless complexity. Should we support pixel repetition, we should update the CTS/N calculation code to use those parameters or the actual TMDS clock rate instead of a ratio. Tested-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* | drm: bridge/dw_hdmi: adjust pixel clock values in N calculationRussell King2015-10-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adjust the pixel clock values in the N calculation to match the more accurate clock values we're given by the DRM subsystem, which are the kHz pixel rate, with any fractional kHz rounded down in the case of the non-240, non-480 line modes, or rounded up for the others. So, 25.20 / 1.001 => 25175 27.00 * 1.001 => 27027 74.25 / 1.001 => 74176 148.50 / 1.001 => 148352 DRM derives these rates from the EDID CEA mode identifiers, which are looked up in the tables in drivers/gpu/drm/drm_edid.c. The values on the right are the clock values found in these tables, and are currently expected to be passed to the HDMI driver unchanged. Tested-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* | drm: bridge/dw_hdmi: avoid being recursive in N calculationRussell King2015-10-09
| | | | | | | | | | | | | | | | | | There's no need to be recursive when computing the N value for the ACR packet - we can instead calculate the multiplier prior to our switch() based lookup, and multiply the N value appropriately afterwards. Tested-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* | drm: bridge/dw_hdmi-ahb-audio: allow larger buffer sizesRussell King2015-10-09
| | | | | | | | | | | | | | | | | | | | With multichannel audio, we need to allow larger buffer sizes to avoid XRUNs during playback. Push the buffer size up to 1024K, but as we maintain two buffers, ensure that the vmalloc buffer does not exceed the userspace buffer size. Tested-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* | drm: bridge/dw_hdmi-ahb-audio: basic support for multi-channel PCM audioRussell King2015-10-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add basic support for multi-channel PCM audio, with fixed speaker mappings. This has been tested with an AV receiver, and appears to work for low sample rates up to 8 channels. It should be noted that multi-channel mode using the IEC958 alsa-lib conversion plugin requires correct AES channel status for the AV receiver to recognise the stream, especially the sample rate bits. "Not identified" does not work there. Tested-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* | drm: bridge/dw_hdmi-ahb-audio: parse ELD from HDMI driverRussell King2015-10-09
| | | | | | | | | | | | | | | | | | | | Parse the ELD (EDID like data) stored from the HDMI driver to restrict the sample rates and channels which are available to ALSA. This causes the ALSA device to reflect the capabilities of the overall audio path, not just what is supported at the HDMI source interface level. Tested-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* | drm: bridge/dw_hdmi-ahb-audio: add audio driverRussell King2015-10-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add ALSA based HDMI AHB audio driver for dw_hdmi. The only buffer format supported by the hardware is its own special IEC958 based format, which is not compatible with any ALSA format. To avoid doing too much data manipulation within the driver, we support only ALSAs IEC958 LE and 24-bit PCM formats for 2 to 6 channels, which we convert to its hardware format. A more desirable solution would be to have this conversion in userspace, but ALSA does not appear to allow such transformations outside of libasound itself. Reviewed-by: Takashi Iwai <tiwai@suse.de> Tested-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* | drm: bridge/dw_hdmi: improve HDMI enable/disable handlingRussell King2015-10-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | HDMI sinks are permitted to de-assert and re-assert the HPD signal to indicate that their EDID has been updated, which may not involve a change of video information. An example of where such a situation can arise is when an AV receiver is connected between the source and the display device. Events which can cause the HPD to be deasserted include: * turning on or switching to standby the AV receiver. * turning on or switching to standby the display device. Each of these can change the entire EDID data, or just a part of the EDID data - it's up to the connected HDMI sink to do what they desire here. For example - with the AV receiver and display device both in standby, a source connected to the AV receiver may provide its own EDID to the source. - turning on the display device causes the display device's EDID to be made available in an unmodified form to the source. - subsequently turning on the AV receiver then provides a modified version of the display device's EDID. Moreover, HPD doesn't tell us whether something is actually listening on the HDMI TDMS signals. The phy gives us a set of RXSENSE indications which tell us whether there is a sink connected to the TMDS signals. Currently, we use the HPD signal to enable or disable the HDMI block, which is questionable when HPD is used in this manner. Using the RXSENSE would be more appropriate, but there is some bad behaviour which needs to be coped with. The iMX6 implementation lets the TMDS signals float when the phy is "powered down", which cause spurious interrupts. Rather than just using RXSENSE, use RXSENSE and HPD becoming both active to signal the presence of a device, but loss of RXSENSE to indicate that the device has been unplugged. The side effect of this change is that a sink deasserting the HPD signal to cause a re-read of the EDID data will not cause the bridge to immediately disable the video signal. Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* | drm: bridge/dw_hdmi: add connector mode forcingRussell King2015-10-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When connected to HDMI sources, some DVI monitors de-assert their HPD signal and TDMS loads for one seconds every four seconds when there is no signal present on the connection. Unfortunately, this behaviour is indistinguishable from a proper HDMI setup with an AV receiver in the path to the display: the HDMI spec requires us to detect HPD deassertions as short as 100ms, which indicate that the EDID has changed. Since it is possible to connect a DVI monitor to an AV receiver and then to a HDMI source, merely working around this by detecting the lack of HDMI vendor block in the EDID is insufficient - the AV receiver is at liberty to modify the EDID as it sees fit, and it will place its own parameters into the EDID including the HDMI vendor block. DRM has support for forcing the state of a connector, which we should implement to allow us to work around these broken DVI monitors - we can tell DRM to force the connection state to indicate that there is always a device connected to work around this problem. Although this requires manual configuration, it is better than nothing at all. When a forced connection state has been set, there is no point handling our RXSENSE interrupts, so disable them in this circumstance. Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* | drm: bridge/dw_hdmi: add support for interlaced video modesRussell King2015-10-06
|/ | | | | | | | | | | | | | | Add support for interlaced video modes to the dw_hdmi bridge. This mainly involves halving the vertical parameters to be programmed into the bridge registers, and setting the interlace_allowed connector flag. This brings working 1080i support. However, 480i and 576i fail to work due to the lack of proper pixel repetition support, which is not trivial to add due to the tabular PLL parameterisation. Hence, we filter out these modes in our mode_valid() method. Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* Merge branch 'drm-dwhdmi-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-arm ↵Dave Airlie2015-08-26
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * drm: bridge/dw_hdmi: fix register I2CM_ADDRESS register nameVladimir Zapolskiy2015-08-18
| | | | | | | | | | | | | | | | I2CM_ADDRESS became a MESS, fix it, also change guarding define to __DW_HDMI_H__ , since the driver is not IMX specific. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * drm: bridge/dw_hdmi: fix phy enable/disable handlingRussell King2015-08-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The dw_hdmi enable/disable handling is particularly weak in several regards: * The hotplug interrupt could call hdmi_poweron() or hdmi_poweroff() while DRM is setting a mode, which could race with a mode being set. * Hotplug will always re-enable the phy whenever it detects an active hotplug signal, even if DRM has disabled the output. Resolve all of these by introducing a mutex to prevent races, and a state-tracking bool so we know whether DRM wishes the output to be enabled. We choose to use our own mutex rather than ->struct_mutex so that we can still process interrupts in a timely fashion. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * drm: bridge/dw_hdmi: rename dw_hdmi_phy_enable_power()Russell King2015-08-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dw_hdmi_phy_enable_power() is not about enabling and disabling power. It is about allowing or preventing power-down mode being entered - the register is documented as "Power-down enable (active low 0b)." This can be seen as the bit has no effect when the HDMI phy is operational on iMX6 hardware. Rename the function to dw_hdmi_phy_enable_powerdown() to reflect the documentation, make it take a bool for the 'enable' argument, and invert the value to be written. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * drm: bridge/dw_hdmi: avoid enabling interface in mode_setRussell King2015-08-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On a mode set, DRM makes the following sequence of calls: * for_each_encoder * bridge mode_fixup * encoder mode_fixup * crtc mode_fixup * for_each_encoder * bridge disable * encoder prepare * bridge post_disable * disable unused encoders * crtc prepare * crtc mode_set * for_each_encoder * encoder mode_set * bridge mode_set * crtc commit * for_each_encoder * bridge pre_enable * encoder commit * bridge enable dw_hdmi enables the HDMI output in both the bridge mode_set() and also the bridge enable() step. This is duplicated work - we can avoid the setup in mode_set() and just do it in the enable() stage. This simplifies the code a little. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * drm: bridge/dw_hdmi: enable audio only if sink supports audioRussell King2015-08-18
| | | | | | | | | | | | | | | | Only enable audio support if the sink supports audio in some form, as defined via its EDID. We discover this capability using the generic drm_detect_monitor_audio() function. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * drm: bridge/dw_hdmi: clean up HDMI vs DVI mode handlingRussell King2015-08-18
| | | | | | | | | | | | | | | | | | | | | | | | The FSL kernel detects the HDMI vendor id, and uses this to set hdmi->edid_cfg.hdmi_cap, which is then used to set mdvi appropriately, rather than detecting whether we are outputting a CEA mode. Update the dw_hdmi code to use this logic, but lets eliminate the mdvi variable, prefering the more verbose "hdmi->sink_is_hdmi" instead. Use the generic drm_detect_hdmi_monitor() to detect a HDMI sink. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * drm: bridge/dw_hdmi: don't support any pixel doubled modesRussell King2015-08-18
| | | | | | | | | | | | | | | | | | As mentioned in the previous commit, the dw-hdmi driver does not support pixel doubled modes at present; it does not configure the PLL correctly for these modes. Therefore, filter out the double-clocked modes as we presently are unable to support them. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * drm: bridge/dw_hdmi: remove pixel repetition setting for all VICsRussell King2015-08-18
| | | | | | | | | | | | | | | | | | | | | | | | dw_hdmi sets a pixel repetition factor of 1 for VICs 10-15, 25-30 and 35-38. However, DRM uses their native resolutions in its timing information. For example, VIC 14 can be 1440x480 with no repetition, or 720x480 with one pixel repetition. As DRM uses 1440 pixels per line for this video mode, we need no pixel repetition. In any case, pixel repetition appears broken in dw_hdmi. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * drm: bridge/dw_hdmi: introduce interfaces to enable and disable audioRussell King2015-08-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm: bridge/dw_hdmi: introduce interface to setting sample rateRussell King2015-08-18
| | | | | | | | | | | | | | | | 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>
| * drm: bridge/dw_hdmi: remove mhsyncpolarity/mvsyncpolarity/minterlacedRussell King2015-08-18
| | | | | | | | | | | | | | | | Remove the struct hdmi_vmode mhsyncpolarity/mvsyncpolarity/minterlaced members, which are only used within a single function. We can directly reference the appropriate mode->flags instead. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * drm: bridge/dw_hdmi: use our own drm_deviceRussell King2015-08-18
| | | | | | | | Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * drm: bridge/dw_hdmi: remove unused 'regmap' struct memberRussell King2015-08-18
| | | | | | | | | | | | | | This driver does not make use of regmaps, let's remove this unnecessary structure member. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * drm: bridge/dw_hdmi: simplify hdmi_config_AVI() a littleRussell King2015-08-18
| | | | | | | | | | | | | | | | When a YCBCR format is selected, we can merely copy the colorimetry information directly as we use the same definitions for both the unpacked AVI info frame and the hdmi_data_info structure. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * drm: bridge/dw_hdmi: use drm_hdmi_avi_infoframe_from_display_mode()Russell King2015-08-18
| | | | | | | | | | | | | | Use drm_hdmi_avi_infoframe_from_display_mode() to compose the AVI frame. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * drm: bridge/dw_hdmi: clean up hdmi_set_clk_regenerator()Russell King2015-08-18
| | | | | | | | | | | | | | | | | | | | Clean up hdmi_set_clk_regenerator() by allowing it to take the audio sample rate and ratio directly, rather than hiding it inside the function. Raise the unsupported pixel clock/sample rate message from debug to error level as this results in audio not working correctly. Tested-by: Yakir Yang <ykk@rock-chips.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * drm: bridge/dw_hdmi: clean up phy configurationRussell King2015-08-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The phy configuration is dependent on the SoC, and we look up values for some of the registers in SoC specific data. However, we had partially programmed the phy before we had successfully looked up the clock rate. Also, we were only checking that we had a valid configuration for the currctrl register. Move all these lookups to the start of this function instead, so we can check that all lookups were successful before beginning to program the phy. Tested-by: Yakir Yang <ykk@rock-chips.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
generated by cgit v1.2.2 (git 2.25.0) at 2025-04-03 15:55:40 -0400