[PATCH v1 0/2] Add support for Xilinx ZynqMP SoC

[PATCH v1 0/2] Add support for Xilinx ZynqMP SoC

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>

Adds support for the Cadence UART in Xilinx ZynqMP. The
rest of the ZynqMP platform is discovered via device-tree.

Cheers,
Edgar

Edgar E. Iglesias (2):
  xen/arm: Add Cadence UART driver
  xen/arm: Add Xilinx ZynqMP early printk support

 config/arm64.mk                      |   1 +
 docs/misc/arm/early-printk.txt       |   1 +
 xen/arch/arm/Rules.mk                |   6 +
 xen/arch/arm/arm64/debug-cadence.inc |  45 +++++++
 xen/drivers/char/Makefile            |   1 +
 xen/drivers/char/cadence-uart.c      | 222 +++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/cadence-uart.h   |  55 +++++++++
 7 files changed, 331 insertions(+)
 create mode 100644 xen/arch/arm/arm64/debug-cadence.inc
 create mode 100644 xen/drivers/char/cadence-uart.c
 create mode 100644 xen/include/asm-arm/cadence-uart.h

-- 
1.9.1

[PATCH v1 1/2] xen/arm: Add Cadence UART driver

[Edgar E. Iglesias]

Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
---
 config/arm64.mk                    |   1 +
 xen/drivers/char/Makefile          |   1 +
 xen/drivers/char/cadence-uart.c    | 222 +++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/cadence-uart.h |  55 +++++++++
 4 files changed, 279 insertions(+)
 create mode 100644 xen/drivers/char/cadence-uart.c
 create mode 100644 xen/include/asm-arm/cadence-uart.h

diff --git a/config/arm64.mk b/config/arm64.mk
index 6eafda2..df6ad0a 100644
--- a/config/arm64.mk
+++ b/config/arm64.mk
@@ -7,6 +7,7 @@ CONFIG_XEN_INSTALL_SUFFIX :=
 CFLAGS += #-marm -march= -mcpu= etc
 
 HAS_PL011 := y
+HAS_CADENCE_UART := y
 HAS_NS16550 := y
 
 # Use only if calling $(LD) directly.
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index 9e94195..47fc3f9 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -1,5 +1,6 @@
 obj-y += console.o
 obj-$(HAS_NS16550) += ns16550.o
+obj-$(HAS_CADENCE_UART) += cadence-uart.o
 obj-$(HAS_PL011) += pl011.o
 obj-$(HAS_EXYNOS4210) += exynos4210-uart.o
 obj-$(HAS_OMAP) += omap-uart.o
