On 10/17/25, Marek Vasut <[email protected]> wrote: > On 10/16/25 4:07 AM, Liu Ying wrote: > > Hello Liu,
Hello Marek, > > >>> +$id: > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicet > ree.org%2Fschemas%2Fdisplay%2Fimx%2Ffsl%2Cimx95-dc- > domainblend.yaml%23&data=05%7C02%7Cvictor.liu%40nxp.com%7Cc0eb44 > 78aced4ce6921d08de0d9d59dd%7C686ea1d3bc2b4c6fa92cd99c5c301635%7 > C0%7C0%7C638963166631090945%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0 > eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb > CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NEUOVd1LBTU%2FIymp1Ieb > 22hbewujlOfQzZTflJ39Nuw%3D&reserved=0 > >>> +$schema: > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicet > ree.org%2Fmeta- > schemas%2Fcore.yaml%23&data=05%7C02%7Cvictor.liu%40nxp.com%7Cc0e > b4478aced4ce6921d08de0d9d59dd%7C686ea1d3bc2b4c6fa92cd99c5c301635 > %7C0%7C0%7C638963166631115160%7CUnknown%7CTWFpbGZsb3d8eyJFb > XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW > FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JSP9XazHXO0HeirsaW3D > lqKf5rXOJgGJ1M1hcsk7jS0%3D&reserved=0 > >>> + > >>> +title: Freescale i.MX95 Display Controller Domain Blend Unit > >>> + > >>> +description: Combines two input frames to a single output frame. > > > > I'd like to comment on patches in split patch serieses(to be sent if > > needed). > > But, since I provide the below interrupt information, anyway I take the > chance > > to comment more: > > > > Add more description about the unit according to i.MX95 DC IP spec: > > The unit operates in four modes: > > - Primary mode: The primary input is used for output. > > - Secondary mode: The secondary input is used for output. > > - Blend mode: Primary and secondary inputs are blended, according to the > > programmed blending functions. > > - SidebySide mode: Primary and secondary streams are projected side by > side, > > i.e., primary video on the left side and secondary on > > the > > right. > > > > BTW, I confirm that two Domain Blend Units exist in i.MX95 DC while they > don't > > exist in i.MX8qxp/qm DCs. And, as you can see, this unit supports multiple > > modes, this would impact how an OS implements a display driver a lot, > especially > > Blend mode and SidebySide mode. > > There is one thing which specifically concerns me about the DB, it seems > to be capable of blending two inputs from different security domains, is > that correct ? For now, I know nothing more than the DT binding description here, i.e., two inputs are combined to one output in four modes. And, DB cannot be bypassed IIUC. > > >>> +maintainers: > >>> + - Marek Vasut <[email protected]> > >>> + > >>> +properties: > >>> + compatible: > >>> + const: fsl,imx95-dc-domainblend > >>> + > >>> + reg: > >>> + maxItems: 1 > >> > >> No clocks or other resources? > > > > As patch 39 shows, there are 3 interrupts - domainblend{0,1}_shdload, > > domainblend{0,1}_framecomplete and domainblend{0,1}_seqcomplete. > It seems we currently do not use either clock or interrupts on either > domainblend or layerblend IPs, but maybe DB and LB are different and LB > really has no clock/interrupts ? If you take a look at NXP downstream kernel, it uses domainblend{0,1}_shdload IRQs in CRTC driver and I believe that upstream driver should use them too. DB and LB are different. DB is in Display Engine, while LB is in Pixel Engine. This pipeline sort of tells how LD and DB are connected: LB -> ED -> DB. LB has no interrupts. And since it processes pixels in Pixel Engine with AXI CLK and it can be configured via the AHB interface of DC with CFG CLK, I'd say it kind of inherits AXI CLK and CFG CLK from Pixel Engine and DC respectively. See the diagram in fsl,imx8qxp-dc.yaml, you'll find those clocks. Liu Ying
