summaryrefslogtreecommitdiff
path: root/drivers/scsi/cxlflash/ocxl_hw.c
AgeCommit message (Collapse)Author
2018-04-18scsi: cxlflash: Adapter context support for OCXLUma Krishnan
Add support to create and release the adapter contexts for OCXL and provide means to specify certain contexts as a master. The existing cxlflash core has a design requirement that each host will have a single host context available by default. To satisfy this requirement, one host adapter context is created when the hardware AFU is initialized. This is returned by the get_context() fop. Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com> Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-04-18scsi: cxlflash: Setup AFU PASIDUma Krishnan
Per the OCXL specification, the maximum PASID supported by the AFU is indicated by a field within the configuration space. Similar to acTags, implementations can choose to use any sub-range of PASID within their assigned range. For cxlflash, the entire range is used. Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com> Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-04-18scsi: cxlflash: Setup AFU acTag rangeUma Krishnan
The OCXL specification supports distributing acTags amongst different AFUs and functions on the link. As cxlflash devices are expected to only support a single AFU per function, the entire range that was assigned to the function is also assigned to the AFU. Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com> Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-04-18scsi: cxlflash: Read host AFU configurationUma Krishnan
The host AFU configuration is read on the initialization path to identify the features and configuration of the AFU. This data is cached for use in later configuration steps. Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com> Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-04-18scsi: cxlflash: Setup function acTag rangeUma Krishnan
The OCXL specification supports distributing acTags amongst different AFUs and functions on the link. The platform-specific acTag range for the link is obtained using the OCXL provider services and then assigned to the host function based on implementation. Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com> Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-04-18scsi: cxlflash: Read host function configurationUma Krishnan
Per the OCXL specification, the underlying host can have multiple AFUs per function with each function supporting its own configuration. The host function configuration is read on the initialization path to evaluate the number of functions present and identify the features and configuration of the functions present. This data is cached for use in later configuration steps. Note that for the OCXL hardware supported by the cxlflash driver, only one AFU per function is expected. Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com> Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-04-18scsi: cxlflash: Hardware AFU for OCXLUma Krishnan
When an adapter is initialized, transport specific configuration and MMIO mapping details need to be saved. For CXL, this data is managed by the underlying kernel module. To maintain a separation between the cxlflash core and underlying transports, introduce a new structure to store data specific to the OCXL AFU. Initially only the pointers to underlying PCI and generic devices are added to this new structure - it will be expanded further in future commits. Services to create and destroy this hardware AFU are added and integrated in the probe and exit paths of the driver. Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com> Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-04-18scsi: cxlflash: Introduce OCXL backendUma Krishnan
Add initial infrastructure to support a new cxlflash transport, OCXL. Claim a dependency on OCXL and add a new file, ocxl_hw.c, which will host the backend routines that are specific to OCXL. Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com> Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>