diff --git a/xen/drivers/char/cadence-uart.c b/xen/drivers/char/cadence-uart.c
new file mode 100644
index 0000000..583bf21
--- /dev/null
+++ b/xen/drivers/char/cadence-uart.c
@@ -0,0 +1,222 @@
+/*
+ * xen/drivers/char/cadence-uart.c
+ *
+ * Driver for Cadence UART in Xilinx ZynqMP.
+ *
+ * Written by Edgar E. Iglesias <edgar.iglesias@gmail.com>
+ * Copyright (c) 2015 Xilinx Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/config.h>
+#include <xen/console.h>
+#include <xen/serial.h>
+#include <xen/init.h>
+#include <xen/irq.h>
+#include <xen/device_tree.h>
+#include <xen/errno.h>
+#include <asm/device.h>
+#include <xen/mm.h>
+#include <xen/vmap.h>
+#include <asm/cadence-uart.h>
+#include <asm/io.h>
+
+static struct cuart {
+    unsigned int irq;
+    void __iomem *regs;
+    /* UART with IRQ line: interrupt-driven I/O. */
+    struct irqaction irqaction;
+    struct vuart_info vuart;
+} cuart_com = {0};
+
+#define cuart_read(uart, off)           readl((uart)->regs + (off))
+#define cuart_write(uart, off,val)      writel((val), (uart)->regs + (off))
+
+static void cuart_interrupt(int irq, void *data, struct cpu_user_regs *regs)
+{
+    struct serial_port *port = data;
+    struct cuart *uart = port->uart;
+    unsigned int status;
+
+    do {
+        status = cuart_read(uart, R_UART_SR);
+        /* ACK.  */
+        if (status & UART_SR_INTR_RTRIG) {
+            serial_rx_interrupt(port, regs);
+            cuart_write(uart, R_UART_CISR, UART_SR_INTR_RTRIG);
+        }
+    } while (status & UART_SR_INTR_RTRIG);
+}
+
+static void __init cuart_init_preirq(struct serial_port *port)
+{
+    struct cuart *uart = port->uart;
+
+    cuart_write(uart, R_UART_MR, UART_MR_NO_PARITY);
+    /* Enable and Reset both the RX and TX paths.  */
+    cuart_write(uart, R_UART_CR, UART_CR_RX_RST | UART_CR_TX_RST |
+                      UART_CR_RX_ENABLE | UART_CR_TX_ENABLE);
+}
+
+static void __init cuart_init_postirq(struct serial_port *port)
+{
+    struct cuart *uart = port->uart;
+    int rc;
+
+    if ( uart->irq > 0 ) {
+        uart->irqaction.handler = cuart_interrupt;
+        uart->irqaction.name    = "cadence-uart";
+        uart->irqaction.dev_id  = port;
+        if ( (rc = setup_irq(uart->irq, 0, &uart->irqaction)) != 0 )
+            printk("ERROR: Failed to allocate cadence-uart IRQ %d\n", uart->irq);
+    }
+
+    /* Clear pending error interrupts */
+    cuart_write(uart, R_UART_RTRIG, 1);
+    cuart_write(uart, R_UART_CISR, ~0);
+
+    /* Unmask interrupts */
+    cuart_write(uart, R_UART_IDR, ~0);
+    cuart_write(uart, R_UART_IER, UART_SR_INTR_RTRIG);
+}
+
+static void cuart_suspend(struct serial_port *port)
+{
+    BUG();
+}
+
+static void cuart_resume(struct serial_port *port)
+{
+    BUG();
+}
+
+static int cuart_tx_ready(struct serial_port *port)
+{
+    struct cuart *uart = port->uart;
+    unsigned int status = cuart_read(uart, R_UART_SR);
+
+    return !(status & UART_SR_INTR_TFUL);
+}
+
+static void cuart_putc(struct serial_port *port, char c)
+{
+    struct cuart *uart = port->uart;
+
+    cuart_write(uart, R_UART_TX, (uint32_t)(unsigned char)c);
+}
+
+static int cuart_getc(struct serial_port *port, char *pc)
+{
+    struct cuart *uart = port->uart;
+
+    if (cuart_read(uart, R_UART_SR) & UART_SR_INTR_REMPTY)
+        return 0;
+
+    *pc = cuart_read(uart, R_UART_RX) & 0xff;
+    return 1;
+}
+
+static int __init cuart_irq(struct serial_port *port)
+{
+    struct cuart *uart = port->uart;
+
+    return ((uart->irq > 0) ? uart->irq : -1);
+}
+
+static const struct vuart_info *cuart_vuart(struct serial_port *port)
+{
+    struct cuart *uart = port->uart;
+
+    return &uart->vuart;
+}
+
+static struct uart_driver __read_mostly cuart_driver = {
+    .init_preirq  = cuart_init_preirq,
+    .init_postirq = cuart_init_postirq,
+    .endboot      = NULL,
+    .suspend      = cuart_suspend,
+    .resume       = cuart_resume,
+    .tx_ready     = cuart_tx_ready,
+    .putc         = cuart_putc,
+    .getc         = cuart_getc,
+    .irq          = cuart_irq,
+    .vuart_info   = cuart_vuart,
+};
+
+static int __init cuart_init(struct dt_device_node *dev, const void *data)
+{
+    const char *config = data;
+    struct cuart *uart;
+    int res;
+    u64 addr, size;
+
+    if ( strcmp(config, "") )
+        printk("WARNING: UART configuration is not supported\n");
+
+    uart = &cuart_com;
+
+    res = dt_device_get_address(dev, 0, &addr, &size);
+    if ( res )
+    {
+        printk("cadence: Unable to retrieve the base"
+               " address of the UART\n");
+        return res;
+    }
+
+    res = platform_get_irq(dev, 0);
+    if ( res < 0 )
+    {
+        printk("cadence: Unable to retrieve the IRQ\n");
+        return -EINVAL;
+    }
+    uart->irq = res;
+
+    uart->regs = ioremap_nocache(addr, size);
+    if ( !uart->regs )
+    {
+        printk("cadence: Unable to map the UART memory\n");
+        return -ENOMEM;
+    }
+
+    uart->vuart.base_addr = addr;
+    uart->vuart.size = size;
+    uart->vuart.data_off = R_UART_RX;
+    uart->vuart.status_off = R_UART_SR;
+    uart->vuart.status = UART_SR_INTR_TEMPTY;
+
+    /* Register with generic serial driver. */
+    serial_register_uart(SERHND_DTUART, &cuart_driver, uart);
+
+    dt_device_set_used_by(dev, DOMID_XEN);
+
+    return 0;
+}
+
+static const char * const cuart_dt_compat[] __initconst =
+{
+    "cdns,uart-r1p8",
+    NULL
+};
+
+DT_DEVICE_START(cuart, "Cadence UART", DEVICE_SERIAL)
+    .compatible = cuart_dt_compat,
+    .init = cuart_init,
+DT_DEVICE_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/cadence-uart.h b/xen/include/asm-arm/cadence-uart.h
new file mode 100644
index 0000000..48680ee
--- /dev/null
+++ b/xen/include/asm-arm/cadence-uart.h
@@ -0,0 +1,55 @@
+/*
+ * xen/include/asm-arm/cadence-uart.h
+ *
+ * Written by Edgar E. Iglesias <edgar.iglesias@xilinx.com>
+ * Copyright (C) 2015 Xilinx Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ASM_ARM_CADENCE_UART_H__
+#define __ASM_ARM_CADENCE_UART_H__
+
+#define R_UART_CR    0x00
+#define UART_CR_RX_RST       0x01
+#define UART_CR_TX_RST       0x02
+#define UART_CR_RX_ENABLE    0x04
+#define UART_CR_RX_DISABLE   0x08
+#define UART_CR_TX_ENABLE    0x10
+#define UART_CR_TX_DISABLE   0x20
+
+#define R_UART_MR    0x04
+#define UART_MR_NO_PARITY    0x20
+
+#define R_UART_IER   0x08
+#define R_UART_IDR   0x0C
+#define R_UART_IMR   0x10
+#define R_UART_CISR  0x14
+#define R_UART_RTRIG 0x20
+#define R_UART_SR    0x2C
+#define UART_SR_INTR_RTRIG   0x01
+#define UART_SR_INTR_REMPTY  0x02
+#define UART_SR_INTR_TEMPTY  0x08
+#define UART_SR_INTR_TFUL    0x10
+
+#define R_UART_TX    0x30
+#define R_UART_RX    0x30
+
+#endif /* __ASM_ARM_CADENCE_UART_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.9.1

Re: [PATCH v1 1/2] xen/arm: Add Cadence UART driver

[Ian Campbell]

On Thu, 2015-03-05 at 18:27 +1000, Edgar E. Iglesias wrote:
> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
> ---
>  config/arm64.mk                    |   1 +
>  xen/drivers/char/Makefile          |   1 +
>  xen/drivers/char/cadence-uart.c    | 222 +++++++++++++++++++++++++++++++++++++
>  xen/include/asm-arm/cadence-uart.h |  55 +++++++++
>  4 files changed, 279 insertions(+)
>  create mode 100644 xen/drivers/char/cadence-uart.c
>  create mode 100644 xen/include/asm-arm/cadence-uart.h

I tried to apply this but:

cadence-uart.c:211:5: error: unknown field 'compatible' specified in initializer
     .compatible = cuart_dt_compat,
     ^
cadence-uart.c:211:5: error: initialization from incompatible pointer type [-Werror]
cadence-uart.c:211:5: error: (near initialization for '__dev_desc_cuart.dt_match') [-Werror]
cc1: all warnings being treated as errors

I think because this patch needs to be rebased onto:
commit f9eff198f9d4863e80078a33001a9bb90a99a4b1
Author: Julien Grall <julien.grall@linaro.org>
Date:   Wed Feb 25 18:52:57 2015 +0000

    xen/arm: Describe devices supported by a driver with dt_device_match
    
    Xen is currently using a list of compatible strings to match drivers again
    device nodes. This leads to having double definitions in the GIC
    code.
    
    Furthermore Linux drivers are using dt_device_match (actually called
    of_device_id in Linux) to list device supported by the drivers.
    
    Remove the exisiting compatible field and replace with a dt_match field
    
    Signed-off-by: Julien Grall <julien.grall@linaro.org>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

Which is currently in the staging branch (this is the pre automated test
branch, normally master is fine but sometimes there can be conflicts).

Please could you rebase and resend.

Thanks,
Ian.


> 
> diff --git a/config/arm64.mk b/config/arm64.mk
> index 6eafda2..df6ad0a 100644
> --- a/config/arm64.mk
> +++ b/config/arm64.mk
> @@ -7,6 +7,7 @@ CONFIG_XEN_INSTALL_SUFFIX :=
>  CFLAGS += #-marm -march= -mcpu= etc
>  
>  HAS_PL011 := y
> +HAS_CADENCE_UART := y
>  HAS_NS16550 := y
>  
>  # Use only if calling $(LD) directly.
> diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
> index 9e94195..47fc3f9 100644
> --- a/xen/drivers/char/Makefile
> +++ b/xen/drivers/char/Makefile
> @@ -1,5 +1,6 @@
>  obj-y += console.o
>  obj-$(HAS_NS16550) += ns16550.o
> +obj-$(HAS_CADENCE_UART) += cadence-uart.o
>  obj-$(HAS_PL011) += pl011.o
>  obj-$(HAS_EXYNOS4210) += exynos4210-uart.o
>  obj-$(HAS_OMAP) += omap-uart.o
> diff --git a/xen/drivers/char/cadence-uart.c b/xen/drivers/char/cadence-uart.c
> new file mode 100644
> index 0000000..583bf21
> --- /dev/null
> +++ b/xen/drivers/char/cadence-uart.c
> @@ -0,0 +1,222 @@
> +/*
> + * xen/drivers/char/cadence-uart.c
> + *
> + * Driver for Cadence UART in Xilinx ZynqMP.
> + *
> + * Written by Edgar E. Iglesias <edgar.iglesias@gmail.com>
> + * Copyright (c) 2015 Xilinx Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <xen/config.h>
> +#include <xen/console.h>
> +#include <xen/serial.h>
> +#include <xen/init.h>
> +#include <xen/irq.h>
> +#include <xen/device_tree.h>
> +#include <xen/errno.h>
> +#include <asm/device.h>
> +#include <xen/mm.h>
> +#include <xen/vmap.h>
> +#include <asm/cadence-uart.h>
> +#include <asm/io.h>
> +
> +static struct cuart {
> +    unsigned int irq;
> +    void __iomem *regs;
> +    /* UART with IRQ line: interrupt-driven I/O. */
> +    struct irqaction irqaction;
> +    struct vuart_info vuart;
> +} cuart_com = {0};
> +
> +#define cuart_read(uart, off)           readl((uart)->regs + (off))
> +#define cuart_write(uart, off,val)      writel((val), (uart)->regs + (off))
> +
> +static void cuart_interrupt(int irq, void *data, struct cpu_user_regs *regs)
> +{
> +    struct serial_port *port = data;
> +    struct cuart *uart = port->uart;
> +    unsigned int status;
> +
> +    do {
> +        status = cuart_read(uart, R_UART_SR);
> +        /* ACK.  */
> +        if (status & UART_SR_INTR_RTRIG) {
> +            serial_rx_interrupt(port, regs);
> +            cuart_write(uart, R_UART_CISR, UART_SR_INTR_RTRIG);
> +        }
> +    } while (status & UART_SR_INTR_RTRIG);
> +}
> +
> +static void __init cuart_init_preirq(struct serial_port *port)
> +{
> +    struct cuart *uart = port->uart;
> +
> +    cuart_write(uart, R_UART_MR, UART_MR_NO_PARITY);
> +    /* Enable and Reset both the RX and TX paths.  */
> +    cuart_write(uart, R_UART_CR, UART_CR_RX_RST | UART_CR_TX_RST |
> +                      UART_CR_RX_ENABLE | UART_CR_TX_ENABLE);
> +}
> +
> +static void __init cuart_init_postirq(struct serial_port *port)
> +{
> +    struct cuart *uart = port->uart;
> +    int rc;
> +
> +    if ( uart->irq > 0 ) {
> +        uart->irqaction.handler = cuart_interrupt;
> +        uart->irqaction.name    = "cadence-uart";
> +        uart->irqaction.dev_id  = port;
> +        if ( (rc = setup_irq(uart->irq, 0, &uart->irqaction)) != 0 )
> +            printk("ERROR: Failed to allocate cadence-uart IRQ %d\n", uart->irq);
> +    }
> +
> +    /* Clear pending error interrupts */
> +    cuart_write(uart, R_UART_RTRIG, 1);
> +    cuart_write(uart, R_UART_CISR, ~0);
> +
> +    /* Unmask interrupts */
> +    cuart_write(uart, R_UART_IDR, ~0);
> +    cuart_write(uart, R_UART_IER, UART_SR_INTR_RTRIG);
> +}
> +
> +static void cuart_suspend(struct serial_port *port)
> +{
> +    BUG();
> +}
> +
> +static void cuart_resume(struct serial_port *port)
> +{
> +    BUG();
> +}
> +
> +static int cuart_tx_ready(struct serial_port *port)
> +{
> +    struct cuart *uart = port->uart;
> +    unsigned int status = cuart_read(uart, R_UART_SR);
> +
> +    return !(status & UART_SR_INTR_TFUL);
> +}
> +
> +static void cuart_putc(struct serial_port *port, char c)
> +{
> +    struct cuart *uart = port->uart;
> +
> +    cuart_write(uart, R_UART_TX, (uint32_t)(unsigned char)c);
> +}
> +
> +static int cuart_getc(struct serial_port *port, char *pc)
> +{
> +    struct cuart *uart = port->uart;
> +
> +    if (cuart_read(uart, R_UART_SR) & UART_SR_INTR_REMPTY)
> +        return 0;
> +
> +    *pc = cuart_read(uart, R_UART_RX) & 0xff;
> +    return 1;
> +}
> +
> +static int __init cuart_irq(struct serial_port *port)
> +{
> +    struct cuart *uart = port->uart;
> +
> +    return ((uart->irq > 0) ? uart->irq : -1);
> +}
> +
> +static const struct vuart_info *cuart_vuart(struct serial_port *port)
> +{
> +    struct cuart *uart = port->uart;
> +
> +    return &uart->vuart;
> +}
> +
> +static struct uart_driver __read_mostly cuart_driver = {
> +    .init_preirq  = cuart_init_preirq,
> +    .init_postirq = cuart_init_postirq,
> +    .endboot      = NULL,
> +    .suspend      = cuart_suspend,
> +    .resume       = cuart_resume,
> +    .tx_ready     = cuart_tx_ready,
> +    .putc         = cuart_putc,
> +    .getc         = cuart_getc,
> +    .irq          = cuart_irq,
> +    .vuart_info   = cuart_vuart,
> +};
> +
> +static int __init cuart_init(struct dt_device_node *dev, const void *data)
> +{
> +    const char *config = data;
> +    struct cuart *uart;
> +    int res;
> +    u64 addr, size;
> +
> +    if ( strcmp(config, "") )
> +        printk("WARNING: UART configuration is not supported\n");
> +
> +    uart = &cuart_com;
> +
> +    res = dt_device_get_address(dev, 0, &addr, &size);
> +    if ( res )
> +    {
> +        printk("cadence: Unable to retrieve the base"
> +               " address of the UART\n");
> +        return res;
> +    }
> +
> +    res = platform_get_irq(dev, 0);
> +    if ( res < 0 )
> +    {
> +        printk("cadence: Unable to retrieve the IRQ\n");
> +        return -EINVAL;
> +    }
> +    uart->irq = res;
> +
> +    uart->regs = ioremap_nocache(addr, size);
> +    if ( !uart->regs )
> +    {
> +        printk("cadence: Unable to map the UART memory\n");
> +        return -ENOMEM;
> +    }
> +
> +    uart->vuart.base_addr = addr;
> +    uart->vuart.size = size;
> +    uart->vuart.data_off = R_UART_RX;
> +    uart->vuart.status_off = R_UART_SR;
> +    uart->vuart.status = UART_SR_INTR_TEMPTY;
> +
> +    /* Register with generic serial driver. */
> +    serial_register_uart(SERHND_DTUART, &cuart_driver, uart);
> +
> +    dt_device_set_used_by(dev, DOMID_XEN);
> +
> +    return 0;
> +}
> +
> +static const char * const cuart_dt_compat[] __initconst =
> +{
> +    "cdns,uart-r1p8",
> +    NULL
> +};
> +
> +DT_DEVICE_START(cuart, "Cadence UART", DEVICE_SERIAL)
> +    .compatible = cuart_dt_compat,
> +    .init = cuart_init,
> +DT_DEVICE_END
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/include/asm-arm/cadence-uart.h b/xen/include/asm-arm/cadence-uart.h
> new file mode 100644
> index 0000000..48680ee
> --- /dev/null
> +++ b/xen/include/asm-arm/cadence-uart.h
> @@ -0,0 +1,55 @@
> +/*
> + * xen/include/asm-arm/cadence-uart.h
> + *
> + * Written by Edgar E. Iglesias <edgar.iglesias@xilinx.com>
> + * Copyright (C) 2015 Xilinx Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef __ASM_ARM_CADENCE_UART_H__
> +#define __ASM_ARM_CADENCE_UART_H__
> +
> +#define R_UART_CR    0x00
> +#define UART_CR_RX_RST       0x01
> +#define UART_CR_TX_RST       0x02
> +#define UART_CR_RX_ENABLE    0x04
> +#define UART_CR_RX_DISABLE   0x08
> +#define UART_CR_TX_ENABLE    0x10
> +#define UART_CR_TX_DISABLE   0x20
> +
> +#define R_UART_MR    0x04
> +#define UART_MR_NO_PARITY    0x20
> +
> +#define R_UART_IER   0x08
> +#define R_UART_IDR   0x0C
> +#define R_UART_IMR   0x10
> +#define R_UART_CISR  0x14
> +#define R_UART_RTRIG 0x20
> +#define R_UART_SR    0x2C
> +#define UART_SR_INTR_RTRIG   0x01
> +#define UART_SR_INTR_REMPTY  0x02
> +#define UART_SR_INTR_TEMPTY  0x08
> +#define UART_SR_INTR_TFUL    0x10
> +
> +#define R_UART_TX    0x30
> +#define R_UART_RX    0x30
> +
> +#endif /* __ASM_ARM_CADENCE_UART_H */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */

Re: [PATCH v1 1/2] xen/arm: Add Cadence UART driver

[Edgar E. Iglesias]

On Thu, Mar 05, 2015 at 05:06:22PM +0000, Ian Campbell wrote:
> On Thu, 2015-03-05 at 18:27 +1000, Edgar E. Iglesias wrote:
> > Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
> > ---
> >  config/arm64.mk                    |   1 +
> >  xen/drivers/char/Makefile          |   1 +
> >  xen/drivers/char/cadence-uart.c    | 222 +++++++++++++++++++++++++++++++++++++
> >  xen/include/asm-arm/cadence-uart.h |  55 +++++++++
> >  4 files changed, 279 insertions(+)
> >  create mode 100644 xen/drivers/char/cadence-uart.c
> >  create mode 100644 xen/include/asm-arm/cadence-uart.h
> 
> I tried to apply this but:
> 
> cadence-uart.c:211:5: error: unknown field 'compatible' specified in initializer
>      .compatible = cuart_dt_compat,
>      ^
> cadence-uart.c:211:5: error: initialization from incompatible pointer type [-Werror]
> cadence-uart.c:211:5: error: (near initialization for '__dev_desc_cuart.dt_match') [-Werror]
> cc1: all warnings being treated as errors
> 
> I think because this patch needs to be rebased onto:
> commit f9eff198f9d4863e80078a33001a9bb90a99a4b1
> Author: Julien Grall <julien.grall@linaro.org>
> Date:   Wed Feb 25 18:52:57 2015 +0000
> 
>     xen/arm: Describe devices supported by a driver with dt_device_match
>     
>     Xen is currently using a list of compatible strings to match drivers again
>     device nodes. This leads to having double definitions in the GIC
>     code.
>     
>     Furthermore Linux drivers are using dt_device_match (actually called
>     of_device_id in Linux) to list device supported by the drivers.
>     
>     Remove the exisiting compatible field and replace with a dt_match field
>     
>     Signed-off-by: Julien Grall <julien.grall@linaro.org>
>     Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>     Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Which is currently in the staging branch (this is the pre automated test
> branch, normally master is fine but sometimes there can be conflicts).
> 
> Please could you rebase and resend.

