| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Currently in NX, only write xscom config failures are tracing.
Add trace statements for read xscom config failures too.
No functional changes.
Signed-off-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
"ibm, power9-nx" should be "ibm,power9-nx" and the mismatch was
causing nuisance errors at boot.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.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>
|
|
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>
|
|
Set the NX crb input queues to be used by 842 only, by not reserving any input
queue slots for the sym or asym engines. This allows the maximum number of
842 crb requests to be queued up, to (hopefully) improve 842 performance.
This patch isn't critical, as the default is no extra input queue locations
for asym, and only 1 extra input queue location for sym, so this only takes
sym's extra location for use by 842.
There is 1 each dedicated input queue location for asym and sym (and 842), so
this patch won't prevent them from working if support is ever added for them.
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>
|
|
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>
|
