2014-10-08 16:55:01 +08:00
|
|
|
#
|
|
|
|
|
# IBM Coherent Accelerator (CXL) compatible devices
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
config CXL_BASE
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
select PPC_COPRO_BASE
|
2014-10-08 16:55:04 +08:00
|
|
|
|
cxl: Add mechanism for delivering AFU driver specific events
This adds an afu_driver_ops structure with fetch_event() and
event_delivered() callbacks. An AFU driver such as cxlflash can fill
this out and associate it with a context to enable passing custom AFU
specific events to userspace.
This also adds a new kernel API function cxl_context_pending_events(),
that the AFU driver can use to notify the cxl driver that new specific
events are ready to be delivered, and wake up anyone waiting on the
context wait queue.
The current count of AFU driver specific events is stored in the field
afu_driver_events of the context structure.
The cxl driver checks the afu_driver_events count during poll, select,
read, etc. calls to check if an AFU driver specific event is pending,
and calls fetch_event() to obtain and deliver that event. This way, the
cxl driver takes care of all the usual locking semantics around these
calls and handles all the generic cxl events, so that the AFU driver
only needs to worry about it's own events.
fetch_event() return a struct cxl_event_afu_driver_reserved, allocated
by the AFU driver, and filled in with the specific event information and
size. Total event size (header + data) should not be greater than
CXL_READ_MIN_SIZE (4K).
Th cxl driver prepends an appropriate cxl event header, copies the event
to userspace, and finally calls event_delivered() to return the status of
the operation to the AFU driver. The event is identified by the context
and cxl_event_afu_driver_reserved pointers.
Since AFU drivers provide their own means for userspace to obtain the
AFU file descriptor (i.e. cxlflash uses an ioctl on their scsi file
descriptor to obtain the AFU file descriptor) and the generic cxl driver
will never use this event, the ABI of the event is up to each individual
AFU driver.
Signed-off-by: Philippe Bergheaud <felix@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-06-23 21:03:53 +08:00
|
|
|
config CXL_AFU_DRIVER_OPS
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
2017-06-22 21:07:27 +08:00
|
|
|
config CXL_LIB
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
2014-10-08 16:55:04 +08:00
|
|
|
config CXL
|
|
|
|
|
tristate "Support for IBM Coherent Accelerators (CXL)"
|
2015-08-14 15:41:27 +08:00
|
|
|
depends on PPC_POWERNV && PCI_MSI && EEH
|
2014-10-08 16:55:04 +08:00
|
|
|
select CXL_BASE
|
cxl: Add mechanism for delivering AFU driver specific events
This adds an afu_driver_ops structure with fetch_event() and
event_delivered() callbacks. An AFU driver such as cxlflash can fill
this out and associate it with a context to enable passing custom AFU
specific events to userspace.
This also adds a new kernel API function cxl_context_pending_events(),
that the AFU driver can use to notify the cxl driver that new specific
events are ready to be delivered, and wake up anyone waiting on the
context wait queue.
The current count of AFU driver specific events is stored in the field
afu_driver_events of the context structure.
The cxl driver checks the afu_driver_events count during poll, select,
read, etc. calls to check if an AFU driver specific event is pending,
and calls fetch_event() to obtain and deliver that event. This way, the
cxl driver takes care of all the usual locking semantics around these
calls and handles all the generic cxl events, so that the AFU driver
only needs to worry about it's own events.
fetch_event() return a struct cxl_event_afu_driver_reserved, allocated
by the AFU driver, and filled in with the specific event information and
size. Total event size (header + data) should not be greater than
CXL_READ_MIN_SIZE (4K).
Th cxl driver prepends an appropriate cxl event header, copies the event
to userspace, and finally calls event_delivered() to return the status of
the operation to the AFU driver. The event is identified by the context
and cxl_event_afu_driver_reserved pointers.
Since AFU drivers provide their own means for userspace to obtain the
AFU file descriptor (i.e. cxlflash uses an ioctl on their scsi file
descriptor to obtain the AFU file descriptor) and the generic cxl driver
will never use this event, the ABI of the event is up to each individual
AFU driver.
Signed-off-by: Philippe Bergheaud <felix@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-06-23 21:03:53 +08:00
|
|
|
select CXL_AFU_DRIVER_OPS
|
2017-06-22 21:07:27 +08:00
|
|
|
select CXL_LIB
|
2014-10-08 16:55:04 +08:00
|
|
|
default m
|
|
|
|
|
help
|
|
|
|
|
Select this option to enable driver support for IBM Coherent
|
|
|
|
|
Accelerators (CXL). CXL is otherwise known as Coherent Accelerator
|
|
|
|
|
Processor Interface (CAPI). CAPI allows accelerators in FPGAs to be
|
|
|
|
|
coherently attached to a CPU via an MMU. This driver enables
|
|
|
|
|
userspace programs to access these accelerators via /dev/cxl/afuM.N
|
|
|
|
|
devices.
|
|
|
|
|
|
|
|
|
|
CAPI adapters are found in POWER8 based systems.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
cxl: Add cxl_check_and_switch_mode() API to switch bi-modal cards
Add a new API, cxl_check_and_switch_mode() to allow for switching of
bi-modal CAPI cards, such as the Mellanox CX-4 network card.
When a driver requests to switch a card to CAPI mode, use PCI hotplug
infrastructure to remove all PCI devices underneath the slot. We then write
an updated mode control register to the CAPI VSEC, hot reset the card, and
reprobe the card.
As the card may present a different set of PCI devices after the mode
switch, use the infrastructure provided by the pnv_php driver and the OPAL
PCI slot management facilities to ensure that:
* the old devices are removed from both the OPAL and Linux device trees
* the new devices are probed by OPAL and added to the OPAL device tree
* the new devices are added to the Linux device tree and probed through
the regular PCI device probe path
As such, introduce a new option, CONFIG_CXL_BIMODAL, with a dependency on
the pnv_php driver.
Refactor existing code that touches the mode control register in the
regular single mode case into a new function, setup_cxl_protocol_area().
Co-authored-by: Ian Munsie <imunsie@au1.ibm.com>
Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-07-14 05:17:14 +08:00
|
|
|
|
|
|
|
|
config CXL_BIMODAL
|
|
|
|
|
bool "Support for bi-modal CAPI cards"
|
|
|
|
|
depends on HOTPLUG_PCI_POWERNV = y && CXL || HOTPLUG_PCI_POWERNV = m && CXL = m
|
|
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
Select this option to enable support for bi-modal CAPI cards, such as
|
|
|
|
|
the Mellanox CX-4.
|