| Message ID | 20200628151813.7679-1-trix@redhat.com (mailing list archive) |
|---|---|
| State | Rejected, archived |
| Headers | show |
| Series | fpga: dfl: improve configuration of dfl pci devices | expand |
I think maybe we don't have to select them all. It is now possible for FPGA DFL boards to work without FME or AFU, providing limited functionality. It is possible designers trim the bitstream for their purpose, and also need a smaller driver set. I think we may add "default FPGA_DFL" for FPGA_DFL_FME, FPGA_DFL_FME_MGR and others to make life easier. How do you think? On Sun, Jun 28, 2020 at 08:18:13AM -0700, trix@redhat.com wrote: > From: Tom Rix <trix@redhat.com> > > To use a dfl pci device, several dfl configs need to be selected. > This is tedious and error prone. > > So automagically select the needed configs when FPGA_DFL_PCI > is selected. > > Signed-off-by: Tom Rix <trix@redhat.com> > --- > drivers/fpga/Kconfig | 36 +++++++++++++++++++++--------------- > 1 file changed, 21 insertions(+), 15 deletions(-) > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig > index 7cd5a29fc437..4b9e05af5426 100644 > --- a/drivers/fpga/Kconfig > +++ b/drivers/fpga/Kconfig > @@ -138,6 +138,27 @@ config OF_FPGA_REGION > Support for loading FPGA images by applying a Device Tree > overlay. > > +config FPGA_DFL_PCI > + tristate "FPGA DFL PCIe Device Driver" > + depends on PCI > + select FPGA_DFL > + select FPGA_DFL_FME > + select FPGA_DFL_FME_MGR > + select FPGA_DFL_FME_BRIDGE > + select FPGA_DFL_FME_REGION > + select FPGA_DFL_AFU > + help > + Select this option to enable PCIe driver for PCIe-based > + Field-Programmable Gate Array (FPGA) solutions which implement > + the Device Feature List (DFL). This driver provides interfaces > + for userspace applications to configure, enumerate, open and access > + FPGA accelerators on the FPGA DFL devices, enables system level > + management functions such as FPGA partial reconfiguration, power > + management and virtualization with DFL framework and DFL feature > + device drivers. > + > + To compile this as a module, choose M here. > + > config FPGA_DFL > tristate "FPGA Device Feature List (DFL) support" > select FPGA_BRIDGE > @@ -191,21 +212,6 @@ config FPGA_DFL_AFU > to the FPGA infrastructure via a Port. There may be more than one > Port/AFU per DFL based FPGA device. > > -config FPGA_DFL_PCI > - tristate "FPGA DFL PCIe Device Driver" > - depends on PCI && FPGA_DFL > - help > - Select this option to enable PCIe driver for PCIe-based > - Field-Programmable Gate Array (FPGA) solutions which implement > - the Device Feature List (DFL). This driver provides interfaces > - for userspace applications to configure, enumerate, open and access > - FPGA accelerators on the FPGA DFL devices, enables system level > - management functions such as FPGA partial reconfiguration, power > - management and virtualization with DFL framework and DFL feature > - device drivers. > - > - To compile this as a module, choose M here. > - > config FPGA_MGR_ZYNQMP_FPGA > tristate "Xilinx ZynqMP FPGA" > depends on ZYNQMP_FIRMWARE || (!ZYNQMP_FIRMWARE && COMPILE_TEST) > -- > 2.18.1
> -----Original Message----- > From: linux-fpga-owner@vger.kernel.org <linux-fpga-owner@vger.kernel.org> > On Behalf Of Xu Yilun > Sent: Monday, June 29, 2020 10:19 AM > To: trix@redhat.com > Cc: mdf@kernel.org; linux-fpga@vger.kernel.org; linux- > kernel@vger.kernel.org; Wu, Hao <hao.wu@intel.com>; > matthew.gerlach@linux.intel.com > Subject: Re: [PATCH] fpga: dfl: improve configuration of dfl pci devices > > I think maybe we don't have to select them all. It is now possible for > FPGA DFL boards to work without FME or AFU, providing limited > functionality. It is possible designers trim the bitstream for their > purpose, and also need a smaller driver set. > Yes, we hope that this dfl-pci could be a common module shared by different cards. Some device doesn't have FME, e.g. some VF device with AFU only, some device has FME, but no PR support, and in the future, it's possible to add new modules, or something replacing AFU or FME, so we don't have to select all here. > I think we may add "default FPGA_DFL" for FPGA_DFL_FME, > FPGA_DFL_FME_MGR and others to make life easier. It's hard to say it's easier for everybody, e.g. I am a user of N3000, but I have to unselect the PR modules, as they are default Yes as proposed? Maybe it's better to let user select what they want, unless we find something really common needed under DFL framework. Hao
On 6/28/20 8:12 PM, Wu, Hao wrote: >> -----Original Message----- >> From: linux-fpga-owner@vger.kernel.org <linux-fpga-owner@vger.kernel.org> >> On Behalf Of Xu Yilun >> Sent: Monday, June 29, 2020 10:19 AM >> To: trix@redhat.com >> Cc: mdf@kernel.org; linux-fpga@vger.kernel.org; linux- >> kernel@vger.kernel.org; Wu, Hao <hao.wu@intel.com>; >> matthew.gerlach@linux.intel.com >> Subject: Re: [PATCH] fpga: dfl: improve configuration of dfl pci devices >> >> I think maybe we don't have to select them all. It is now possible for >> FPGA DFL boards to work without FME or AFU, providing limited >> functionality. It is possible designers trim the bitstream for their >> purpose, and also need a smaller driver set. >> > Yes, we hope that this dfl-pci could be a common module shared by > different cards. Some device doesn't have FME, e.g. some VF device > with AFU only, some device has FME, but no PR support, and in the > future, it's possible to add new modules, or something replacing AFU > or FME, so we don't have to select all here. > >> I think we may add "default FPGA_DFL" for FPGA_DFL_FME, >> FPGA_DFL_FME_MGR and others to make life easier. > It's hard to say it's easier for everybody, e.g. I am a user of N3000, but > I have to unselect the PR modules, as they are default Yes as proposed? > Maybe it's better to let user select what they want, unless we find > something really common needed under DFL framework. I get your point about n3000, but that card is not currently supported in the public. Currently there is really only pac10, the 0x9c4 device. Once n3000 (and d5005) is out, it will have several sub devices that will also so need to be manually configured. While a developer of the n3000 will know which subdevices are needed, someone just building the kernel will not. So would expect there to be something like CONFIG_FPGA_DFL_N3000 select CONFIG_DFL_PCI select CONFIG_DFL_SUBDEV_1 .. On PF vs FP, yes only afu parts are needed. But i doubt anyone builds a VF specific kernel. And if folks wanted to not use the fme parts they would not have to load it's module at run time. I would like a top level config what auto selects all of the submodules needed based on the card. I think maybe that is CONFIG_FPGA_DFL_PAC10. so we will be ready for CONFIG_FPGA_DFL_N3000 and CONFIG_FPGA_DFL_D5005 and what ever comes later. Tom > Hao >
Hi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.8-rc3 next-20200629]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/trix-redhat-com/fpga-dfl-improve-configuration-of-dfl-pci-devices/20200628-231854
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 719fdd32921fb7e3208db8832d32ae1c2d68900f
config: s390-randconfig-s031-20200629 (attached as .config)
compiler: s390-linux-gcc (GCC) 9.3.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-3-gfa153962-dirty
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C= CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=s390
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
sparse warnings: (new ones prefixed by >>)
drivers/fpga/dfl-fme-perf.c:788:61: sparse: sparse: using member 'hw' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:789:38: sparse: sparse: using member 'pmu' in incomplete struct perf_event
>> drivers/fpga/dfl-fme-perf.c:789:38: sparse: sparse: cast from unknown type
drivers/fpga/dfl-fme-perf.c:789:38: sparse: sparse: using member 'pmu' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:789:38: sparse: sparse: using member 'pmu' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:792:47: sparse: sparse: using member 'hw' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:797:38: sparse: sparse: using member 'pmu' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:797:38: sparse: sparse: cast from unknown type
drivers/fpga/dfl-fme-perf.c:797:38: sparse: sparse: using member 'pmu' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:797:38: sparse: sparse: using member 'pmu' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:798:43: sparse: sparse: using member 'hw' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:803:18: sparse: sparse: using member 'attr' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:803:38: sparse: sparse: using member 'pmu' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:811:13: sparse: sparse: undefined identifier 'is_sampling_event'
drivers/fpga/dfl-fme-perf.c:814:18: sparse: sparse: using member 'cpu' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:817:18: sparse: sparse: using member 'cpu' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:820:19: sparse: sparse: using member 'attr' in incomplete struct perf_event
>> drivers/fpga/dfl-fme-perf.c:820:19: sparse: sparse: incompatible types for operation (>):
>> drivers/fpga/dfl-fme-perf.c:820:19: sparse: unsigned long long
>> drivers/fpga/dfl-fme-perf.c:820:19: sparse: bad type
drivers/fpga/dfl-fme-perf.c:820:19: sparse: sparse: using member 'attr' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:820:19: sparse: sparse: cast from unknown type
drivers/fpga/dfl-fme-perf.c:821:18: sparse: sparse: using member 'attr' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:821:18: sparse: sparse: incompatible types for operation (>):
drivers/fpga/dfl-fme-perf.c:821:18: sparse: unsigned long long
drivers/fpga/dfl-fme-perf.c:821:18: sparse: bad type
drivers/fpga/dfl-fme-perf.c:821:18: sparse: sparse: using member 'attr' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:821:18: sparse: sparse: cast from unknown type
drivers/fpga/dfl-fme-perf.c:822:18: sparse: sparse: using member 'attr' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:822:18: sparse: sparse: incompatible types for operation (>):
drivers/fpga/dfl-fme-perf.c:822:18: sparse: unsigned long long
drivers/fpga/dfl-fme-perf.c:822:18: sparse: bad type
drivers/fpga/dfl-fme-perf.c:822:18: sparse: sparse: using member 'attr' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:822:18: sparse: sparse: cast from unknown type
drivers/fpga/dfl-fme-perf.c:826:12: sparse: sparse: using member 'event_base' in incomplete struct hw_perf_event
drivers/fpga/dfl-fme-perf.c:827:12: sparse: sparse: using member 'idx' in incomplete struct hw_perf_event
drivers/fpga/dfl-fme-perf.c:828:12: sparse: sparse: using member 'config_base' in incomplete struct hw_perf_event
drivers/fpga/dfl-fme-perf.c:830:14: sparse: sparse: using member 'destroy' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:844:61: sparse: sparse: using member 'hw' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:845:38: sparse: sparse: using member 'pmu' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:845:38: sparse: sparse: cast from unknown type
drivers/fpga/dfl-fme-perf.c:845:38: sparse: sparse: using member 'pmu' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:845:38: sparse: sparse: using member 'pmu' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:846:43: sparse: sparse: using member 'hw' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:849:47: sparse: sparse: using member 'idx' in incomplete struct hw_perf_event
drivers/fpga/dfl-fme-perf.c:849:57: sparse: sparse: using member 'config_base' in incomplete struct hw_perf_event
drivers/fpga/dfl-fme-perf.c:850:16: sparse: sparse: using member 'prev_count' in incomplete struct hw_perf_event
drivers/fpga/dfl-fme-perf.c:853:9: sparse: sparse: using member 'count' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:858:61: sparse: sparse: using member 'hw' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:859:38: sparse: sparse: using member 'pmu' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:859:38: sparse: sparse: cast from unknown type
drivers/fpga/dfl-fme-perf.c:859:38: sparse: sparse: using member 'pmu' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:859:38: sparse: sparse: using member 'pmu' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:860:43: sparse: sparse: using member 'hw' in incomplete struct perf_event
drivers/fpga/dfl-fme-perf.c:863:49: sparse: sparse: using member 'idx' in incomplete struct hw_perf_event
drivers/fpga/dfl-fme-perf.c:863:59: sparse: sparse: using member 'config_base' in incomplete struct hw_perf_event
drivers/fpga/dfl-fme-perf.c:864:9: sparse: sparse: using member 'prev_count' in incomplete struct hw_perf_event
drivers/fpga/dfl-fme-perf.c:929:15: sparse: sparse: undefined identifier 'perf_pmu_register'
drivers/fpga/dfl-fme-perf.c:938:9: sparse: sparse: undefined identifier 'perf_pmu_unregister'
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:236:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned long long [usertype] val @@ got restricted __le64 [usertype] @@
include/asm-generic/io.h:236:22: sparse: expected unsigned long long [usertype] val
include/asm-generic/io.h:236:22: sparse: got restricted __le64 [usertype]
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
include/asm-generic/io.h:236:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned long long [usertype] val @@ got restricted __le64 [usertype] @@
include/asm-generic/io.h:236:22: sparse: expected unsigned long long [usertype] val
vim +789 drivers/fpga/dfl-fme-perf.c
724142f8c42a7b Wu Hao 2020-04-27 785
724142f8c42a7b Wu Hao 2020-04-27 786 static void fme_perf_event_destroy(struct perf_event *event)
724142f8c42a7b Wu Hao 2020-04-27 787 {
724142f8c42a7b Wu Hao 2020-04-27 788 struct fme_perf_event_ops *ops = get_event_ops(event->hw.event_base);
724142f8c42a7b Wu Hao 2020-04-27 @789 struct fme_perf_priv *priv = to_fme_perf_priv(event->pmu);
724142f8c42a7b Wu Hao 2020-04-27 790
724142f8c42a7b Wu Hao 2020-04-27 791 if (ops->event_destroy)
724142f8c42a7b Wu Hao 2020-04-27 792 ops->event_destroy(priv, event->hw.idx, event->hw.config_base);
724142f8c42a7b Wu Hao 2020-04-27 793 }
724142f8c42a7b Wu Hao 2020-04-27 794
724142f8c42a7b Wu Hao 2020-04-27 795 static int fme_perf_event_init(struct perf_event *event)
724142f8c42a7b Wu Hao 2020-04-27 796 {
724142f8c42a7b Wu Hao 2020-04-27 797 struct fme_perf_priv *priv = to_fme_perf_priv(event->pmu);
724142f8c42a7b Wu Hao 2020-04-27 798 struct hw_perf_event *hwc = &event->hw;
724142f8c42a7b Wu Hao 2020-04-27 799 struct fme_perf_event_ops *ops;
724142f8c42a7b Wu Hao 2020-04-27 800 u32 eventid, evtype, portid;
724142f8c42a7b Wu Hao 2020-04-27 801
724142f8c42a7b Wu Hao 2020-04-27 802 /* test the event attr type check for PMU enumeration */
724142f8c42a7b Wu Hao 2020-04-27 803 if (event->attr.type != event->pmu->type)
724142f8c42a7b Wu Hao 2020-04-27 804 return -ENOENT;
724142f8c42a7b Wu Hao 2020-04-27 805
724142f8c42a7b Wu Hao 2020-04-27 806 /*
724142f8c42a7b Wu Hao 2020-04-27 807 * fme counters are shared across all cores.
724142f8c42a7b Wu Hao 2020-04-27 808 * Therefore, it does not support per-process mode.
724142f8c42a7b Wu Hao 2020-04-27 809 * Also, it does not support event sampling mode.
724142f8c42a7b Wu Hao 2020-04-27 810 */
724142f8c42a7b Wu Hao 2020-04-27 811 if (is_sampling_event(event) || event->attach_state & PERF_ATTACH_TASK)
724142f8c42a7b Wu Hao 2020-04-27 812 return -EINVAL;
724142f8c42a7b Wu Hao 2020-04-27 813
724142f8c42a7b Wu Hao 2020-04-27 814 if (event->cpu < 0)
724142f8c42a7b Wu Hao 2020-04-27 815 return -EINVAL;
724142f8c42a7b Wu Hao 2020-04-27 816
724142f8c42a7b Wu Hao 2020-04-27 817 if (event->cpu != priv->cpu)
724142f8c42a7b Wu Hao 2020-04-27 818 return -EINVAL;
724142f8c42a7b Wu Hao 2020-04-27 819
724142f8c42a7b Wu Hao 2020-04-27 @820 eventid = get_event(event->attr.config);
724142f8c42a7b Wu Hao 2020-04-27 821 portid = get_portid(event->attr.config);
724142f8c42a7b Wu Hao 2020-04-27 822 evtype = get_evtype(event->attr.config);
724142f8c42a7b Wu Hao 2020-04-27 823 if (evtype > FME_EVTYPE_MAX)
724142f8c42a7b Wu Hao 2020-04-27 824 return -EINVAL;
724142f8c42a7b Wu Hao 2020-04-27 825
724142f8c42a7b Wu Hao 2020-04-27 826 hwc->event_base = evtype;
724142f8c42a7b Wu Hao 2020-04-27 827 hwc->idx = (int)eventid;
724142f8c42a7b Wu Hao 2020-04-27 828 hwc->config_base = portid;
724142f8c42a7b Wu Hao 2020-04-27 829
724142f8c42a7b Wu Hao 2020-04-27 830 event->destroy = fme_perf_event_destroy;
724142f8c42a7b Wu Hao 2020-04-27 831
724142f8c42a7b Wu Hao 2020-04-27 832 dev_dbg(priv->dev, "%s event=0x%x, evtype=0x%x, portid=0x%x,\n",
724142f8c42a7b Wu Hao 2020-04-27 833 __func__, eventid, evtype, portid);
724142f8c42a7b Wu Hao 2020-04-27 834
724142f8c42a7b Wu Hao 2020-04-27 835 ops = get_event_ops(evtype);
724142f8c42a7b Wu Hao 2020-04-27 836 if (ops->event_init)
724142f8c42a7b Wu Hao 2020-04-27 837 return ops->event_init(priv, eventid, portid);
724142f8c42a7b Wu Hao 2020-04-27 838
724142f8c42a7b Wu Hao 2020-04-27 839 return 0;
724142f8c42a7b Wu Hao 2020-04-27 840 }
724142f8c42a7b Wu Hao 2020-04-27 841
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
> On 6/28/20 8:12 PM, Wu, Hao wrote: > >> -----Original Message----- > >> From: linux-fpga-owner@vger.kernel.org <linux-fpga- > owner@vger.kernel.org> > >> On Behalf Of Xu Yilun > >> Sent: Monday, June 29, 2020 10:19 AM > >> To: trix@redhat.com > >> Cc: mdf@kernel.org; linux-fpga@vger.kernel.org; linux- > >> kernel@vger.kernel.org; Wu, Hao <hao.wu@intel.com>; > >> matthew.gerlach@linux.intel.com > >> Subject: Re: [PATCH] fpga: dfl: improve configuration of dfl pci devices > >> > >> I think maybe we don't have to select them all. It is now possible for > >> FPGA DFL boards to work without FME or AFU, providing limited > >> functionality. It is possible designers trim the bitstream for their > >> purpose, and also need a smaller driver set. > >> > > Yes, we hope that this dfl-pci could be a common module shared by > > different cards. Some device doesn't have FME, e.g. some VF device > > with AFU only, some device has FME, but no PR support, and in the > > future, it's possible to add new modules, or something replacing AFU > > or FME, so we don't have to select all here. > > > >> I think we may add "default FPGA_DFL" for FPGA_DFL_FME, > >> FPGA_DFL_FME_MGR and others to make life easier. > > It's hard to say it's easier for everybody, e.g. I am a user of N3000, but > > I have to unselect the PR modules, as they are default Yes as proposed? > > Maybe it's better to let user select what they want, unless we find > > something really common needed under DFL framework. > > I get your point about n3000, but that card is not currently supported in the > public. Currently there is really only pac10, the 0x9c4 device. Once n3000 > (and d5005) is out, it will have several sub devices that will also so need to be > manually configured. While a developer of the n3000 will know which > subdevices are needed, someone just building the kernel will not. So would > expect there to be something like > > CONFIG_FPGA_DFL_N3000 > > select CONFIG_DFL_PCI > > select CONFIG_DFL_SUBDEV_1 > > .. How about non DFL sub modules? Do you mean it's going to select everything this card needs, including spi, ethernet, bmc and other components used on this card, as FPGA (e.g. N3000) is the only communication channel to them? > > On PF vs FP, yes only afu parts are needed. But i doubt anyone builds a VF > specific kernel. And if folks wanted to not use the fme parts they would not > have to load it's module at run time. It's possible to build a smaller image for virtual machine usage. > > I would like a top level config what auto selects all of the submodules needed > based on the card. I think maybe that is CONFIG_FPGA_DFL_PAC10. so we > will be ready for CONFIG_FPGA_DFL_N3000 and CONFIG_FPGA_DFL_D5005 > and what ever comes later. How about a reference kernel config listed somewhere (e.g. in kernel doc or some other public place) for them? Hao > > Tom > > > Hao > >
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig index 7cd5a29fc437..4b9e05af5426 100644 --- a/drivers/fpga/Kconfig +++ b/drivers/fpga/Kconfig @@ -138,6 +138,27 @@ config OF_FPGA_REGION Support for loading FPGA images by applying a Device Tree overlay. +config FPGA_DFL_PCI + tristate "FPGA DFL PCIe Device Driver" + depends on PCI + select FPGA_DFL + select FPGA_DFL_FME + select FPGA_DFL_FME_MGR + select FPGA_DFL_FME_BRIDGE + select FPGA_DFL_FME_REGION + select FPGA_DFL_AFU + help + Select this option to enable PCIe driver for PCIe-based + Field-Programmable Gate Array (FPGA) solutions which implement + the Device Feature List (DFL). This driver provides interfaces + for userspace applications to configure, enumerate, open and access + FPGA accelerators on the FPGA DFL devices, enables system level + management functions such as FPGA partial reconfiguration, power + management and virtualization with DFL framework and DFL feature + device drivers. + + To compile this as a module, choose M here. + config FPGA_DFL tristate "FPGA Device Feature List (DFL) support" select FPGA_BRIDGE @@ -191,21 +212,6 @@ config FPGA_DFL_AFU to the FPGA infrastructure via a Port. There may be more than one Port/AFU per DFL based FPGA device. -config FPGA_DFL_PCI - tristate "FPGA DFL PCIe Device Driver" - depends on PCI && FPGA_DFL - help - Select this option to enable PCIe driver for PCIe-based - Field-Programmable Gate Array (FPGA) solutions which implement - the Device Feature List (DFL). This driver provides interfaces - for userspace applications to configure, enumerate, open and access - FPGA accelerators on the FPGA DFL devices, enables system level - management functions such as FPGA partial reconfiguration, power - management and virtualization with DFL framework and DFL feature - device drivers. - - To compile this as a module, choose M here. - config FPGA_MGR_ZYNQMP_FPGA tristate "Xilinx ZynqMP FPGA" depends on ZYNQMP_FIRMWARE || (!ZYNQMP_FIRMWARE && COMPILE_TEST)