Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp2377915ioo; Sat, 28 May 2022 11:46:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxjTzIGZLCcOb0/CIgPop2qBFSL6rvxCgkd98bz1CkmyFTC0S5GZRqBkpLdhxJ2hdqLBDf7 X-Received: by 2002:a17:907:7245:b0:6ff:38d0:9708 with SMTP id ds5-20020a170907724500b006ff38d09708mr7760162ejc.172.1653763606837; Sat, 28 May 2022 11:46:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653763606; cv=none; d=google.com; s=arc-20160816; b=af/4HbL5H5neZZ6T23wsnNzNmZC9bMSuFjDQJBBsjSo0fOq2ms8eFbZqjgh4QC51Hu 13vw5qX1zcWSQDZK8cPzrEaLEG/TyBcA7Fm++KG46U6pQAIQvu0ouD1G3FDSM7Z0IJXS 8rlw6h9Wa0FG43UyK7gmmLe/wfZlmuHKWumlI9g0k6tz588dxdtvESMzMIcSameJzmNx qPj/ChUntiTkUFsWW9Y47TRqjNgQYMTfRqQ7nohftE331oe61DDGr26Ol/pSvT4sXCjZ zp8xC/HLnPX8AUJxFWbl83+P9COaQS1P9TZ2Cnwee6P5OIUsaSM4f69sObU/3l4dvHZh ZXzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=aVm4PAPozCt4SBVWHupc23/46bhdNAKn4SHg88rl/g0=; b=WtdakJrwCoFzFjplz7Obt8nH1hSbEtMKpIsSCo/m7deIZIRMT5XEOLNjBYvmNNPY5H 055SalCvEAVnHVgfIhVAKbXWWUdJ0M5Q1xPDCRrZKo0M4fSYBImZ2Yqch1DDbs62SNNt FPSMdcWA67nkazagfnYrEUV4H36ANALjnV3BBV0Qg7GQjx6c2XeHvfnbmzqUDNiCRaQn BCVFmeHTz8I0cyZ6FeYpj1eNOQ0rPACDm/zVqpv1efpIEFfYBbDyaavvqSD2XUDGfeqd KrzrOdW+rgWLf7SPMZQEGmwYjCKVDgFg4r/May2xpDwLzEGYWuZlDhiX5jCu2e16du+P CJvg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Z0J9HqPh; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id ew19-20020a170907951300b006f3cfb1d563si6247876ejc.348.2022.05.28.11.46.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 May 2022 11:46:46 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Z0J9HqPh; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id F3E4E13DE0; Sat, 28 May 2022 11:36:43 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351073AbiE1KK6 (ORCPT + 99 others); Sat, 28 May 2022 06:10:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35534 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231951AbiE1KK4 (ORCPT ); Sat, 28 May 2022 06:10:56 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EE624FF3; Sat, 28 May 2022 03:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1653732654; x=1685268654; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=rvv/1ikIsTltk1vVwBcc2RZ1C1BbsqEGEPXUWzW4f3w=; b=Z0J9HqPhH17NjYRyv8t+Mw5R9zw/0ufAtpQ3VNlZIjli7tQWNgYgW2Bd enL5cSu+X9C/PFS0n4tXa9LSsG49gH6FTziRUmIZMEwKcX7ZmtYHc4Hce N5A82LCJLXINXmryXD7A6/3U1cbbJveAYrvIScp+VWWXMulf+uC3YmQh+ xclAwdhYLl2bxIUcmWemv1tGffN8f3Z9LEkv15+ryyXCoAPgSx2XDKYQY 0i9CnpBRpl04Pma7tc9Q4qtJh5EuiUR+sFjL8zWLgpzAt5XDbjGdEy06M o2o4bBQ3NO8hv3lTJ/O4mQfGCDd+QGptgv4itWMOektU9cq0XXbPLbj6c g==; X-IronPort-AV: E=McAfee;i="6400,9594,10360"; a="300005768" X-IronPort-AV: E=Sophos;i="5.91,258,1647327600"; d="scan'208";a="300005768" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 May 2022 03:10:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,258,1647327600"; d="scan'208";a="719230172" Received: from yilunxu-optiplex-7050.sh.intel.com (HELO localhost) ([10.239.159.135]) by fmsmga001.fm.intel.com with ESMTP; 28 May 2022 03:10:52 -0700 Date: Sat, 28 May 2022 18:03:09 +0800 From: Xu Yilun To: Tom Rix Cc: tien.sung.ang@intel.com, mdf@kernel.org, hao.wu@intel.com, linux-fpga@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fpga: altera-cvp: Truncated bitstream error support Message-ID: <20220528100309.GD175008@yilunxu-OptiPlex-7050> References: <20220518064844.2694651-1-tien.sung.ang@intel.com> <3911c8c7-da6d-e6f2-c747-3b601d9cdacc@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3911c8c7-da6d-e6f2-c747-3b601d9cdacc@redhat.com> X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 18, 2022 at 01:08:31PM -0700, Tom Rix wrote: > > On 5/17/22 11:48 PM, tien.sung.ang@intel.com wrote: > > From: Ang Tien Sung > > > > To support the error handling of a truncated bitstream sent. > > The current AIB CvP firmware is not capable of handling a > > data stream smaller than 4096bytes. The firmware's limitation > > causes a hung-up as it's DMA engine waits forever for the > > completion of the instructed 4096bytes. > > To resolve this design limitation, both firmware and CvP > > driver made several changes. At the CvP driver, we just > > have to ensure that anything lesser than 4096bytes are > > padded with extra bytes. The CvP will then, initiate the > > tear-down by clearing the START_XFER and CVP_CONFIG bits. > > We should also check for CVP_ERROR during the CvP completion. > > A send_buf which is always 4096bytes is used to copy the > > data during every transaction. > > > > Signed-off-by: Ang Tien Sung > > --- > > drivers/fpga/altera-cvp.c | 24 +++++++++++++++++++----- > > 1 file changed, 19 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/fpga/altera-cvp.c b/drivers/fpga/altera-cvp.c > > index 4ffb9da537d8..80edcfb5e5fc 100644 > > --- a/drivers/fpga/altera-cvp.c > > +++ b/drivers/fpga/altera-cvp.c > > @@ -81,6 +81,7 @@ struct altera_cvp_conf { > > u8 numclks; > > u32 sent_packets; > > u32 vsec_offset; > > + u8 *send_buf; > > Why is it necessary to hold? the send_buf in this structure ? > > If it is used only in *_write, could it alloc/freed there ? > > Because the write happens rarely, my preference is to alloc/free in > *_write(). Is it better alloc in write_init()? Thanks, Yilun > > > const struct cvp_priv *priv; > > }; > > @@ -453,7 +454,11 @@ static int altera_cvp_write(struct fpga_manager *mgr, const char *buf, > > } > > len = min(conf->priv->block_size, remaining); > > - altera_cvp_send_block(conf, data, len); > > + /* Copy the requested host data into the transmit buffer */ > > + > > + memcpy(conf->send_buf, data, len); > Is a memset needed for a short buffer ? > > + altera_cvp_send_block(conf, (const u32 *)conf->send_buf, > > + conf->priv->block_size); > > data += len / sizeof(u32); > > done += len; > > remaining -= len; > > @@ -492,10 +497,13 @@ static int altera_cvp_write_complete(struct fpga_manager *mgr, > > if (ret) > > return ret; > > - /* STEP 16 - check CVP_CONFIG_ERROR_LATCHED bit */ > > - altera_read_config_dword(conf, VSE_UNCOR_ERR_STATUS, &val); > > - if (val & VSE_UNCOR_ERR_CVP_CFG_ERR) { > > - dev_err(&mgr->dev, "detected CVP_CONFIG_ERROR_LATCHED!\n"); > > + /* > > + * STEP 16 - If bitstream error (truncated/miss-matched), > > + * we shall exit here. > > + */ > > + ret = altera_read_config_dword(conf, VSE_CVP_STATUS, &val); > Should this be STEP 17 ? the old 16 checked something else. > > Tom > > > + if (ret || (val & VSE_CVP_STATUS_CFG_ERR)) { > > + dev_err(&mgr->dev, "CVP_CONFIG_ERROR!\n"); > > return -EPROTO; > > } > > @@ -661,6 +669,12 @@ static int altera_cvp_probe(struct pci_dev *pdev, > > pci_set_drvdata(pdev, mgr); > > + /* Allocate the 4096 block size transmit buffer */ > > + conf->send_buf = devm_kzalloc(&pdev->dev, conf->priv->block_size, GFP_KERNEL); > > + if (!conf->send_buf) { > > + ret = -ENOMEM; > > + goto err_unmap; > > + } > > return 0; > > err_unmap: