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@xxxxxxx> >>>> --- >>>> 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
