linux-kernel - Re: [PATCH 0/4] Fixing live video input in ZynqMP DPSUB

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>] [day] [month] [year] [list]

Message-ID:
 <MW4PR12MB716560EDEF35C59F77D7156FE6702@MW4PR12MB7165.namprd12.prod.outlook.com>
Date: Fri, 19 Jan 2024 05:49:41 +0000
From: "Klymenko, Anatoliy" <Anatoliy.Klymenko@....com>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>, Maxime Ripard
	<mripard@...nel.org>, "maarten.lankhorst@...ux.intel.com"
	<maarten.lankhorst@...ux.intel.com>, "tzimmermann@...e.de"
	<tzimmermann@...e.de>, "airlied@...il.com" <airlied@...il.com>,
	"daniel@...ll.ch" <daniel@...ll.ch>, "Simek, Michal" <michal.simek@....com>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/4] Fixing live video input in ZynqMP DPSUB

Hi Laurent and Maxime,

Laurent, thank you very much for clear and comprehensive description of the "live video input" feature.

Maxime, sure, I will elaborate more in the next version of cover letter.

> Date: Wed, 17 Jan 2024 16:23:43 +0200
> From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
> To: Maxime Ripard <mripard@...nel.org>
> Cc: Anatoliy Klymenko <anatoliy.klymenko@....com>,
>         maarten.lankhorst@...ux.intel.com, tzimmermann@...e.de,
>         airlied@...il.com, daniel@...ll.ch, michal.simek@....com,
>         dri-devel@...ts.freedesktop.org, linux-arm-kernel@...ts.infradeadorg,
>         linux-kernel@...r.kernel.org
> Subject: Re: [PATCH 0/4] Fixing live video input in ZynqMP DPSUB
> Message-ID: <20240117142343.GD17920@...dragon.ideasonboard.com>
> Content-Type: text/plain; charset=utf-8
> 
> On Mon, Jan 15, 2024 at 09:28:39AM +0100, Maxime Ripard wrote:
> > On Fri, Jan 12, 2024 at 03:42:18PM -0800, Anatoliy Klymenko wrote:
> > > Patches 1/4,2/4,3/4 are minor fixes.
> > >
> > > DPSUB requires input live video format to be configured.
> > > Patch 4/4: The DP Subsystem requires the input live video format to
> > > be configured. In this patch we are assuming that the CRTC's bus
> > > format is fixed and comes from the device tree. This is a proposed
> > > solution, as there are no api to query CRTC output bus format.
> > >
> > > Is this a good approach to go with?
> >
> > I guess you would need to expand a bit on what "live video input" is?
> > Is it some kind of mechanism to bypass memory and take your pixels
> > straight from a FIFO from another device, or something else?
> 
> Yes and no.
> 
> The DPSUB integrates DMA engines, a blending engine (two planes), and a DP
> encoder. The dpsub driver supports all of this, and creates a DRM device. The DP
> encoder hardware always takes its input data from the output of the blending
> engine.
> 
> The blending engine can optionally take input data from a bus connected to the
> FPGA fabric, instead of taking it from the DPSUB internal DMA engines. When
> operating in that mode, the dpsub driver exposes the DP encoder as a bridge, and
> internally programs the blending engine to disable blending. Typically, the FPGA
> fabric will then contain a CRTC of some sort, with a driver that will acquire the DP
> encoder bridge as usually done.
> 
> In this mode of operation, it is typical for the IP cores in FPGA fabric to be
> synthesized with a fixed format (as that saves resources), while the DPSUB
> supports multiple input formats. Bridge drivers in the upstream kernel work the
> other way around, with the bridge hardware supporting a limited set of formats,
> and the CRTC then being programmed with whatever the bridges chain needs.
> Here, the negotiation needs to go the other way around, as the CRTC is the
> limiting factor, not the bridge.
> 
> Is this explanation clear ?
> 
> --
> Regards,
> 
> Laurent Pinchart
> 
> 

Thank you,
Anatoliy