On 4/10/2024 7:38 PM, Dmitry Baryshkov wrote:
On Thu, 11 Apr 2024 at 02:54, Abhinav Kumar <quic_abhinavk@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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.
Because the term MDP no longer holds true for DPU.
I am even looking for future chipsets. We cannot live with MDP5 names.
Have to think of generic names for formats.
Another point: MDP_ is still frequently used in the DPU driver. See
dpu_hwio.h, dpu_hw_catalog.h or dpu_hw_interrupts.c
As I wrote in
https://patchwork.freedesktop.org/patch/570148/?series=127230&rev=1,
lets go ahead with the MDP naming which you have. If we see its not
working out later on, please be open to a mass renaming that time.
With that expectation set,
Reviewed-by: Abhinav Kumar <quic_abhinavk@xxxxxxxxxxx>
