linux-kernel - Re: [PATCH] drm/msm/mdp5: Use eariler mixers when possible

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAF6AEGsGRcuk3xnWG8KspW4wzG38o-Xg8tybnND9Lb24PWP5dw@mail.gmail.com>
Date:   Mon, 1 Jul 2019 12:55:05 -0700
From:   Rob Clark <robdclark@...il.com>
To:     Jeffrey Hugo <jeffrey.l.hugo@...il.com>
Cc:     Sean Paul <sean@...rly.run>, David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        freedreno <freedreno@...ts.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm/msm/mdp5: Use eariler mixers when possible

On Mon, Jul 1, 2019 at 10:41 AM Jeffrey Hugo <jeffrey.l.hugo@...il.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@...il.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
>