kernel/drivers/gpu/drm/exynos/exynos_hdmi.c, branch linux-4.17.y

drm/exynos: hdmi: avoid duplicating drm_bridge_attach

2018-05-09T00:04:57Z

drm_bridge_attach takes care of these assignments, so there is no need to open-code them a second time. Signed-off-by: Peter Rosin Signed-off-by: Inki Dae

drm: exynos: Use proper macro definition for HDMI_I2S_PIN_SEL_1

2018-02-20T01:51:36Z

Bit field [2:0] of HDMI_I2S_PIN_SEL_1 corresponds to SDATA_0, not SDATA_2. This patch removes redefinition of HDMI_I2S_SEL_DATA2 constant and adds missing HDMI_I2S_SEL_DATA0. The value of bit field selecting SDATA_1 (pin_sel_3) is also changed, so it is 3 as suggested in the Exynos TRMs. Signed-off-by: Sylwester Nawrocki Signed-off-by: Inki Dae

drm/edid: Allow HDMI infoframe without VIC or S3D

2017-11-22T17:24:34Z

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 Cc: Andrzej Hajda Cc: Laurent Pinchart Signed-off-by: Ville Syrjälä Reviewed-by: Shashank Sharma Link: https://patchwork.freedesktop.org/patch/msgid/20171113170427.4150-3-ville.syrjala@linux.intel.com

drm: exynos: Add driver for HDMI audio interface

2017-10-26T00:06:34Z

The hdmi-codec interface added in this patch is required to properly support HDMI audio. Currently the audio part of the SoC internal HDMI transmitter is configured with fixed values, which makes HDMI audio working by chance, only on boards having an external audio codec connected in parallel with the HDMI audio transmitter's input I2S interface. Signed-off-by: Sylwester Nawrocki Reviewed-by: Andrzej Hajda Signed-off-by: Inki Dae

drm/exynos/hdmi: add 85.5MHz pixel clock for v14 HDMI PHY

2017-10-26T00:06:34Z

Configuration details from Samsung. This enables 1366x768@60Hz, which also needs the 256px timing hack to work around a mixer limitation. Signed-off-by: Daniel Drake Signed-off-by: Tobias Jakobi [a.hajda@samsung.com: rebased onto proposed patchset] Signed-off-by: Andrzej Hajda Signed-off-by: Inki Dae

drm/exynos/hdmi: quirk for support mode timings conversion

2017-10-26T00:06:33Z

MIXER in SoCs prior to Exynos5420 supports only 4 video modes: 720x480, 720x576, 1280x720, 1920x1080. Support for other modes can be enabled by manipulating timings of HDMI. To do it adjusted_mode should contain actual mode set on crtc. With this patch it is possible to enable 1024x768 and 1280x1024 modes in MIXER. Suggested-by: Daniel Drake Signed-off-by: Andrzej Hajda Reviewed-by: Tobias Jakobi Signed-off-by: Inki Dae

drm/exynos/hdmi: remove redundant mode field

2017-10-26T00:06:33Z

Display mode is preserved in CRTC state, there is no need to keep local copy of it. Moreover since HDMI should configure registers according to requested mode, use it instead of adjusted_mode, which should contain mode produced by CRTC - functionally it does not change anything, but subsequent patches will make the difference. Signed-off-by: Andrzej Hajda Reviewed-by: Tobias Jakobi Signed-off-by: Inki Dae

drm/exynos/hdmi: Fix unsafe list iteration

2017-09-20T03:05:23Z

Function hdmi_mode_fixup() used bare list_for_each entry, which was unsafe and caused memory corruption detected by kasan. It now uses drm_for_each_connector_iter macro, which is now recommended by the documentation and safe. Signed-off-by: Maciej Purski Signed-off-by: Inki Dae

drm/exynos: use helper to set possible crtcs

2017-08-25T02:26:10Z

All encoders share the same code to set encoders possible_crtcs field. The patch creates helper to abstract out this code. Signed-off-by: Andrzej Hajda Signed-off-by: Inki Dae

Backmerge tag 'v4.13-rc5' into drm-next

2017-08-15T06:16:58Z

Linux 4.13-rc5 There's a really nasty nouveau collision, hopefully someone can take a look once I pushed this out.