Message ID | 20230314094222.66916-1-nava.kishore.manne@amd.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp1667865wrd; Tue, 14 Mar 2023 03:10:50 -0700 (PDT) X-Google-Smtp-Source: AK7set8AxQ7f2xw/8aJa7zPGGEhJkssZt/F8m/La5CgmsrZxuMLg9gO1XNzEfTGk6rUIg1gNxT/h X-Received: by 2002:a05:6a20:669c:b0:d5:c0dc:643c with SMTP id o28-20020a056a20669c00b000d5c0dc643cmr139223pzh.10.1678788650439; Tue, 14 Mar 2023 03:10:50 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1678788650; cv=pass; d=google.com; s=arc-20160816; b=UhKDNON1IgCpa614FnPTjomMEV7yCKUXqkSiOvEfHQ63DV9mn+hRCzs+o9jOkampQm BBoYzoFK4JRRFGCUpetKF+WG3HoA+v1NxSAcN74cSq7qpnH1gjCPk08FPiALWe05O+N5 c4YkY1F2islcjtazNHNyqMGlRZFiTEvzpgi/l/z1w+ZROW9bvEXcJEh0kxY+JrymDQh9 VTMPOOM02Js5vugXe7vas5eg+XqRHSiPKOtU9SlH/WzXR/6YCMYD5bCub6oA8T7X1zdm kK30XYl2p8uyls8tFpBlGg1ThXFoj7WouE4TW46Od+oiSFVOxIoLFbntQVkhgvUUAcay P9gw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:to:from:dkim-signature; bh=/Z69c7WM4rC1yEaAa+JumfL+MFI2E1NVoMA+og4oSWk=; b=qQMgn4QA+ji6NYN6KcYQ05DVCQk2KoN2kZOwlU+RXE08zUt2edThPhMcrmDlV7Hi4g NlbFDMCWX0NVIFEqD2vXo+atyK8B3xjxIIfq1qc2v2ibDJY+ohsET8m0lla7QXLLEi6c P6T2U87hnxo/xIdTZdVQ5U0NNbQxvpmT4yrWy2Zn1UHePreTrn354kctFsp/y22AdCA8 1YATFOxLfElrFvRi6clPbAECly86aTOqH8W7tPz/PGvDwx6HOqOB3vJ/JDwOfd6sQMK6 GW0nJ5XgTHMIQx49vmvdXoNXAPXCb/DEll0bSaia9x4IOYNhxiopN7g2GTcsL5C6PpQO W6xw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b="I/rwCIrR"; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h185-20020a6383c2000000b00508aca0d0desi1961270pge.815.2023.03.14.03.10.35; Tue, 14 Mar 2023 03:10:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b="I/rwCIrR"; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231175AbjCNJmi (ORCPT <rfc822;realc9580@gmail.com> + 99 others); Tue, 14 Mar 2023 05:42:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230474AbjCNJmc (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 14 Mar 2023 05:42:32 -0400 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2041.outbound.protection.outlook.com [40.107.236.41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C78EF93E25; Tue, 14 Mar 2023 02:42:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DD5Gm3lwLnBFaIDxlzdnvg/DX80wEnCQujuyr1jpCE3kBUiShMsnIboO1Zsm0JlxCYu3K7636rLJu5X63NwFx40XPMy95tzsayq/dw2FLVyOnw/+s3KMSq/4fX6ZOqjwwb6xxErAx7O5qsCxI429ZYh2fbOlOldWZmW5qLhU/kaNW3C4z3dFPc8rLPaSxwVW5jb/S2LlzqIcignkzXJ+3oTo+2NUjE3t0l4Nlj6ATYzh8kN0YFuHGYKohk1frgkWuOKZrLd0M3mh4X7mbzZRT8HGEmPWflVW0j4WZOxKWSMQm5wnv1gOqTxKVvrIsEHICDv5HE9JPg6AbppLxQ4u6A== 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=/Z69c7WM4rC1yEaAa+JumfL+MFI2E1NVoMA+og4oSWk=; b=MKw9RsE/CO0P+t6M4K7bqNu21bHXrpSP2xD5PKchirgBSBmn6xyTjzy8VLbzxmHKsSoof+ff7v3BxE5kf0QJnKGUrMZdzPlUfebxpZ2q3oTUo+Mw7C4syGI84DUwa4Sy92T8ZAntA4fwXT8wHVYS0wboW4iB7FHFDDY6qbMHvC1JbOWzs6GBzeusQ5Ij1O1HG77EStmFuFv2ICU+zOwG1SRpEoII53uz97BrJPoaW2mwYdi3J5M4IQ9mAzj1Xq+iX2OtlGjqq73iN6nTTZNvcYOIlbSd4S2PKthTxj9ZMdGbTy2+vEHpSX67XsyGDzKRkpsnLmvQkS6xm1jlas2bvw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org 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 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=/Z69c7WM4rC1yEaAa+JumfL+MFI2E1NVoMA+og4oSWk=; b=I/rwCIrRjApZjo4KuLbXhdXNQ81ed6+aOW55iszcY1cEXlXHnsm/ARAFZPh/gLCPa2Kz/LlowllAJvVCQNeGctBQe7ow2DzEIN5qQKuND4SPqhbEf93MIFgduX0EVhe5XDBwSQHHF/jzqZP2+Reqsty5ioMA+EdGYKTGync74Tg= Received: from DM6PR08CA0056.namprd08.prod.outlook.com (2603:10b6:5:1e0::30) by CY8PR12MB8196.namprd12.prod.outlook.com (2603:10b6:930:78::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6178.26; Tue, 14 Mar 2023 09:42:25 +0000 Received: from DM6NAM11FT025.eop-nam11.prod.protection.outlook.com (2603:10b6:5:1e0:cafe::f9) by DM6PR08CA0056.outlook.office365.com (2603:10b6:5:1e0::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6178.26 via Frontend Transport; Tue, 14 Mar 2023 09:42:25 +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 DM6NAM11FT025.mail.protection.outlook.com (10.13.172.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.6178.25 via Frontend Transport; Tue, 14 Mar 2023 09:42:25 +0000 Received: from localhost (10.180.168.240) 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.2375.34; Tue, 14 Mar 2023 04:42:24 -0500 From: Nava kishore Manne <nava.kishore.manne@amd.com> To: <mdf@kernel.org>, <hao.wu@intel.com>, <yilun.xu@intel.com>, <trix@redhat.com>, <michal.simek@xilinx.com>, <linux-fpga@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org> Subject: [PATCH] fpga: zynqmp: Make word align the configuration data Date: Tue, 14 Mar 2023 15:12:22 +0530 Message-ID: <20230314094222.66916-1-nava.kishore.manne@amd.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM6NAM11FT025:EE_|CY8PR12MB8196:EE_ X-MS-Office365-Filtering-Correlation-Id: 25c6848b-b32d-4f30-4be9-08db24706b1e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: CaJ0CdzlhFLbMfG8hs2o/qEK3KfZac9/YLUPZX9FDBiI2d8IaWl7w51yeQi5mCbYqW44vjGhYP+sylkw7/v+jS3cTxkhJfqz4bYt4Gzw3TdZTbaujwE4A3ebUim7QiU2KMm3lsWyubmuIJGgxqAXPtwV5MoQx9WOp/RvzGyD0OaBPgSz76DfdcgTviIUJxbiapKtHONQq6YnVTSFHW50edhN2rk2y59lytJnd0fc7kU23ytu6PzI6Wqh5ZXgRdzk6uBwzmJGDGZxS+KjEJacilON11a1ttTjAzXMDSCTRRd3ouW/WhZuq/M0ezTTjVQLGAzZrt3GeyG1dIvtZLl6Hdndqle/R6mikrAmG4MOdm7nJZ9JcQ6PKfH7tysGybjXhKxRN8RRh0qclm4TCu7gfTQZPALK0g5ovMaPzSMg8wZyP1WsMh20vYtTkTOobACZptMz+RhG/NkVxggwCBaJhBh6i49cUKAYZUGayOsTFVqt3ZVfQ8NjYs8XeaGp7mmVjvQEmfRHn1gzV6pzhra1xzuAJ6IbpJJjC7j4qrgP+ZM1HuRxKwS5IHAwrn6i+LOl41kWBsVEMBgvEr4Sd9Y4PWl9Y4wkFhzlnoJEjENUSARquMQ2DV2/PtYwPU/UEXyYhnp0CFywsnoc0+IQut2f1CXrhN+XMw0siCXgDT99gK7HFCaOF+9yczXsL5aA/Og9wUFv4ea3lzvvNQHljEZtrlzJTL51BFLHAAoldWRnh2vFbRA5kNgmetSF3QfQW7g4 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:(13230025)(4636009)(376002)(396003)(136003)(39860400002)(346002)(451199018)(36840700001)(46966006)(40470700004)(86362001)(356005)(36756003)(103116003)(36860700001)(82740400003)(81166007)(8936002)(2906002)(41300700001)(5660300002)(40480700001)(40460700003)(82310400005)(2616005)(16526019)(186003)(26005)(1076003)(83380400001)(426003)(336012)(47076005)(316002)(110136005)(8676002)(70586007)(70206006)(478600001)(2101003)(36900700001);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2023 09:42:25.4360 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 25c6848b-b32d-4f30-4be9-08db24706b1e 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: DM6NAM11FT025.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8196 X-Spam-Status: No, score=-0.6 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760337487782828873?= X-GMAIL-MSGID: =?utf-8?q?1760337487782828873?= |
Series |
fpga: zynqmp: Make word align the configuration data
|
|
Commit Message
Manne, Nava kishore
March 14, 2023, 9:42 a.m. UTC
To avoid unwanted copies at firmware(PMUFW) this patch provides a fix
to align programmable logic(PL) configuration data if the data is not
word-aligned. To align the configuration data this patch adds a few
padding bytes and these additional padding bytes will not create any
functional impact on the PL configuration.
Signed-off-by: Nava kishore Manne <nava.kishore.manne@amd.com>
---
drivers/fpga/zynqmp-fpga.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
Comments
On 2023-03-14 at 15:12:22 +0530, Nava kishore Manne wrote: > To avoid unwanted copies at firmware(PMUFW) this patch provides a fix The copy happens in firmware? Please help briefly describe the firmware operations in commit message. > to align programmable logic(PL) configuration data if the data is not > word-aligned. To align the configuration data this patch adds a few > padding bytes and these additional padding bytes will not create any > functional impact on the PL configuration. > > Signed-off-by: Nava kishore Manne <nava.kishore.manne@amd.com> > --- > drivers/fpga/zynqmp-fpga.c | 15 +++++++++++++-- > 1 file changed, 13 insertions(+), 2 deletions(-) > > diff --git a/drivers/fpga/zynqmp-fpga.c b/drivers/fpga/zynqmp-fpga.c > index c60f20949c47..70a12dc6e15c 100644 > --- a/drivers/fpga/zynqmp-fpga.c > +++ b/drivers/fpga/zynqmp-fpga.c > @@ -15,6 +15,9 @@ > /* Constant Definitions */ > #define IXR_FPGA_DONE_MASK BIT(3) > > +#define DUMMY_PAD_BYTE 0xFF > +#define FPGA_WORD_SIZE 4 > + > /** > * struct zynqmp_fpga_priv - Private data structure > * @dev: Device data structure > @@ -41,18 +44,26 @@ static int zynqmp_fpga_ops_write(struct fpga_manager *mgr, > const char *buf, size_t size) > { > struct zynqmp_fpga_priv *priv; > + int word_align, ret, index; > dma_addr_t dma_addr; > u32 eemi_flags = 0; > char *kbuf; > - int ret; > > priv = mgr->priv; > + word_align = size % FPGA_WORD_SIZE; > + if (word_align) > + word_align = FPGA_WORD_SIZE - word_align; > + > + size = size + word_align; Does the Macro ALIGN() help? > > kbuf = dma_alloc_coherent(priv->dev, size, &dma_addr, GFP_KERNEL); > if (!kbuf) > return -ENOMEM; > > - memcpy(kbuf, buf, size); This is historical, but why do the realloc & copy? Any better way? > + for (index = 0; index < word_align; index++) > + kbuf[index] = DUMMY_PAD_BYTE; > + > + memcpy(&kbuf[index], buf, size - index); Generally I object to massive copy in fpga_manager_ops::write if not necessary. If there is an alignment requirement from HW, it should be noticed to the caller in some way, before the buffer is created. Thanks, Yilun > > wmb(); /* ensure all writes are done before initiate FW call */ > > -- > 2.25.1 >
Hi Yilun, Please find my response inline. > -----Original Message----- > From: Xu Yilun <yilun.xu@intel.com> > Sent: Saturday, March 18, 2023 2:55 PM > To: Manne, Nava kishore <nava.kishore.manne@amd.com> > Cc: mdf@kernel.org; hao.wu@intel.com; trix@redhat.com; > michal.simek@xilinx.com; linux-fpga@vger.kernel.org; linux-arm- > kernel@lists.infradead.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] fpga: zynqmp: Make word align the configuration data > > On 2023-03-14 at 15:12:22 +0530, Nava kishore Manne wrote: > > To avoid unwanted copies at firmware(PMUFW) this patch provides a fix > > The copy happens in firmware? Please help briefly describe the firmware > operations in commit message. > Yes, If the firmware receives unaligned Bitstream file from Linux to make them align it will do one more copy at firmware and this copy takes much time as firmware code runs on microblaze(32-bit processor and runs at lower frequency). So, we suggested the users to handle the alignment issues at top layers(Before submitting request to the firmware). Will update the description in v2. > > to align programmable logic(PL) configuration data if the data is not > > word-aligned. To align the configuration data this patch adds a few > > padding bytes and these additional padding bytes will not create any > > functional impact on the PL configuration. > > > > Signed-off-by: Nava kishore Manne <nava.kishore.manne@amd.com> > > --- > > drivers/fpga/zynqmp-fpga.c | 15 +++++++++++++-- > > 1 file changed, 13 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/fpga/zynqmp-fpga.c b/drivers/fpga/zynqmp-fpga.c > > index c60f20949c47..70a12dc6e15c 100644 > > --- a/drivers/fpga/zynqmp-fpga.c > > +++ b/drivers/fpga/zynqmp-fpga.c > > @@ -15,6 +15,9 @@ > > /* Constant Definitions */ > > #define IXR_FPGA_DONE_MASK BIT(3) > > > > +#define DUMMY_PAD_BYTE 0xFF > > +#define FPGA_WORD_SIZE 4 > > + > > /** > > * struct zynqmp_fpga_priv - Private data structure > > * @dev: Device data structure > > @@ -41,18 +44,26 @@ static int zynqmp_fpga_ops_write(struct > fpga_manager *mgr, > > const char *buf, size_t size) > > { > > struct zynqmp_fpga_priv *priv; > > + int word_align, ret, index; > > dma_addr_t dma_addr; > > u32 eemi_flags = 0; > > char *kbuf; > > - int ret; > > > > priv = mgr->priv; > > + word_align = size % FPGA_WORD_SIZE; > > + if (word_align) > > + word_align = FPGA_WORD_SIZE - word_align; > > + > > + size = size + word_align; > > Does the Macro ALIGN() help? > Will fix in v2. > > > > kbuf = dma_alloc_coherent(priv->dev, size, &dma_addr, > GFP_KERNEL); > > if (!kbuf) > > return -ENOMEM; > > > > - memcpy(kbuf, buf, size); > > This is historical, but why do the realloc & copy? Any better way? > Firmware internally uses the AXI DMA engine to transfer PL data from memory to the device and it supports only continues DMA-able memory access(It will not support scatter-gather memory access). So, this extra copy is needed to copy the data from kernel memory(allocated by the firmware subsystem using page allocators) to continues DMA-able memory. > > + for (index = 0; index < word_align; index++) > > + kbuf[index] = DUMMY_PAD_BYTE; > > + > > + memcpy(&kbuf[index], buf, size - index); > > Generally I object to massive copy in fpga_manager_ops::write if not > necessary. If there is an alignment requirement from HW, it should be > noticed to the caller in some way, before the buffer is created. > Agree, we should find a way to support this kind of use cases. Regards, Navakishore.
On 2023-03-28 at 09:33:17 +0000, Manne, Nava kishore wrote: > Hi Yilun, > > Please find my response inline. > > > -----Original Message----- > > From: Xu Yilun <yilun.xu@intel.com> > > Sent: Saturday, March 18, 2023 2:55 PM > > To: Manne, Nava kishore <nava.kishore.manne@amd.com> > > Cc: mdf@kernel.org; hao.wu@intel.com; trix@redhat.com; > > michal.simek@xilinx.com; linux-fpga@vger.kernel.org; linux-arm- > > kernel@lists.infradead.org; linux-kernel@vger.kernel.org > > Subject: Re: [PATCH] fpga: zynqmp: Make word align the configuration data > > > > On 2023-03-14 at 15:12:22 +0530, Nava kishore Manne wrote: > > > To avoid unwanted copies at firmware(PMUFW) this patch provides a fix > > > > The copy happens in firmware? Please help briefly describe the firmware > > operations in commit message. > > > > Yes, If the firmware receives unaligned Bitstream file from Linux to make them align > it will do one more copy at firmware and this copy takes much time as firmware code > runs on microblaze(32-bit processor and runs at lower frequency). > So, we suggested the users to handle the alignment issues at top layers(Before submitting request to the firmware). > > Will update the description in v2. > > > > to align programmable logic(PL) configuration data if the data is not > > > word-aligned. To align the configuration data this patch adds a few > > > padding bytes and these additional padding bytes will not create any > > > functional impact on the PL configuration. > > > > > > Signed-off-by: Nava kishore Manne <nava.kishore.manne@amd.com> > > > --- > > > drivers/fpga/zynqmp-fpga.c | 15 +++++++++++++-- > > > 1 file changed, 13 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/fpga/zynqmp-fpga.c b/drivers/fpga/zynqmp-fpga.c > > > index c60f20949c47..70a12dc6e15c 100644 > > > --- a/drivers/fpga/zynqmp-fpga.c > > > +++ b/drivers/fpga/zynqmp-fpga.c > > > @@ -15,6 +15,9 @@ > > > /* Constant Definitions */ > > > #define IXR_FPGA_DONE_MASK BIT(3) > > > > > > +#define DUMMY_PAD_BYTE 0xFF > > > +#define FPGA_WORD_SIZE 4 > > > + > > > /** > > > * struct zynqmp_fpga_priv - Private data structure > > > * @dev: Device data structure > > > @@ -41,18 +44,26 @@ static int zynqmp_fpga_ops_write(struct > > fpga_manager *mgr, > > > const char *buf, size_t size) > > > { > > > struct zynqmp_fpga_priv *priv; > > > + int word_align, ret, index; > > > dma_addr_t dma_addr; > > > u32 eemi_flags = 0; > > > char *kbuf; > > > - int ret; > > > > > > priv = mgr->priv; > > > + word_align = size % FPGA_WORD_SIZE; > > > + if (word_align) > > > + word_align = FPGA_WORD_SIZE - word_align; > > > + > > > + size = size + word_align; > > > > Does the Macro ALIGN() help? > > > > Will fix in v2. > > > > > > > kbuf = dma_alloc_coherent(priv->dev, size, &dma_addr, > > GFP_KERNEL); > > > if (!kbuf) > > > return -ENOMEM; > > > > > > - memcpy(kbuf, buf, size); > > > > This is historical, but why do the realloc & copy? Any better way? > > > > Firmware internally uses the AXI DMA engine to transfer PL data from memory to the device > and it supports only continues DMA-able memory access(It will not support scatter-gather memory access). > So, this extra copy is needed to copy the data from kernel memory(allocated by the firmware subsystem using page allocators) I see, but seems the issues are generic. Same issues for versal-fpga 1. fpga_mgr_buf_load_mapped(), fpgamanager_ops::write are intended for contiguous (and maybe dma-safe) buffer but fpga_mgr_firmware_load() breaks this. This may also affect spi backend drivers. 2. Some drivers needs dma addr rather than cpu addr, this could be generally supported. But allocating a bounce buffer by dma_alloc_coherent() is not a good idea. 3. fpga_manager_ops::write() may also be called for each fragment of a sg buffer, could the firmware OK to handle this case? I think framework refactoring is needed for these issues. I may not have time to do the refactoring but will support these topics in first priority. Thanks, Yilun > to continues DMA-able memory. > > > > + for (index = 0; index < word_align; index++) > > > + kbuf[index] = DUMMY_PAD_BYTE; > > > + > > > + memcpy(&kbuf[index], buf, size - index); > > > > Generally I object to massive copy in fpga_manager_ops::write if not > > necessary. If there is an alignment requirement from HW, it should be > > noticed to the caller in some way, before the buffer is created. > > > > Agree, we should find a way to support this kind of use cases. > > Regards, > Navakishore. >
diff --git a/drivers/fpga/zynqmp-fpga.c b/drivers/fpga/zynqmp-fpga.c index c60f20949c47..70a12dc6e15c 100644 --- a/drivers/fpga/zynqmp-fpga.c +++ b/drivers/fpga/zynqmp-fpga.c @@ -15,6 +15,9 @@ /* Constant Definitions */ #define IXR_FPGA_DONE_MASK BIT(3) +#define DUMMY_PAD_BYTE 0xFF +#define FPGA_WORD_SIZE 4 + /** * struct zynqmp_fpga_priv - Private data structure * @dev: Device data structure @@ -41,18 +44,26 @@ static int zynqmp_fpga_ops_write(struct fpga_manager *mgr, const char *buf, size_t size) { struct zynqmp_fpga_priv *priv; + int word_align, ret, index; dma_addr_t dma_addr; u32 eemi_flags = 0; char *kbuf; - int ret; priv = mgr->priv; + word_align = size % FPGA_WORD_SIZE; + if (word_align) + word_align = FPGA_WORD_SIZE - word_align; + + size = size + word_align; kbuf = dma_alloc_coherent(priv->dev, size, &dma_addr, GFP_KERNEL); if (!kbuf) return -ENOMEM; - memcpy(kbuf, buf, size); + for (index = 0; index < word_align; index++) + kbuf[index] = DUMMY_PAD_BYTE; + + memcpy(&kbuf[index], buf, size - index); wmb(); /* ensure all writes are done before initiate FW call */