linux-kernel - Re: [PATCH v14 RESEND 1/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPU binding

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: <aaxikc6gowwpjhhsmfeu3djepwuqovebojveil4judk2glazii@53j5bulxwud3>
Date:   Fri, 29 Sep 2023 15:46:52 +0200
From:   Maxime Ripard <mripard@...nel.org>
To:     Ying Liu <victor.liu@....com>
Cc:     "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
        "airlied@...il.com" <airlied@...il.com>,
        "daniel@...ll.ch" <daniel@...ll.ch>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "conor+dt@...nel.org" <conor+dt@...nel.org>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "festevam@...il.com" <festevam@...il.com>,
        dl-linux-imx <linux-imx@....com>,
        "maarten.lankhorst@...ux.intel.com" 
        <maarten.lankhorst@...ux.intel.com>,
        "tzimmermann@...e.de" <tzimmermann@...e.de>,
        Guido Günther <guido.gunther@...i.sm>,
        Marcel Ziswiler <marcel.ziswiler@...adex.com>,
        "Laurentiu Palcu (OSS)" <laurentiu.palcu@....nxp.com>,
        "robh@...nel.org" <robh@...nel.org>
Subject: Re: [PATCH v14 RESEND 1/6] dt-bindings: display: imx: Add
 i.MX8qxp/qm DPU binding

On Tue, Sep 05, 2023 at 03:44:23AM +0000, Ying Liu wrote:
> On Thursday, August 24, 2023 5:48 PM, Maxime Ripard <mripard@...nel.org> wrote: 
> > On Wed, Aug 23, 2023 at 08:47:51AM +0000, Ying Liu wrote:
> > > > > This dt-binding just follows generic dt-binding rule to describe the DPU
> > IP
> > > > > hardware, not the software implementation.  DPU internal units do not
> > > > > constitute separate devices.
> > > >
> > > > I mean, your driver does split them into separate devices so surely it
> > > > constitutes separate devices.
> > >
> > > My driver treats them as DPU internal units, especially not Linux devices.
> > >
> > > Let's avoid Linuxisms when implementing this dt-binding and just be simple
> > > to describe necessary stuff exposing to DPU's embodying system/SoC, like
> > > reg, interrupts, clocks and power-domains.
> > 
> > Let's focus the conversation here, because it's redundant with the rest.
> > 
> > Your driver registers two additional devices, that have a different
> > register space, different clocks, different interrupts, different power
> > domains, etc. That has nothing to do with Linux, it's hardware
> > properties.
> > 
> > That alone is a very good indication to me that these devices should be
> > modeled as such. And your driver agrees.
> > 
> > Whether or not the other internal units need to be described as separate
> > devices, I can't really tell, I don't have the datasheet.
> 
> i.MX8qxp and i.MX8qm SoC reference manuals can be found at(I think
> registration is needed first):
> https://www.nxp.com/webapp/Download?colCode=IMX8DQXPRM
> https://www.nxp.com/webapp/Download?colCode=IMX8QMRM

I tried, but the registration is buggy. The email takes longer than the
timeout to be sent.

> Sorry for putting this in a short way, but the DPU is one IP, so one dt-binding.
> 
> > 
> > But at least the CRTC and the interrupt controller should be split away,
> > or explained and detailed far better than "well it's just convenient".
> 
> CRTC is Linuxisms, which cannot be referenced to determine dt-binding.
> 
> DPU as Display Controller is listed as a standalone module/IP in RM.
> This is how the IP is designed in the first place, not for any convenient
> purpose.

Sure, but pushing that argument further, the entire SoC has been
designed as a single entity.

Every vendor out there designs its display pipeline in its entirety and
not block by block. This doesn't mean that it isn't composed of several
mostly discrete components.

If it has a separate address space, clock and interrupt, it's a
different device, no matter how it was designed or what the intent was.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)