kernel/linux.git/drivers/gpu/drm/sun4i, branch v5.10.45

drm/sun4i: tcon: fix inverted DCLK polarity

2021-03-04T10:37:41+00:00

[ Upstream commit 67f4aeb2b41a0629abde3794d463547f60b0cbdd ] During commit 88bc4178568b ("drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags") DRM_BUS_FLAG_* macros have been changed to avoid ambiguity but just because of this ambiguity previous DRM_BUS_FLAG_PIXDATA_(POS/NEG)EDGE were used meaning _SAMPLE_ not _DRIVE_. This leads to DLCK inversion and need to fix but instead of swapping phase values, let's adopt an easier approach Maxime suggested: It turned out that bit 26 of SUN4I_TCON0_IO_POL_REG is dedicated to invert DCLK polarity and this makes things really easier than before. So let's handle DCLK polarity by adding SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE as bit 26 and activating according to bus_flags the same way it is done for all the other signals polarity. Fixes: 88bc4178568b ("drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags") Suggested-by: Maxime Ripard Signed-off-by: Giulio Benetti Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20210114081732.9386-1-giulio.benetti@benettiengineering.com Signed-off-by: Sasha Levin

drm/sun4i: dw-hdmi: Fix max. frequency for H6

2021-02-17T10:02:28+00:00

[ Upstream commit 1926a0508d8947cf081280d85ff035300dc71da7 ] It turns out that reasoning for lowering max. supported frequency is wrong. Scrambling works just fine. Several now fixed bugs prevented proper functioning, even with rates lower than 340 MHz. Issues were just more pronounced with higher frequencies. Fix that by allowing max. supported frequency in HW and fix the comment. Fixes: cd9063757a22 ("drm/sun4i: DW HDMI: Lower max. supported rate for H6") Reviewed-by: Chen-Yu Tsai Tested-by: Andre Heider Signed-off-by: Jernej Skrabec Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20210209175900.7092-6-jernej.skrabec@siol.net Signed-off-by: Sasha Levin

drm/sun4i: Fix H6 HDMI PHY configuration

2021-02-17T10:02:28+00:00

[ Upstream commit 6a155216c48f2f65c8dcb02c4c27549c170d24a9 ] As it turns out, vendor HDMI PHY driver for H6 has a pretty big table of predefined values for various pixel clocks. However, most of them are not useful/tested because they come from reference driver code. Vendor PHY driver is concerned with only few of those, namely 27 MHz, 74.25 MHz, 148.5 MHz, 297 MHz and 594 MHz. These are all frequencies for standard CEA modes. Fix sun50i_h6_cur_ctr and sun50i_h6_phy_config with the values only for aforementioned frequencies. Table sun50i_h6_mpll_cfg doesn't need to be changed because values are actually frequency dependent and not so much SoC dependent. See i.MX6 documentation for explanation of those values for similar PHY. Fixes: c71c9b2fee17 ("drm/sun4i: Add support for Synopsys HDMI PHY") Tested-by: Andre Heider Signed-off-by: Jernej Skrabec Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20210209175900.7092-5-jernej.skrabec@siol.net Signed-off-by: Sasha Levin

drm/sun4i: dw-hdmi: always set clock rate

2021-02-17T10:02:27+00:00

[ Upstream commit 36b53581fe0dc2e25b67de4e58920307f22d195a ] As expected, HDMI controller clock should always match pixel clock. In the past, changing HDMI controller rate would seemingly worsen situation. However, that was the result of other bugs which are now fixed. Fix that by removing set_rate quirk and always set clock rate. Fixes: 40bb9d3147b2 ("drm/sun4i: Add support for H6 DW HDMI controller") Reviewed-by: Chen-Yu Tsai Tested-by: Andre Heider Signed-off-by: Jernej Skrabec Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20210209175900.7092-4-jernej.skrabec@siol.net Signed-off-by: Sasha Levin

drm/sun4i: tcon: set sync polarity for tcon1 channel

2021-02-17T10:02:27+00:00

[ Upstream commit 50791f5d7b6a14b388f46c8885f71d1b98216d1d ] Channel 1 has polarity bits for vsync and hsync signals but driver never sets them. It turns out that with pre-HDMI2 controllers seemingly there is no issue if polarity is not set. However, with HDMI2 controllers (H6) there often comes to de-synchronization due to phase shift. This causes flickering screen. It's safe to assume that similar issues might happen also with pre-HDMI2 controllers. Solve issue with setting vsync and hsync polarity. Note that display stacks with tcon top have polarity bits actually in tcon0 polarity register. Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support") Reviewed-by: Chen-Yu Tsai Tested-by: Andre Heider Signed-off-by: Jernej Skrabec Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20210209175900.7092-3-jernej.skrabec@siol.net Signed-off-by: Sasha Levin

Merge tag 'drm/sun4i-dma-fix-pull-request' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mripard/linux into drm-misc-fixes

2020-11-19T08:26:07+00:00

Fix for drm/sun4i shared with arm-soc This patch is a preliminary fix that will conflict with subsequent work merged through arm-soc. Signed-off-by: Maxime Ripard # gpg: Signature made Wed 18 Nov 2020 09:51:53 AM CET # gpg: using EDDSA key 5C1337A45ECA9AEB89060E9EE3EF0D6F671851C5 # gpg: Good signature from "Maxime Ripard " [unknown] # gpg: aka "Maxime Ripard " [unknown] # gpg: aka "Maxime Ripard (Work Address) " [unknown] # gpg: aka "Maxime Ripard (Work Address) " [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: BE56 75C3 7E81 8C8B 5764 241C 254B CFC5 6BF6 CE8D # Subkey fingerprint: 5C13 37A4 5ECA 9AEB 8906 0E9E E3EF 0D6F 6718 51C5 From: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20201118090455.sznrgpduuytlc22k@gilmour.lan

drm/sun4i: backend: Fix probe failure with multiple backends

2020-11-18T08:01:30+00:00

Commit e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset") introduced a regression in our code since the second backed to probe will now get -EINVAL back from dma_direct_set_offset and will prevent the entire DRM device from probing. Ignore -EINVAL as a temporary measure to get it back working, before removing that call entirely. Fixes: e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset") Signed-off-by: Maxime Ripard Reviewed-by: Chen-Yu Tsai Reviewed-by: Christoph Hellwig Acked-by: Daniel Vetter

drm/sun4i: dw-hdmi: fix error return code in sun8i_dw_hdmi_bind()

2020-11-17T17:23:00+00:00

Fix to return a negative error code from the error handling case instead of 0 in function sun8i_dw_hdmi_bind(). Fixes: b7c7436a5ff0 ("drm/sun4i: Implement A83T HDMI driver") Reported-by: Hulk Robot Signed-off-by: Xiongfeng Wang Reviewed-by: Jernej Skrabec Signed-off-by: Jernej Skrabec Link: https://patchwork.freedesktop.org/patch/msgid/1605488969-5211-1-git-send-email-wangxiongfeng2@huawei.com

drm/sun4i: frontend: Fix the scaler phase on A33

2020-10-26T10:43:30+00:00

The A33 has a different phase parameter in the Allwinner BSP on the channel1 than the one currently applied. Fix this. Signed-off-by: Maxime Ripard Acked-by: Jernej Skrabec Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-3-maxime@cerno.tech

drm/sun4i: frontend: Reuse the ch0 phase for RGB formats

2020-10-26T10:43:30+00:00

When using the scaler on the A10-like frontend with single-planar formats, the current code will setup the channel 0 filter (used for the R or Y component) with a different phase parameter than the channel 1 filter (used for the G/B or U/V components). This creates a bleed out that keeps repeating on of the last line of the RGB plane across the rest of the display. The Allwinner BSP either applies the same phase parameter over both channels or use a separate one, the condition being whether the input format is YUV420 or not. Since YUV420 is both subsampled and multi-planar, and since YUYV is subsampled but single-planar, we can rule out the subsampling and assume that the condition is actually whether the format is single or multi-planar. And it looks like applying the same phase parameter over both channels for single-planar formats fixes our issue, while we keep the multi-planar formats working properly. Reported-by: Taras Galchenko Signed-off-by: Maxime Ripard Acked-by: Jernej Skrabec Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-2-maxime@cerno.tech