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 <[email protected]>
---
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
On Mon, Jul 1, 2019 at 10:41 AM Jeffrey Hugo <[email protected]> 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 <[email protected]>
> ---
> 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
>
On Mon, Jul 1, 2019 at 1:55 PM Rob Clark <[email protected]> wrote:
>
> On Mon, Jul 1, 2019 at 10:41 AM Jeffrey Hugo <[email protected]> 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.