2021-05-14 13:21:49 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
|
|
|
/* Copyright(c) 2020-2021 Intel Corporation. */
|
|
|
|
#ifndef __CXL_MEM_H__
|
|
|
|
#define __CXL_MEM_H__
|
2021-06-16 07:36:31 +08:00
|
|
|
#include <linux/cdev.h>
|
|
|
|
#include "cxl.h"
|
2021-05-14 13:21:49 +08:00
|
|
|
|
|
|
|
/* CXL 2.0 8.2.8.5.1.1 Memory Device Status Register */
|
|
|
|
#define CXLMDEV_STATUS_OFFSET 0x0
|
|
|
|
#define CXLMDEV_DEV_FATAL BIT(0)
|
|
|
|
#define CXLMDEV_FW_HALT BIT(1)
|
|
|
|
#define CXLMDEV_STATUS_MEDIA_STATUS_MASK GENMASK(3, 2)
|
|
|
|
#define CXLMDEV_MS_NOT_READY 0
|
|
|
|
#define CXLMDEV_MS_READY 1
|
|
|
|
#define CXLMDEV_MS_ERROR 2
|
|
|
|
#define CXLMDEV_MS_DISABLED 3
|
|
|
|
#define CXLMDEV_READY(status) \
|
|
|
|
(FIELD_GET(CXLMDEV_STATUS_MEDIA_STATUS_MASK, status) == \
|
|
|
|
CXLMDEV_MS_READY)
|
|
|
|
#define CXLMDEV_MBOX_IF_READY BIT(4)
|
|
|
|
#define CXLMDEV_RESET_NEEDED_MASK GENMASK(7, 5)
|
|
|
|
#define CXLMDEV_RESET_NEEDED_NOT 0
|
|
|
|
#define CXLMDEV_RESET_NEEDED_COLD 1
|
|
|
|
#define CXLMDEV_RESET_NEEDED_WARM 2
|
|
|
|
#define CXLMDEV_RESET_NEEDED_HOT 3
|
|
|
|
#define CXLMDEV_RESET_NEEDED_CXL 4
|
|
|
|
#define CXLMDEV_RESET_NEEDED(status) \
|
|
|
|
(FIELD_GET(CXLMDEV_RESET_NEEDED_MASK, status) != \
|
|
|
|
CXLMDEV_RESET_NEEDED_NOT)
|
|
|
|
|
2021-08-03 01:29:59 +08:00
|
|
|
/**
|
|
|
|
* struct cdevm_file_operations - devm coordinated cdev file operations
|
|
|
|
* @fops: file operations that are synchronized against @shutdown
|
|
|
|
* @shutdown: disconnect driver data
|
|
|
|
*
|
|
|
|
* @shutdown is invoked in the devres release path to disconnect any
|
|
|
|
* driver instance data from @dev. It assumes synchronization with any
|
|
|
|
* fops operation that requires driver data. After @shutdown an
|
|
|
|
* operation may only reference @device data.
|
|
|
|
*/
|
|
|
|
struct cdevm_file_operations {
|
|
|
|
struct file_operations fops;
|
|
|
|
void (*shutdown)(struct device *dev);
|
|
|
|
};
|
|
|
|
|
2021-05-14 13:21:49 +08:00
|
|
|
/**
|
|
|
|
* struct cxl_memdev - CXL bus object representing a Type-3 Memory Device
|
|
|
|
* @dev: driver core device object
|
|
|
|
* @cdev: char dev core object for ioctl operations
|
|
|
|
* @cxlm: pointer to the parent device driver data
|
|
|
|
* @id: id number of this memdev instance.
|
|
|
|
*/
|
|
|
|
struct cxl_memdev {
|
|
|
|
struct device dev;
|
|
|
|
struct cdev cdev;
|
|
|
|
struct cxl_mem *cxlm;
|
|
|
|
int id;
|
|
|
|
};
|
|
|
|
|
2021-08-03 01:30:05 +08:00
|
|
|
static inline struct cxl_memdev *to_cxl_memdev(struct device *dev)
|
|
|
|
{
|
|
|
|
return container_of(dev, struct cxl_memdev, dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct cxl_memdev *
|
|
|
|
devm_cxl_add_memdev(struct device *host, struct cxl_mem *cxlm,
|
|
|
|
const struct cdevm_file_operations *cdevm_fops);
|
|
|
|
|
2021-05-14 13:21:49 +08:00
|
|
|
/**
|
|
|
|
* struct cxl_mem - A CXL memory device
|
|
|
|
* @pdev: The PCI device associated with this CXL device.
|
cxl/mem: Introduce 'struct cxl_regs' for "composable" CXL devices
CXL MMIO register blocks are organized by device type and capabilities.
There are Component registers, Device registers (yes, an ambiguous
name), and Memory Device registers (a specific extension of Device
registers).
It is possible for a given device instance (endpoint or port) to
implement register sets from multiple of the above categories.
The driver code that enumerates and maps the registers is type specific
so it is useful to have a dedicated type and helpers for each block
type.
At the same time, once the registers are mapped the origin type does not
matter. It is overly pedantic to reference the register block type in
code that is using the registers.
In preparation for the endpoint driver to incorporate Component registers
into its MMIO operations reorganize the registers to allow typed
enumeration + mapping, but anonymous usage. With the end state of
'struct cxl_regs' to be:
struct cxl_regs {
union {
struct {
CXL_DEVICE_REGS();
};
struct cxl_device_regs device_regs;
};
union {
struct {
CXL_COMPONENT_REGS();
};
struct cxl_component_regs component_regs;
};
};
With this arrangement the driver can share component init code with
ports, but when using the registers it can directly reference the
component register block type by name without the 'component_regs'
prefix.
So, map + enumerate can be shared across drivers of different CXL
classes e.g.:
void cxl_setup_device_regs(struct device *dev, void __iomem *base,
struct cxl_device_regs *regs);
void cxl_setup_component_regs(struct device *dev, void __iomem *base,
struct cxl_component_regs *regs);
...while inline usage in the driver need not indicate where the
registers came from:
readl(cxlm->regs.mbox + MBOX_OFFSET);
readl(cxlm->regs.hdm + HDM_OFFSET);
...instead of:
readl(cxlm->regs.device_regs.mbox + MBOX_OFFSET);
readl(cxlm->regs.component_regs.hdm + HDM_OFFSET);
This complexity of the definition in .h yields improvement in code
readability in .c while maintaining type-safety for organization of
setup code. It prepares the implementation to maintain organization in
the face of CXL devices that compose register interfaces consisting of
multiple types.
Given that this new container is named 'regs' rename the common register
base pointer @base, and fixup the kernel-doc for the missing @cxlmd
description.
Reviewed-by: Ben Widawsky <ben.widawsky@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/162096971451.1865304.13540251513463515153.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-05-14 13:21:54 +08:00
|
|
|
* @cxlmd: Logical memory device chardev / interface
|
|
|
|
* @regs: Parsed register blocks
|
2021-05-14 13:21:49 +08:00
|
|
|
* @payload_size: Size of space for payload
|
|
|
|
* (CXL 2.0 8.2.8.4.3 Mailbox Capabilities Register)
|
2021-05-21 03:47:45 +08:00
|
|
|
* @lsa_size: Size of Label Storage Area
|
|
|
|
* (CXL 2.0 8.2.9.5.1.1 Identify Memory Device)
|
2021-05-14 13:21:49 +08:00
|
|
|
* @mbox_mutex: Mutex to synchronize mailbox access.
|
|
|
|
* @firmware_version: Firmware version for the memory device.
|
|
|
|
* @enabled_cmds: Hardware commands found enabled in CEL.
|
|
|
|
* @pmem_range: Persistent memory capacity information.
|
|
|
|
* @ram_range: Volatile memory capacity information.
|
|
|
|
*/
|
|
|
|
struct cxl_mem {
|
|
|
|
struct pci_dev *pdev;
|
|
|
|
struct cxl_memdev *cxlmd;
|
|
|
|
|
cxl/mem: Introduce 'struct cxl_regs' for "composable" CXL devices
CXL MMIO register blocks are organized by device type and capabilities.
There are Component registers, Device registers (yes, an ambiguous
name), and Memory Device registers (a specific extension of Device
registers).
It is possible for a given device instance (endpoint or port) to
implement register sets from multiple of the above categories.
The driver code that enumerates and maps the registers is type specific
so it is useful to have a dedicated type and helpers for each block
type.
At the same time, once the registers are mapped the origin type does not
matter. It is overly pedantic to reference the register block type in
code that is using the registers.
In preparation for the endpoint driver to incorporate Component registers
into its MMIO operations reorganize the registers to allow typed
enumeration + mapping, but anonymous usage. With the end state of
'struct cxl_regs' to be:
struct cxl_regs {
union {
struct {
CXL_DEVICE_REGS();
};
struct cxl_device_regs device_regs;
};
union {
struct {
CXL_COMPONENT_REGS();
};
struct cxl_component_regs component_regs;
};
};
With this arrangement the driver can share component init code with
ports, but when using the registers it can directly reference the
component register block type by name without the 'component_regs'
prefix.
So, map + enumerate can be shared across drivers of different CXL
classes e.g.:
void cxl_setup_device_regs(struct device *dev, void __iomem *base,
struct cxl_device_regs *regs);
void cxl_setup_component_regs(struct device *dev, void __iomem *base,
struct cxl_component_regs *regs);
...while inline usage in the driver need not indicate where the
registers came from:
readl(cxlm->regs.mbox + MBOX_OFFSET);
readl(cxlm->regs.hdm + HDM_OFFSET);
...instead of:
readl(cxlm->regs.device_regs.mbox + MBOX_OFFSET);
readl(cxlm->regs.component_regs.hdm + HDM_OFFSET);
This complexity of the definition in .h yields improvement in code
readability in .c while maintaining type-safety for organization of
setup code. It prepares the implementation to maintain organization in
the face of CXL devices that compose register interfaces consisting of
multiple types.
Given that this new container is named 'regs' rename the common register
base pointer @base, and fixup the kernel-doc for the missing @cxlmd
description.
Reviewed-by: Ben Widawsky <ben.widawsky@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/162096971451.1865304.13540251513463515153.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-05-14 13:21:54 +08:00
|
|
|
struct cxl_regs regs;
|
2021-05-14 13:21:49 +08:00
|
|
|
|
|
|
|
size_t payload_size;
|
2021-05-21 03:47:45 +08:00
|
|
|
size_t lsa_size;
|
2021-05-14 13:21:49 +08:00
|
|
|
struct mutex mbox_mutex; /* Protects device mailbox and firmware */
|
|
|
|
char firmware_version[0x10];
|
|
|
|
unsigned long *enabled_cmds;
|
|
|
|
|
|
|
|
struct range pmem_range;
|
|
|
|
struct range ram_range;
|
2021-06-18 06:16:18 +08:00
|
|
|
u64 total_bytes;
|
|
|
|
u64 volatile_only_bytes;
|
|
|
|
u64 persistent_only_bytes;
|
|
|
|
u64 partition_align_bytes;
|
2021-08-11 02:57:59 +08:00
|
|
|
|
|
|
|
u64 active_volatile_bytes;
|
|
|
|
u64 active_persistent_bytes;
|
|
|
|
u64 next_volatile_bytes;
|
|
|
|
u64 next_persistent_bytes;
|
2021-05-14 13:21:49 +08:00
|
|
|
};
|
|
|
|
#endif /* __CXL_MEM_H__ */
|