All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xu Yilun <yilun.xu@intel.com>
To: Tom Rix <trix@redhat.com>
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
Date: Sat, 28 May 2022 18:03:09 +0800	[thread overview]
Message-ID: <20220528100309.GD175008@yilunxu-OptiPlex-7050> (raw)
In-Reply-To: <3911c8c7-da6d-e6f2-c747-3b601d9cdacc@redhat.com>

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 <tien.sung.ang@intel.com>
> > 
> > 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 <tien.sung.ang@intel.com>
> > ---
> >   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:

  parent reply	other threads:[~2022-05-28 10:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-18  6:48 [PATCH] fpga: altera-cvp: Truncated bitstream error support tien.sung.ang
2022-05-18 20:08 ` Tom Rix
2022-05-19  4:34   ` tien.sung.ang
2022-05-28 10:01     ` Xu Yilun
2022-05-28 10:03   ` Xu Yilun [this message]
2022-05-18 20:54 ` Christophe JAILLET
2022-05-19  4:21   ` tien.sung.ang
2022-05-28 10:08     ` Xu Yilun
2022-05-20  1:30   ` [PATCH v2] " tien.sung.ang
2022-05-28  9:59     ` Xu Yilun
2022-05-31  1:53       ` tien.sung.ang
2022-06-03  9:49         ` Xu Yilun
2022-06-07  5:55           ` tien.sung.ang
2022-06-08 10:30             ` Xu Yilun
2022-06-27  7:45               ` tien.sung.ang
2022-06-27  8:52                 ` Xu Yilun
2022-05-18 14:04 [PATCH] fpga: altera-cvp: allow interrupt to continue next time Tom Rix
2022-05-19  9:39 ` [PATCH] fpga: altera-cvp: Truncated bitstream error support tien.sung.ang
2022-05-28 12:05   ` Xu Yilun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220528100309.GD175008@yilunxu-OptiPlex-7050 \
    --to=yilun.xu@intel.com \
    --cc=hao.wu@intel.com \
    --cc=linux-fpga@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mdf@kernel.org \
    --cc=tien.sung.ang@intel.com \
    --cc=trix@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.