Michael Neuling [mikey@neuling.org] wrote:

On Thu, 2017-03-16 at 20:33 -0700, Sukadev Bhattiprolu wrote:

quoted

Define macros for the VAS hardware registers and bit-fields as well
as couple of data structures needed by the VAS driver.
=20

quoted

Signed-off-by: Sukadev Bhattiprolu <redacted>

---
Changelog[v3]
	- Rename winctx->pid to winctx->pidr to reflect that its a value
	=A0=A0from the PID register (SPRN_PID), not the linux process id.
	- Make it easier to split header into kernel/user parts
	- To keep user interface simple, use macros rather than enum for
	=A0=A0the threshold-control modes.
	- Add a pid field to struct vas_window - needed for user space
	=A0=A0send windows.
=20
Changelog[v2]
	- Add an overview of VAS in vas-internal.h
	- Get window context parameters from device tree and drop
	=A0=A0unnecessary macros.
---
=A0MAINTAINERS=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=

=A0=A0|=A0=A0=A06 +

quoted

=A0arch/powerpc/include/asm/vas.h=A0=A0|=A0=A043 +++++
=A0drivers/misc/vas/vas-internal.h | 392 ++++++++++++++++++++++++++++++=

++++++++++

=20
This is going to have to go through gregkh/lkml if it's drivers/misc.  yo=

u'll at

least need gregkh's ack/ok before mpe will take them (which is what we di=

d for

CAPI).
=20
We might want to keep this in arch/powerpc but I'm not sure.
=20

We will have device nodes accessible to user space so put it here and can
copy Gregkh next time. But let me know if we should move to arch/powerpc.

quoted

=A03 files changed, 441 insertions(+)
=A0create mode 100644 arch/powerpc/include/asm/vas.h
=A0create mode 100644 drivers/misc/vas/vas-internal.h
=20

<snip>

quoted

+
+/*
+ * Overview of Virtual Accelerator Switchboard (VAS).
+ *
+ * VAS is a hardware "switchboard" that allows senders and receivers to
+ * exchange messages with _minimal_ kernel involvment. The receivers a=

re

quoted

+ * typically NX coprocessor engines that perform compression or encryp=

tion

quoted

+ * in hardware, but receivers can also be other software threads.
+ *
+ * Senders are user/kernel threads that submit compression/encryption =

or

quoted

+ * other requests to the receivers. Senders must format their messages=

 as

quoted

+ * Coprocessor Request Blocks (CRB)s and submit them using the instruc=

tions

quoted

+ * "copy" and "paste" which were introduced in Power9.
+ *
+ * A Power node can have (upto?) 8 Power chips. There is one instance =

of

quoted

+ * VAS in each Power9 chip. Each instance of VAS has 64K windows or po=

rts,

quoted

+ * Senders and receivers must each connect to a separate window before=

 they

quoted

+ * can exchange messages through the switchboard.
+ *
+ * Each window is described by two types of window contexts:
+ *

quoted

+ *	Hypervisor Window Context (HVWC) of size VAS_HVWC_SIZE bytes

+ *

quoted

+ *	OS/User Window Context (UWC) of size VAS_UWC_SIZE bytes.

+ *
+ * A window context can be viewed as a set of 64-bit registers. The se=

ttings

quoted

+ * in these registers configure/control/determine the behavior of the =

VAS

quoted

+ * hardware when messages are sent/received through the window. The re=

gisters

quoted

+ * in the HVWC are configured by the kernel while the registers in the=

 UWC can

quoted

+ * be configured by the kernel or by the user space application that i=

s using

quoted

+ * the window.
+ *
+ * The HVWCs for all windows on a specific instance of VAS are in a co=

ntiguous

quoted

+ * range of hardware addresses or Base address region (BAR) referred t=

o as the

quoted

+ * HVWC BAR for the instance. Similarly the UWCs for all windows on an=

 instance

quoted

+ * are referred to as the UWC BAR for the instance. The two BARs for e=

ach

quoted

+ * instance are defined Power9 MMIO Ranges spreadsheet and available t=

o the

quoted

+ * kernel the device tree as follows:
+ *

quoted

+ *	/proc/device-tree/xscom@.../vas@.../hvwc-bar-start
+ *	/proc/device-tree/xscom@.../vas@.../hvwc-bar-size
+ *	/proc/device-tree/xscom@.../vas@.../uwc-bar-start

+ *	/proc/device-tree/xscom@.../vas@.../uwc-bar-size

=20
should these just be reg properties?

I guess they could. Will try that

=20

quoted

+ *
+ * The kernel maps these two hardware address regions into the kernel =

address

quoted

+ * space (hvwc_map and uwc_map) and accesses the window contexts of a =

specific

quoted

+ * window using:
+ *

quoted

+ *	=A0hvwc =3D hvwc_map + winid * VAS_HVWC_SIZE.
+ *	=A0uwc =3D uwc_map + winid * VAS_UWC_SIZE.

+ *
+ * where winid is the window index (0..64K).
+ *
+ * Note that the window contexts are used to "configure" the windows. =

In

quoted

+ * addition to this configuration address, each _send_ window also has=

 a

quoted

+ * unique hardware address, referred to as the "paste-address" to whic=

h the

quoted

+ * sender must "paste" the message (CRB) they wish to submit. This har=

dware

quoted

+ * paste address for window can be computed from the following nodes i=

n the

quoted

+ * device tree:
+ *

quoted

+ *	/proc/device-tree/xscom@.../vas@.../window-base

+ *	/proc/device-tree/xscom@.../vas@.../window-shift

=20
Same here with reg properties.

ok

=20
<snip>=20

quoted

+struct vas_winctx {

<snip>

quoted

quoted

+	int lpid;

+	int pidr;		/* value from SPRN_PID, not linux pid */

=20
I'm surprised we have a copy of these here.  They should be accessed from=

 the

context we are attaching to, rather than copied here... but I've not look=

ed at

the rest of the code yet...

struct vas_winctx is just a convenient container for the window context.
It gets initialized based on type/use of window (user/kernel send/receive).
The lpid/pid are set by callers of VAS kernel interfaces.

Sukadev