| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
