Message ID | 20240112234222.913138-1-anatoliy.klymenko@amd.com |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-25108-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2614:b0:101:6a76:bbe3 with SMTP id mm20csp503974dyc; Fri, 12 Jan 2024 15:43:01 -0800 (PST) X-Google-Smtp-Source: AGHT+IH/otdFPxWuN9GqauWn466ulh7TxPEsLEeHp+Pfssq3UjBa7srq3aXnjdXxymJSZf2THePa X-Received: by 2002:ac2:4da3:0:b0:50e:7bf5:5424 with SMTP id h3-20020ac24da3000000b0050e7bf55424mr889697lfe.47.1705102981373; Fri, 12 Jan 2024 15:43:01 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1705102981; cv=pass; d=google.com; s=arc-20160816; b=JrWVPn46J23XxI1+/QIHmMB3U+NQve3MrClkkwTCpfxj8CcXcoAc/eN6WgHnPwzBdz 3oRHGvKPfviV21Pv2kWoMOvknQw4n2GVW7V8rkG7v3KzHoo/rNKdg3vXAosNt9EDdZvl 5HSc84Yr6sBd2whSUzpIwCmWzzyDwCGoJFyCX+ATqsxL/uCVxXS3BlONJNPCVJn86c9E 3VAfBbje4v0gatdv1sxJhLwyysEJHJlKZfsdpYk2IV+wputBescGULHsLFw8JI7MeAP0 dU5KlJOP6HEeqQ/Z5LrAWiuQgOCtnz3jd/fnECCKKaYtmBhrQ0r+uoFJmq+vMMOtLVEO oNkw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:to:from :dkim-signature; bh=tWf/8uBjRlPqQznobCoVW/pEu//iw895Li+y2SCJaCQ=; fh=rF57AgvMrLxj8O0ts2KvK1OMlfkXv3jlBwSVETyRr5o=; b=dF5d4xaHXNtUHQw0m4KqYwZbYiZseD8wUaLJKsJTXhkkHvrAvwkHarfPmTea9HvN8P gceju0SH7q0AlA6Te0CGyEclF1Fl2VKvQXIYc9ciexFd3vIghLz7hOkqCjsD3dbeFScq 7KLxksj0ameEaRNA1hEJ5bVVWeiFUWhHdHcc9YiNsyQOVmedQ41fz5yx8wFl63/XapRB YKgiU0O7X9hL7Zf9Cyhtu9uyKr49CoSt2nfvEugxda2fqIk4cTH8k9JcQdy3C8cFyivm DLqph1tTKWuRFDT/GO6pHVxHuTR0azngC0zDIFK6vixWRIayPmMGFDJRqfYOp0LUzCt+ 4g1A== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=Ou+EdePn; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel+bounces-25108-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-25108-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id e8-20020a17090681c800b00a2b0b0df816si1772375ejx.300.2024.01.12.15.43.01 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jan 2024 15:43:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-25108-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=Ou+EdePn; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel+bounces-25108-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-25108-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id C81E41F23670 for <ouuuleilei@gmail.com>; Fri, 12 Jan 2024 23:43:00 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id ECB1B1A728; Fri, 12 Jan 2024 23:42:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="Ou+EdePn" Received: from NAM04-BN8-obe.outbound.protection.outlook.com (mail-bn8nam04on2053.outbound.protection.outlook.com [40.107.100.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4275618C1D for <linux-kernel@vger.kernel.org>; Fri, 12 Jan 2024 23:42:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T+rQU08PVQ0BJiFNh12goKX6lDxHDKiFj5d7RdhskFJ6A+5eptdFRBwGUUQnobf3ZZywHlpRW3zLJvqyxHYFfz4IXsNX/px2JIQZ+qAoNXHu4DFxdJwqAAHKiPs2jrKj44ahfrhKYTqceS+c8qPSHKQhS76DdZEz1LleZcLZnCO2igsKSOFJxGpg9LCjpRibpIAf64uiD7/q5GqmnLlESCF0xpYNgGf49wsaunTF+RhMEMWgjNpWybfHbofvN3IFeoYhQf6N8vwA90zb8M6nKqnB9nu8sxC77gmEq1IZIkJD592y0HyuFYyuHqgjlg5/UPZckV6EJRZ17qGae5MCyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tWf/8uBjRlPqQznobCoVW/pEu//iw895Li+y2SCJaCQ=; b=b83LKT5IdRtOXLLqRhw8m4AndmpOjCcajSHvhG/5kILloiasnbAvCTpJvATN/7YU/J2L1U1U4gcxJnVM4Ow8FTSscqzwb0/IqhPSiLqWLG3FGsCxztQuLpkv/zWObrkCmCkNCr9jNWiIfesb6wV4aLqCJZkC2qgQau5QU5BymXn0hj7CP+EcmRUenaiHEwx0UCdw5UjcH0/KfPJy2s2BBSN8ns+QKEGgrleSKpHQI5Bjo01V8OCZvWswATALBtEmdaQOo4BYvlv9QruXcrbqMoq8Q7QEoyMKIrbCOVK4pSqUM3FkTT6YUnYAD5sH87jc/aA63faJF+PSpKDIz7gOPA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=ideasonboard.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tWf/8uBjRlPqQznobCoVW/pEu//iw895Li+y2SCJaCQ=; b=Ou+EdePnONuTMLVxve8j6+pJa9JBBXsVVHF0CO2NMGTExY8YnSF5Q+7s2zCk6FueBNL4uOdeIhsSjdWH3Qjnp72wHhy+QPnDMJ7pMLAxTby4GDvj+rjkTH5k/R63rsthCiRJ7AL5h1Z3h2LIS5kObIUIcJ+PvP18j+DxR9FQDCg= Received: from SN6PR16CA0048.namprd16.prod.outlook.com (2603:10b6:805:ca::25) by SJ1PR12MB6362.namprd12.prod.outlook.com (2603:10b6:a03:454::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7181.18; Fri, 12 Jan 2024 23:42:24 +0000 Received: from SN1PEPF000252A2.namprd05.prod.outlook.com (2603:10b6:805:ca:cafe::e1) by SN6PR16CA0048.outlook.office365.com (2603:10b6:805:ca::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7181.19 via Frontend Transport; Fri, 12 Jan 2024 23:42:24 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by SN1PEPF000252A2.mail.protection.outlook.com (10.167.242.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7181.14 via Frontend Transport; Fri, 12 Jan 2024 23:42:24 +0000 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.34; Fri, 12 Jan 2024 17:42:23 -0600 Received: from xsjanatoliy50.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.34 via Frontend Transport; Fri, 12 Jan 2024 17:42:22 -0600 From: Anatoliy Klymenko <anatoliy.klymenko@amd.com> To: <laurent.pinchart@ideasonboard.com>, <maarten.lankhorst@linux.intel.com>, <mripard@kernel.org>, <tzimmermann@suse.de>, <airlied@gmail.com>, <daniel@ffwll.ch>, <michal.simek@amd.com>, <dri-devel@lists.freedesktop.org>, <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org> Subject: [PATCH 0/4] Fixing live video input in ZynqMP DPSUB Date: Fri, 12 Jan 2024 15:42:18 -0800 Message-ID: <20240112234222.913138-1-anatoliy.klymenko@amd.com> X-Mailer: git-send-email 2.25.1 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 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PEPF000252A2:EE_|SJ1PR12MB6362:EE_ X-MS-Office365-Filtering-Correlation-Id: bb9f8137-7455-459d-f957-08dc13c82099 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: BBkfDItSvDPknROhMRLKDdLBSs1SSqRqo3QMYmZGlHhzt3xoALNQauiSisaQptXoQk5shIg3Pyb9m5nOpOJ2GA/XagSZr77xafJSi3ebKZmQsjZB1tPsL7YyhcpqIaJInBRnj617UwI1nqBJLtYBDosy/yQmBw6WbBeC6fKS3FSzxSR8PSHoH2G7UgwCBZENQ+E5B29875aADWNjBfLns+YroIEchLnW4DHlIa0v48GTI4Oo7ya+7obLpWgb1owUDS3rV+Ixsq60nMn7+QAzzWrCAQ5stX2K7BVNBPdEQpJmRdIx7eZQvFWC2/U6vAuMDnS/LlIQBUma5fHLKKvHaNc8kKxq7UtDeI+cN08KMTmEpRh5K/lRACKil1YOooLbju3ZW2wuF29r0IJWBdO+ngqp7d9hLBUsFoDZhObD8zLL3x91lUtCF0lWO6glsq1qgpqm5r4pIWzcDmyD2QH+3yvUJHMcB6M+unnAndffdTjs9JKP2D8EuRC2Dpuwr6VjB5sPKy9IOWv3F4mx7H811kBD7iDCMEjEClvH0VVNLXRsPpviwxDaf42SCui+cU7K3RugE0Tbs+He2yjfzGHVLBc9EOXvd1dpoCjKP57eB2pAiB1TqfP4Ct+8zaJHsSuxopUXYlZQ/5xjXdw0OZQrSGb6R4CmVK5geB7QC71oXA2p8jTobTN4Mz535swnC5Efs0lyOayElYPjj0wxhH2ia5I4qpDlQmbOx+8sdMV297scM8+pYszfn6JpDpzKfCIMzlJyqHFx1o/+fIR7J/DwcqSbj+OWsvTec0cmrLCj0Fp6fIBYqkZsMl3/r6rExFuUOzjzFoYYZcZrFGdHdWJUQw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(4636009)(346002)(39860400002)(396003)(376002)(136003)(230922051799003)(1800799012)(64100799003)(451199024)(186009)(82310400011)(36840700001)(40470700004)(46966006)(40460700003)(40480700001)(47076005)(83380400001)(86362001)(81166007)(356005)(921011)(36756003)(5660300002)(36860700001)(8676002)(82740400003)(2616005)(336012)(26005)(1076003)(426003)(70206006)(478600001)(6666004)(316002)(44832011)(70586007)(110136005)(4744005)(2906002)(41300700001)(8936002)(83996005)(36900700001)(2101003);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2024 23:42:24.0491 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bb9f8137-7455-459d-f957-08dc13c82099 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SN1PEPF000252A2.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6362 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787930063590717725 X-GMAIL-MSGID: 1787930063590717725 |
Series | Fixing live video input in ZynqMP DPSUB | |
Message
Klymenko, Anatoliy
Jan. 12, 2024, 11:42 p.m. UTC
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? Anatoliy Klymenko (4): drm: xlnx: zynqmp_dpsub: Make drm bridge discoverable drm: xlnx: zynqmp_dpsub: Fix timing for live mode drm: xlnx: zynqmp_dpsub: Don't generate vblank in live mode drm: xlnx: zynqmp_dpsub: Set live video in format drivers/gpu/drm/xlnx/zynqmp_disp.c | 111 +++++++++++++++++++++--- drivers/gpu/drm/xlnx/zynqmp_disp.h | 3 +- drivers/gpu/drm/xlnx/zynqmp_disp_regs.h | 8 +- drivers/gpu/drm/xlnx/zynqmp_dp.c | 14 ++- drivers/gpu/drm/xlnx/zynqmp_kms.c | 2 +- 5 files changed, 118 insertions(+), 20 deletions(-)
Comments
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? Maxime
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 ?
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 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. 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. > 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. Sounds like there's something to rework in the API then? Maxime
> -----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 > > 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 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. > > 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. > 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 utilizing Xilinx-specific bridge framework. Ideally, it would be nice to rework this 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. > > Sounds like there's something to rework in the API then? > Adding an optional CRTC callback imposing CRTC specific bus format restrictions, 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
On Fri, Jan 26, 2024 at 11:18:30PM +0000, Klymenko, Anatoliy wrote: > > > > -----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 > > > > 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 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. > > > > 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. > > 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 utilizing Xilinx-specific bridge > framework. Ideally, it would be nice to rework this 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. > > > > Sounds like there's something to rework in the API then? > > > Adding an optional CRTC callback imposing CRTC specific bus format restrictions, which may be > called from here https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_bridge.c#L935 > would solve the problem. CRTCs and bridges are orthogonal. If anything, I'd expect that callback to be set at the CRTC, encoder and connector levels and filled by the drm_bridge code if relevant. Maxime
On Thu, Feb 01, 2024 at 06:01:01PM +0100, Maxime Ripard wrote: > On Fri, Jan 26, 2024 at 11:18:30PM +0000, Klymenko, Anatoliy wrote: > > On Friday, January 26, 2024 4:26 AM, Maxime Ripard wrote: > > > 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 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. > > > > > > 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. > > > > 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 utilizing Xilinx-specific bridge > > framework. Ideally, it would be nice to rework this 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. > > > > > > Sounds like there's something to rework in the API then? > > > > > Adding an optional CRTC callback imposing CRTC specific bus format restrictions, which may be > > called from here https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_bridge.c#L935 > > would solve the problem. > > CRTCs and bridges are orthogonal. If anything, I'd expect that callback > to be set at the CRTC, encoder and connector levels and filled by the > drm_bridge code if relevant. I'm thinking about a new CRTC operation that would be called by the bridge chain format negotiation helper drm_atomic_bridge_chain_select_bus_fmts() (or one of the functions it calls), to filter the list of formats supported by the chain based on what the CRTC supports, or possibly to pick a format in that list. This needs to be prototyped
On Sun, Feb 04, 2024 at 11:56:18AM +0200, Laurent Pinchart wrote: > On Thu, Feb 01, 2024 at 06:01:01PM +0100, Maxime Ripard wrote: > > On Fri, Jan 26, 2024 at 11:18:30PM +0000, Klymenko, Anatoliy wrote: > > > On Friday, January 26, 2024 4:26 AM, Maxime Ripard wrote: > > > > 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 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. > > > > > > > > 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. > > > > > > 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 utilizing Xilinx-specific bridge > > > framework. Ideally, it would be nice to rework this 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. > > > > > > > > Sounds like there's something to rework in the API then? > > > > > > > Adding an optional CRTC callback imposing CRTC specific bus format restrictions, which may be > > > called from here https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_bridge.c#L935 > > > would solve the problem. > > > > CRTCs and bridges are orthogonal. If anything, I'd expect that callback > > to be set at the CRTC, encoder and connector levels and filled by the > > drm_bridge code if relevant. > > I'm thinking about a new CRTC operation that would be called by the > bridge chain format negotiation helper > drm_atomic_bridge_chain_select_bus_fmts() (or one of the functions it > calls), to filter the list of formats supported by the chain based on > what the CRTC supports, or possibly to pick a format in that list. This > needs to be prototyped As long as we come up with something that works for regular encoders, I'm fine with that. Maxime