Skip to content

GitLab

L
linux
Switch branch/tag
  1. 26 Nov, 2018 1 commit
    • Laurent Pinchart's avatar
      drm: rcar-du: Fix DU3 start/stop on M3-N · 0bc3544a
      Laurent Pinchart authored 
      Group start/stop is controlled by the DRES and DEN bits of DSYSR0 for
the first group and DSYSR2 for the second group. On most DU instances,
this maps to the first CRTC of the group. On M3-N, however, DU2 doesn't
exist, but DSYSR2 does. There is no CRTC object there that maps to the
correct DSYSR register.

Commit 9144adc5 ("drm: rcar-du: Cache DSYSR value to ensure known
initial value") switched group start/stop from using group read/write
access to DSYSR to a CRTC-based API to cache the DSYSR value. While
doing so, it introduced a regression on M3-N by accessing DSYSR3 instead
of DSYSR2 to start/stop the second group.

To fix this, access the DSYSR register directly through group read/write
if the SoC is missing the first DU channel of the group. Keep using the
rcar_du_crtc_dsysr_clr_set() function otherwise, to retain the DSYSR
caching feature.

Fixes: 9144adc5 ("drm: rcar-du: Cache DSYSR value to ensure known initial value")
Reported-by: default avatarHoan Nguyen An <na-hoan@jinso.co.jp>
Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: default avatarKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Tested-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      0bc3544a
  3. 24 Sep, 2018 3 commits
    • Laurent Pinchart's avatar
      drm: rcar-du: Cache DSYSR value to ensure known initial value · 9144adc5
      Laurent Pinchart authored 
      DSYSR is a DU channel register that also contains group fields. It is
thus written to by both the group and CRTC code, using read-update-write
sequences. As the register isn't initialized explicitly at startup time,
this can lead to invalid or otherwise unexpected values being written to
some of the fields if they have been modified by the firmware or just
not reset properly.

To fix this we can write a fully known value to the DSYSR register when
turning a channel's functional clock on. However, the mix of group and
channel fields complicate this. A simpler solution is to cache the
register and initialize the cached value to the desired hardware
defaults.
Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: default avatarJacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: default avatarKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
      9144adc5
    • Laurent Pinchart's avatar
      drm: rcar-du: Enable configurable DPAD0 routing on Gen3 · 1f98b2a4
      Laurent Pinchart authored 
      All Gen3 SoCs supported so far have a fixed association between DPAD0
and DU channels, which led to hardcoding that association when writing
the corresponding hardware register. The D3 and E3 will break that
mechanism as DPAD0 can be dynamically connected to either DU0 or DU1.

Make DPAD0 routing dynamic on Gen3. To ensure a valid hardware
configuration when the DU starts without the RGB output enabled, DPAD0
is associated at initialization time to the first DU channel that it can
be connected to. This makes no change on Gen2 as all Gen2 SoCs can
connected DPAD0 to DU0, which is the current implicit default value.

As the DPAD0 source is always 0 when a single source is possible on
Gen2, we can also simplify the Gen2 code in the same function to remove
a conditional check.
Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: default avatarJacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: default avatarJacopo Mondi <jacopo+renesas@jmondi.org>
      1f98b2a4
    • Laurent Pinchart's avatar
      drm: rcar-du: Use LVDS PLL clock as dot clock when possible · b4734f43
      Laurent Pinchart authored 
      On selected SoCs, the DU can use the clock output by the LVDS encoder
PLL as its input dot clock. This feature is optional, but on the D3 and
E3 SoC it is often the only way to obtain a precise dot clock frequency,
as the other available clocks (CPG-generated clock and external clock)
usually have fixed rates.

Add a DU model information field to describe which DU channels can use
the LVDS PLL output clock as their input clock, and configure clock
routing accordingly.

This feature is available on H2, M2-W, M2-N, D3 and E3 SoCs, with D3 and
E3 being the primary targets. It is left disabled in this commit, and
will be enabled per-SoC after careful testing.

At the hardware level, clock routing is configured at runtime in two
steps, first selecting an internal dot clock between the LVDS PLL clock
and the external DOTCLKIN clock, and then selecting between the internal
dot clock and the CPG-generated clock. The first part requires stopping
the whole DU group in order for the change to take effect, thus causing
flickering on the screen. For this reason we currently hardcode the
clock source to the LVDS PLL clock if available, and allow flicker-free
selection of the external DOTCLKIN clock or CPG-generated clock
otherwise. A more dynamic clock selection process can be implemented
later if the need arises.
Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: default avatarJacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: default avatarJacopo Mondi <jacopo+renesas@jmondi.org>
      b4734f43
  5. 14 Sep, 2018 1 commit
  7. 05 May, 2018 2 commits
  9. 03 Aug, 2017 2 commits
  11. 14 Nov, 2016 1 commit
  13. 23 Feb, 2016 2 commits
  15. 20 Feb, 2016 2 commits
  17. 21 Oct, 2015 1 commit
  19. 25 May, 2015 1 commit
  21. 23 Dec, 2014 2 commits
  23. 15 Sep, 2014 1 commit
  25. 09 Aug, 2013 6 commits