diff mbox series

drm/msm/mdp5: Use eariler mixers when possible

Message ID 20190701174120.15551-1-jeffrey.l.hugo@gmail.com (mailing list archive)
State Not Applicable, archived
Headers show
Series drm/msm/mdp5: Use eariler mixers when possible | expand

Commit Message

Jeffrey Hugo July 1, 2019, 5:41 p.m. UTC
When assigning a mixer, we will iterate through the entire list looking for
a suitable match.  This results in selecting the last match.  We should
stop at the first match, since lower numbered mixers will typically have
more capabilities, and are likely to be what the bootloader used, if we
are looking to reuse the bootloader config in future.

Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

Comments

Rob Clark July 1, 2019, 7:55 p.m. UTC | #1
On Mon, Jul 1, 2019 at 10:41 AM Jeffrey Hugo <jeffrey.l.hugo@gmail.com> wrote:
>
> When assigning a mixer, we will iterate through the entire list looking for
> a suitable match.  This results in selecting the last match.  We should
> stop at the first match, since lower numbered mixers will typically have
> more capabilities, and are likely to be what the bootloader used, if we
> are looking to reuse the bootloader config in future.

I think for matching bootloader config, we need to read it out of the
hw and do it the hard way, rather than making assumptions.

For picking hwpipe for a plane, I made an effort to pick the available
hwpipe w/ the *least* capabilities that fit the requirements (ie.
scaling/yuv/etc) in order to leave the more capable hwpipe available
for future use.  Not sure if same approach would make sense for
mixers?  But not sure if picking something that bootloader probably
also would have picked is a great argument.

I do have some (now ancient) code from db410/mdp5 to read out he hw
state.. I *think* that might have post-dated dynamically picking
mixers.  (The older mdp5 on db410c also had to deal with figuring out
SMP block config, iirc.. thankfully newer mdp5 doesn't have to deal
with that.)

BR,
-R

>
> Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
> ---
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c
> index 954db683ae44..1638042ad974 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c
> @@ -96,6 +96,17 @@ int mdp5_mixer_assign(struct drm_atomic_state *s, struct drm_crtc *crtc,
>                  */
>                 if (!(*mixer) || cur->caps & MDP_LM_CAP_PAIR)
>                         *mixer = cur;
> +
> +               /*
> +                * We have everything we could want, exit early.
> +                * We have a valid mixer, that mixer pairs with another if we
> +                * need that ability in future, and we have a right mixer if
> +                * needed.
> +                * Later LMs could be less optimal
> +                */
> +               if (*mixer && (*mixer)->caps & MDP_LM_CAP_PAIR &&
> +                   ((r_mixer && *r_mixer) || !r_mixer))
> +                       break;
>         }
>
>         if (!(*mixer))
> --
> 2.17.1
>
Jeffrey Hugo July 5, 2019, 7:24 p.m. UTC | #2
On Mon, Jul 1, 2019 at 1:55 PM Rob Clark <robdclark@gmail.com> wrote:
>
> On Mon, Jul 1, 2019 at 10:41 AM Jeffrey Hugo <jeffrey.l.hugo@gmail.com> wrote:
> >
> > When assigning a mixer, we will iterate through the entire list looking for
> > a suitable match.  This results in selecting the last match.  We should
> > stop at the first match, since lower numbered mixers will typically have
> > more capabilities, and are likely to be what the bootloader used, if we
> > are looking to reuse the bootloader config in future.
>
> I think for matching bootloader config, we need to read it out of the
> hw and do it the hard way, rather than making assumptions.
>
> For picking hwpipe for a plane, I made an effort to pick the available
> hwpipe w/ the *least* capabilities that fit the requirements (ie.
> scaling/yuv/etc) in order to leave the more capable hwpipe available
> for future use.  Not sure if same approach would make sense for
> mixers?  But not sure if picking something that bootloader probably
> also would have picked is a great argument.
>
> I do have some (now ancient) code from db410/mdp5 to read out he hw
> state.. I *think* that might have post-dated dynamically picking
> mixers.  (The older mdp5 on db410c also had to deal with figuring out
> SMP block config, iirc.. thankfully newer mdp5 doesn't have to deal
> with that.)

So I ripped this out and retested as I was looking back at it.  Things
still work.  I probably saw a need for this in the middle of my
hacking, but its clearly not needed anymore so lets drop it for now.
diff mbox series

Patch

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c
index 954db683ae44..1638042ad974 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c
@@ -96,6 +96,17 @@  int mdp5_mixer_assign(struct drm_atomic_state *s, struct drm_crtc *crtc,
 		 */
 		if (!(*mixer) || cur->caps & MDP_LM_CAP_PAIR)
 			*mixer = cur;
+
+		/*
+		 * We have everything we could want, exit early.
+		 * We have a valid mixer, that mixer pairs with another if we
+		 * need that ability in future, and we have a right mixer if
+		 * needed.
+		 * Later LMs could be less optimal
+		 */
+		if (*mixer && (*mixer)->caps & MDP_LM_CAP_PAIR &&
+		    ((r_mixer && *r_mixer) || !r_mixer))
+			break;
 	}
 
 	if (!(*mixer))