From: "Manne, Nava kishore" <nava.kishore.manne@amd.com>
To: Xu Yilun <yilun.xu@linux.intel.com>
Cc: "mdf@kernel.org" <mdf@kernel.org>,
"hao.wu@intel.com" <hao.wu@intel.com>,
"yilun.xu@intel.com" <yilun.xu@intel.com>,
"trix@redhat.com" <trix@redhat.com>,
"peter.colberg@intel.com" <peter.colberg@intel.com>,
"conor.dooley@microchip.com" <conor.dooley@microchip.com>,
"v.georgiev@metrotek.ru" <v.georgiev@metrotek.ru>,
"Simek, Michal" <michal.simek@amd.com>,
Marco Pagani <marpagan@redhat.com>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"ruanjinjie@huawei.com" <ruanjinjie@huawei.com>,
"linux-fpga@vger.kernel.org" <linux-fpga@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"git (AMD-Xilinx)" <git@amd.com>
Subject: RE: [RFC] FPGA Subsystem User Space Interface Proposal
Date: Thu, 11 Jan 2024 12:13:12 +0000 [thread overview]
Message-ID: <DM6PR12MB39935C794D7A14E800F433E6CD682@DM6PR12MB3993.namprd12.prod.outlook.com> (raw)
In-Reply-To: <ZZuW7rQv22xEreu0@yilunxu-OptiPlex-7050>
Hi Yilun,
Please find my response inline.
> -----Original Message-----
> From: Xu Yilun <yilun.xu@linux.intel.com>
> Sent: Monday, January 8, 2024 12:02 PM
> To: Manne, Nava kishore <nava.kishore.manne@amd.com>
> Cc: mdf@kernel.org; hao.wu@intel.com; yilun.xu@intel.com;
> trix@redhat.com; peter.colberg@intel.com; conor.dooley@microchip.com;
> v.georgiev@metrotek.ru; Simek, Michal <michal.simek@amd.com>; Marco
> Pagani <marpagan@redhat.com>; gregkh@linuxfoundation.org;
> ruanjinjie@huawei.com; linux-fpga@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; git (AMD-Xilinx)
> <git@amd.com>
> Subject: Re: [RFC] FPGA Subsystem User Space Interface Proposal
>
> On Thu, Jan 04, 2024 at 04:52:15AM +0000, Manne, Nava kishore wrote:
> >
> ================================================================
> ======
> > =
> > | Introduction |
> >
> ================================================================
> ======
> > = This document provides a detailed overview of the proposed Kernel
> > feature for FPGA Manager subsystem user interface.
> > It describes the problem statement behind the proposal, the problem to be
> solved, a top-level solution design.
> >
> > Table of Contents:
> > ------------------
> > A. Problem Statement and Background
> > B. Scope and Out of scope of the proposal
> > B.1 Scope
> > B.2 Out of scope
> > C. Proposed Solution
> > D. Proposed User Interface Details
> >
> ================================================================
> ======
> > =
> > | A. Problem Statement and Background |
> >
> ================================================================
> ======
> > = The existing FPGA manager subsystem didn't have any user space
> > interface (other than the status/state in sysfs) in Kernel.
> > Basically, FPGAs are semiconductor devices that can be reprogrammed for
> desired hardware functionality.
> > FPGAs can be reprogrammed at runtime with different types of logic and IPs
> as per user need and hence there is a need to use device tree overlays for
> removing/updating/adding the devices at runtime for the IPs/controllers that
> are present in FPGA.
> > But we don't have any user interface in kernel for updating the device tree
> at runtime.
> >
> > Sometime back there was a series sent by Pantelis Antoniou
> (https://lore.kernel.org/lkml/1414528565-10907-4-git-send-email-
> pantelis.antoniou@konsulko.com/).
> > This patch introduced a user interface configfs for Device Tree overlays, a
> method of dynamically altering the kernel's live Device Tree. However, this
> patch series was not accepted in mainline due to various concerns.
> > For more details refer to this link:
> >
> https://elinux.org/Frank%27s_Evolving_Overlay_Thoughts#issues_and_what
> > _needs_to_be_completed_--_Not_an_exhaustive_list
> >
> > One of the major valid concerns that were raised with this configfs interface
> was security as it opens up the interface to users for modifying the live device
> tree.
> >
> > So, in order to configure/program the FPGA devices, All the major
> > vendors of FPGA are using this configfs series as out-of-tree patch for
> configuring the FPGAs and there was never an attempt to introduce a generic
> interface to configure/program the FPGA in upstream and hence upstream
> kernel ended up in not having proper support for FPGAs.
> >
> > The proposal below tries to address this gap of FPGA programmability by
> providing an interface to the user.
> >
> >
> ================================================================
> ======
> > =
> > | B. Proposed Solution |
> >
> ================================================================
> ======
> > = The proposed interface adds a new sysfs interface (of-fpga-region.c)
> > as part of the fpga subsystem and it is responsible for supporting the below
> functionalities.
>
> Why only for of-fpga-region? There are also FPGA regions that don't rely on
> OF. My quick idea is that an interface for /sys/class/fpga-region/ and OF could
> be one of the implementation.
>
I agree, few devices(Like - dfl-fme-region.c) are rely only on FPGA region and they are not using OF. Thanks for pointing out this case.
I will look at the possibility of having a generic interface for both Fpga region and OF and I will get back to you soon.
Regards,
Navakishore.
prev parent reply other threads:[~2024-01-11 12:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-04 4:52 [RFC] FPGA Subsystem User Space Interface Proposal Manne, Nava kishore
2024-01-04 8:02 ` gregkh
2024-01-08 6:32 ` Xu Yilun
2024-01-11 12:13 ` Manne, Nava kishore [this message]
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=DM6PR12MB39935C794D7A14E800F433E6CD682@DM6PR12MB3993.namprd12.prod.outlook.com \
--to=nava.kishore.manne@amd.com \
--cc=conor.dooley@microchip.com \
--cc=git@amd.com \
--cc=gregkh@linuxfoundation.org \
--cc=hao.wu@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fpga@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marpagan@redhat.com \
--cc=mdf@kernel.org \
--cc=michal.simek@amd.com \
--cc=peter.colberg@intel.com \
--cc=ruanjinjie@huawei.com \
--cc=trix@redhat.com \
--cc=v.georgiev@metrotek.ru \
--cc=yilun.xu@intel.com \
--cc=yilun.xu@linux.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).