[PATCH 03/12] drm/msm/dpu: use format-related definitions from mdp_common.xml.h
Dmitry Baryshkov
dmitry.baryshkov at linaro.org
Thu Apr 11 01:20:57 UTC 2024
On Thu, 11 Apr 2024 at 02:54, Abhinav Kumar <quic_abhinavk at quicinc.com> wrote:
>
>
>
> On 4/10/2024 2:12 PM, Dmitry Baryshkov wrote:
> > On Wed, Apr 10, 2024 at 01:18:42PM -0700, Abhinav Kumar wrote:
> >>
> >>
> >> On 4/10/2024 1:16 PM, Dmitry Baryshkov wrote:
> >>> On Wed, 10 Apr 2024 at 23:00, Abhinav Kumar <quic_abhinavk at quicinc.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 12/2/2023 1:40 PM, Dmitry Baryshkov wrote:
> >>>>> Instead of having DPU-specific defines, switch to the definitions from
> >>>>> the mdp_common.xml.h file. This is the preparation for merged of DPU and
> >>>>> MDP format tables.
> >>>>>
> >>>>
> >>>> Adding MDP_***__ usages in DPU driver is quite confusing.
> >>>>
> >>>> Can we align to a common naming scheme such as DISP_***?
> >>>
> >>> No, it's not something display-generic. It is specific to MDP
> >>> platforms. In the end DPU is a continuation of the MDP lineup, isn't
> >>> it?
> >>>
> >>
> >> No some aspects of the hw are completely different as you already know
> >> between MDP4/MDP5 and DPU. Bringing back MDP usages into DPU does not seem
> >> right.
> >
> > MDP4 is different, it's true. But there is a lot of common between MDP5
> > and DPU. Frakly speaking, I don't see an issue with using the constant
> > that was defined for MDP5 for DPU layer. Especially since we are also
> > going to use mdp_ functions for format handling.
> >
>
> All the HW naming etc in the doc has migrated to DPU and in fact it only
> makes sense to start using DPU for MDP5 as we plan to move mdp5 targets
> to DPU anyway. Not the other way around.
>
> MDP4 remains different.
>
> How about MSM_DISP then? I dont get why this is MDP platform specific.
I expect MSM_DISP to be applicable to all MSM displays, even if e.g.
at some point DPU2 switches colour component encoding.
> Because the term MDP no longer holds true for DPU.
The XML is still called mdp_common. And the functions are in the mdp_
namespace. I don't think we should be changing them just because the
name has changed.
Likewise if MDP3 is not compatible with these definitions (to be
honest, I didn't check) I still don't think we should change these
names.
> I am even looking for future chipsets. We cannot live with MDP5 names.
> Have to think of generic names for formats.
Ok, I'm open for suggestions from your side.
--
With best wishes
Dmitry
More information about the dri-devel
mailing list