| 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
| ||
|
Message-ID: <6548eb6e-d4c3-495b-b59e-5fdbcb6ca398@nxp.com>
Date: Fri, 13 Dec 2024 11:40:22 +0800
From: Liu Ying <victor.liu@....com>
To: Rob Herring <robh@...nel.org>
Cc: dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-phy@...ts.infradead.org,
p.zabel@...gutronix.de, maarten.lankhorst@...ux.intel.com,
mripard@...nel.org, tzimmermann@...e.de, airlied@...il.com, simona@...ll.ch,
krzk+dt@...nel.org, conor+dt@...nel.org, shawnguo@...nel.org,
s.hauer@...gutronix.de, kernel@...gutronix.de, festevam@...il.com,
tglx@...utronix.de, vkoul@...nel.org, kishon@...nel.org,
aisheng.dong@....com, agx@...xcpu.org, francesco@...cini.it,
frank.li@....com, dmitry.baryshkov@...aro.org, u.kleine-koenig@...libre.com
Subject: Re: [PATCH v6 01/19] dt-bindings: display: imx: Add i.MX8qxp Display
Controller processing units
On 12/11/2024, Rob Herring wrote:
> On Wed, Dec 11, 2024 at 11:05:52AM +0800, Liu Ying wrote:
>> On 12/11/2024, Rob Herring wrote:
>>> On Mon, Dec 09, 2024 at 11:39:05AM +0800, Liu Ying wrote:
>>>> Freescale i.MX8qxp Display Controller is implemented as construction set of
>>>> building blocks with unified concept and standardized interfaces. Document
>>>> all existing processing units.
>>>>
>>>> Signed-off-by: Liu Ying <victor.liu@....com>
>>>> ---
>>>> v6:
>>>> * No change.
>>>>
>>>> v5:
>>>> * Document aliases for processing units which have multiple instances in
>>>> the Display Controller. Drop Rob's previous R-b tag. (Maxime)
>>>>
>>>> v4:
>>>> * Collect Rob's R-b tag.
>>>>
>>>> v3:
>>>> * Combine fsl,imx8qxp-dc-fetchunit-common.yaml,
>>>> fsl,imx8qxp-dc-fetchlayer.yaml and fsl,imx8qxp-dc-fetchwarp.yaml
>>>> into 1 schema doc fsl,imx8qxp-dc-fetchunit.yaml. (Rob)
>>>> * Document all processing units. (Rob)
>>>>
>>>> v2:
>>>> * Drop fsl,dc-*-id DT properties. (Krzysztof)
>>>> * Add port property to fsl,imx8qxp-dc-tcon.yaml. (Krzysztof)
>>>> * Fix register range sizes in examples.
>>>>
>>>> .../display/imx/fsl,imx8qxp-dc-blitblend.yaml | 46 ++++++
>>>> .../display/imx/fsl,imx8qxp-dc-clut.yaml | 49 ++++++
>>>> .../imx/fsl,imx8qxp-dc-constframe.yaml | 49 ++++++
>>>> .../display/imx/fsl,imx8qxp-dc-dither.yaml | 49 ++++++
>>>> .../display/imx/fsl,imx8qxp-dc-extdst.yaml | 77 +++++++++
>>>> .../display/imx/fsl,imx8qxp-dc-fetchunit.yaml | 147 ++++++++++++++++++
>>>> .../display/imx/fsl,imx8qxp-dc-filter.yaml | 47 ++++++
>>>> .../display/imx/fsl,imx8qxp-dc-framegen.yaml | 68 ++++++++
>>>> .../display/imx/fsl,imx8qxp-dc-gammacor.yaml | 38 +++++
>>>> .../imx/fsl,imx8qxp-dc-layerblend.yaml | 45 ++++++
>>>> .../display/imx/fsl,imx8qxp-dc-matrix.yaml | 48 ++++++
>>>> .../display/imx/fsl,imx8qxp-dc-rop.yaml | 48 ++++++
>>>> .../display/imx/fsl,imx8qxp-dc-safety.yaml | 34 ++++
>>>> .../imx/fsl,imx8qxp-dc-scaling-engine.yaml | 89 +++++++++++
>>>> .../display/imx/fsl,imx8qxp-dc-signature.yaml | 58 +++++++
>>>> .../display/imx/fsl,imx8qxp-dc-store.yaml | 100 ++++++++++++
>>>> .../display/imx/fsl,imx8qxp-dc-tcon.yaml | 50 ++++++
>>>> 17 files changed, 1042 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-blitblend.yaml
>>>> create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-clut.yaml
>>>> create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-constframe.yaml
>>>> create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-dither.yaml
>>>> create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-extdst.yaml
>>>> create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-fetchunit.yaml
>>>> create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-filter.yaml
>>>> create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-framegen.yaml
>>>> create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-gammacor.yaml
>>>> create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-layerblend.yaml
>>>> create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-matrix.yaml
>>>> create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-rop.yaml
>>>> create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-safety.yaml
>>>> create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-scaling-engine.yaml
>>>> create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-signature.yaml
>>>> create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-store.yaml
>>>> create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-tcon.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-blitblend.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-blitblend.yaml
>>>> new file mode 100644
>>>> index 000000000000..7f800e72c3f3
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-blitblend.yaml
>>>> @@ -0,0 +1,46 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-blitblend.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Freescale i.MX8qxp Display Controller Blit Blend Unit
>>>> +
>>>> +description: |
>>>> + Combines two input frames to a single output frame, all frames having the
>>>> + same dimension.
>>>> +
>>>> + Each Blit Blend Unit device should have an alias in the aliases node, in the
>>>> + form of dc<x>-blitblend<y>, where <x> is an integer specifying the Display
>>>> + Controller instance and <y> is an integer specifying the Blit Blend Unit
>>>> + device instance.
>>>
>>> That's really an abuse of aliases. If you need to describe connections
>>> between components, use the graph binding like everyone else does for
>>> display path components.
>>
>> I need to describe components' instance numbers which imply the connections
>> between components but not vice versa. If I use the graph binding, I cannot
>> get the instance numbers(0 or 1) of the two display engines(documented by
>> fsl,imx8qxp-dc-display-engine.yaml). If you have no objections, I may add the
>> instance numbers to compatible strings, like brcm,bcm2835-pixelvalve0.yaml.
>> What do you think?
>
> You could have dc<x> and blitblend<y> aliases and use the graph to
> define the connections. But I'm not really a fan of adding custom
> aliases either. Why are the instance numbers important?
>
> Are the programming models or features of the instances different? If
> so, then a different compatible or property describing the feature may
> be appropriate.
The instances numbers are important mainly because the four ExtDsts(0/1/4/5)
belong to content or safety streams of the two Display Engines, plus the four
LayerBlends(0/1/2/3) in Pixel Engine have different numbers of input ports to
connect with the outputs of other LayerBlends, though the reason for LBs is
weak since the input ports can be expressed by the graph binding.
CF0/1/4/5
PE | | | |
V V V V primary layer cross bar
+------------------------------------------+
| |
4 FUs + (VS4/5 + HS4/5) =>| LB0/1/2/3 |
secondary layer | |
cross bar +------------------------------------------+
| | | |
V V V V
+-----+ +-----+ +-----+ +-----+
| ED0 | | ED4 | | ED5 | | ED1 |
+-----+ +-----+ +-----+ +-----+
-----------------------------|----------|--------------|----------|-------------
content safety content safety
stream0 stream0 stream1 stream1
| | | |
| DE0 V V DE1 |
| +-----+ +-----+ |
------>| FG0 | | FG1 |<------
+-----+ +-----+
| |
V V
... ...
(Safety stream still is supposed to still function when content stream fails
over.)
LayerBlend primary layer selections:
static const enum dc_link_id prim_sels[] = {
/* common options */
LINK_ID_NONE,
LINK_ID_CONSTFRAME0,
LINK_ID_CONSTFRAME1,
LINK_ID_CONSTFRAME4,
LINK_ID_CONSTFRAME5,
/*
* special options:
* layerblend(n) has n special options,
* from layerblend0 to layerblend(n - 1), e.g.,
* layerblend3 has 3 special options -
* layerblend0/1/2.
*/
LINK_ID_LAYERBLEND0,
LINK_ID_LAYERBLEND1,
LINK_ID_LAYERBLEND2,
LINK_ID_LAYERBLEND3,
};
People may argue that ED instance number is also not that important, because
content/safety stream can be inferred from FG input port numbers. That's
true, but the connections between the internal devices are too complex and
I'm afraid it's an over-kill to use the graph binding. I list LB2 primary
layer selections and ED0 input selections here as examples:
--8<--
Selection of the source for the prim input of the layerblend2 module
0: disable
10: blitblend9
12: constframe0
16: constframe1
14: constframe4
18: constframe5
27: matrix4
28: hscaler4
29: vscaler4
30: matrix5
31: hscaler5
32: vscaler5
34: layerblend1
33: layerblend0
--8<--
--8<--
Selection of the source for the src input of the extdst0 module
0: disable
10: blitblend9
12: constframe0
16: constframe1
14: constframe4
18: constframe5
27: matrix4
28: hscaler4
29: vscaler4
30: matrix5
31: hscaler5
32: vscaler5
36: layerblend3
35: layerblend2
34: layerblend1
33: layerblend0
--8<--
TL;DR: I'd like to get instance numbers because of an appropriate programming
model _and_ different features of EDs and LBs(content/safety steam for EDs +
different input selections for LBs). If no objections, I'll add instance
numbers to compatible strings in next version.
>
> Rob
--
Regards,
Liu Ying
Powered by blists - more mailing lists