| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This patch adds changes needed for 842 compression engine on power 9.
Virtual Accelerator Switch (VAS) is used to access NX 842 engine on P9
and the channel setup will be done with receive FIFO. So RxFIFO
address, logical partition ID (lpid), process ID (pid) and thread ID
(tid) are used for this setup. p9 NX supports high and normal priority
FIFOs. skiboot is not involved to process data with 842 engine, but
configures User Mode Access Control (UMAC) noitify match register with
these values and export them to kernel with device-tree entries.
Also configure registers to setup and enable / disable the engine with
the appropriate registers. Creates the following device-tree entries to
provide RxFIFO address, RxFIFO size, Fifo priority, lpid, pid and tid
values so that kernel can drive P9 NX 842 engine.
The following nodes are located under an xscom node:
/xscom@<xscom_addr>/nx@<nx_addr>
/ibm,842-high-fifo : High priority 842 RxFIFO
/ibm,842-normal-fifo : Normal priority 842 RxFIFO
Each RxFIFO node contains:
compatible : ibm,p9-nx-842
priority : High or Normal
rx-fifo-address : RxFIFO address
rx-fifo-size : RXFIFO size
lpid : 0xfff (1's for 12 bits set in UMAC notify
match register)
pid : 842 coprocessor type
tid : Counter for 842
Signed-off-by: Haren Myneni <haren@us.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
P9 NX also supports gzip compression. So this patch creates
nx-compress.c and reorg nx-842.c code so that common functions that are
needed for both 842 and gzip compression will be moved in to
nx-compress.c. This patch does not change the actual functionality.
Signed-off-by: Haren Myneni <hmyneni@us.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
In commit e077676 the nx CI's were changed to just use the chip id.
That works fine, except CI 0 is reserved, so if there is a chip id
of 0, the CI is set to 0, which is invalid. This doesn't currently
affect the kernel driver, as it just uses the reserved CI of 0 for
all requests, as CI == 0 tells the hw to auto-select which CI to
send the request to. However, valid CI's should be assigned; we can
use the chip id + 1 to ensure a valid CI.
This commit fixes the CI assignment by setting each CI to the chip
id + 1.
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Simplify the NX 842 config logic by using the global proc_gen to
conditionally apply P8-specific configuration values, instead of
passing the proc gen in a function parameter.
No functional change here, it just simplifies the code.
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Remove the counters for each NX engine that are used to assign a unique
Coprocessor Instance (CI) to each engine, and instead just use the chip
id for the CI.
Originally I created the counter to avoid the possibility of assigning
a CI that was out of the defined range for each engine's CI, but I did
not check then what the max chip id was. Since MAX_CHIPS is 64, which
is less than all the engine's max CI value, the chip id can be safely
used for the engine CI.
Additionally, add a BUILD_ASSERT in each engine's setup to verify that
MAX_CHIPS is <= the engine's max CI.
While this changes the CI numbers that are visible to the kernel driver,
the CI values can't be relied on by the kernel to be any specific number,
so this has no effect from an API perspective. The kernel will simply
use whatever CI values are provided (technically, the current kernel
driver uses the special "0" CI value to allow the hw to select which
instance to use for each request, and it does nothing with the actual
CI values).
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Add NX config register values for P7+. Remove "P8" from all register
defines, where the define is common to P7+ and P8. For values new to P8
(specifically 842 prefeching), only enable on P8.
This should correctly setup the NX coprocessors on P7+ systems.
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We don't actually need to use a separate node for the nx-842
details, so move its information nodes (for CT and CI) under
each main nx node for each coprocessor.
Part of the reason for this is the kernel driver will need to
read/write xscom registers, for coprocessor monitoring and
error recovery, and locating the CT and CI nodes under the
main nx node allows the nx-842 driver to easily get more
information about the coprocessor, like its base xscom
address, and the processor version (p7, p8, etc).
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Add support for the 842 hw memory compression engine in the NX Coprocessor.
This moves the existing RNG support into its own nx-rng.c file, adds 842
support in a nx-842.c file, and creates a nx-crypto.c file to configure and
disable the crypto engines (which are not supported yet).
New nodes are created for each 842 engine found. This does not actually
process any of the data or drive the 842 engines, it only configures
registers to set up and enable/disable the engines appropriately, and
creates new nodes so the OS can drive the 842 engines.
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
