[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANk1AXTLBWXGUozXJdKRThJwLiHJ==B--DkkE+YRjveA2YvifQ@mail.gmail.com>
Date: Wed, 20 Dec 2017 16:31:15 -0600
From: Alan Tull <atull@...nel.org>
To: Wu Hao <hao.wu@...el.com>
Cc: Moritz Fischer <mdf@...nel.org>, linux-fpga@...r.kernel.org,
linux-kernel <linux-kernel@...r.kernel.org>,
linux-api@...r.kernel.org, "Kang, Luwei" <luwei.kang@...el.com>,
"Zhang, Yi Z" <yi.z.zhang@...el.com>,
Enno Luebbers <enno.luebbers@...el.com>,
Xiao Guangrong <guangrong.xiao@...ux.intel.com>
Subject: Re: [PATCH v3 01/21] docs: fpga: add a document for Intel FPGA driver overview
On Mon, Nov 27, 2017 at 12:42 AM, Wu Hao <hao.wu@...el.com> wrote:
> +
> +PORT
> +====
> +A port represents the interface between the static FPGA fabric (the "blue
> +bitstream") and a partially reconfigurable region containing an AFU (the "green
> +bitstream"). It controls the communication from SW to the accelerator and
> +exposes features such as reset and debug.
Hi Hao,
If I remember correctly, reset means that the accelerator gets reset
and this is something that is desirable to do between jobs. I've
asked for some documentation about the port reset function, partly
because the idea of being able to reset hardware from userspace
somehow scares me. So please find a good logical place to explain
what a port reset does and how it is safe for userspace to request it
at some arbitrary time and how it won't crash the kernel. We
discussed this in v2, I grepped v3 for it, maybe I missed it, but I
don't see it in v3. My understanding is that disabling and reenabling
the port bridge causes the accelerator in its FPGA region to get
reset.
Alan
> +
> +A PCIe device may have several ports and each port can be released from PF by
> +FPGA_FME_PORT_RELEASE ioctl on FME, and exposed through a VF via PCIe sriov
> +sysfs interface.
> +
Powered by blists - more mailing lists