Thanks Ian,

I've rebased and sending out a v2 now.

Cheers,
Edgar


> 
> Thanks,
> Ian.

[PATCH v1 2/2] xen/arm: Add Xilinx ZynqMP early printk support

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>

Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
---
 docs/misc/arm/early-printk.txt       |  1 +
 xen/arch/arm/Rules.mk                |  6 +++++
 xen/arch/arm/arm64/debug-cadence.inc | 45 ++++++++++++++++++++++++++++++++++++
 3 files changed, 52 insertions(+)
 create mode 100644 xen/arch/arm/arm64/debug-cadence.inc

diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt
index 1ca2a55..537e15d 100644
--- a/docs/misc/arm/early-printk.txt
+++ b/docs/misc/arm/early-printk.txt
@@ -20,6 +20,7 @@ where mach is the name of the machine:
   - hip04-d01: printk with 8250 on HiSilicon Hip-04 D01
   - seattle: printk with pl011 for AMD Seattle processor
   - lager: printk with SCIF0 on Renesas R-Car H2 processors
+  - zynqmp: printk with Cadence UART for Xilinx ZynqMP SoCs
 
 The base address and baud rate is hardcoded in xen/arch/arm/Rules.mk,
 see there when adding support for new machines.
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index c7bd227..649de49 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -114,6 +114,12 @@ EARLY_PRINTK_INC := scif
 EARLY_UART_BASE_ADDRESS := 0xe6e60000
 endif
 
