Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 13 10月, 2017 1 次提交
  3. 23 8月, 2017 1 次提交
  5. 08 8月, 2017 1 次提交
  7. 02 8月, 2017 4 次提交
    • A
      drm/msm/mdp5: Don't use mode_set helper funcs for encoders and CRTCs · 710e7a44
      由 Archit Taneja 提交于 
      We shouldn't use use mode_set/mode_set_nofb helpers when we use runtime
PM. The registers configured in these funcs lose their state when we
eventually enable the display pipeline.

Do not implement these vfuncs in the helpers, and call them in the
crtc_enable/encoder_enable paths instead.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      710e7a44
    • A
      drm/msm/mdp5: Use runtime PM get/put API instead of toggling clocks · d68fe15b
      由 Archit Taneja 提交于 
      mdp5_enable/disable calls are scattered all around in the MDP5 code.
Use the pm_runtime_get/put calls here instead, and populate the
runtime PM suspend/resume ops to manage the clocks.

About the overall design: MDP5 is a child of the top level MDSS
device. MDSS is also the parent to DSI, HDMI and other interfaces. When
we enable MDP5's power domain, we end up enabling MDSS's PD too. It is
only MDSS's PD that actually controlls the GDSC HW. Therefore, calling
runtime_get/put on the MDP5 device is like just requesting a vote to
enable/disable the GDSC.

Functionally, replacing the clock enable/disable calls with the RPM API
can result in the power domain (GDSC) state being toggled if no other
child isn't powered on. This can result in the register context being lost.
We make sure (in future commits) that code paths don't end up configuring
registers and then later lose state, resulting in a bad HW state.

For now, we've replaced each mdp5_enable/disable with runtime_get/put API.
We could optimize things later by removing runtime_get/put calls which
don't really need to be there. This could prevent unnecessary toggling of
the power domain and clocks.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      d68fe15b
    • R
      drm/msm/mdp5: fix unclocked register access in _cursor_set() · af1f5f12
      由 Rob Clark 提交于 
      Fixes an insta-reboot when screen-blanking kicks in, due to cursor
updates without clocks enabled.
Signed-off-by: NRob Clark <robdclark@gmail.com>
      af1f5f12
    • V
      drm/msm/mdp5: Fix compilation warnings · d490c9cd
      由 Viresh Kumar 提交于 
      Following compilation warnings were observed for these files:

  CC [M]  drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.o
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c: In function 'blend_setup':
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c:223:7: warning: missing braces around initializer [-Wmissing-braces]
  enum mdp5_pipe stage[STAGE_MAX + 1][MAX_PIPE_STAGE] = { SSPP_NONE };
       ^
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c:223:7: warning: (near initialization for 'stage[0]') [-Wmissing-braces]
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c:224:7: warning: missing braces around initializer [-Wmissing-braces]
  enum mdp5_pipe r_stage[STAGE_MAX + 1][MAX_PIPE_STAGE] = { SSPP_NONE };
       ^
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c:224:7: warning: (near initialization for 'r_stage[0]') [-Wmissing-braces]

drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: In function 'mdp5_plane_mode_set':
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:892:9: warning: missing braces around initializer [-Wmissing-braces]
  struct phase_step step = { 0 };
         ^
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:892:9: warning: (near initialization for 'step.x') [-Wmissing-braces]
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:893:9: warning: missing braces around initializer [-Wmissing-braces]
  struct pixel_ext pe = { 0 };
         ^
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:893:9: warning: (near initialization for 'pe.left') [-Wmissing-braces]

This happens because in the first case we were initializing a two
dimensional array with {0} and in the second case we were initializing a
struct containing two arrays with {0}.

Fix them by adding another pair of {}.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      d490c9cd
  9. 30 6月, 2017 2 次提交
  11. 16 6月, 2017 2 次提交
  13. 17 5月, 2017 1 次提交
  15. 08 4月, 2017 13 次提交
    • A
      drm/msm/mdp5: Assign 'right' mixer to CRTC state · 8480adac
      由 Archit Taneja 提交于 
      Dynamically assign a right mixer to mdp5_crtc_state in the CRTC's
