On Renesas Salvaotor board with Xen SCIF2 is provided to hypervisor, so
kernel should not manage SCIF2 clock.

Signed-off-by: Iurii Konovalenko <[email protected]>
Signed-off-by: Andrii Anisov <[email protected]>

This function creates userspace mapping for the DMA-coherent memory.

Signed-off-by: Stefano Stabellini <[email protected]>
Signed-off-by: Oleksandr Dmytryshyn <[email protected]>
Signed-off-by: Andrii Anisov <[email protected]>

Signed-off-by: Andrii Anisov <[email protected]>

The defconfig was copied from here:
path_to_yocto/build/tmp/work-shared/salvator-x/kernel-build-artifacts/.config

I guess this .config is a result of following defconfigs:
path_to_kernel/arch/arm64/configs/defconfig
path_to_yocto/meta-renesas/meta-rcar-gen3/recipes-kernel/linux/linux-renesas/*

Signed-off-by: Oleksandr Tyshchenko <[email protected]>

Signed-off-by: Oleksandr Tyshchenko <[email protected]>

The device-tree was copied from here:
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts

Signed-off-by: Oleksandr Tyshchenko <[email protected]>

Signed-off-by: Oleksandr Tyshchenko <[email protected]>

Signed-off-by: Oleksandr Tyshchenko <[email protected]>

…them

The list of devices being connected to the IPMMU:
- usb
- sata
- gsx
- avb
- sdhi

Temporarily unconnect system dmacs from the IPMMUs.

Signed-off-by: Oleksandr Tyshchenko <[email protected]>

This simple dts contains only gsx node as we want it to be
passthroughed to the guest domain.

One important notice regarding gsx usage in domu.
DEVPATH string in the 72-pvr-seat.rules file should be changed
from
"/devices/platform/soc/fd000000.gsx/drm/*"
to
"/devices/platform/passthrough/fd000000.gsx/drm/*"

Signed-off-by: Oleksandr Tyshchenko <[email protected]>

Retrieve gsx clock (3dge in our case) and enable it to
make gsx happy.

Signed-off-by: Oleksandr Tyshchenko <[email protected]>

With gsx being passthroughed to the guest domain there is nobody in the
harware domain to care about gsx power resources.
So, ask rcar-du to enable gsx clock and power domain for now.

Following patch must be applied for rcar-du system for getting
the appropriate clock configured and enabled (3dge in our case):
drm: rcar-du: hack: Enable gsx clock too

Signed-off-by: Oleksandr Tyshchenko <[email protected]>

Signed-off-by: Oleksandr Tyshchenko <[email protected]>

The patch clarifies the protocol that is used by the PV keyboard
drivers.

Signed-off-by: Oleksandr Andrushchenko <[email protected]>
Acked-by: Juergen Gross <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>

Multi-touch fields re-use the page that is used by the other features
which means that you can interleave multi-touch, motion, and key
events.

Signed-off-by: Oleksandr Andrushchenko <[email protected]>
Acked-by: Juergen Gross <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>

This is the ABI for the two halves of a para-virtualized
display driver.

This protocol aims to provide a unified protocol which fits more
sophisticated use-cases than a framebuffer device can handle. At the
moment basic functionality is supported with the intention to extend:
  o multiple dynamically allocated/destroyed framebuffers
  o buffers of arbitrary sizes
  o better configuration options including multiple display support

Note: existing fbif can be used together with displif running at the
same time, e.g. on Linux one provides framebuffer and another DRM/KMS

Future extensions to the existing protocol may include:
  o allow display/connector cloning
  o allow allocating objects other than display buffers
  o add planes/overlays support
  o support scaling
  o support rotation

Note, that this protocol doesn't use ring macros for
bi-directional exchange (PV calls/9pfs) bacause:
  o it statically defines the use of a single page
    for the ring buffer
  o it uses direct memory access to ring's contents
    w/o memory copying
  o re-uses the same idea that kbdif/fbif use
    which for this use-case seems to be appropriate

==================================================
Rationale for introducing this protocol instead of
using the existing fbif:
==================================================

1. In/out event sizes
  o fbif - 40 octets
  o displif - 40 octets
This is only the initial version of the displif protocol
which means that there could be requests which will not fit
(WRT introducing some GPU related functionality
later on). In that case we cannot alter fbif sizes as we need to
be backward compatible an will be forced to handle those
apart of fbif.

2. Shared page
Displif doesn't use anything like struct xenfb_page, but
DEFINE_RING_TYPES(xen_displif, struct xendispl_req, struct
xendispl_resp) which is a better and more common way.
Output events use a shared page which only has in_cons and in_prod
and all the rest is used for incoming events. Here struct xenfb_page
could probably be used as is despite the fact that it only has a half
of a page for incoming events which is only 50 events. (consider
something like 60Hz display)

3. Amount of changes.
fbif only provides XENFB_TYPE_UPDATE and XENFB_TYPE_RESIZE
events, so it looks like it is easier to get fb support into displif
than vice versa. displif at the moment has 6 requests and 1 event,
multiple connector support, etc.

Signed-off-by: Oleksandr Grytsov <[email protected]>
Signed-off-by: Oleksandr Andrushchenko <[email protected]>
Acked-by: Juergen Gross <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>

There are multiple instances of code reading an optional unsigned
parameter from Xenstore via xenbus_scanf(). Instead of repeating the
same code over and over add a service function doing the job.

Signed-off-by: Juergen Gross <[email protected]>
Reviewed-by: David Vrabel <[email protected]>

Use xenbus_read_unsigned() instead of xenbus_scanf() when possible.
This requires to change the type of the reads from int to unsigned,
but these cases have been wrong before: negative values are not allowed
for the modified cases.

Cc: [email protected]
Cc: [email protected]

Signed-off-by: Juergen Gross <[email protected]>
Acked-by: David Vrabel <[email protected]>

Signed-off-by: Oleksandr Andrushchenko <[email protected]>

Add a parameter for setting the resolution of xen-kbdfront in order to
be able to cope with a (virtual) frame buffer of arbitrary resolution.

While at it remove the pointless second reading of parameters from
Xenstore in the device connection phase: all parameters are available
during device probing already and that is where they should be read.

Signed-off-by: Juergen Gross <[email protected]>

Xen input para-virtual protocol defines string constants
used by both back and frontend. Use those instead of
explicit strings in the frontend driver.

Signed-off-by: Oleksandr Andrushchenko <[email protected]>

Extend xen_kbdfront to provide multi-touch support
to unprivileged domains.

Signed-off-by: Oleksandr Andrushchenko <[email protected]>

Actually it is a copy of salvator_x_dom0_defconfig but with
following strings added:

CONFIG_DRM_XEN=y
CONFIG_DRM_XEN_FRONTEND=y
CONFIG_INPUT_UINPUT=y

Signed-off-by: Oleksandr Tyshchenko <[email protected]>