+ifeq ($(CONFIG_EARLY_PRINTK), zynqmp)
+EARLY_PRINTK_INC := cadence
+EARLY_PRINTK_BAUD := 115200
+EARLY_UART_BASE_ADDRESS := 0xff000000
+endif
+
 ifneq ($(EARLY_PRINTK_INC),)
 EARLY_PRINTK := y
 endif
diff --git a/xen/arch/arm/arm64/debug-cadence.inc b/xen/arch/arm/arm64/debug-cadence.inc
new file mode 100644
index 0000000..84dee4c
--- /dev/null
+++ b/xen/arch/arm/arm64/debug-cadence.inc
@@ -0,0 +1,45 @@
+/*
+ * xen/arch/arm/arm64/debug-cadence.S
+ *
+ * Cadence UART specific debug code
+ *
+ * Copyright (c) 2015 Xilinx Inc.
+ * Written by Edgar E. Iglesias.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <asm/asm_defns.h>
+#include <asm/cadence-uart.h>
+
+/* Cadence UART wait UART to be ready to transmit
+ * xb: register which contains the UART base address
+ * c: scratch register number */
+.macro early_uart_ready xb, c
+1:
+        ldrh  w\c, [\xb, #R_UART_SR]
+        tst   w\c, #UART_SR_INTR_TFUL
+        b.ne  1b
+.endm
+
+/* Cadence UART transmit character
+ * xb: register which contains the UART base address
+ * wt: register which contains the character to transmit */
+.macro early_uart_transmit xb, wt
+        strb  \wt, [\xb, #R_UART_TX]
+.endm
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.9.1

Re: [PATCH v1 0/2] Add support for Xilinx ZynqMP SoC

[Ian Campbell]

On Thu, 2015-03-05 at 18:27 +1000, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>
> 
> Adds support for the Cadence UART in Xilinx ZynqMP. The
> rest of the ZynqMP platform is discovered via device-tree.

Is it fully discovered and working out of the box? That would be ....
awesome!

Do you have any links to any more information about this platform (I'm
just curious).

Also, if you could find the time to add a wikipage as a child of
http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions
(like for the other platforms) and add it to the h/w table on the main
page that would be great.

The wiki is locked down because of spammers, once you've created an
account either drop me a line or fill in the form
http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html and someone will enable write access for you.

Ian.

> 
> Cheers,
> Edgar
> 
> Edgar E. Iglesias (2):
>   xen/arm: Add Cadence UART driver
>   xen/arm: Add Xilinx ZynqMP early printk support
> 
>  config/arm64.mk                      |   1 +
>  docs/misc/arm/early-printk.txt       |   1 +
>  xen/arch/arm/Rules.mk                |   6 +
>  xen/arch/arm/arm64/debug-cadence.inc |  45 +++++++
>  xen/drivers/char/Makefile            |   1 +
>  xen/drivers/char/cadence-uart.c      | 222 +++++++++++++++++++++++++++++++++++
>  xen/include/asm-arm/cadence-uart.h   |  55 +++++++++
>  7 files changed, 331 insertions(+)
>  create mode 100644 xen/arch/arm/arm64/debug-cadence.inc
>  create mode 100644 xen/drivers/char/cadence-uart.c
>  create mode 100644 xen/include/asm-arm/cadence-uart.h
> 

Re: [PATCH v1 0/2] Add support for Xilinx ZynqMP SoC

[Edgar E. Iglesias]

On Thu, Mar 05, 2015 at 04:50:15PM +0000, Ian Campbell wrote:
> On Thu, 2015-03-05 at 18:27 +1000, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>
> > 
> > Adds support for the Cadence UART in Xilinx ZynqMP. The
> > rest of the ZynqMP platform is discovered via device-tree.
> 
> Is it fully discovered and working out of the box? That would be ....
> awesome!

Yes it would be awesome if we can keep it like that :-)

For a while we were carrying platform code to enable the gic
PLATFORM_QUIRK_GIC_64K_STRIDE but we later realized that we can
work around that issue in the device tree by moving the GICC offsets.

It's possible that we will need to add platform code in the future
as we test out more features. In particular we'll likely need to do
something around power/clock management.


> Do you have any links to any more information about this platform (I'm
> just curious).

This one is a good starting point with follow-up links:
http://www.xilinx.com/products/technology/ultrascale-mpsoc.html

The short version is that the ZynqMP is a chip including both a hard SoC part
(PS, Programmable System) and a "soft" Programmable Logic (PL) FPGA part.
In terms of Virtualization, the hard PS part has quad Cortex-A53s with
EL2 enabled and an SMMU to allow secure device-passthrough of DMA capable devices.

For early access there are two platforms available, an FPGA based
emulation platform (EP108) and a modified version of QEMU. XEN can run
on both those platforms.


> Also, if you could find the time to add a wikipage as a child of
> http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions
> (like for the other platforms) and add it to the h/w table on the main
> page that would be great.
> 
> The wiki is locked down because of spammers, once you've created an
> account either drop me a line or fill in the form
> http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html and someone will enable write access for you.

Yes, I'm happy to update the wiki. I've created a user (edgar_igl) and filled out the form.

Best regards,
Edgar


> 
> Ian.
> 
> > 
> > Cheers,
> > Edgar
> > 
> > Edgar E. Iglesias (2):
> >   xen/arm: Add Cadence UART driver
> >   xen/arm: Add Xilinx ZynqMP early printk support
> > 
> >  config/arm64.mk                      |   1 +
> >  docs/misc/arm/early-printk.txt       |   1 +
> >  xen/arch/arm/Rules.mk                |   6 +
> >  xen/arch/arm/arm64/debug-cadence.inc |  45 +++++++
> >  xen/drivers/char/Makefile            |   1 +
> >  xen/drivers/char/cadence-uart.c      | 222 +++++++++++++++++++++++++++++++++++
> >  xen/include/asm-arm/cadence-uart.h   |  55 +++++++++
> >  7 files changed, 331 insertions(+)
> >  create mode 100644 xen/arch/arm/arm64/debug-cadence.inc
> >  create mode 100644 xen/drivers/char/cadence-uart.c
> >  create mode 100644 xen/include/asm-arm/cadence-uart.h
> > 
> 
> 

Re: [PATCH v1 0/2] Add support for Xilinx ZynqMP SoC

[Ian Campbell]

On Fri, 2015-03-06 at 11:31 +1000, Edgar E. Iglesias wrote:
> On Thu, Mar 05, 2015 at 04:50:15PM +0000, Ian Campbell wrote:
> > On Thu, 2015-03-05 at 18:27 +1000, Edgar E. Iglesias wrote:
> > > From: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>
> > > 
> > > Adds support for the Cadence UART in Xilinx ZynqMP. The
> > > rest of the ZynqMP platform is discovered via device-tree.
> > 
> > Is it fully discovered and working out of the box? That would be ....
> > awesome!
> 
> Yes it would be awesome if we can keep it like that :-)

I suppose you are seeing the "WARNING: Unrecognized/unsupported device
tree compatible list" message?

I wonder if we should either remove or tone down that warning, now that
we have a platform which genuinely doesn't require any platform specific
code. I think we probably want to say something so in bug reports we
know what is happening, maybe just something like "Platform: Generic
System".

> It's possible that we will need to add platform code in the future
> as we test out more features. In particular we'll likely need to do
> something around power/clock management.

Yes, this is something of an open problem for us, and one which I'm
unsure how to solve without some platform specific code in each case.

Most power/clock management should be deferred to the h/w domain which
is managing the I/O peripherals (likely dom0) but we need some way to
filter its activities to keep e.g. the CPU and UART (or in reality any
h/w block Xen itself is using, which isn't many fortunately) clocks on.

http://bugs.xenproject.org/xen/bug/45 is a related bug.

> > Do you have any links to any more information about this platform (I'm
> > just curious).
> 
> This one is a good starting point with follow-up links:
> http://www.xilinx.com/products/technology/ultrascale-mpsoc.html
> 
> The short version is that the ZynqMP is a chip including both a hard SoC part
> (PS, Programmable System) and a "soft" Programmable Logic (PL) FPGA part.
> In terms of Virtualization, the hard PS part has quad Cortex-A53s with
> EL2 enabled and an SMMU to allow secure device-passthrough of DMA capable devices.

That sounds like a pretty sweet platform, thanks!

> For early access there are two platforms available, an FPGA based
> emulation platform (EP108) and a modified version of QEMU. XEN can run
> on both those platforms.
> 
> 
> > Also, if you could find the time to add a wikipage as a child of
> > http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions
> > (like for the other platforms) and add it to the h/w table on the main
> > page that would be great.
> > 
> > The wiki is locked down because of spammers, once you've created an
> > account either drop me a line or fill in the form
> > http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html and someone will enable write access for you.
> 
> Yes, I'm happy to update the wiki. I've created a user (edgar_igl) and filled out the form.

I've just seen the form entry and added the write bit to "edgar_igl".
Thanks!

Ian.

Re: [PATCH v1 0/2] Add support for Xilinx ZynqMP SoC

[Edgar E. Iglesias]

On Fri, Mar 06, 2015 at 09:44:16AM +0000, Ian Campbell wrote:
> On Fri, 2015-03-06 at 11:31 +1000, Edgar E. Iglesias wrote:
> > On Thu, Mar 05, 2015 at 04:50:15PM +0000, Ian Campbell wrote:
> > > On Thu, 2015-03-05 at 18:27 +1000, Edgar E. Iglesias wrote:
> > > > From: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>
> > > > 
> > > > Adds support for the Cadence UART in Xilinx ZynqMP. The
> > > > rest of the ZynqMP platform is discovered via device-tree.
> > > 
> > > Is it fully discovered and working out of the box? That would be ....
> > > awesome!
> > 
> > Yes it would be awesome if we can keep it like that :-)
> 
> I suppose you are seeing the "WARNING: Unrecognized/unsupported device
> tree compatible list" message?

Yes, thats right.

> 
> I wonder if we should either remove or tone down that warning, now that
> we have a platform which genuinely doesn't require any platform specific
> code. I think we probably want to say something so in bug reports we
> know what is happening, maybe just something like "Platform: Generic
> System".


Sounds good to me, I can send a follow up patch for that.

> 
> > It's possible that we will need to add platform code in the future
> > as we test out more features. In particular we'll likely need to do
> > something around power/clock management.
> 
> Yes, this is something of an open problem for us, and one which I'm
> unsure how to solve without some platform specific code in each case.
> 
> Most power/clock management should be deferred to the h/w domain which
> is managing the I/O peripherals (likely dom0) but we need some way to
> filter its activities to keep e.g. the CPU and UART (or in reality any
> h/w block Xen itself is using, which isn't many fortunately) clocks on.
> 
> http://bugs.xenproject.org/xen/bug/45 is a related bug.

Very interesting, thanks.

There is another dimenson to the power/clock problem. The ZynqMP has a
runtime programmable TrustZone system partitioning block in the interconnect.
Something similar to ARMs TZASC. This allows you to program the
Secure/Non-Secure device partitioning for example at boot time.
Depending on the split, it might not be OK to give NS Linux or even
NS XEN direct access to the power/clock configuration registers.
I.e, we don't want NS Linux to power down a device currently in use
by a Trusted OS.

What we are considering is an extension to the PSCI approach, an SMC
interface to expose the low level power/clock operations.

Linux can still have all the smart control logic for Power Management
but an SMC interface would allow the various layers (XEN EL2,
ARM trusted firmware EL3) to filter or emulate the various requests.

Ofcourse, the devil will be in the details...

It would be interesting to hear your and others thought on that kind
of approach.


> 
> > > Do you have any links to any more information about this platform (I'm
> > > just curious).
> > 
> > This one is a good starting point with follow-up links:
> > http://www.xilinx.com/products/technology/ultrascale-mpsoc.html
> > 
> > The short version is that the ZynqMP is a chip including both a hard SoC part
> > (PS, Programmable System) and a "soft" Programmable Logic (PL) FPGA part.
> > In terms of Virtualization, the hard PS part has quad Cortex-A53s with
> > EL2 enabled and an SMMU to allow secure device-passthrough of DMA capable devices.
> 
> That sounds like a pretty sweet platform, thanks!
> 
> > For early access there are two platforms available, an FPGA based
> > emulation platform (EP108) and a modified version of QEMU. XEN can run
> > on both those platforms.
> > 
> > 
> > > Also, if you could find the time to add a wikipage as a child of
> > > http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions
> > > (like for the other platforms) and add it to the h/w table on the main
> > > page that would be great.
> > > 
> > > The wiki is locked down because of spammers, once you've created an
> > > account either drop me a line or fill in the form
> > > http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html and someone will enable write access for you.
> > 
> > Yes, I'm happy to update the wiki. I've created a user (edgar_igl) and filled out the form.
> 
> I've just seen the form entry and added the write bit to "edgar_igl".
> Thanks!

Thanks!

Best regards,
Edgar

Re: [PATCH v1 0/2] Add support for Xilinx ZynqMP SoC

[Ian Campbell]

On Mon, 2015-03-09 at 13:14 +1000, Edgar E. Iglesias wrote:
> On Fri, Mar 06, 2015 at 09:44:16AM +0000, Ian Campbell wrote:
> > On Fri, 2015-03-06 at 11:31 +1000, Edgar E. Iglesias wrote:
> > > On Thu, Mar 05, 2015 at 04:50:15PM +0000, Ian Campbell wrote:
> > > > On Thu, 2015-03-05 at 18:27 +1000, Edgar E. Iglesias wrote:
> > > > > From: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>
> > > > > 
> > > > > Adds support for the Cadence UART in Xilinx ZynqMP. The
> > > > > rest of the ZynqMP platform is discovered via device-tree.
> > > > 
> > > > Is it fully discovered and working out of the box? That would be ....
> > > > awesome!
> > > 
> > > Yes it would be awesome if we can keep it like that :-)
> > 
> > I suppose you are seeing the "WARNING: Unrecognized/unsupported device
> > tree compatible list" message?
> 
> Yes, thats right.
> 
> > 
> > I wonder if we should either remove or tone down that warning, now that
> > we have a platform which genuinely doesn't require any platform specific
> > code. I think we probably want to say something so in bug reports we
> > know what is happening, maybe just something like "Platform: Generic
> > System".
> 
> 
> Sounds good to me, I can send a follow up patch for that.

I've seen it and put it in my (rather long) list of things to look at,
thanks!

> > > It's possible that we will need to add platform code in the future
> > > as we test out more features. In particular we'll likely need to do
> > > something around power/clock management.
> > 
> > Yes, this is something of an open problem for us, and one which I'm
> > unsure how to solve without some platform specific code in each case.
> > 
> > Most power/clock management should be deferred to the h/w domain which
> > is managing the I/O peripherals (likely dom0) but we need some way to
> > filter its activities to keep e.g. the CPU and UART (or in reality any
> > h/w block Xen itself is using, which isn't many fortunately) clocks on.
> > 
> > http://bugs.xenproject.org/xen/bug/45 is a related bug.
> 
> Very interesting, thanks.
> 
> There is another dimenson to the power/clock problem. The ZynqMP has a
> runtime programmable TrustZone system partitioning block in the interconnect.
> Something similar to ARMs TZASC. This allows you to program the
> Secure/Non-Secure device partitioning for example at boot time.
> Depending on the split, it might not be OK to give NS Linux or even
> NS XEN direct access to the power/clock configuration registers.
> I.e, we don't want NS Linux to power down a device currently in use
> by a Trusted OS.
> 
> What we are considering is an extension to the PSCI approach, an SMC
> interface to expose the low level power/clock operations.
> 
> Linux can still have all the smart control logic for Power Management
> but an SMC interface would allow the various layers (XEN EL2,
> ARM trusted firmware EL3) to filter or emulate the various requests.
> 
> Ofcourse, the devil will be in the details...
> 
> It would be interesting to hear your and others thought on that kind
> of approach.

It's an interesting approach, and not without precedent AIUI. And I
think you are right to make the link between NS.EL1 vs NS.EL2 and NS.EL*
vs S.EL*, they are very similar problems in the end.

We've not actually come across such a platform yet, but I think it is
inevitable that eventually we will need to trap platform specific SMC
calls from dom0 on some platform and decide what to do with them on a
per-operation basis (quash them, emulate them, forward them to S world,
etc).

If such an interface was available for power/clock then I think that
would be preferable to trapping and emulating register writes and
white/blacklisting individual register bits etc.

Best of all, I think, at least from Xen's PoV, would be if there was
some PSCI-like overall standard which all vendors used for this, such
that Xen could grow a more generic framework for SMC traps of this type.

As you say, devil is in the details!

Ian.

Re: [PATCH v1 0/2] Add support for Xilinx ZynqMP SoC

[Edgar E. Iglesias]

On Mon, Mar 09, 2015 at 11:09:13AM +0000, Ian Campbell wrote:
> On Mon, 2015-03-09 at 13:14 +1000, Edgar E. Iglesias wrote:
> > On Fri, Mar 06, 2015 at 09:44:16AM +0000, Ian Campbell wrote:
> > > On Fri, 2015-03-06 at 11:31 +1000, Edgar E. Iglesias wrote:
> > > > On Thu, Mar 05, 2015 at 04:50:15PM +0000, Ian Campbell wrote:
> > > > > On Thu, 2015-03-05 at 18:27 +1000, Edgar E. Iglesias wrote:
> > > > > > From: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>
> > > > > > 
> > > > > > Adds support for the Cadence UART in Xilinx ZynqMP. The
> > > > > > rest of the ZynqMP platform is discovered via device-tree.
> > > > > 
> > > > > Is it fully discovered and working out of the box? That would be ....
> > > > > awesome!
> > > > 
> > > > Yes it would be awesome if we can keep it like that :-)
> > > 
> > > I suppose you are seeing the "WARNING: Unrecognized/unsupported device
> > > tree compatible list" message?
> > 
> > Yes, thats right.
> > 
> > > 
> > > I wonder if we should either remove or tone down that warning, now that
> > > we have a platform which genuinely doesn't require any platform specific
> > > code. I think we probably want to say something so in bug reports we
> > > know what is happening, maybe just something like "Platform: Generic
> > > System".
> > 
> > 
> > Sounds good to me, I can send a follow up patch for that.
> 
> I've seen it and put it in my (rather long) list of things to look at,
> thanks!
> 
> > > > It's possible that we will need to add platform code in the future
> > > > as we test out more features. In particular we'll likely need to do
> > > > something around power/clock management.
> > > 
> > > Yes, this is something of an open problem for us, and one which I'm
> > > unsure how to solve without some platform specific code in each case.
> > > 
> > > Most power/clock management should be deferred to the h/w domain which
> > > is managing the I/O peripherals (likely dom0) but we need some way to
> > > filter its activities to keep e.g. the CPU and UART (or in reality any
> > > h/w block Xen itself is using, which isn't many fortunately) clocks on.
> > > 
> > > http://bugs.xenproject.org/xen/bug/45 is a related bug.
> > 
> > Very interesting, thanks.
> > 
> > There is another dimenson to the power/clock problem. The ZynqMP has a
> > runtime programmable TrustZone system partitioning block in the interconnect.
> > Something similar to ARMs TZASC. This allows you to program the
> > Secure/Non-Secure device partitioning for example at boot time.
> > Depending on the split, it might not be OK to give NS Linux or even
> > NS XEN direct access to the power/clock configuration registers.
> > I.e, we don't want NS Linux to power down a device currently in use
> > by a Trusted OS.
> > 
> > What we are considering is an extension to the PSCI approach, an SMC
> > interface to expose the low level power/clock operations.
> > 
> > Linux can still have all the smart control logic for Power Management
> > but an SMC interface would allow the various layers (XEN EL2,
> > ARM trusted firmware EL3) to filter or emulate the various requests.
> > 
> > Ofcourse, the devil will be in the details...
> > 
> > It would be interesting to hear your and others thought on that kind
> > of approach.
> 
> It's an interesting approach, and not without precedent AIUI. And I
> think you are right to make the link between NS.EL1 vs NS.EL2 and NS.EL*
> vs S.EL*, they are very similar problems in the end.
> 
> We've not actually come across such a platform yet, but I think it is
> inevitable that eventually we will need to trap platform specific SMC
> calls from dom0 on some platform and decide what to do with them on a
> per-operation basis (quash them, emulate them, forward them to S world,
> etc).
> 
> If such an interface was available for power/clock then I think that
> would be preferable to trapping and emulating register writes and
> white/blacklisting individual register bits etc.
> 
> Best of all, I think, at least from Xen's PoV, would be if there was
> some PSCI-like overall standard which all vendors used for this, such
> that Xen could grow a more generic framework for SMC traps of this type.

Yes, such a standard would be great.

Thanks alot for your comments!

Cheers,
Edgar