From: tien.sung.ang@intel.com
To: yilun.xu@intel.com
Cc: dinh.nguyen@intel.com, hao.wu@intel.com,
linux-fpga@vger.kernel.org, linux-kernel@vger.kernel.org,
mdf@kernel.org, tien.sung.ang@intel.com, trix@redhat.com
Subject: Re: [PATCH] fpga: altera-cvp: allow interrupt to continue next time
Date: Tue, 31 May 2022 10:20:04 +0800 [thread overview]
Message-ID: <20220531022004.2314963-1-tien.sung.ang@intel.com> (raw)
In-Reply-To: <20220528120400.GA175058@yilunxu-OptiPlex-7050>
>> CFG_READY signal/bit may time-out due to firmware not responding
>> within the given time-out. This time varies due to numerous
>> factors like size of bitstream and others.
>> This time-out error does not impact the result of the CvP
>> previous transactions. The CvP driver shall then, respond with
>Do you mean the reprogramming is successful even if you find the time
>out in write_complete()? Then return 0 is better?
Based on the information given by the Intel FPGA firmware team,
CFG_READY is essential to indicate if the current FPGA
configuration session is indeed a success. There are
cases we test in the lab whereby, CFG_READY stays invalid and
the tests performed subsequently to verify the FPGA functionality
could not detect the failed session. A failed FPGA
configuration session means, the new bitstream wasn't
successfully configured and tests ran later will just be passing
on the previous working bitstream version. In short, CFG_READY
is esential, and an error indicating the time-out is a must.
Another example, using an incorrect SOF/Design FPGA results
in CFG_READY being invalid. The user must be informed of a
potential error.
I will correct the wordings i used earlier that says that
the timoeut error does not impact the results of the CvP
previous transactions. It may so if the firmware has some sort
of error.
>And could you specify what the time-out mean on write_init() phase?
I could not really understand your question. We set huge
time-outs of ~10seconds. Every wait for the firmware to respond
is potentially a hazard. The firmware CvP is has it's limitation
unfortunately.
next prev parent reply other threads:[~2022-05-31 2:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-18 7:38 [PATCH] fpga: altera-cvp: allow interrupt to continue next time tien.sung.ang
2022-05-18 14:04 ` 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
2022-06-01 1:40 ` [PATCH v2] fpga: altera-cvp: allow interrupt to continue next time tien.sung.ang
2022-06-03 11:00 ` Xu Yilun
2022-05-28 12:04 ` [PATCH] " Xu Yilun
2022-05-31 2:20 ` tien.sung.ang [this message]
2022-06-03 10:14 ` 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=20220531022004.2314963-1-tien.sung.ang@intel.com \
--to=tien.sung.ang@intel.com \
--cc=dinh.nguyen@intel.com \
--cc=hao.wu@intel.com \
--cc=linux-fpga@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mdf@kernel.org \
--cc=trix@redhat.com \
--cc=yilun.xu@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox