Received-SPF: pass (google.com: domain of linux-kernel+bounces-40838-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
From: "Klymenko, Anatoliy" <Anatoliy.Klymenko@amd.com>
To: Maxime Ripard <mripard@kernel.org>, Laurent Pinchart
	<laurent.pinchart@ideasonboard.com>
CC: "maarten.lankhorst@linux.intel.com" <maarten.lankhorst@linux.intel.com>,
	"tzimmermann@suse.de" <tzimmermann@suse.de>, "airlied@gmail.com"
	<airlied@gmail.com>, "daniel@ffwll.ch" <daniel@ffwll.ch>, "Simek, Michal"
	<michal.simek@amd.com>, "dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>
Subject: RE: Re: [PATCH 0/4] Fixing live video input in ZynqMP DPSUB
Thread-Topic: Re: [PATCH 0/4] Fixing live video input in ZynqMP DPSUB
Thread-Index: AQHaR4zbqultFCfObkKOHwb14YSQ3LDeEnKAgA4EJYCAAK6mAA==
Date: Fri, 26 Jan 2024 23:18:30 +0000
Message-ID:
 <MW4PR12MB7165D35189BEECA8769552AFE6792@MW4PR12MB7165.namprd12.prod.outlook.com>
References: <20240112234222.913138-1-anatoliy.klymenko@amd.com>
 <6jhwss2wego6yoo5mwmphwawhsj5bbj62gwrzcpapoixwkrkli@g4fbxdooopby>
 <20240117142343.GD17920@pendragon.ideasonboard.com>
 <u5mngxudtdgy3vqkfbpgqng6tdahijnet2jtj345hrowbt47ce@t3e7hul45mr3>
In-Reply-To: <u5mngxudtdgy3vqkfbpgqng6tdahijnet2jtj345hrowbt47ce@t3e7hul45mr3>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?uSLc0DDOZ/TQ750Uw45BMKJDlbLwCPaa2O9fB7i1wH6XBN04vJU+33XJwhFb?=
 =?us-ascii?Q?nbAkFS04aeesViSMLVm1j3pwBRPmwbrQiamJV+VGtSQz+0G0/tQOY48r/S81?=
 =?us-ascii?Q?ZKmbKjpEVyx8/EFWn1MFV4aSNcV6RFL8uTBd4HRnFbH+7RWVMhSqT5ms9g07?=
 =?us-ascii?Q?ic6K2/DlTqgX8ctBTC42nyDvt+3+ZXNjJvFgSbo8LDe9c07IGwsiCOQvhX4y?=
 =?us-ascii?Q?4ieziWdfaWnUwitEomo9DyjM9XteKBPPmu6dfhN3qsFHYKTZvcwXsWDUH8Bj?=
 =?us-ascii?Q?LDKgriMMis2N6H47UaCra+xDAl9+OWT+Fu5H0rcrXWyxznr5R9GVcbIOzBHO?=
 =?us-ascii?Q?gbbU/WJPG5mjCrm61NYWatb8/C6Jfgee2J9+tmspnKHzYkqQHjAsf/npinK2?=
 =?us-ascii?Q?90g1HQe1oo/lq1mQHXgD89ZrpooqTDLX9tElPJkCwJ3u8a7CT61MQ33F6ZvU?=
 =?us-ascii?Q?vmrjb/+o/e/evED0qLrNW5Cb3vtNjxALHJF1YSYftRkEC26E6vAoxJXbq30R?=
 =?us-ascii?Q?3O2DtQNG5pUCNf7bu+xOdwuWWQ+gltOBm0P35xypRP9s+8eVUly+QscDSJAs?=
 =?us-ascii?Q?q6UOAFpQjyls9Lk6eYuMkmdNflth11kUovIlldmgQf1IxrlGkVxQGsD3KWeR?=
 =?us-ascii?Q?RMjJjx0F9Q60s67thFzfCArdlcKePQ/FDxTUNwe0Y0SkGLp3mXp+CsK5IlDi?=
 =?us-ascii?Q?BE04pN12k774YE9+fkXbkn9PIzeabrjgDYwaPPwf25IaJyiVop5shb2+NmMm?=
 =?us-ascii?Q?FK6XtVEyNHfTWpvZm9vLUl8e1/BPPdoaX33EWcdpk1eB7RO8ZgjNY6TNOVdw?=
 =?us-ascii?Q?ChsACU2pBqSygZCIzKxkIl7jSpbjkzLd3uy7rZejd7RJvCHy1bAlXt4XJ45s?=
 =?us-ascii?Q?9x6PVl2+6V6j0iJhQ7wEuIH0v9Kf5Kf4knvSm3kBF9XdsdLSt4oi8eetwH8B?=
 =?us-ascii?Q?amis3hT1kT89PjPJRJyRf/GLmRlDvg2k+MRY3xQ9KblaPoaJ6sVV1QIuEOCn?=
 =?us-ascii?Q?xcH4UhJxe/HaTbm3a9o2A4XVNfPt7LfKLVC/JEXQg2RpZxDEN12ep8YhESfs?=
 =?us-ascii?Q?RvbhI9EHkGD2h5fUMb7mci85WZG3CI1r7vo37UiNeQqMwdjL3Sa0gGeepIik?=
 =?us-ascii?Q?lU5W27Qu54uB/nt9HChIPcdgWuQVeJdcrV4BOgRrpn2qIX9CKknHKetvREAn?=
 =?us-ascii?Q?Nq0PKHlEyQIARsZsapYs9v7/JOX8Eyd3tBXJ1Wl2RnZX4wXwAMqMfj51Nnz7?=
 =?us-ascii?Q?zXPTMiFcLyNZtH5FX9iuXdPBYJpyWdzfqAdHL8BXIl6+uoTOnyMFWfvfvqO8?=
 =?us-ascii?Q?EmwotjvbID31udrVUbEgoXznODmq/XQLV+3Xrzo4POgrYrBSEpxGG1+zjI01?=
 =?us-ascii?Q?ZH+5SVyMCszsBa/fofWdVcrDF9Cc8wygl64UvNxLF7oTzGHLdHZM4sgmvowz?=
 =?us-ascii?Q?PlfGYoLVriCDcXVbCG3D4lUBo8hwL+S0NM1s6tzz15leSw+ZF6pvXQcb9T1X?=
 =?us-ascii?Q?OM0PttHdNmzML5ZIasDBGgxbBTd+2gIEl9IErv2d/SKLr2asTLS/mQJ00TAg?=
 =?us-ascii?Q?D+HGnzJ0UyRhCAHhnL0=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW4PR12MB7165.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 23416a01-d254-46df-f278-08dc1ec51bed
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2024 23:18:30.5683
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: WUV6hdzcG3I8JZM4EgohRGPUAde9/vAJmJfJ9/If85C6NGDku+g+0SvCmTCAAInYmTvKMC6bjlpwCsvvSYbb/Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR12MB5299


> -----Original Message-----
> From: Maxime Ripard <mripard@kernel.org>
> Sent: Friday, January 26, 2024 4:26 AM
> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Klymenko, Anatoliy <Anatoliy.Klymenko@amd.com>;
> maarten.lankhorst@linux.intel.com; tzimmermann@suse.de; airlied@gmail.com=
;
> daniel@ffwll.ch; Simek, Michal <michal.simek@amd.com>; dri-
> devel@lists.freedesktop.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org
> Subject: Re: Re: [PATCH 0/4] Fixing live video input in ZynqMP DPSUB
>=20
> On Wed, Jan 17, 2024 at 04:23:43PM +0200, Laurent Pinchart wrote:
> > 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 forma=
t is fixed
> > > > and comes from the device tree. This is a proposed solution, as the=
re 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 strai=
ght
> > > 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 o=
f
> > 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 fabri=
c
> > to be synthesized with a fixed format (as that saves resources), while
> > the DPSUB supports multiple input formats.
>=20
> Where is that CRTC driver? It's not clear to me why the format would
> need to be in the device tree at all. Format negociation between the
> CRTC and whatever comes next is already done in a number of drivers so
> it would be useful to have that kind of API outside of the bridge
> support.
>=20
One example of such CRTC driver: https://github.com/Xilinx/linux-xlnx/blob/=
master/drivers/gpu/drm/xlnx/xlnx_mixer.c
It's not upstreamed yet. Bus format negotiations here are handled by utiliz=
ing Xilinx-specific bridge framework. Ideally, it would be nice to rework t=
his to comply with the upstream DRM bridge framework.

> > 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.
>=20
> Sounds like there's something to rework in the API then?
>=20
Adding an optional CRTC callback imposing CRTC specific bus format restrict=
ions, which may be called from here https://github.com/torvalds/linux/blob/=
master/drivers/gpu/drm/drm_bridge.c#L935 would solve the problem.

> Maxime

--

Regards,
Anatoliy