atomic_check path. Assigning the right mixer has some constraints,
i.e, only a few LMs can be paired together. Update mdp5_mixer_assign
to handle these constraints.

Firstly, we need to identify whether we need a right mixer or not.
At the moment, there are 2 scenarios where a right mixer might be
needed:
- If any of the planes connected to this CRTC is too wide (i.e, is
  comprised of 2 hwpipes).
- If the CRTC's mode itself is too wide (i.e, a 4K mode on HDMI).

We implement both these checks in the mdp5_crtc_atomic_check(), and
pass 'need_right_mixer' to mdp5_setup_pipeline.

If a CRTC is already assigned a single mixer, and a new atomic commit
brings in a drm_plane that needs 2 hwpipes, we can successfully commit
this mode without requiring a full modeset, provided that we still use
the previously assigned mixer as the left mixer. If such an assignment
isn't possible, we'd need to do a full modeset. This scenario has been
ignored for now.

The mixer assignment code is a bit messy, considering we have at most
4 LM instances in hardware. This can probably be re-visited later with
simplified logic.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      8480adac
    • A
      drm/msm/mdp5: Stage border out on base stage if CRTC has 2 LMs · 359ae862
      由 Archit Taneja 提交于 
      If a CRTC comprises of 2 LMs, it is mandatory to enable border out
and assign it to the base stage.

We had to enable border out also when the base plane wasn't fullscreen.
Club these checks and put them in a separate function called
get_start_stage() that returns the starting stage for assigning planes.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      359ae862
    • A
      drm/msm/mdp5: Stage right side hwpipes on Right-side Layer Mixer · bf8dc0a0
      由 Archit Taneja 提交于 
      Now that our mdp5_planes can consist of 2 hwpipes, update the
blend_setup() code to stage the right hwpipe to the left and
right LMs
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      bf8dc0a0
    • A
      drm/msm/mdp5: Prepare Layer Mixers for source split · ed78560d
      由 Archit Taneja 提交于 
      In order to enable Source Split in HW, we need to add/modify
a few LM register configurations:

- Configure the LM width to be half the mode width, so that
  each LM manages one half of the scanout.
- Tell the 'right' LM that it is configured to be the 'right'
  LM in source split mode.
- Since we now have 2 places where REG_MDP5_LM_BLEND_COLOR_OUT is
  configured, do a read-update-store for the register instead of
  directly writing a value to it.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      ed78560d
    • A
      drm/msm/mdp5: Add optional 'right' Layer Mixer in CRTC state · b7621b2a
      由 Archit Taneja 提交于 
      Add another mdp5_hw_mixer pointer (r_mixer) in mdp5_crtc_state.
This mixer will be used to generate the right half of the scanout.

With Source Split, a SSPP can now be connected to 2 Layer Mixers, but
has to be at the same blend level (stage #) on both Layer Mixers.

A drm_plane that has a lesser width than the max width supported, will
comprise of a single SSPP/hwpipe, staged on both the Layer Mixers at
the same blend level. A plane that is greater than max width will comprise
of 2 SSPPs, with the 'left' SSPP staged on the left LM, and the 'right'
SSPP staged on the right LM at the same blend level.

For now, the drm_plane consists of only one SSPP, therefore, it
needs to be staged on both the LMs in blend_setup() and mdp5_ctl_blend().
We'll extend this logic to support 2 hwpipes per plane later.

The crtc cursor ops (using the LM cursors, not SSPP cursors) simply
return an error if they're called when the right mixer is assigned to
the CRTC state. With source split is enabled, we're expected to only
SSPP cursors.

This commit adds code that configures the right mixer, but the r_mixer
itself isn't assigned at the moment.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      b7621b2a
    • A
      drm/msm/mdp5: Remove mixer/intf pointers from mdp5_ctl · f316b25a
      由 Archit Taneja 提交于 
      These are a part of CRTC state, it doesn't feel nice to leave them
hanging in mdp5_ctl struct. Pass mdp5_pipeline pointer instead
wherever it is needed.

We still have some params in mdp5_ctl like start_mask etc which
are derivative of atomic state, and should be rolled back if
a commit fails, but it doesn't seem to cause much trouble.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      f316b25a
    • A
      drm/msm/mdp5: Start using parameters from CRTC state · 0ddc3a63
      由 Archit Taneja 提交于 
      In the last few commits, we've been adding params to mdp5_crtc_state, and
assigning them in the atomic_check() funcs. Now it's time to actually
start using them.

Remove the duplicated params from the mdp5_crtc struct, and start using
them in the mdp5_crtc code. The majority of the references to these params
is in code that executes after the atomic swap has occurred, so it's okay
to use crtc->state in them. There are a couple of legacy LM cursor ops that
may not use the updated state, but (I think) it's okay to live with that.

Now that we dynamically allocate a mixer to the CRTC, we can also remove
the static assignment to it in mdp5_crtc_init, and also drop the code that
skipped init-ing WB bound mixers (those will now be rejected by
mdp5_mixer_assign()).
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      0ddc3a63
    • A
      drm/msm/mdp5: Add more stuff to CRTC state · bcb877b7
      由 Archit Taneja 提交于 
      Things like vblank/err irq masks, mode of operation (command mode or not)
are derivative of the interface and mixer state. Therefore, they need to
be a part of the CRTC state too.

Add them to mdp5_crtc_state, and assign them in the CRTC's atomic_check()
func, so that it can be rolled back to a clean state.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      bcb877b7
    • A
      drm/msm/mdp5: Prepare for dynamic assignment of mixers · 894558ec
      由 Archit Taneja 提交于 
      Add the stuff needed to allow dynamically assigning a mixer to a CRTC.

Since mixers are a resource that can be shared across multiple CRTCs, we
need to maintain a 'hwmixer_to_crtc' map in the global atomic state,
acquire the mdp5_kms.state_lock modeset lock and so on.

The mixer is assigned in the CRTC's atomic_check() func, a failure will
result in the new state being cleanly rolled back.

The mixer assignment itself is straightforward, and almost identical to
what we do for hwpipes. We don't need to grab the old hwmixer_to_crtc
state like we do in hwpipes since we don't need to compare anything
with the old state at the moment.

The only LM capability we care about at the moment is whether the mixer
instance can be used to display stuff (i.e, connect to an INTF
downstream).
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      894558ec
    • A
      drm/msm/mdp5: subclass CRTC state · c1e2a130
      由 Archit Taneja 提交于 
      Subclass drm_crtc_state so that we can maintain additional state for
our CRTCs.

Add mdp5_pipeline and mdp5_ctl pointers in the subclassed state.
mdp5_pipeline is a grouping of the HW entities that forms the downstream
pipeline for a particular CRTC. It currently contains pointers to
mdp5_interface and mdp5_hw_mixer tied to this CRTC. Later, we will
have 2 hwmixers in this struct. (We could also have 2 intfs if we want
to support dual DSI with Source Split enabled. Implementing that feature
isn't planned at the moment).

The mdp5_pipeline state isn't used at the moment. For now, we just
introduce mdp5_crtc_state and the crtc funcs needed to manage the
subclassed state.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      c1e2a130
    • A
      drm/msm/mdp5: Simplify LM <-> PP mapping · a2380124
      由 Archit Taneja 提交于 
      PingPong ID for a Layer Mixer is already contained in
mdp5_hw_mixer.

This avoids the need to retrieve PP ID using macros
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      a2380124
    • A
      drm/msm/mdp5: Start using mdp5_hw_mixer · adfc0e63
      由 Archit Taneja 提交于 
      Use the mdp5_hw_mixer struct in the mdp5_crtc and mdp5_ctl instead of
using the LM index.

Like before, the Layer Mixers are assigned statically to the CRTCs.
The hwmixer(s) will later be dynamically assigned to CRTCs.

For now, ignore the hwmixers that can only do WB.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      adfc0e63
    • D
      drm/msm: Simplify vblank event delivery · 02efb359
      由 Daniel Vetter 提交于 
      The core takes care of handling the send_event vs. close() issues, we
can remove that driver code.

Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      02efb359
  17. 07 2月, 2017 4 次提交
    • A
      drm/msm/mdp5: Add support for legacy cursor updates · 10967a06
      由 Archit Taneja 提交于 
      This code has been more or less picked up from the vc4 and intel
implementations of update_plane() funcs for cursor planes.

The update_plane() func is usually the drm_atomic_helper_update_plane
func that will issue an atomic commit with the plane updates. Such
commits are not intended to be done faster than the vsync rate.

The legacy cursor userspace API, on the other hand, expects the kernel
to handle cursor updates immediately.

Create a fast path in update_plane, which updates the cursor registers
and flushes the configuration. The fast path is taken when there is only
a change in the cursor's position in the crtc, or a change in the
cursor's crop co-ordinates. For anything else, we go via the slow path.

We take the slow path even when the fb changes, and when there is
currently no fb tied to the plane. This should hopefully ensure that we
always take a slow path for every new fb. This in turn should ensure that
the fb is pinned/prepared.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      10967a06
    • A
      drm/msm/mdp5: Misc cursor plane bits · 5798c8e0
      由 Archit Taneja 提交于 
      These are various changes added in preparation for cursor planes:

- Add a pipe_cursor block for 8x96 in mdp5_cfg.
- Add a new pipe CAP called MDP_PIPE_CAP_CURSOR. Use this to ensure we
  assign a cursor SSPP for a drm_plane with type DRM_PLANE_TYPE_CURSOR.
- Update mdp5_ctl_blend_mask/ext_blend_mask funcs to incorporate cursor
  SSPPs.
- In mdp5_ctl_blend, iterate through MAX_STAGES instead of stage_cnt,
  we need to do this because we can now have empty stages in between.
- In mdp5_crtc_atomic_check, make sure that the cursor plane has the
  highest zorder, and stage the cursor plane to the maximum stage #
  present on the HW.
- Create drm_crtc_funcs that doesn't try to implement cursors using the
  older LM cursor HW.
- Pass drm_plane_type in mdp5_plane_init instead of a bool telling
  whether plane is primary or not.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      5798c8e0
    • A
      drm/msm/mdp5: Configure COLOR3_OUT propagation · 829200ac
      由 Archit Taneja 提交于 
      In MDP5 Layer Mixer HW, the blender output is only the blended color
components (i.e R, G and B, or COLOR0/1/2 in MDP5 HW terminology). This
is fed to the BG input of the next blender. We also need to provide an
alpha (COLOR3) value for the BG input at the next stage.

This is configured via using the REG_MDP5_LM_BLEND_COLOR_OUT register.
For each stage, we can propagate either the BG or FG alpha to the next
stage.

The approach taken by the driver is to propagate FG alpha, if the plane
staged on that blender has an alpha. If it doesn't, we try to propagate
the base layer's alpha.

This is borrowed from downstream MDP5 kernel driver. Without this, we
don't see any cursor plane content.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      829200ac
    • A
      drm/msm/mdp5: Prepare CRTC/LM for empty stages · 106f9727
      由 Archit Taneja 提交于 
      Use SSPP_NONE in mdp5_plane_pipe() if there is now hwpipe allocated for
the drm_plane. Returning '0' means we are returning VIG0 pipe.

Also, use the mdp5_pipe enum to pass around the stage array. Initialize
the stage to SSPP_NONE by default.

We do the above because 1) Cursor plane has to be staged at the topmost
blender of the LM, which can result in empty stages in between 2) In
the future, when we support multiple LMs per CRTC. We could have stages
which don't have any pipe assigned to them.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
      106f9727
  19. 29 11月, 2016 1 次提交
    • R
      drm/msm: convert iova to 64b · 78babc16
      由 Rob Clark 提交于 
      For a5xx the gpu is 64b so we need to change iova to 64b everywhere.  On
the display side, iova is still 32b so it can ignore the upper bits.
(Although all the armv8 devices have an iommu that can map 64b pa to 32b
iova.)
Signed-off-by: NRob Clark <robdclark@gmail.com>
      78babc16
  21. 28 11月, 2016 4 次提交
    • R
      drm/msm/mdp5: dynamically assign hw pipes to planes · 4a0f012d
      由 Rob Clark 提交于 
      (re)assign the hw pipes to planes based on required caps, and to handle
situations where we could not modify an in-use plane (ie. SMP block
reallocation).

This means all planes advertise the superset of formats and properties.
Userspace must (as always) use atomic TEST_ONLY step for atomic updates,
as not all planes may be available for use on every frame.

The mapping of hwpipe to plane is stored in mdp5_state, so that state
updates are atomically committed in the same way that plane/etc state
updates are managed.  This is needed because the mdp5_plane_state keeps
a pointer to the hwpipe, and we don't want global state to become out
of sync with the plane state if an atomic update fails, we hit deadlock/
backoff scenario, etc.  The use of state_lock keeps multiple parallel
updates which both re-assign hwpipes properly serialized.
Signed-off-by: NRob Clark <robdclark@gmail.com>
      4a0f012d
    • R
      drm/msm/mdp5: introduce mdp5_hw_pipe · c056b55d
      由 Rob Clark 提交于 
      Split out the hardware pipe specifics from mdp5_plane.  To start, the hw
pipes are statically assigned to planes, but next step is to assign the
hw pipes during plane->atomic_check() based on requested caps (scaling,
YUV, etc).  And then hw pipe re-assignment if required if required SMP
blocks changes.
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
      c056b55d
    • R
      drm/msm/mdp5: nuke mdp5_plane_complete_flip() · a2100695
      由 Rob Clark 提交于 
      We can do this all from mdp5_plane_complete_commit(), so simplify things
a bit and drop mdp5_plane_complete_flip().
Signed-off-by: NRob Clark <robdclark@gmail.com>
      a2100695
    • R
      drm/msm/mdp5: drop mdp5_crtc::name · cee26588
      由 Rob Clark 提交于 
      Plane's (pipes) can be assigned dynamically with atomic, so it doesn't
make much sense to name the pipe after it's primary plane.
Signed-off-by: NRob Clark <robdclark@gmail.com>
      cee26588
  23. 27 11月, 2016 1 次提交
    • R
      drm/msm/mdp5: handle non-fullscreen base plane case · 1455adbd
      由 Rob Clark 提交于 
      If the bottom-most layer is not fullscreen, we need to use the BASE
mixer stage for solid fill (ie. MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT).  The
blend_setup() code pretty much handled this already, we just had to
figure this out in _atomic_check() and assign the stages appropriately.

Also fix the case where there are zero enabled planes, where we also
need to enable BORDER_OUT.
Signed-off-by: NRob Clark <robdclark@gmail.com>
      1455adbd
  25. 02 11月, 2016 1 次提交
    • R
      drm/msm/mdp5: handle non-fullscreen base plane case · 31e4801a
      由 Rob Clark 提交于 
      If the bottom-most layer is not fullscreen, we need to use the BASE
mixer stage for solid fill (ie. MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT).  The
blend_setup() code pretty much handled this already, we just had to
figure this out in _atomic_check() and assign the stages appropriately.

Also fix the case where there are zero enabled planes, where we also
need to enable BORDER_OUT.
Signed-off-by: NRob Clark <robdclark@gmail.com>
      31e4801a
  27. 16 7月, 2016 1 次提交
  29. 02 6月, 2016 1 次提交
  31. 17 5月, 2016 1 次提交
  33. 02 5月, 2016 1 次提交