archive mirror
 help / color / mirror / Atom feed
From: Andreas Puhm <>
To: ""
	Moritz Fischer <>
Cc: Anatolij Gustschin <>, Alan Tull <>,
	"" <>,
	"" <>
Subject: AW: [PATCH] fpga: altera_cvp: restrict registration to CvP enabled devices
Date: Thu, 25 Oct 2018 08:44:06 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <alpine.DEB.2.20.1810241545580.2819@mgerlach-VirtualBox>

Hi Moritz, Matthew,

>> Hi Anatolij, Andreas,
>> On Tue, Oct 23, 2018 at 06:46:47PM +0000, Andreas Puhm wrote:
>>> Hi Anatolij,
>>>> The CvP docs says that on some FPGAs (e.g. Arria 10) the assertion of CVP
>>>> status can take up to 500ms. However it is not clear whether this delay
>>>> might be required after peripheral image configuration and after PCIe
>>>> link activation. The diagram describing configuration sequence suggests
>>>> that CVP_EN should be polled until it is asserted. I can imaging the
>>>> situation that this bit is still not asserted when the device is being
>>>> probed. Maybe we should better defer device probing if CVP_EN bit is
>>>> cleared? When deferred probing fails again and sufficient period for
>>>> CVP_EN bit assertion elapsed, then stop deferred probing and return
>>>> -ENODEV?
>>>> Thanks,
>>>> Anatolij
>>> Anatolij, thank you for your feedback.
>>> My rationale behind the patch is as follows:
>>> The CVP_EN is part of the Hard PCIe IP core configuration,
>>> and therefore, has a defined and static value right from "the start".
>>> Remark in [1, fig 12]
>>> " For high density devices such as Intel Cyclone 10 GX,
>>> it may be necessary to wait up to 500 ms for the CvP
>>> status register bit assertion."
>>> According to [2] the Cyclone 10 GX devices achieve proper operation
>>> within 100 ms (via the PCIe IP core and CvP).
>>> I think (and here the documentation is a bit lacking),
>>> that this remark is valid only for other bits of the status register,
>>> I also think, that the 500 ms delay is calculated from peripheral + core image programming
>>> and that the time for peripheral image programming is far lower than that
>>> (i.e., low enough to allow PCI enumeration).
>>> But if this actually means that it can take up to 500 ms to program the peripheral image,
>>> than such FPGAs would have different problems.
>>> I.e., missing the deadline for PCI enumeration.
>>> This would need a solution outside of the scope of the
>>> altera_cvp module (e.g., soft-reset to re-start enumeration with a stable system).
>>> Bottom line:
>>> The CVP_EN should be deemed stable when altera_cvp is called,
>>> if not,
>>> the programming of the Intel/Altera FPGA and PCIe IP core has not been completed in time
>>> for the enumeration of the PCI device. Hence it would be questionable or, more likely, would not
>>> have completed successfully in the first place, i.e., altera_cvp would not have been called.
>> Yeah I think this makes sense. If your config space isn't up on boot you
>> would run into issues. I agree the docs are soemwhat vague here. Maybe Matthew or Alan can shoot
>> an email to their HW folks internally to clarify?
>My experience with cvp is with Arria10 and Stratix 10.  The PCIe Hard IP
>gets configured when the IOring gets configured at power on.  The idea is
>that the load of the IOring is very fast, much before the infamous 100ms
>PCIe timeout for link training.  When the Hard IP is configured, the
>CVP_EN is set or cleared according to how it was configured.  Yes, you

So is it correct that the value of CVP_EN can be evaluated by the altera_cvp right in the first call of its probe function
(as would be the case with my proposed patch).

If it is, I will fix the remaining issues with the patch and submit it.

>will run into issues if config space is not up on boot.  The exact nature
>of the issues is dependent on the platform being used.
>For the record, if cvp is not being used then the initial full
>configuration of the FPGA can take much longer than just configuring the
>IOring.  In the worst case, if the initial FPGA image in flash is
>corrupted, it can take a while before the failover image gets configured
>into the fpga.  This might be the explanation for the 500 ms for Cyclone
>10 GX devices.  For an Arria10, the flash failover can take much longer
>than even the 500ms, which has been shown to have issues for many platforms.
>> Thanks,
>> Moritz


  reply	other threads:[~2018-10-25  8:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-22 13:15 Andreas Puhm
2018-10-22 13:34 ` Eric Schwarz
2018-10-22 14:04 ` Moritz Fischer
2018-10-23 16:26 ` Anatolij Gustschin
2018-10-23 18:46   ` AW: " Andreas Puhm
2018-10-24  9:51     ` Moritz Fischer
2018-10-24 23:00       ` matthew.gerlach
2018-10-25  8:44         ` Andreas Puhm [this message]
2018-10-28 17:35           ` Moritz Fischer

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:

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

  git send-email \ \ \ \ \ \ \ \ \
    --subject='Re: AW: [PATCH] fpga: altera_cvp: restrict registration to CvP enabled devices' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).