BMC/Intel-BMC/linux.git/drivers/gpu/drm/rcar-du, branch dev-5.2

drm: rcar-du: lvds: Set LVEN and LVRES bits together on D3

2019-03-28T04:12:42+00:00

On the D3 SoC the LVDS PHY must be enabled in the same register write that enables the LVDS output. Skip writing the LVEN bit independently on that platform, it will be set by the write that sets LVRES. Signed-off-by: Laurent Pinchart Reviewed-by: Jacopo Mondi

drm: rcar-du: lvds: Adjust operating frequency for D3 and E3

2019-03-28T04:12:38+00:00

The D3 and E3 SoCs have different pixel clock frequency limits for the LVDS encoder than the other SoCs in the Gen3 family. Adjust the mode fixup implementation accordingly. Signed-off-by: Laurent Pinchart Reviewed-by: Jacopo Mondi

drm: rcar-du: Link CRTCs to the DU device

2019-03-28T04:06:33+00:00

The rcar_du_crtc functions have a heavy reliance on the rcar_du_group structure, in many cases just to access the DU device context. To better separate the groups out of the CRTC handling code, give the rcar_du_crtc its own pointer to the device and remove the indirection through the group pointers. Signed-off-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart

drm: rcar-du: lvds: Fix post-DLL divider calculation

2019-03-28T04:06:33+00:00

The PLL parameters are computed by looping over the range of acceptable M, N and E values, and selecting the combination that produces the output frequency closest to the target. The internal frequency constraints are taken into account by restricting the tested values for the PLL parameters, reducing the search space. The target frequency, however, is only taken into account when computing the post-PLL divider, which can result in a 0 value for the divider when the PLL output frequency being tested is lower than half of the target frequency. Subsequent loops will produce a better set of PLL parameters, but for some of the iterations this can result in a division by 0. Fix it by clamping the divider value. We could instead restrict the E values being tested in the inner loop, but that would require additional calculation that would likely be less efficient as the E parameter can only take three different values. Fixes: c25c01361199 ("drm: rcar-du: lvds: D3/E3 support") Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham

drm: rcar-du: Remove unused prototypes

2019-03-28T04:06:33+00:00

The CRTC suspend and resume functions have been replaced, but the prototypes were not removed. Remove the redundant definitions. Signed-off-by: Kieran Bingham Reviewed-by: Simon Horman Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart

drm: rcar-du: crtc: Make local functions static

2019-03-28T04:06:33+00:00

The rcar_du_crtc_mode_valid() and rcar_du_crtc_get_crc_sources() functions are accessed only through a function pointer table. Convert the function definitions to be static to the module. Signed-off-by: Kieran Bingham Reviewed-by: Simon Horman Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart

drm: rcar-du: Support panels connected directly to the DPAD outputs

2019-03-28T04:06:33+00:00

The R-Car DU driver assumes that a bridge is always connected to the DU output. This is valid for the LVDS and HDMI outputs, but the DPAD outputs can be connected directly to a panel, in which case no bridge is available. To support this use case, detect whether the entities connected to the DU DPAD outputs are encoders or panels based on the number of ports of their DT node, and retrieve the corresponding type of DRM objects. For panels, additionally create panel bridge instances. Signed-off-by: Laurent Pinchart Tested-by: Kevin Key Reviewed-by: Kieran Bingham Reviewed-by: Jacopo Mondi

drm: rcar-du: Add writeback support for R-Car Gen3

2019-03-18T15:24:51+00:00

Implement writeback support for R-Car Gen3 by exposing writeback connectors. Behind the scene the calls are forwarded to the VSP backend. Using writeback connectors will allow implemented writeback support for R-Car Gen2 with a consistent API if desired. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham

drm: rcar-du: vsp: Extract framebuffer (un)mapping to separate functions

2019-03-18T15:24:46+00:00

The rcar_du_vsp_plane_prepare_fb() and rcar_du_vsp_plane_cleanup_fb() functions implement the DRM plane .prepare_fb() and .cleanup_fb() operations. They map and unmap the framebuffer to/from the VSP internally, which will be useful to implement writeback support. Split the mapping and unmapping out to separate functions. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham

drm: rcar-du: Store V4L2 fourcc in rcar_du_format_info structure

2019-03-18T15:24:45+00:00

The mapping between DRM and V4L2 fourcc's is stored in two separate tables in rcar_du_vsp.c. In order to make it reusable to implement writeback support, move it to the rcar_du_format_info structure. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham