fpga: dfl: improve configuration of dfl pci devices
diff mbox series

Message ID 20200628151813.7679-1-trix@redhat.com
State New
Headers show
Series
  • fpga: dfl: improve configuration of dfl pci devices
Related show

Commit Message

Tom Rix June 28, 2020, 3:18 p.m. UTC
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(-)

Comments

Xu Yilun June 29, 2020, 2:19 a.m. UTC | #1
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
Wu, Hao June 29, 2020, 3:12 a.m. UTC | #2
> -----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
Tom Rix June 29, 2020, 1:28 p.m. UTC | #3
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
>
kernel test robot June 29, 2020, 7:22 p.m. UTC | #4
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
Wu, Hao June 30, 2020, 2:34 a.m. UTC | #5
> 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
> >

Patch
diff mbox series

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)