[PATCH v1 0/4] Renesas Stout board support (R-Car Gen2)

[PATCH v1 0/4] Renesas Stout board support (R-Car Gen2)

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>

Hi, all.

The purpose of this patch series is to add required support to be able to run Xen on
Renesas Stout board [1] which uses SCIFA compatible UART as a console interface.

Actually Xen already has support for SCIF compatible UARTs which are used on Renesas Lager (R-Car Gen2),
Salvator-X, H3ULCB/M3ULCB (R-Car Gen3) and other development boards.
So this patch series extends existing support to be able to handle both interfaces.   

Tested on Stout (ARM32) and H3ULCB (ARM64) boards using current master. 
Have a plan to update Xen Wiki regarding this board.

You can find current patch series here:
repo: https://github.com/otyshchenko1/xen.git branch: stout_xen_4.12_unstable

[1] https://elinux.org/R-Car/Boards/Stout

Oleksandr Tyshchenko (4):
  xen/arm: drivers: scif: Remove unused #define-s
  xen/arm: drivers: scif: Add support for SCIFA compatible UARTs
  xen/arm: Add SCIFA UART support for early printk
  xen/arm: Reuse R-Car Gen2 platform code for Stout board

 docs/misc/arm/early-printk.txt     |   3 +-
 xen/arch/arm/Rules.mk              |   1 +
 xen/arch/arm/arm32/debug-scifa.inc |  51 ++++++++++++++
 xen/arch/arm/platforms/rcar2.c     |   4 ++
 xen/drivers/char/scif-uart.c       | 133 ++++++++++++++++++++++++++++---------
 xen/include/asm-arm/scif-uart.h    |  55 ++++++++++-----
 6 files changed, 196 insertions(+), 51 deletions(-)
 create mode 100644 xen/arch/arm/arm32/debug-scifa.inc

-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v1 1/4] xen/arm: drivers: scif: Remove unused #define-s

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>

Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien.grall@arm.com>
---
 xen/drivers/char/scif-uart.c    |  4 ----
 xen/include/asm-arm/scif-uart.h | 11 -----------
 2 files changed, 15 deletions(-)

diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
index 4a71bac..465fb34 100644
--- a/xen/drivers/char/scif-uart.c
+++ b/xen/drivers/char/scif-uart.c
@@ -29,10 +29,6 @@
 #include <asm/scif-uart.h>
 #include <asm/io.h>
 
-#define PARITY_NONE    0
-#define PARITY_EVEN    1
-#define PARITY_ODD     2
-
 #define scif_readb(uart, off)          readb((uart)->regs + (off))
 #define scif_writeb(uart, off, val)    writeb((val), (uart)->regs + (off))
 
diff --git a/xen/include/asm-arm/scif-uart.h b/xen/include/asm-arm/scif-uart.h
index d030b26..8137850 100644
--- a/xen/include/asm-arm/scif-uart.h
+++ b/xen/include/asm-arm/scif-uart.h
@@ -47,17 +47,6 @@
 #define SCSCR_CKE1    (1 << 1)    /* Clock Enable 1 */
 #define SCSCR_CKE0    (1 << 0)    /* Clock Enable 0 */
 
-#define SCSCR_CKE00    (0)
-#define SCSCR_CKE01    (SCSCR_CKE0)
-#define SCSCR_CKE10    (SCSCR_CKE1)
-#define SCSCR_CKE11    (SCSCR_CKE1 | SCSCR_CKE0)
-
-/* Serial Mode Register (SCSMR) */
-#define SCSMR_CHR     (1 << 6)    /* 7-bit Character Length */
-#define SCSMR_PE      (1 << 5)    /* Parity Enable */
-#define SCSMR_ODD     (1 << 4)    /* Odd Parity */
-#define SCSMR_STOP    (1 << 3)    /* Stop Bit Length */
-
 /* Serial Status Register (SCFSR) */
 #define SCFSR_ER      (1 << 7)    /* Receive Error */
 #define SCFSR_TEND    (1 << 6)    /* Transmission End */
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 1/4] xen/arm: drivers: scif: Remove unused #define-s

[Julien Grall]

Hi Oleksandr,

On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> 
> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Julien Grall <julien.grall@arm.com>

Acked-by: Julien Grall <julien.grall@arm.com>

Cheers,

> ---
>   xen/drivers/char/scif-uart.c    |  4 ----
>   xen/include/asm-arm/scif-uart.h | 11 -----------
>   2 files changed, 15 deletions(-)
> 
> diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
> index 4a71bac..465fb34 100644
> --- a/xen/drivers/char/scif-uart.c
> +++ b/xen/drivers/char/scif-uart.c
> @@ -29,10 +29,6 @@
>   #include <asm/scif-uart.h>
>   #include <asm/io.h>
>   
> -#define PARITY_NONE    0
> -#define PARITY_EVEN    1
> -#define PARITY_ODD     2
> -
>   #define scif_readb(uart, off)          readb((uart)->regs + (off))
>   #define scif_writeb(uart, off, val)    writeb((val), (uart)->regs + (off))
>   
> diff --git a/xen/include/asm-arm/scif-uart.h b/xen/include/asm-arm/scif-uart.h
> index d030b26..8137850 100644
> --- a/xen/include/asm-arm/scif-uart.h
> +++ b/xen/include/asm-arm/scif-uart.h
> @@ -47,17 +47,6 @@
>   #define SCSCR_CKE1    (1 << 1)    /* Clock Enable 1 */
>   #define SCSCR_CKE0    (1 << 0)    /* Clock Enable 0 */
>   
> -#define SCSCR_CKE00    (0)
> -#define SCSCR_CKE01    (SCSCR_CKE0)
> -#define SCSCR_CKE10    (SCSCR_CKE1)
> -#define SCSCR_CKE11    (SCSCR_CKE1 | SCSCR_CKE0)
> -
> -/* Serial Mode Register (SCSMR) */
> -#define SCSMR_CHR     (1 << 6)    /* 7-bit Character Length */
> -#define SCSMR_PE      (1 << 5)    /* Parity Enable */
> -#define SCSMR_ODD     (1 << 4)    /* Odd Parity */
> -#define SCSMR_STOP    (1 << 3)    /* Stop Bit Length */
> -
>   /* Serial Status Register (SCFSR) */
>   #define SCFSR_ER      (1 << 7)    /* Receive Error */
>   #define SCFSR_TEND    (1 << 6)    /* Transmission End */
> 

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v1 2/4] xen/arm: drivers: scif: Add support for SCIFA compatible UARTs

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>

Extend existing driver to be able to handle SCIFA interface as well.
SCIF and SCIFA have lot in common, though SCIFA has different
offsets and bits for some registers.

Use compatible string to recognize what interface is present
on a target board.

Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien.grall@arm.com>
---
 xen/drivers/char/scif-uart.c    | 129 +++++++++++++++++++++++++++++++---------
 xen/include/asm-arm/scif-uart.h |  44 ++++++++++++--
 2 files changed, 138 insertions(+), 35 deletions(-)

diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
index 465fb34..d1eb713 100644
--- a/xen/drivers/char/scif-uart.c
+++ b/xen/drivers/char/scif-uart.c
@@ -1,7 +1,7 @@
 /*
  * xen/drivers/char/scif-uart.c
  *
- * Driver for SCIF (Serial communication interface with FIFO)
+ * Driver for SCIF(A) (Serial communication interface with FIFO (A))
  * compatible UART.
  *
  * Oleksandr Tyshchenko <oleksandr.tyshchenko@globallogic.com>
@@ -40,8 +40,57 @@ static struct scif_uart {
     char __iomem *regs;
     struct irqaction irqaction;
     struct vuart_info vuart;
+    const struct port_params *params;
 } scif_com = {0};
 
+enum
+{
+    SCIF_PORT,
+    SCIFA_PORT,
+    NR_PORTS,
+};
+
+struct port_params
+{
+    unsigned int status_reg;
+    unsigned int tx_fifo_reg;
+    unsigned int rx_fifo_reg;
+    unsigned int overrun_reg;
+    unsigned int overrun_mask;
+    unsigned int error_mask;
+    unsigned int irq_flags;
+    unsigned int fifo_size;
+};
+
+static const struct port_params port_params[NR_PORTS] =
+{
+    [SCIF_PORT] =
+    {
+        .status_reg   = SCIF_SCFSR,
+        .tx_fifo_reg  = SCIF_SCFTDR,
+        .rx_fifo_reg  = SCIF_SCFRDR,
+        .overrun_reg  = SCIF_SCLSR,
+        .overrun_mask = SCLSR_ORER,
+        .error_mask   = SCFSR_PER | SCFSR_FER | SCFSR_BRK | SCFSR_ER,
+        .irq_flags    = SCSCR_RIE | SCSCR_TIE | SCSCR_REIE,
+        .fifo_size    = 16,
+    },
+
+    [SCIFA_PORT] =
+    {
+        .status_reg   = SCIFA_SCASSR,
+        .tx_fifo_reg  = SCIFA_SCAFTDR,
+        .rx_fifo_reg  = SCIFA_SCAFRDR,
+        .overrun_reg  = SCIFA_SCASSR,
+        .overrun_mask = SCASSR_ORER,
+        .error_mask   = SCASSR_PER | SCASSR_FER | SCASSR_BRK | SCASSR_ER |
+                        SCASSR_ORER,
+        .irq_flags    = SCASCR_RIE | SCASCR_TIE | SCASCR_DRIE | SCASCR_ERIE |
+                        SCASCR_BRIE,
+        .fifo_size    = 64,
+    },
+};
+
 static void scif_uart_interrupt(int irq, void *data, struct cpu_user_regs *regs)
 {
     struct serial_port *port = data;
@@ -49,7 +98,7 @@ static void scif_uart_interrupt(int irq, void *data, struct cpu_user_regs *regs)
     uint16_t status, ctrl;
 
     ctrl = scif_readw(uart, SCIF_SCSCR);
-    status = scif_readw(uart, SCIF_SCFSR) & ~SCFSR_TEND;
+    status = scif_readw(uart, uart->params->status_reg) & ~SCFSR_TEND;
     /* Ignore next flag if TX Interrupt is disabled */
     if ( !(ctrl & SCSCR_TIE) )
         status &= ~SCFSR_TDFE;
@@ -65,13 +114,19 @@ static void scif_uart_interrupt(int irq, void *data, struct cpu_user_regs *regs)
             serial_rx_interrupt(port, regs);
 
         /* Error Interrupt */
-        if ( status & SCIF_ERRORS )
-            scif_writew(uart, SCIF_SCFSR, ~SCIF_ERRORS);
-        if ( scif_readw(uart, SCIF_SCLSR) & SCLSR_ORER )
-            scif_writew(uart, SCIF_SCLSR, 0);
+        if ( status & uart->params->error_mask )
+            scif_writew(uart, uart->params->status_reg,
+                        ~uart->params->error_mask);
+        if ( uart->params->overrun_reg != uart->params->status_reg )
+        {
+            if ( scif_readw(uart, uart->params->overrun_reg) &
+                 uart->params->overrun_mask )
+                scif_writew(uart, uart->params->overrun_reg,
+                            ~uart->params->overrun_mask);
+        }
 
         ctrl = scif_readw(uart, SCIF_SCSCR);
-        status = scif_readw(uart, SCIF_SCFSR) & ~SCFSR_TEND;
+        status = scif_readw(uart, uart->params->status_reg) & ~SCFSR_TEND;
         /* Ignore next flag if TX Interrupt is disabled */
         if ( !(ctrl & SCSCR_TIE) )
             status &= ~SCFSR_TDFE;
@@ -86,7 +141,7 @@ static void __init scif_uart_init_preirq(struct serial_port *port)
      * Wait until last bit has been transmitted. This is needed for a smooth
      * transition when we come from early printk
      */
-    while ( !(scif_readw(uart, SCIF_SCFSR) & SCFSR_TEND) );
+    while ( !(scif_readw(uart, uart->params->status_reg) & SCFSR_TEND) );
 
     /* Disable TX/RX parts and all interrupts */
     scif_writew(uart, SCIF_SCSCR, 0);
@@ -95,10 +150,13 @@ static void __init scif_uart_init_preirq(struct serial_port *port)
     scif_writew(uart, SCIF_SCFCR, SCFCR_RFRST | SCFCR_TFRST);
 
     /* Clear all errors and flags */
-    scif_readw(uart, SCIF_SCFSR);
-    scif_writew(uart, SCIF_SCFSR, 0);
-    scif_readw(uart, SCIF_SCLSR);
-    scif_writew(uart, SCIF_SCLSR, 0);
+    scif_readw(uart, uart->params->status_reg);
+    scif_writew(uart, uart->params->status_reg, 0);
+    if ( uart->params->overrun_reg != uart->params->status_reg )
+    {
+        scif_readw(uart, uart->params->overrun_reg);
+        scif_writew(uart, uart->params->overrun_reg, 0);
+    }
 
     /* Setup trigger level for TX/RX FIFOs */
     scif_writew(uart, SCIF_SCFCR, SCFCR_RTRG11 | SCFCR_TTRG11);
@@ -122,14 +180,19 @@ static void __init scif_uart_init_postirq(struct serial_port *port)
                 uart->irq);
 
     /* Clear all errors */
-    if ( scif_readw(uart, SCIF_SCFSR) & SCIF_ERRORS )
-        scif_writew(uart, SCIF_SCFSR, ~SCIF_ERRORS);
-    if ( scif_readw(uart, SCIF_SCLSR) & SCLSR_ORER )
-        scif_writew(uart, SCIF_SCLSR, 0);
+    if ( scif_readw(uart, uart->params->status_reg) & uart->params->error_mask )
+        scif_writew(uart, uart->params->status_reg, ~uart->params->error_mask);
+    if ( uart->params->overrun_reg != uart->params->status_reg )
+    {
+        if ( scif_readw(uart, uart->params->overrun_reg) &
+             uart->params->overrun_mask )
+            scif_writew(uart, uart->params->overrun_reg,
+                        ~uart->params->overrun_mask);
+    }
 
     /* Enable TX/RX and Error Interrupts  */
     scif_writew(uart, SCIF_SCSCR, scif_readw(uart, SCIF_SCSCR) |
-                 SCSCR_TIE | SCSCR_RIE | SCSCR_REIE);
+                uart->params->irq_flags);
 }
 
 static void scif_uart_suspend(struct serial_port *port)
@@ -148,24 +211,25 @@ static int scif_uart_tx_ready(struct serial_port *port)
     uint16_t cnt;
 
     /* Check for empty space in TX FIFO */
-    if ( !(scif_readw(uart, SCIF_SCFSR) & SCFSR_TDFE) )
+    if ( !(scif_readw(uart, uart->params->status_reg) & SCFSR_TDFE) )
         return 0;
 
      /* Check number of data bytes stored in TX FIFO */
     cnt = scif_readw(uart, SCIF_SCFDR) >> 8;
-    ASSERT( cnt >= 0 && cnt <= SCIF_FIFO_MAX_SIZE );
+    ASSERT( cnt >= 0 && cnt <= uart->params->fifo_size );
 
-    return (SCIF_FIFO_MAX_SIZE - cnt);
+    return (uart->params->fifo_size - cnt);
 }
 
 static void scif_uart_putc(struct serial_port *port, char c)
 {
     struct scif_uart *uart = port->uart;
 
-    scif_writeb(uart, SCIF_SCFTDR, c);
+    scif_writeb(uart, uart->params->tx_fifo_reg, c);
     /* Clear required TX flags */
-    scif_writew(uart, SCIF_SCFSR, scif_readw(uart, SCIF_SCFSR) &
-                 ~(SCFSR_TEND | SCFSR_TDFE));
+    scif_writew(uart, uart->params->status_reg,
+                scif_readw(uart, uart->params->status_reg) &
+                ~(SCFSR_TEND | SCFSR_TDFE));
 }
 
 static int scif_uart_getc(struct serial_port *port, char *pc)
@@ -173,15 +237,16 @@ static int scif_uart_getc(struct serial_port *port, char *pc)
     struct scif_uart *uart = port->uart;
 
     /* Check for available data bytes in RX FIFO */
-    if ( !(scif_readw(uart, SCIF_SCFSR) & (SCFSR_RDF | SCFSR_DR)) )
+    if ( !(scif_readw(uart, uart->params->status_reg) &
+          (SCFSR_RDF | SCFSR_DR)) )
         return 0;
 
-    *pc = scif_readb(uart, SCIF_SCFRDR);
+    *pc = scif_readb(uart, uart->params->rx_fifo_reg);
 
     /* dummy read */
-    scif_readw(uart, SCIF_SCFSR);
+    scif_readw(uart, uart->params->status_reg);
     /* Clear required RX flags */
-    scif_writew(uart, SCIF_SCFSR, ~(SCFSR_RDF | SCFSR_DR));
+    scif_writew(uart, uart->params->status_reg, ~(SCFSR_RDF | SCFSR_DR));
 
     return 1;
 }
@@ -265,10 +330,15 @@ static int __init scif_uart_init(struct dt_device_node *dev,
         return -ENOMEM;
     }
 
+    if ( dt_device_is_compatible(dev, "renesas,scifa") )
+        uart->params = &port_params[SCIFA_PORT];
+    else
+        uart->params = &port_params[SCIF_PORT];
+
     uart->vuart.base_addr  = addr;
     uart->vuart.size       = size;
-    uart->vuart.data_off   = SCIF_SCFTDR;
-    uart->vuart.status_off = SCIF_SCFSR;
+    uart->vuart.data_off   = uart->params->tx_fifo_reg;
+    uart->vuart.status_off = uart->params->status_reg;
     uart->vuart.status     = SCFSR_TDFE;
 
     /* Register with generic serial driver */
@@ -282,6 +352,7 @@ static int __init scif_uart_init(struct dt_device_node *dev,
 static const struct dt_device_match scif_uart_dt_match[] __initconst =
 {
     DT_MATCH_COMPATIBLE("renesas,scif"),
+    DT_MATCH_COMPATIBLE("renesas,scifa"),
     { /* sentinel */ },
 };
 
diff --git a/xen/include/asm-arm/scif-uart.h b/xen/include/asm-arm/scif-uart.h
index 8137850..bce3404 100644
--- a/xen/include/asm-arm/scif-uart.h
+++ b/xen/include/asm-arm/scif-uart.h
@@ -2,7 +2,7 @@
  * xen/include/asm-arm/scif-uart.h
  *
  * Common constant definition between early printk and the UART driver
- * for the SCIF compatible UART.
+ * for the SCIF(A) compatible UART.
  *
  * Oleksandr Tyshchenko <oleksandr.tyshchenko@globallogic.com>
  * Copyright (C) 2014, Globallogic.
@@ -21,9 +21,7 @@
 #ifndef __ASM_ARM_SCIF_UART_H
 #define __ASM_ARM_SCIF_UART_H
 
-#define SCIF_FIFO_MAX_SIZE    16
-
-/* Register offsets */
+/* Register offsets (SCIF) */
 #define SCIF_SCSMR     (0x00)    /* Serial mode register           */
 #define SCIF_SCBRR     (0x04)    /* Bit rate register              */
 #define SCIF_SCSCR     (0x08)    /* Serial control register        */
@@ -57,8 +55,6 @@
 #define SCFSR_RDF     (1 << 1)    /* Receive FIFO Data Full */
 #define SCFSR_DR      (1 << 0)    /* Receive Data Ready */
 
-#define SCIF_ERRORS    (SCFSR_PER | SCFSR_FER | SCFSR_ER | SCFSR_BRK)
-
 /* Line Status Register (SCLSR) */
 #define SCLSR_TO      (1 << 2)    /* Timeout */
 #define SCLSR_ORER    (1 << 0)    /* Overrun Error */
@@ -83,6 +79,42 @@
 #define SCFCR_TTRG10    (SCFCR_TTRG1)
 #define SCFCR_TTRG11    (SCFCR_TTRG1 | SCFCR_TTRG0)
 
+/* Register offsets (SCIFA) */
+#define SCIFA_SCASMR     (0x00)    /* Serial mode register           */
+#define SCIFA_SCABRR     (0x04)    /* Bit rate register              */
+#define SCIFA_SCASCR     (0x08)    /* Serial control register        */
+#define SCIFA_SCATDSR    (0x0C)    /* Transmit data stop register    */
+#define SCIFA_SCAFER     (0x10)    /* FIFO error count register      */
+#define SCIFA_SCASSR     (0x14)    /* Serial status register         */
+#define SCIFA_SCAFCR     (0x18)    /* FIFO control register          */
+#define SCIFA_SCAFDR     (0x1C)    /* FIFO data count register       */
+#define SCIFA_SCAFTDR    (0x20)    /* Transmit FIFO data register    */
+#define SCIFA_SCAFRDR    (0x24)    /* Receive FIFO data register     */
+#define SCIFA_SCAPCR     (0x30)    /* Serial port control register   */
+#define SCIFA_SCAPDR     (0x34)    /* Serial port data register      */
+
+/* Serial Control Register (SCASCR) */
+#define SCASCR_ERIE     (1 << 10)    /* Receive Error Interrupt Enable */
+#define SCASCR_BRIE     (1 << 9)     /* Break Interrupt Enable */
+#define SCASCR_DRIE     (1 << 8)     /* Receive Data Ready Interrupt Enable */
+#define SCASCR_TIE      (1 << 7)     /* Transmit Interrupt Enable */
+#define SCASCR_RIE      (1 << 6)     /* Receive Interrupt Enable */
+#define SCASCR_TE       (1 << 5)     /* Transmit Enable */
+#define SCASCR_RE       (1 << 4)     /* Receive Enable */
+#define SCASCR_CKE0     (1 << 0)     /* Clock Enable 0 */
+
+/* Serial Status Register (SCASSR) */
+#define SCASSR_ORER    (1 << 9)    /* Overrun Error */
+#define SCASSR_TSF     (1 << 8)    /* Transmit Data Stop */
+#define SCASSR_ER      (1 << 7)    /* Receive Error */
+#define SCASSR_TEND    (1 << 6)    /* Transmission End */
+#define SCASSR_TDFE    (1 << 5)    /* Transmit FIFO Data Empty */
+#define SCASSR_BRK     (1 << 4)    /* Break Detect */
+#define SCASSR_FER     (1 << 3)    /* Framing Error */
+#define SCASSR_PER     (1 << 2)    /* Parity Error */
+#define SCASSR_RDF     (1 << 1)    /* Receive FIFO Data Full */
+#define SCASSR_DR      (1 << 0)    /* Receive Data Ready */
+
 #endif /* __ASM_ARM_SCIF_UART_H */
 
 /*
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 2/4] xen/arm: drivers: scif: Add support for SCIFA compatible UARTs

[Julien Grall]

Hi Oleksandr,

On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> 
> Extend existing driver to be able to handle SCIFA interface as well.
> SCIF and SCIFA have lot in common, though SCIFA has different
> offsets and bits for some registers.
> 
> Use compatible string to recognize what interface is present
> on a target board.
> 
> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Julien Grall <julien.grall@arm.com>
> ---
>   xen/drivers/char/scif-uart.c    | 129 +++++++++++++++++++++++++++++++---------
>   xen/include/asm-arm/scif-uart.h |  44 ++++++++++++--
>   2 files changed, 138 insertions(+), 35 deletions(-)
> 
> diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
> index 465fb34..d1eb713 100644
> --- a/xen/drivers/char/scif-uart.c
> +++ b/xen/drivers/char/scif-uart.c
> @@ -1,7 +1,7 @@
>   /*
>    * xen/drivers/char/scif-uart.c
>    *
> - * Driver for SCIF (Serial communication interface with FIFO)
> + * Driver for SCIF(A) (Serial communication interface with FIFO (A))
>    * compatible UART.
>    *
>    * Oleksandr Tyshchenko <oleksandr.tyshchenko@globallogic.com>
> @@ -40,8 +40,57 @@ static struct scif_uart {
>       char __iomem *regs;
>       struct irqaction irqaction;
>       struct vuart_info vuart;
> +    const struct port_params *params;
>   } scif_com = {0};
>   
> +enum

Should not this enum has a name?

> +{
> +    SCIF_PORT,
> +    SCIFA_PORT,
> +    NR_PORTS,
> +};
> +
> +struct port_params
> +{
> +    unsigned int status_reg;
> +    unsigned int tx_fifo_reg;
> +    unsigned int rx_fifo_reg;
> +    unsigned int overrun_reg;
> +    unsigned int overrun_mask;
> +    unsigned int error_mask;
> +    unsigned int irq_flags;
> +    unsigned int fifo_size;
> +};
> +
> +static const struct port_params port_params[NR_PORTS] =
> +{
> +    [SCIF_PORT] =
> +    {
> +        .status_reg   = SCIF_SCFSR,
> +        .tx_fifo_reg  = SCIF_SCFTDR,
> +        .rx_fifo_reg  = SCIF_SCFRDR,
> +        .overrun_reg  = SCIF_SCLSR,
> +        .overrun_mask = SCLSR_ORER,
> +        .error_mask   = SCFSR_PER | SCFSR_FER | SCFSR_BRK | SCFSR_ER,
> +        .irq_flags    = SCSCR_RIE | SCSCR_TIE | SCSCR_REIE,
> +        .fifo_size    = 16,
> +    },
> +
> +    [SCIFA_PORT] =
> +    {
> +        .status_reg   = SCIFA_SCASSR,
> +        .tx_fifo_reg  = SCIFA_SCAFTDR,
> +        .rx_fifo_reg  = SCIFA_SCAFRDR,
> +        .overrun_reg  = SCIFA_SCASSR,
> +        .overrun_mask = SCASSR_ORER,
> +        .error_mask   = SCASSR_PER | SCASSR_FER | SCASSR_BRK | SCASSR_ER |
> +                        SCASSR_ORER,
> +        .irq_flags    = SCASCR_RIE | SCASCR_TIE | SCASCR_DRIE | SCASCR_ERIE |
> +                        SCASCR_BRIE,
> +        .fifo_size    = 64,
> +    },
> +};
> +
>   static void scif_uart_interrupt(int irq, void *data, struct cpu_user_regs *regs)
>   {
>       struct serial_port *port = data;
> @@ -49,7 +98,7 @@ static void scif_uart_interrupt(int irq, void *data, struct cpu_user_regs *regs)
>       uint16_t status, ctrl;
>   
>       ctrl = scif_readw(uart, SCIF_SCSCR);
> -    status = scif_readw(uart, SCIF_SCFSR) & ~SCFSR_TEND;
> +    status = scif_readw(uart, uart->params->status_reg) & ~SCFSR_TEND;

I would prefer if you introduce a local variable for the params. This 
would avoid to write uart->params everywhere.

>       /* Ignore next flag if TX Interrupt is disabled */
>       if ( !(ctrl & SCSCR_TIE) )
>           status &= ~SCFSR_TDFE;
> @@ -65,13 +114,19 @@ static void scif_uart_interrupt(int irq, void *data, struct cpu_user_regs *regs)
>               serial_rx_interrupt(port, regs);
>   
>           /* Error Interrupt */
> -        if ( status & SCIF_ERRORS )
> -            scif_writew(uart, SCIF_SCFSR, ~SCIF_ERRORS);
> -        if ( scif_readw(uart, SCIF_SCLSR) & SCLSR_ORER )
> -            scif_writew(uart, SCIF_SCLSR, 0);
> +        if ( status & uart->params->error_mask )
> +            scif_writew(uart, uart->params->status_reg,
> +                        ~uart->params->error_mask);
> +        if ( uart->params->overrun_reg != uart->params->status_reg )
> +        {
> +            if ( scif_readw(uart, uart->params->overrun_reg) &
> +                 uart->params->overrun_mask )
> +                scif_writew(uart, uart->params->overrun_reg,
> +                            ~uart->params->overrun_mask);
> +        }
>   
>           ctrl = scif_readw(uart, SCIF_SCSCR);
> -        status = scif_readw(uart, SCIF_SCFSR) & ~SCFSR_TEND;
> +        status = scif_readw(uart, uart->params->status_reg) & ~SCFSR_TEND;
>           /* Ignore next flag if TX Interrupt is disabled */
>           if ( !(ctrl & SCSCR_TIE) )
>               status &= ~SCFSR_TDFE;
> @@ -86,7 +141,7 @@ static void __init scif_uart_init_preirq(struct serial_port *port)
>        * Wait until last bit has been transmitted. This is needed for a smooth
>        * transition when we come from early printk
>        */
> -    while ( !(scif_readw(uart, SCIF_SCFSR) & SCFSR_TEND) );
> +    while ( !(scif_readw(uart, uart->params->status_reg) & SCFSR_TEND) );
>   
>       /* Disable TX/RX parts and all interrupts */
>       scif_writew(uart, SCIF_SCSCR, 0);
> @@ -95,10 +150,13 @@ static void __init scif_uart_init_preirq(struct serial_port *port)
>       scif_writew(uart, SCIF_SCFCR, SCFCR_RFRST | SCFCR_TFRST);
>   
>       /* Clear all errors and flags */
> -    scif_readw(uart, SCIF_SCFSR);
> -    scif_writew(uart, SCIF_SCFSR, 0);
> -    scif_readw(uart, SCIF_SCLSR);
> -    scif_writew(uart, SCIF_SCLSR, 0);
> +    scif_readw(uart, uart->params->status_reg);
> +    scif_writew(uart, uart->params->status_reg, 0);
> +    if ( uart->params->overrun_reg != uart->params->status_reg )

I don't think there is any harm to reset the registers twice when 
overrun_reg != status_reg.

> +    {
> +        scif_readw(uart, uart->params->overrun_reg);
> +        scif_writew(uart, uart->params->overrun_reg, 0);
> +    }
>   
>       /* Setup trigger level for TX/RX FIFOs */
>       scif_writew(uart, SCIF_SCFCR, SCFCR_RTRG11 | SCFCR_TTRG11);
> @@ -122,14 +180,19 @@ static void __init scif_uart_init_postirq(struct serial_port *port)
>                   uart->irq);
>   
>       /* Clear all errors */
> -    if ( scif_readw(uart, SCIF_SCFSR) & SCIF_ERRORS )
> -        scif_writew(uart, SCIF_SCFSR, ~SCIF_ERRORS);
> -    if ( scif_readw(uart, SCIF_SCLSR) & SCLSR_ORER )
> -        scif_writew(uart, SCIF_SCLSR, 0);
> +    if ( scif_readw(uart, uart->params->status_reg) & uart->params->error_mask )
> +        scif_writew(uart, uart->params->status_reg, ~uart->params->error_mask);
> +    if ( uart->params->overrun_reg != uart->params->status_reg )
> +    {
> +        if ( scif_readw(uart, uart->params->overrun_reg) &
> +             uart->params->overrun_mask )
> +            scif_writew(uart, uart->params->overrun_reg,
> +                        ~uart->params->overrun_mask);
> +    }
>   
>       /* Enable TX/RX and Error Interrupts  */
>       scif_writew(uart, SCIF_SCSCR, scif_readw(uart, SCIF_SCSCR) |
> -                 SCSCR_TIE | SCSCR_RIE | SCSCR_REIE);
> +                uart->params->irq_flags);

The indentation looks wrong here.

>   }
>   
>   static void scif_uart_suspend(struct serial_port *port)
> @@ -148,24 +211,25 @@ static int scif_uart_tx_ready(struct serial_port *port)
>       uint16_t cnt;
>   
>       /* Check for empty space in TX FIFO */
> -    if ( !(scif_readw(uart, SCIF_SCFSR) & SCFSR_TDFE) )
> +    if ( !(scif_readw(uart, uart->params->status_reg) & SCFSR_TDFE) )
>           return 0;
>   
>        /* Check number of data bytes stored in TX FIFO */
>       cnt = scif_readw(uart, SCIF_SCFDR) >> 8;
> -    ASSERT( cnt >= 0 && cnt <= SCIF_FIFO_MAX_SIZE );
> +    ASSERT( cnt >= 0 && cnt <= uart->params->fifo_size );
>   
> -    return (SCIF_FIFO_MAX_SIZE - cnt);
> +    return (uart->params->fifo_size - cnt);
>   }
>   
>   static void scif_uart_putc(struct serial_port *port, char c)
>   {
>       struct scif_uart *uart = port->uart;
>   
> -    scif_writeb(uart, SCIF_SCFTDR, c);
> +    scif_writeb(uart, uart->params->tx_fifo_reg, c);
>       /* Clear required TX flags */
> -    scif_writew(uart, SCIF_SCFSR, scif_readw(uart, SCIF_SCFSR) &
> -                 ~(SCFSR_TEND | SCFSR_TDFE));
> +    scif_writew(uart, uart->params->status_reg,
> +                scif_readw(uart, uart->params->status_reg) &
> +                ~(SCFSR_TEND | SCFSR_TDFE));
>   }
>   
>   static int scif_uart_getc(struct serial_port *port, char *pc)
> @@ -173,15 +237,16 @@ static int scif_uart_getc(struct serial_port *port, char *pc)
>       struct scif_uart *uart = port->uart;
>   
>       /* Check for available data bytes in RX FIFO */
> -    if ( !(scif_readw(uart, SCIF_SCFSR) & (SCFSR_RDF | SCFSR_DR)) )
> +    if ( !(scif_readw(uart, uart->params->status_reg) &
> +          (SCFSR_RDF | SCFSR_DR)) )
>           return 0;
>   
> -    *pc = scif_readb(uart, SCIF_SCFRDR);
> +    *pc = scif_readb(uart, uart->params->rx_fifo_reg);
>   
>       /* dummy read */
> -    scif_readw(uart, SCIF_SCFSR);
> +    scif_readw(uart, uart->params->status_reg);
>       /* Clear required RX flags */
> -    scif_writew(uart, SCIF_SCFSR, ~(SCFSR_RDF | SCFSR_DR));
> +    scif_writew(uart, uart->params->status_reg, ~(SCFSR_RDF | SCFSR_DR));
>   
>       return 1;
>   }
> @@ -265,10 +330,15 @@ static int __init scif_uart_init(struct dt_device_node *dev,
>           return -ENOMEM;
>       }
>   
> +    if ( dt_device_is_compatible(dev, "renesas,scifa") )
> +        uart->params = &port_params[SCIFA_PORT];
> +    else
> +        uart->params = &port_params[SCIF_PORT];

You can use the field .data in dt_device_match to store specific data 
and then use dt_match_node to find the correct node.

> +
>       uart->vuart.base_addr  = addr;
>       uart->vuart.size       = size;
> -    uart->vuart.data_off   = SCIF_SCFTDR;
> -    uart->vuart.status_off = SCIF_SCFSR;
> +    uart->vuart.data_off   = uart->params->tx_fifo_reg;
> +    uart->vuart.status_off = uart->params->status_reg;
>       uart->vuart.status     = SCFSR_TDFE;
>   
>       /* Register with generic serial driver */
> @@ -282,6 +352,7 @@ static int __init scif_uart_init(struct dt_device_node *dev,
>   static const struct dt_device_match scif_uart_dt_match[] __initconst =
>   {
>       DT_MATCH_COMPATIBLE("renesas,scif"),
> +    DT_MATCH_COMPATIBLE("renesas,scifa"),
>       { /* sentinel */ },
>   };
>   
> diff --git a/xen/include/asm-arm/scif-uart.h b/xen/include/asm-arm/scif-uart.h
> index 8137850..bce3404 100644
> --- a/xen/include/asm-arm/scif-uart.h
> +++ b/xen/include/asm-arm/scif-uart.h
> @@ -2,7 +2,7 @@
>    * xen/include/asm-arm/scif-uart.h
>    *
>    * Common constant definition between early printk and the UART driver
> - * for the SCIF compatible UART.
> + * for the SCIF(A) compatible UART.
>    *
>    * Oleksandr Tyshchenko <oleksandr.tyshchenko@globallogic.com>
>    * Copyright (C) 2014, Globallogic.
> @@ -21,9 +21,7 @@
>   #ifndef __ASM_ARM_SCIF_UART_H
>   #define __ASM_ARM_SCIF_UART_H
>   
> -#define SCIF_FIFO_MAX_SIZE    16
> -
> -/* Register offsets */
> +/* Register offsets (SCIF) */
>   #define SCIF_SCSMR     (0x00)    /* Serial mode register           */
>   #define SCIF_SCBRR     (0x04)    /* Bit rate register              */
>   #define SCIF_SCSCR     (0x08)    /* Serial control register        */
> @@ -57,8 +55,6 @@
>   #define SCFSR_RDF     (1 << 1)    /* Receive FIFO Data Full */
>   #define SCFSR_DR      (1 << 0)    /* Receive Data Ready */
>   
> -#define SCIF_ERRORS    (SCFSR_PER | SCFSR_FER | SCFSR_ER | SCFSR_BRK)
> -
>   /* Line Status Register (SCLSR) */
>   #define SCLSR_TO      (1 << 2)    /* Timeout */
>   #define SCLSR_ORER    (1 << 0)    /* Overrun Error */
> @@ -83,6 +79,42 @@
>   #define SCFCR_TTRG10    (SCFCR_TTRG1)
>   #define SCFCR_TTRG11    (SCFCR_TTRG1 | SCFCR_TTRG0)
>   
> +/* Register offsets (SCIFA) */
> +#define SCIFA_SCASMR     (0x00)    /* Serial mode register           */
> +#define SCIFA_SCABRR     (0x04)    /* Bit rate register              */
> +#define SCIFA_SCASCR     (0x08)    /* Serial control register        */
> +#define SCIFA_SCATDSR    (0x0C)    /* Transmit data stop register    */
> +#define SCIFA_SCAFER     (0x10)    /* FIFO error count register      */
> +#define SCIFA_SCASSR     (0x14)    /* Serial status register         */
> +#define SCIFA_SCAFCR     (0x18)    /* FIFO control register          */
> +#define SCIFA_SCAFDR     (0x1C)    /* FIFO data count register       */
> +#define SCIFA_SCAFTDR    (0x20)    /* Transmit FIFO data register    */
> +#define SCIFA_SCAFRDR    (0x24)    /* Receive FIFO data register     */
> +#define SCIFA_SCAPCR     (0x30)    /* Serial port control register   */
> +#define SCIFA_SCAPDR     (0x34)    /* Serial port data register      */
> +
> +/* Serial Control Register (SCASCR) */
> +#define SCASCR_ERIE     (1 << 10)    /* Receive Error Interrupt Enable */
> +#define SCASCR_BRIE     (1 << 9)     /* Break Interrupt Enable */
> +#define SCASCR_DRIE     (1 << 8)     /* Receive Data Ready Interrupt Enable */
> +#define SCASCR_TIE      (1 << 7)     /* Transmit Interrupt Enable */
> +#define SCASCR_RIE      (1 << 6)     /* Receive Interrupt Enable */
> +#define SCASCR_TE       (1 << 5)     /* Transmit Enable */
> +#define SCASCR_RE       (1 << 4)     /* Receive Enable */
> +#define SCASCR_CKE0     (1 << 0)     /* Clock Enable 0 */
> +
> +/* Serial Status Register (SCASSR) */
> +#define SCASSR_ORER    (1 << 9)    /* Overrun Error */
> +#define SCASSR_TSF     (1 << 8)    /* Transmit Data Stop */
> +#define SCASSR_ER      (1 << 7)    /* Receive Error */
> +#define SCASSR_TEND    (1 << 6)    /* Transmission End */
> +#define SCASSR_TDFE    (1 << 5)    /* Transmit FIFO Data Empty */
> +#define SCASSR_BRK     (1 << 4)    /* Break Detect */
> +#define SCASSR_FER     (1 << 3)    /* Framing Error */
> +#define SCASSR_PER     (1 << 2)    /* Parity Error */
> +#define SCASSR_RDF     (1 << 1)    /* Receive FIFO Data Full */
> +#define SCASSR_DR      (1 << 0)    /* Receive Data Ready */
> +
>   #endif /* __ASM_ARM_SCIF_UART_H */
>   
>   /*
> 

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 2/4] xen/arm: drivers: scif: Add support for SCIFA compatible UARTs

[Oleksandr Tyshchenko]

On Tue, Aug 7, 2018 at 4:43 PM, Julien Grall <julien.grall@arm.com> wrote:
> Hi Oleksandr,
Hi, Julien

>
>
> On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>
>> Extend existing driver to be able to handle SCIFA interface as well.
>> SCIF and SCIFA have lot in common, though SCIFA has different
>> offsets and bits for some registers.
>>
>> Use compatible string to recognize what interface is present
>> on a target board.
>>
>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>> CC: Stefano Stabellini <sstabellini@kernel.org>
>> CC: Julien Grall <julien.grall@arm.com>
>> ---
>>   xen/drivers/char/scif-uart.c    | 129
>> +++++++++++++++++++++++++++++++---------
>>   xen/include/asm-arm/scif-uart.h |  44 ++++++++++++--
>>   2 files changed, 138 insertions(+), 35 deletions(-)
>>
>> diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
>> index 465fb34..d1eb713 100644
>> --- a/xen/drivers/char/scif-uart.c
>> +++ b/xen/drivers/char/scif-uart.c
>> @@ -1,7 +1,7 @@
>>   /*
>>    * xen/drivers/char/scif-uart.c
>>    *
>> - * Driver for SCIF (Serial communication interface with FIFO)
>> + * Driver for SCIF(A) (Serial communication interface with FIFO (A))
>>    * compatible UART.
>>    *
>>    * Oleksandr Tyshchenko <oleksandr.tyshchenko@globallogic.com>
>> @@ -40,8 +40,57 @@ static struct scif_uart {
>>       char __iomem *regs;
>>       struct irqaction irqaction;
>>       struct vuart_info vuart;
>> +    const struct port_params *params;
>>   } scif_com = {0};
>>   +enum
>
>
> Should not this enum has a name?
I think, it should.

>
>
>> +{
>> +    SCIF_PORT,
>> +    SCIFA_PORT,
>> +    NR_PORTS,
>> +};
>> +
>> +struct port_params
>> +{
>> +    unsigned int status_reg;
>> +    unsigned int tx_fifo_reg;
>> +    unsigned int rx_fifo_reg;
>> +    unsigned int overrun_reg;
>> +    unsigned int overrun_mask;
>> +    unsigned int error_mask;
>> +    unsigned int irq_flags;
>> +    unsigned int fifo_size;
>> +};
>> +
>> +static const struct port_params port_params[NR_PORTS] =
>> +{
>> +    [SCIF_PORT] =
>> +    {
>> +        .status_reg   = SCIF_SCFSR,
>> +        .tx_fifo_reg  = SCIF_SCFTDR,
>> +        .rx_fifo_reg  = SCIF_SCFRDR,
>> +        .overrun_reg  = SCIF_SCLSR,
>> +        .overrun_mask = SCLSR_ORER,
>> +        .error_mask   = SCFSR_PER | SCFSR_FER | SCFSR_BRK | SCFSR_ER,
>> +        .irq_flags    = SCSCR_RIE | SCSCR_TIE | SCSCR_REIE,
>> +        .fifo_size    = 16,
>> +    },
>> +
>> +    [SCIFA_PORT] =
>> +    {
>> +        .status_reg   = SCIFA_SCASSR,
>> +        .tx_fifo_reg  = SCIFA_SCAFTDR,
>> +        .rx_fifo_reg  = SCIFA_SCAFRDR,
>> +        .overrun_reg  = SCIFA_SCASSR,
>> +        .overrun_mask = SCASSR_ORER,
>> +        .error_mask   = SCASSR_PER | SCASSR_FER | SCASSR_BRK | SCASSR_ER
>> |
>> +                        SCASSR_ORER,
>> +        .irq_flags    = SCASCR_RIE | SCASCR_TIE | SCASCR_DRIE |
>> SCASCR_ERIE |
>> +                        SCASCR_BRIE,
>> +        .fifo_size    = 64,
>> +    },
>> +};
>> +
>>   static void scif_uart_interrupt(int irq, void *data, struct
>> cpu_user_regs *regs)
>>   {
>>       struct serial_port *port = data;
>> @@ -49,7 +98,7 @@ static void scif_uart_interrupt(int irq, void *data,
>> struct cpu_user_regs *regs)
>>       uint16_t status, ctrl;
>>         ctrl = scif_readw(uart, SCIF_SCSCR);
>> -    status = scif_readw(uart, SCIF_SCFSR) & ~SCFSR_TEND;
>> +    status = scif_readw(uart, uart->params->status_reg) & ~SCFSR_TEND;
>
>
> I would prefer if you introduce a local variable for the params. This would
> avoid to write uart->params everywhere.
Agree. Do you want me to use this local variable only in interrupt
handler or everywhere in a file where uart->params is used?

>
>
>>       /* Ignore next flag if TX Interrupt is disabled */
>>       if ( !(ctrl & SCSCR_TIE) )
>>           status &= ~SCFSR_TDFE;
>> @@ -65,13 +114,19 @@ static void scif_uart_interrupt(int irq, void *data,
>> struct cpu_user_regs *regs)
>>               serial_rx_interrupt(port, regs);
>>             /* Error Interrupt */
>> -        if ( status & SCIF_ERRORS )
>> -            scif_writew(uart, SCIF_SCFSR, ~SCIF_ERRORS);
>> -        if ( scif_readw(uart, SCIF_SCLSR) & SCLSR_ORER )
>> -            scif_writew(uart, SCIF_SCLSR, 0);
>> +        if ( status & uart->params->error_mask )
>> +            scif_writew(uart, uart->params->status_reg,
>> +                        ~uart->params->error_mask);
>> +        if ( uart->params->overrun_reg != uart->params->status_reg )
>> +        {
>> +            if ( scif_readw(uart, uart->params->overrun_reg) &
>> +                 uart->params->overrun_mask )
>> +                scif_writew(uart, uart->params->overrun_reg,
>> +                            ~uart->params->overrun_mask);
>> +        }
>>             ctrl = scif_readw(uart, SCIF_SCSCR);
>> -        status = scif_readw(uart, SCIF_SCFSR) & ~SCFSR_TEND;
>> +        status = scif_readw(uart, uart->params->status_reg) &
>> ~SCFSR_TEND;
>>           /* Ignore next flag if TX Interrupt is disabled */
>>           if ( !(ctrl & SCSCR_TIE) )
>>               status &= ~SCFSR_TDFE;
>> @@ -86,7 +141,7 @@ static void __init scif_uart_init_preirq(struct
>> serial_port *port)
>>        * Wait until last bit has been transmitted. This is needed for a
>> smooth
>>        * transition when we come from early printk
>>        */
>> -    while ( !(scif_readw(uart, SCIF_SCFSR) & SCFSR_TEND) );
>> +    while ( !(scif_readw(uart, uart->params->status_reg) & SCFSR_TEND) );
>>         /* Disable TX/RX parts and all interrupts */
>>       scif_writew(uart, SCIF_SCSCR, 0);
>> @@ -95,10 +150,13 @@ static void __init scif_uart_init_preirq(struct
>> serial_port *port)
>>       scif_writew(uart, SCIF_SCFCR, SCFCR_RFRST | SCFCR_TFRST);
>>         /* Clear all errors and flags */
>> -    scif_readw(uart, SCIF_SCFSR);
>> -    scif_writew(uart, SCIF_SCFSR, 0);
>> -    scif_readw(uart, SCIF_SCLSR);
>> -    scif_writew(uart, SCIF_SCLSR, 0);
>> +    scif_readw(uart, uart->params->status_reg);
>> +    scif_writew(uart, uart->params->status_reg, 0);
>> +    if ( uart->params->overrun_reg != uart->params->status_reg )
>
>
> I don't think there is any harm to reset the registers twice when
> overrun_reg != status_reg.
Agree.

>
>
>> +    {
>> +        scif_readw(uart, uart->params->overrun_reg);
>> +        scif_writew(uart, uart->params->overrun_reg, 0);
>> +    }
>>         /* Setup trigger level for TX/RX FIFOs */
>>       scif_writew(uart, SCIF_SCFCR, SCFCR_RTRG11 | SCFCR_TTRG11);
>> @@ -122,14 +180,19 @@ static void __init scif_uart_init_postirq(struct
>> serial_port *port)
>>                   uart->irq);
>>         /* Clear all errors */
>> -    if ( scif_readw(uart, SCIF_SCFSR) & SCIF_ERRORS )
>> -        scif_writew(uart, SCIF_SCFSR, ~SCIF_ERRORS);
>> -    if ( scif_readw(uart, SCIF_SCLSR) & SCLSR_ORER )
>> -        scif_writew(uart, SCIF_SCLSR, 0);
>> +    if ( scif_readw(uart, uart->params->status_reg) &
>> uart->params->error_mask )
>> +        scif_writew(uart, uart->params->status_reg,
>> ~uart->params->error_mask);
>> +    if ( uart->params->overrun_reg != uart->params->status_reg )
>> +    {
>> +        if ( scif_readw(uart, uart->params->overrun_reg) &
>> +             uart->params->overrun_mask )
>> +            scif_writew(uart, uart->params->overrun_reg,
>> +                        ~uart->params->overrun_mask);
>> +    }
>>         /* Enable TX/RX and Error Interrupts  */
>>       scif_writew(uart, SCIF_SCSCR, scif_readw(uart, SCIF_SCSCR) |
>> -                 SCSCR_TIE | SCSCR_RIE | SCSCR_REIE);
>> +                uart->params->irq_flags);
>
>
> The indentation looks wrong here.
Will correct.

>
>
>>   }
>>     static void scif_uart_suspend(struct serial_port *port)
>> @@ -148,24 +211,25 @@ static int scif_uart_tx_ready(struct serial_port
>> *port)
>>       uint16_t cnt;
>>         /* Check for empty space in TX FIFO */
>> -    if ( !(scif_readw(uart, SCIF_SCFSR) & SCFSR_TDFE) )
>> +    if ( !(scif_readw(uart, uart->params->status_reg) & SCFSR_TDFE) )
>>           return 0;
>>          /* Check number of data bytes stored in TX FIFO */
>>       cnt = scif_readw(uart, SCIF_SCFDR) >> 8;
>> -    ASSERT( cnt >= 0 && cnt <= SCIF_FIFO_MAX_SIZE );
>> +    ASSERT( cnt >= 0 && cnt <= uart->params->fifo_size );
>>   -    return (SCIF_FIFO_MAX_SIZE - cnt);
>> +    return (uart->params->fifo_size - cnt);
>>   }
>>     static void scif_uart_putc(struct serial_port *port, char c)
>>   {
>>       struct scif_uart *uart = port->uart;
>>   -    scif_writeb(uart, SCIF_SCFTDR, c);
>> +    scif_writeb(uart, uart->params->tx_fifo_reg, c);
>>       /* Clear required TX flags */
>> -    scif_writew(uart, SCIF_SCFSR, scif_readw(uart, SCIF_SCFSR) &
>> -                 ~(SCFSR_TEND | SCFSR_TDFE));
>> +    scif_writew(uart, uart->params->status_reg,
>> +                scif_readw(uart, uart->params->status_reg) &
>> +                ~(SCFSR_TEND | SCFSR_TDFE));
>>   }
>>     static int scif_uart_getc(struct serial_port *port, char *pc)
>> @@ -173,15 +237,16 @@ static int scif_uart_getc(struct serial_port *port,
>> char *pc)
>>       struct scif_uart *uart = port->uart;
>>         /* Check for available data bytes in RX FIFO */
>> -    if ( !(scif_readw(uart, SCIF_SCFSR) & (SCFSR_RDF | SCFSR_DR)) )
>> +    if ( !(scif_readw(uart, uart->params->status_reg) &
>> +          (SCFSR_RDF | SCFSR_DR)) )
>>           return 0;
>>   -    *pc = scif_readb(uart, SCIF_SCFRDR);
>> +    *pc = scif_readb(uart, uart->params->rx_fifo_reg);
>>         /* dummy read */
>> -    scif_readw(uart, SCIF_SCFSR);
>> +    scif_readw(uart, uart->params->status_reg);
>>       /* Clear required RX flags */
>> -    scif_writew(uart, SCIF_SCFSR, ~(SCFSR_RDF | SCFSR_DR));
>> +    scif_writew(uart, uart->params->status_reg, ~(SCFSR_RDF | SCFSR_DR));
>>         return 1;
>>   }
>> @@ -265,10 +330,15 @@ static int __init scif_uart_init(struct
>> dt_device_node *dev,
>>           return -ENOMEM;
>>       }
>>   +    if ( dt_device_is_compatible(dev, "renesas,scifa") )
>> +        uart->params = &port_params[SCIFA_PORT];
>> +    else
>> +        uart->params = &port_params[SCIF_PORT];
>
>
> You can use the field .data in dt_device_match to store specific data and
> then use dt_match_node to find the correct node.
I understand. Will change.

>
>
>> +
>>       uart->vuart.base_addr  = addr;
>>       uart->vuart.size       = size;
>> -    uart->vuart.data_off   = SCIF_SCFTDR;
>> -    uart->vuart.status_off = SCIF_SCFSR;
>> +    uart->vuart.data_off   = uart->params->tx_fifo_reg;
>> +    uart->vuart.status_off = uart->params->status_reg;
>>       uart->vuart.status     = SCFSR_TDFE;
>>         /* Register with generic serial driver */
>> @@ -282,6 +352,7 @@ static int __init scif_uart_init(struct dt_device_node
>> *dev,
>>   static const struct dt_device_match scif_uart_dt_match[] __initconst =
>>   {
>>       DT_MATCH_COMPATIBLE("renesas,scif"),
>> +    DT_MATCH_COMPATIBLE("renesas,scifa"),
>>       { /* sentinel */ },
>>   };
>>   diff --git a/xen/include/asm-arm/scif-uart.h
>> b/xen/include/asm-arm/scif-uart.h
>> index 8137850..bce3404 100644
>> --- a/xen/include/asm-arm/scif-uart.h
>> +++ b/xen/include/asm-arm/scif-uart.h
>> @@ -2,7 +2,7 @@
>>    * xen/include/asm-arm/scif-uart.h
>>    *
>>    * Common constant definition between early printk and the UART driver
>> - * for the SCIF compatible UART.
>> + * for the SCIF(A) compatible UART.
>>    *
>>    * Oleksandr Tyshchenko <oleksandr.tyshchenko@globallogic.com>
>>    * Copyright (C) 2014, Globallogic.
>> @@ -21,9 +21,7 @@
>>   #ifndef __ASM_ARM_SCIF_UART_H
>>   #define __ASM_ARM_SCIF_UART_H
>>   -#define SCIF_FIFO_MAX_SIZE    16
>> -
>> -/* Register offsets */
>> +/* Register offsets (SCIF) */
>>   #define SCIF_SCSMR     (0x00)    /* Serial mode register           */
>>   #define SCIF_SCBRR     (0x04)    /* Bit rate register              */
>>   #define SCIF_SCSCR     (0x08)    /* Serial control register        */
>> @@ -57,8 +55,6 @@
>>   #define SCFSR_RDF     (1 << 1)    /* Receive FIFO Data Full */
>>   #define SCFSR_DR      (1 << 0)    /* Receive Data Ready */
>>   -#define SCIF_ERRORS    (SCFSR_PER | SCFSR_FER | SCFSR_ER | SCFSR_BRK)
>> -
>>   /* Line Status Register (SCLSR) */
>>   #define SCLSR_TO      (1 << 2)    /* Timeout */
>>   #define SCLSR_ORER    (1 << 0)    /* Overrun Error */
>> @@ -83,6 +79,42 @@
>>   #define SCFCR_TTRG10    (SCFCR_TTRG1)
>>   #define SCFCR_TTRG11    (SCFCR_TTRG1 | SCFCR_TTRG0)
>>   +/* Register offsets (SCIFA) */
>> +#define SCIFA_SCASMR     (0x00)    /* Serial mode register           */
>> +#define SCIFA_SCABRR     (0x04)    /* Bit rate register              */
>> +#define SCIFA_SCASCR     (0x08)    /* Serial control register        */
>> +#define SCIFA_SCATDSR    (0x0C)    /* Transmit data stop register    */
>> +#define SCIFA_SCAFER     (0x10)    /* FIFO error count register      */
>> +#define SCIFA_SCASSR     (0x14)    /* Serial status register         */
>> +#define SCIFA_SCAFCR     (0x18)    /* FIFO control register          */
>> +#define SCIFA_SCAFDR     (0x1C)    /* FIFO data count register       */
>> +#define SCIFA_SCAFTDR    (0x20)    /* Transmit FIFO data register    */
>> +#define SCIFA_SCAFRDR    (0x24)    /* Receive FIFO data register     */
>> +#define SCIFA_SCAPCR     (0x30)    /* Serial port control register   */
>> +#define SCIFA_SCAPDR     (0x34)    /* Serial port data register      */
>> +
>> +/* Serial Control Register (SCASCR) */
>> +#define SCASCR_ERIE     (1 << 10)    /* Receive Error Interrupt Enable */
>> +#define SCASCR_BRIE     (1 << 9)     /* Break Interrupt Enable */
>> +#define SCASCR_DRIE     (1 << 8)     /* Receive Data Ready Interrupt
>> Enable */
>> +#define SCASCR_TIE      (1 << 7)     /* Transmit Interrupt Enable */
>> +#define SCASCR_RIE      (1 << 6)     /* Receive Interrupt Enable */
>> +#define SCASCR_TE       (1 << 5)     /* Transmit Enable */
>> +#define SCASCR_RE       (1 << 4)     /* Receive Enable */
>> +#define SCASCR_CKE0     (1 << 0)     /* Clock Enable 0 */
>> +
>> +/* Serial Status Register (SCASSR) */
>> +#define SCASSR_ORER    (1 << 9)    /* Overrun Error */
>> +#define SCASSR_TSF     (1 << 8)    /* Transmit Data Stop */
>> +#define SCASSR_ER      (1 << 7)    /* Receive Error */
>> +#define SCASSR_TEND    (1 << 6)    /* Transmission End */
>> +#define SCASSR_TDFE    (1 << 5)    /* Transmit FIFO Data Empty */
>> +#define SCASSR_BRK     (1 << 4)    /* Break Detect */
>> +#define SCASSR_FER     (1 << 3)    /* Framing Error */
>> +#define SCASSR_PER     (1 << 2)    /* Parity Error */
>> +#define SCASSR_RDF     (1 << 1)    /* Receive FIFO Data Full */
>> +#define SCASSR_DR      (1 << 0)    /* Receive Data Ready */
>> +
>>   #endif /* __ASM_ARM_SCIF_UART_H */
>>     /*
>>
>
> Cheers,
>
> --
> Julien Grall



-- 
Regards,

Oleksandr Tyshchenko

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 2/4] xen/arm: drivers: scif: Add support for SCIFA compatible UARTs

[Julien Grall]

Hi Oleksandr,

On 07/08/18 16:01, Oleksandr Tyshchenko wrote:
> On Tue, Aug 7, 2018 at 4:43 PM, Julien Grall <julien.grall@arm.com> wrote:
>> On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
>> I would prefer if you introduce a local variable for the params. This would
>> avoid to write uart->params everywhere.
> Agree. Do you want me to use this local variable only in interrupt
> handler or everywhere in a file where uart->params is used?

At least in all functions where uart->params is used more than once.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v1 3/4] xen/arm: Add SCIFA UART support for early printk

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>

Add support for Renesas "Stout" development board based on
R-Car H2 SoC which has SCIFA compatible UART.

Actually existing SCIF UART support (debug-scif.inc) and
newly added SCIFA UART support (debug-scifa.inc) differ only
in registers offsets.

Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien.grall@arm.com>
---
 docs/misc/arm/early-printk.txt     |  3 ++-
 xen/arch/arm/Rules.mk              |  1 +
 xen/arch/arm/arm32/debug-scifa.inc | 51 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 54 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/arm/arm32/debug-scifa.inc

diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt
index f765f59..f1b55d3 100644
--- a/docs/misc/arm/early-printk.txt
+++ b/docs/misc/arm/early-printk.txt
@@ -39,12 +39,13 @@ the name of the machine:
   - fastmodel: printk on ARM Fastmodel software emulators
   - hikey960: printk with pl011 with Hikey 960
   - juno: printk with pl011 on Juno platform
-  - lager: printk with SCIF0 on Renesas R-Car H2 processors
+  - lager: printk with SCIF0 on Renesas Lager board (R-Car H2 processor)
   - midway: printk with the pl011 on Calxeda Midway processors
   - mvebu: printk with the MVEBU for Marvell Armada 3700 SoCs
   - omap5432: printk with UART3 on TI OMAP5432 processors
   - rcar3: printk with SCIF2 on Renesas R-Car Gen3 processors
   - seattle: printk with pl011 for AMD Seattle processor
+  - stout: printk with SCIFA0 on Renesas Stout board (R-Car H2 processor)
   - sun6i: printk with 8250 on Allwinner A31 processors
   - sun7i: printk with 8250 on Allwinner A20 processors
   - thunderx: printk with pl011 for Cavium ThunderX processor
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index f264592..e011f8b 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -40,6 +40,7 @@ EARLY_PRINTK_mvebu          := mvebu,0xd0012000
 EARLY_PRINTK_omap5432       := 8250,0x48020000,2
 EARLY_PRINTK_rcar3          := scif,0xe6e88000
 EARLY_PRINTK_seattle        := pl011,0xe1010000
+EARLY_PRINTK_stout          := scifa,0xe6c40000
 EARLY_PRINTK_sun6i          := 8250,0x01c28000,2
 EARLY_PRINTK_sun7i          := 8250,0x01c28000,2
 EARLY_PRINTK_thunderx       := pl011,0x87e024000000
diff --git a/xen/arch/arm/arm32/debug-scifa.inc b/xen/arch/arm/arm32/debug-scifa.inc
new file mode 100644
index 0000000..b5e60db
--- /dev/null
+++ b/xen/arch/arm/arm32/debug-scifa.inc
@@ -0,0 +1,51 @@
+/*
+ * xen/arch/arm/arm32/debug-scifa.inc
+ *
+ * SCIFA specific debug code
+ *
+ * Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
+ * Copyright (C) 2018 EPAM Systems 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 <asm/scif-uart.h>
+
+/*
+ * SCIFA UART wait UART to be ready to transmit
+ * rb: register which contains the UART base address
+ * rc: scratch register
+ */
+.macro early_uart_ready rb rc
+1:
+        ldrh   \rc, [\rb, #SCIFA_SCASSR]   /* <- SCASSR (status register) */
+        tst    \rc, #SCASSR_TDFE           /* Check TDFE bit */
+        beq    1b                          /* Wait for the UART to be ready */
+.endm
+
+/*
+ * SCIFA UART transmit character
+ * rb: register which contains the UART base address
+ * rt: register which contains the character to transmit
+ */
+.macro early_uart_transmit rb rt
+        strb   \rt, [\rb, #SCIFA_SCAFTDR]                  /* -> SCAFTDR (data register) */
+        ldrh   \rt, [\rb, #SCIFA_SCASSR]                   /* <- SCASSR (status register) */
+        and    \rt, \rt, #(~(SCASSR_TEND | SCASSR_TDFE))   /* Clear TEND and TDFE bits */
+        strh   \rt, [\rb, #SCIFA_SCASSR]                   /* -> SCASSR (status register) */
+.endm
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 3/4] xen/arm: Add SCIFA UART support for early printk

[Julien Grall]

Hi,

On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> 
> Add support for Renesas "Stout" development board based on
> R-Car H2 SoC which has SCIFA compatible UART.
> 
> Actually existing SCIF UART support (debug-scif.inc) and
> newly added SCIFA UART support (debug-scifa.inc) differ only
> in registers offsets.
In that case, could we just extend debug-scif.inc?

> 
> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Julien Grall <julien.grall@arm.com>
> ---
>   docs/misc/arm/early-printk.txt     |  3 ++-
>   xen/arch/arm/Rules.mk              |  1 +
>   xen/arch/arm/arm32/debug-scifa.inc | 51 ++++++++++++++++++++++++++++++++++++++
>   3 files changed, 54 insertions(+), 1 deletion(-)
>   create mode 100644 xen/arch/arm/arm32/debug-scifa.inc
> 
> diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt
> index f765f59..f1b55d3 100644
> --- a/docs/misc/arm/early-printk.txt
> +++ b/docs/misc/arm/early-printk.txt
> @@ -39,12 +39,13 @@ the name of the machine:
>     - fastmodel: printk on ARM Fastmodel software emulators
>     - hikey960: printk with pl011 with Hikey 960
>     - juno: printk with pl011 on Juno platform
> -  - lager: printk with SCIF0 on Renesas R-Car H2 processors
> +  - lager: printk with SCIF0 on Renesas Lager board (R-Car H2 processor)

Why this change?

>     - midway: printk with the pl011 on Calxeda Midway processors
>     - mvebu: printk with the MVEBU for Marvell Armada 3700 SoCs
>     - omap5432: printk with UART3 on TI OMAP5432 processors
>     - rcar3: printk with SCIF2 on Renesas R-Car Gen3 processors
>     - seattle: printk with pl011 for AMD Seattle processor
> +  - stout: printk with SCIFA0 on Renesas Stout board (R-Car H2 processor)

I have started to look at porting that to Kconfig ealyprintk and it is a 
massive pain. So I would tend to prefer if we avoid adding more 
convenience alias and instead document on the wiki page how to use 
earlyprintk for that.

>     - sun6i: printk with 8250 on Allwinner A31 processors
>     - sun7i: printk with 8250 on Allwinner A20 processors
>     - thunderx: printk with pl011 for Cavium ThunderX processor
> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> index f264592..e011f8b 100644
> --- a/xen/arch/arm/Rules.mk
> +++ b/xen/arch/arm/Rules.mk
> @@ -40,6 +40,7 @@ EARLY_PRINTK_mvebu          := mvebu,0xd0012000
>   EARLY_PRINTK_omap5432       := 8250,0x48020000,2
>   EARLY_PRINTK_rcar3          := scif,0xe6e88000
>   EARLY_PRINTK_seattle        := pl011,0xe1010000
> +EARLY_PRINTK_stout          := scifa,0xe6c40000
>   EARLY_PRINTK_sun6i          := 8250,0x01c28000,2
>   EARLY_PRINTK_sun7i          := 8250,0x01c28000,2
>   EARLY_PRINTK_thunderx       := pl011,0x87e024000000
> diff --git a/xen/arch/arm/arm32/debug-scifa.inc b/xen/arch/arm/arm32/debug-scifa.inc
> new file mode 100644
> index 0000000..b5e60db
> --- /dev/null
> +++ b/xen/arch/arm/arm32/debug-scifa.inc
> @@ -0,0 +1,51 @@
> +/*
> + * xen/arch/arm/arm32/debug-scifa.inc
> + *
> + * SCIFA specific debug code
> + *
> + * Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> + * Copyright (C) 2018 EPAM Systems 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 <asm/scif-uart.h>
> +
> +/*
> + * SCIFA UART wait UART to be ready to transmit
> + * rb: register which contains the UART base address
> + * rc: scratch register
> + */
> +.macro early_uart_ready rb rc
> +1:
> +        ldrh   \rc, [\rb, #SCIFA_SCASSR]   /* <- SCASSR (status register) */
> +        tst    \rc, #SCASSR_TDFE           /* Check TDFE bit */
> +        beq    1b                          /* Wait for the UART to be ready */
> +.endm
> +
> +/*
> + * SCIFA UART transmit character
> + * rb: register which contains the UART base address
> + * rt: register which contains the character to transmit
> + */
> +.macro early_uart_transmit rb rt
> +        strb   \rt, [\rb, #SCIFA_SCAFTDR]                  /* -> SCAFTDR (data register) */
> +        ldrh   \rt, [\rb, #SCIFA_SCASSR]                   /* <- SCASSR (status register) */
> +        and    \rt, \rt, #(~(SCASSR_TEND | SCASSR_TDFE))   /* Clear TEND and TDFE bits */
> +        strh   \rt, [\rb, #SCIFA_SCASSR]                   /* -> SCASSR (status register) */
> +.endm
> +
> +/*
> + * Local variables:
> + * mode: ASM
> + * indent-tabs-mode: nil
> + * End:
> + */
> 

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 3/4] xen/arm: Add SCIFA UART support for early printk

[Oleksandr Tyshchenko]

On Tue, Aug 7, 2018 at 4:48 PM, Julien Grall <julien.grall@arm.com> wrote:
> Hi,

Hi, Julien

>
> On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>
>> Add support for Renesas "Stout" development board based on
>> R-Car H2 SoC which has SCIFA compatible UART.
>>
>> Actually existing SCIF UART support (debug-scif.inc) and
>> newly added SCIFA UART support (debug-scifa.inc) differ only
>> in registers offsets.
>
> In that case, could we just extend debug-scif.inc?
I was thinking about that, but couldn't find suitable solution without
adding extra config option.
As I understand, we need to recognize in run-time somehow which
interface is present to use proper register offsets,
so in UART driver it is easy to recognize using device-tree compatible
string, but what to do here in such an early code.

>
>>
>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>> CC: Stefano Stabellini <sstabellini@kernel.org>
>> CC: Julien Grall <julien.grall@arm.com>
>> ---
>>   docs/misc/arm/early-printk.txt     |  3 ++-
>>   xen/arch/arm/Rules.mk              |  1 +
>>   xen/arch/arm/arm32/debug-scifa.inc | 51
>> ++++++++++++++++++++++++++++++++++++++
>>   3 files changed, 54 insertions(+), 1 deletion(-)
>>   create mode 100644 xen/arch/arm/arm32/debug-scifa.inc
>>
>> diff --git a/docs/misc/arm/early-printk.txt
>> b/docs/misc/arm/early-printk.txt
>> index f765f59..f1b55d3 100644
>> --- a/docs/misc/arm/early-printk.txt
>> +++ b/docs/misc/arm/early-printk.txt
>> @@ -39,12 +39,13 @@ the name of the machine:
>>     - fastmodel: printk on ARM Fastmodel software emulators
>>     - hikey960: printk with pl011 with Hikey 960
>>     - juno: printk with pl011 on Juno platform
>> -  - lager: printk with SCIF0 on Renesas R-Car H2 processors
>> +  - lager: printk with SCIF0 on Renesas Lager board (R-Car H2 processor)
>
>
> Why this change?
This sentence was not entirely correct. Since SCIF0 interface is
applicable for Lager
board, but is not applicable for Stout board which also based on R-Car
H2 processor.
Shall I create a separate patch for this small correction?

>
>>     - midway: printk with the pl011 on Calxeda Midway processors
>>     - mvebu: printk with the MVEBU for Marvell Armada 3700 SoCs
>>     - omap5432: printk with UART3 on TI OMAP5432 processors
>>     - rcar3: printk with SCIF2 on Renesas R-Car Gen3 processors
>>     - seattle: printk with pl011 for AMD Seattle processor
>> +  - stout: printk with SCIFA0 on Renesas Stout board (R-Car H2 processor)
>
>
> I have started to look at porting that to Kconfig ealyprintk and it is a
> massive pain. So I would tend to prefer if we avoid adding more convenience
> alias and instead document on the wiki page how to use earlyprintk for that.
I will update a wiki page. Shall I drop this string in early-printk.txt?

>
>
>>     - sun6i: printk with 8250 on Allwinner A31 processors
>>     - sun7i: printk with 8250 on Allwinner A20 processors
>>     - thunderx: printk with pl011 for Cavium ThunderX processor
>> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
>> index f264592..e011f8b 100644
>> --- a/xen/arch/arm/Rules.mk
>> +++ b/xen/arch/arm/Rules.mk
>> @@ -40,6 +40,7 @@ EARLY_PRINTK_mvebu          := mvebu,0xd0012000
>>   EARLY_PRINTK_omap5432       := 8250,0x48020000,2
>>   EARLY_PRINTK_rcar3          := scif,0xe6e88000
>>   EARLY_PRINTK_seattle        := pl011,0xe1010000
>> +EARLY_PRINTK_stout          := scifa,0xe6c40000
>>   EARLY_PRINTK_sun6i          := 8250,0x01c28000,2
>>   EARLY_PRINTK_sun7i          := 8250,0x01c28000,2
>>   EARLY_PRINTK_thunderx       := pl011,0x87e024000000
>> diff --git a/xen/arch/arm/arm32/debug-scifa.inc
>> b/xen/arch/arm/arm32/debug-scifa.inc
>> new file mode 100644
>> index 0000000..b5e60db
>> --- /dev/null
>> +++ b/xen/arch/arm/arm32/debug-scifa.inc
>> @@ -0,0 +1,51 @@
>> +/*
>> + * xen/arch/arm/arm32/debug-scifa.inc
>> + *
>> + * SCIFA specific debug code
>> + *
>> + * Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>> + * Copyright (C) 2018 EPAM Systems 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 <asm/scif-uart.h>
>> +
>> +/*
>> + * SCIFA UART wait UART to be ready to transmit
>> + * rb: register which contains the UART base address
>> + * rc: scratch register
>> + */
>> +.macro early_uart_ready rb rc
>> +1:
>> +        ldrh   \rc, [\rb, #SCIFA_SCASSR]   /* <- SCASSR (status register)
>> */
>> +        tst    \rc, #SCASSR_TDFE           /* Check TDFE bit */
>> +        beq    1b                          /* Wait for the UART to be
>> ready */
>> +.endm
>> +
>> +/*
>> + * SCIFA UART transmit character
>> + * rb: register which contains the UART base address
>> + * rt: register which contains the character to transmit
>> + */
>> +.macro early_uart_transmit rb rt
>> +        strb   \rt, [\rb, #SCIFA_SCAFTDR]                  /* -> SCAFTDR
>> (data register) */
>> +        ldrh   \rt, [\rb, #SCIFA_SCASSR]                   /* <- SCASSR
>> (status register) */
>> +        and    \rt, \rt, #(~(SCASSR_TEND | SCASSR_TDFE))   /* Clear TEND
>> and TDFE bits */
>> +        strh   \rt, [\rb, #SCIFA_SCASSR]                   /* -> SCASSR
>> (status register) */
>> +.endm
>> +
>> +/*
>> + * Local variables:
>> + * mode: ASM
>> + * indent-tabs-mode: nil
>> + * End:
>> + */
>>
>
> Cheers,
>
> --
> Julien Grall



-- 
Regards,

Oleksandr Tyshchenko

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 3/4] xen/arm: Add SCIFA UART support for early printk

[Julien Grall]

On 07/08/18 15:28, Oleksandr Tyshchenko wrote:
> On Tue, Aug 7, 2018 at 4:48 PM, Julien Grall <julien.grall@arm.com> wrote:
>> Hi,
> 
> Hi, Julien
> 
>>
>> On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
>>>
>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>
>>> Add support for Renesas "Stout" development board based on
>>> R-Car H2 SoC which has SCIFA compatible UART.
>>>
>>> Actually existing SCIF UART support (debug-scif.inc) and
>>> newly added SCIFA UART support (debug-scifa.inc) differ only
>>> in registers offsets.
>>
>> In that case, could we just extend debug-scif.inc?
> I was thinking about that, but couldn't find suitable solution without
> adding extra config option.

I had the config option in my mind. But it may not be worth it.

> As I understand, we need to recognize in run-time somehow which
> interface is present to use proper register offsets,
> so in UART driver it is easy to recognize using device-tree compatible
> string, but what to do here in such an early code.
> 
>>
>>>
>>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>> CC: Stefano Stabellini <sstabellini@kernel.org>
>>> CC: Julien Grall <julien.grall@arm.com>
>>> ---
>>>    docs/misc/arm/early-printk.txt     |  3 ++-
>>>    xen/arch/arm/Rules.mk              |  1 +
>>>    xen/arch/arm/arm32/debug-scifa.inc | 51
>>> ++++++++++++++++++++++++++++++++++++++
>>>    3 files changed, 54 insertions(+), 1 deletion(-)
>>>    create mode 100644 xen/arch/arm/arm32/debug-scifa.inc
>>>
>>> diff --git a/docs/misc/arm/early-printk.txt
>>> b/docs/misc/arm/early-printk.txt
>>> index f765f59..f1b55d3 100644
>>> --- a/docs/misc/arm/early-printk.txt
>>> +++ b/docs/misc/arm/early-printk.txt
>>> @@ -39,12 +39,13 @@ the name of the machine:
>>>      - fastmodel: printk on ARM Fastmodel software emulators
>>>      - hikey960: printk with pl011 with Hikey 960
>>>      - juno: printk with pl011 on Juno platform
>>> -  - lager: printk with SCIF0 on Renesas R-Car H2 processors
>>> +  - lager: printk with SCIF0 on Renesas Lager board (R-Car H2 processor)
>>
>>
>> Why this change?
> This sentence was not entirely correct. Since SCIF0 interface is
> applicable for Lager
> board, but is not applicable for Stout board which also based on R-Car
> H2 processor.
> Shall I create a separate patch for this small correction?

Yes please.

> 
>>
>>>      - midway: printk with the pl011 on Calxeda Midway processors
>>>      - mvebu: printk with the MVEBU for Marvell Armada 3700 SoCs
>>>      - omap5432: printk with UART3 on TI OMAP5432 processors
>>>      - rcar3: printk with SCIF2 on Renesas R-Car Gen3 processors
>>>      - seattle: printk with pl011 for AMD Seattle processor
>>> +  - stout: printk with SCIFA0 on Renesas Stout board (R-Car H2 processor)
>>
>>
>> I have started to look at porting that to Kconfig ealyprintk and it is a
>> massive pain. So I would tend to prefer if we avoid adding more convenience
>> alias and instead document on the wiki page how to use earlyprintk for that.
> I will update a wiki page. Shall I drop this string in early-printk.txt?

Yes please.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 3/4] xen/arm: Add SCIFA UART support for early printk

[Oleksandr Tyshchenko]

On Tue, Aug 7, 2018 at 6:22 PM, Julien Grall <julien.grall@arm.com> wrote:
>
>
> On 07/08/18 15:28, Oleksandr Tyshchenko wrote:
>>
>> On Tue, Aug 7, 2018 at 4:48 PM, Julien Grall <julien.grall@arm.com> wrote:
>>>
>>> Hi,

Hi, Julien

>>
>>
>> Hi, Julien
>>
>>>
>>> On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
>>>>
>>>>
>>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>
>>>> Add support for Renesas "Stout" development board based on
>>>> R-Car H2 SoC which has SCIFA compatible UART.
>>>>
>>>> Actually existing SCIF UART support (debug-scif.inc) and
>>>> newly added SCIFA UART support (debug-scifa.inc) differ only
>>>> in registers offsets.
>>>
>>>
>>> In that case, could we just extend debug-scif.inc?
>>
>> I was thinking about that, but couldn't find suitable solution without
>> adding extra config option.
>
>
> I had the config option in my mind. But it may not be worth it.
So, if you or anyone else don't mind I leave this patch creating
debug-scifa.inc file.

>
>
>> As I understand, we need to recognize in run-time somehow which
>> interface is present to use proper register offsets,
>> so in UART driver it is easy to recognize using device-tree compatible
>> string, but what to do here in such an early code.
>>
>>>
>>>>
>>>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>> CC: Stefano Stabellini <sstabellini@kernel.org>
>>>> CC: Julien Grall <julien.grall@arm.com>
>>>> ---
>>>>    docs/misc/arm/early-printk.txt     |  3 ++-
>>>>    xen/arch/arm/Rules.mk              |  1 +
>>>>    xen/arch/arm/arm32/debug-scifa.inc | 51
>>>> ++++++++++++++++++++++++++++++++++++++
>>>>    3 files changed, 54 insertions(+), 1 deletion(-)
>>>>    create mode 100644 xen/arch/arm/arm32/debug-scifa.inc
>>>>
>>>> diff --git a/docs/misc/arm/early-printk.txt
>>>> b/docs/misc/arm/early-printk.txt
>>>> index f765f59..f1b55d3 100644
>>>> --- a/docs/misc/arm/early-printk.txt
>>>> +++ b/docs/misc/arm/early-printk.txt
>>>> @@ -39,12 +39,13 @@ the name of the machine:
>>>>      - fastmodel: printk on ARM Fastmodel software emulators
>>>>      - hikey960: printk with pl011 with Hikey 960
>>>>      - juno: printk with pl011 on Juno platform
>>>> -  - lager: printk with SCIF0 on Renesas R-Car H2 processors
>>>> +  - lager: printk with SCIF0 on Renesas Lager board (R-Car H2
>>>> processor)
>>>
>>>
>>>
>>> Why this change?
>>
>> This sentence was not entirely correct. Since SCIF0 interface is
>> applicable for Lager
>> board, but is not applicable for Stout board which also based on R-Car
>> H2 processor.
>> Shall I create a separate patch for this small correction?
>
>
> Yes please.
>
>>
>>>
>>>>      - midway: printk with the pl011 on Calxeda Midway processors
>>>>      - mvebu: printk with the MVEBU for Marvell Armada 3700 SoCs
>>>>      - omap5432: printk with UART3 on TI OMAP5432 processors
>>>>      - rcar3: printk with SCIF2 on Renesas R-Car Gen3 processors
>>>>      - seattle: printk with pl011 for AMD Seattle processor
>>>> +  - stout: printk with SCIFA0 on Renesas Stout board (R-Car H2
>>>> processor)
>>>
>>>
>>>
>>> I have started to look at porting that to Kconfig ealyprintk and it is a
>>> massive pain. So I would tend to prefer if we avoid adding more
>>> convenience
>>> alias and instead document on the wiki page how to use earlyprintk for
>>> that.
>>
>> I will update a wiki page. Shall I drop this string in early-printk.txt?
>
>
> Yes please.
>
> Cheers,
>
> --
> Julien Grall



-- 
Regards,

Oleksandr Tyshchenko

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v1 4/4] xen/arm: Reuse R-Car Gen2 platform code for Stout board

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>

Renesas "Stout" development board (with different expansion boards)
is also based on R-Car Gen2 SoC. So extend compat array with
board's compatible strings.

Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien.grall@arm.com>
---
 xen/arch/arm/platforms/rcar2.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/xen/arch/arm/platforms/rcar2.c b/xen/arch/arm/platforms/rcar2.c
index df0ac84..ee2ded0 100644
--- a/xen/arch/arm/platforms/rcar2.c
+++ b/xen/arch/arm/platforms/rcar2.c
@@ -49,6 +49,10 @@ static int __init rcar2_smp_init(void)
 static const char *const rcar2_dt_compat[] __initconst =
 {
     "renesas,lager",
+    "renesas,r8a7790stout",
+    "renesas,r8a7790stout-view",
+    "renesas,r8a7790stout-had",
+    "renesas,r8a7790stout-full",
     NULL
 };
 
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 4/4] xen/arm: Reuse R-Car Gen2 platform code for Stout board

[Julien Grall]

Hi,

On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> 
> Renesas "Stout" development board (with different expansion boards)
> is also based on R-Car Gen2 SoC. So extend compat array with
> board's compatible strings.
> 
> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Julien Grall <julien.grall@arm.com>
> ---
>   xen/arch/arm/platforms/rcar2.c | 4 ++++
>   1 file changed, 4 insertions(+)
> 
> diff --git a/xen/arch/arm/platforms/rcar2.c b/xen/arch/arm/platforms/rcar2.c
> index df0ac84..ee2ded0 100644
> --- a/xen/arch/arm/platforms/rcar2.c
> +++ b/xen/arch/arm/platforms/rcar2.c
> @@ -49,6 +49,10 @@ static int __init rcar2_smp_init(void)
>   static const char *const rcar2_dt_compat[] __initconst =
>   {
>       "renesas,lager",
> +    "renesas,r8a7790stout",
> +    "renesas,r8a7790stout-view",
> +    "renesas,r8a7790stout-had",
> +    "renesas,r8a7790stout-full",

I am quite reluctant to add compatible that are not present in upstream 
Linux. Looking at the DT upstreamed in Linux, the compatible for r8a7790 
SoC seem to be "renesas,r8a7790". Wouldn't it be sufficient to cover all 
the boards? But ...

... don't you have PSCI support on those platforms?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 4/4] xen/arm: Reuse R-Car Gen2 platform code for Stout board

[Oleksandr Tyshchenko]

Hi, Julien

On Tue, Aug 7, 2018 at 6:18 PM, Julien Grall <julien.grall@arm.com> wrote:
> Hi,
>
> On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>
>> Renesas "Stout" development board (with different expansion boards)
>> is also based on R-Car Gen2 SoC. So extend compat array with
>> board's compatible strings.
>>
>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>> CC: Stefano Stabellini <sstabellini@kernel.org>
>> CC: Julien Grall <julien.grall@arm.com>
>> ---
>>   xen/arch/arm/platforms/rcar2.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/xen/arch/arm/platforms/rcar2.c
>> b/xen/arch/arm/platforms/rcar2.c
>> index df0ac84..ee2ded0 100644
>> --- a/xen/arch/arm/platforms/rcar2.c
>> +++ b/xen/arch/arm/platforms/rcar2.c
>> @@ -49,6 +49,10 @@ static int __init rcar2_smp_init(void)
>>   static const char *const rcar2_dt_compat[] __initconst =
>>   {
>>       "renesas,lager",
>> +    "renesas,r8a7790stout",
>> +    "renesas,r8a7790stout-view",
>> +    "renesas,r8a7790stout-had",
>> +    "renesas,r8a7790stout-full",
>
>
> I am quite reluctant to add compatible that are not present in upstream
> Linux. Looking at the DT upstreamed in Linux, the compatible for r8a7790 SoC
> seem to be "renesas,r8a7790". Wouldn't it be sufficient to cover all the
> boards? But ...

This compatible came from official BSP for this board...
https://elinux.org/R-Car/Boards/Yocto#Running

I have just checked "renesas,r8a7790" and you was right, it covers
these modifications. So, I will change.
Moreover, we can just have only single compatible, which will cover (I
hope) all boards based on R-Car H2 SoC, including Lager board
(compatible = "renesas,lager", "renesas,r8a7790")

 static const char *const rcar2_dt_compat[] __initconst =
 {
-    "renesas,lager",
+    "renesas,r8a7790",
     NULL
 };

What do you think?

>
> ... don't you have PSCI support on those platforms?

AFAIK, no.
This code is definitely needed for Stout board as well, since the SoC
is the same (R-Car Gen2).

>
> Cheers,
>
> --
> Julien Grall


-- 
Regards,

Oleksandr Tyshchenko

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 4/4] xen/arm: Reuse R-Car Gen2 platform code for Stout board

[Julien Grall]

On 07/08/18 18:12, Oleksandr Tyshchenko wrote:
> Hi, Julien

Hi Oleksandr,

> 
> On Tue, Aug 7, 2018 at 6:18 PM, Julien Grall <julien.grall@arm.com> wrote:
>> Hi,
>>
>> On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
>>>
>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>
>>> Renesas "Stout" development board (with different expansion boards)
>>> is also based on R-Car Gen2 SoC. So extend compat array with
>>> board's compatible strings.
>>>
>>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>> CC: Stefano Stabellini <sstabellini@kernel.org>
>>> CC: Julien Grall <julien.grall@arm.com>
>>> ---
>>>    xen/arch/arm/platforms/rcar2.c | 4 ++++
>>>    1 file changed, 4 insertions(+)
>>>
>>> diff --git a/xen/arch/arm/platforms/rcar2.c
>>> b/xen/arch/arm/platforms/rcar2.c
>>> index df0ac84..ee2ded0 100644
>>> --- a/xen/arch/arm/platforms/rcar2.c
>>> +++ b/xen/arch/arm/platforms/rcar2.c
>>> @@ -49,6 +49,10 @@ static int __init rcar2_smp_init(void)
>>>    static const char *const rcar2_dt_compat[] __initconst =
>>>    {
>>>        "renesas,lager",
>>> +    "renesas,r8a7790stout",
>>> +    "renesas,r8a7790stout-view",
>>> +    "renesas,r8a7790stout-had",
>>> +    "renesas,r8a7790stout-full",
>>
>>
>> I am quite reluctant to add compatible that are not present in upstream
>> Linux. Looking at the DT upstreamed in Linux, the compatible for r8a7790 SoC
>> seem to be "renesas,r8a7790". Wouldn't it be sufficient to cover all the
>> boards? But ...
> 
> This compatible came from official BSP for this board...
> https://elinux.org/R-Car/Boards/Yocto#Running
> 
> I have just checked "renesas,r8a7790" and you was right, it covers
> these modifications. So, I will change.
> Moreover, we can just have only single compatible, which will cover (I
> hope) all boards based on R-Car H2 SoC, including Lager board
> (compatible = "renesas,lager", "renesas,r8a7790")
> 
>   static const char *const rcar2_dt_compat[] __initconst =
>   {
> -    "renesas,lager",
> +    "renesas,r8a7790",
>       NULL
>   };
> 
> What do you think?

That would be the best.

> 
>>
>> ... don't you have PSCI support on those platforms?
> 
> AFAIK, no.
> This code is definitely needed for Stout board as well, since the SoC
> is the same (R-Car Gen2).

When I looked at the device-tree upstreamed for R-Car Gen2 (I think 
r8a7790), PSCI is supported. So I am a bit surprised that the Stout (or 
even lager) does not support it. Are you sure you are not using an old 
firmware?

If not, can you please point me to the code in Linux (upstream or BSP) 
doing the SMP bring-up for the R-Car?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 4/4] xen/arm: Reuse R-Car Gen2 platform code for Stout board

[Oleksandr Tyshchenko]

On Tue, Aug 7, 2018 at 8:21 PM, Julien Grall <julien.grall@arm.com> wrote:
> On 07/08/18 18:12, Oleksandr Tyshchenko wrote:
>>
>> Hi, Julien
>
>
> Hi Oleksandr,
Hi Julien

>
>
>>
>> On Tue, Aug 7, 2018 at 6:18 PM, Julien Grall <julien.grall@arm.com> wrote:
>>>
>>> Hi,
>>>
>>> On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
>>>>
>>>>
>>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>
>>>> Renesas "Stout" development board (with different expansion boards)
>>>> is also based on R-Car Gen2 SoC. So extend compat array with
>>>> board's compatible strings.
>>>>
>>>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>> CC: Stefano Stabellini <sstabellini@kernel.org>
>>>> CC: Julien Grall <julien.grall@arm.com>
>>>> ---
>>>>    xen/arch/arm/platforms/rcar2.c | 4 ++++
>>>>    1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/xen/arch/arm/platforms/rcar2.c
>>>> b/xen/arch/arm/platforms/rcar2.c
>>>> index df0ac84..ee2ded0 100644
>>>> --- a/xen/arch/arm/platforms/rcar2.c
>>>> +++ b/xen/arch/arm/platforms/rcar2.c
>>>> @@ -49,6 +49,10 @@ static int __init rcar2_smp_init(void)
>>>>    static const char *const rcar2_dt_compat[] __initconst =
>>>>    {
>>>>        "renesas,lager",
>>>> +    "renesas,r8a7790stout",
>>>> +    "renesas,r8a7790stout-view",
>>>> +    "renesas,r8a7790stout-had",
>>>> +    "renesas,r8a7790stout-full",
>>>
>>>
>>>
>>> I am quite reluctant to add compatible that are not present in upstream
>>> Linux. Looking at the DT upstreamed in Linux, the compatible for r8a7790
>>> SoC
>>> seem to be "renesas,r8a7790". Wouldn't it be sufficient to cover all the
>>> boards? But ...
>>
>>
>> This compatible came from official BSP for this board...
>> https://elinux.org/R-Car/Boards/Yocto#Running
>>
>> I have just checked "renesas,r8a7790" and you was right, it covers
>> these modifications. So, I will change.
>> Moreover, we can just have only single compatible, which will cover (I
>> hope) all boards based on R-Car H2 SoC, including Lager board
>> (compatible = "renesas,lager", "renesas,r8a7790")
>>
>>   static const char *const rcar2_dt_compat[] __initconst =
>>   {
>> -    "renesas,lager",
>> +    "renesas,r8a7790",
>>       NULL
>>   };
>>
>> What do you think?
>
>
> That would be the best.
>
>>
>>>
>>> ... don't you have PSCI support on those platforms?
>>
>>
>> AFAIK, no.
>> This code is definitely needed for Stout board as well, since the SoC
>> is the same (R-Car Gen2).
>
>
> When I looked at the device-tree upstreamed for R-Car Gen2 (I think
> r8a7790), PSCI is supported. So I am a bit surprised that the Stout (or even
> lager) does not support it. Are you sure you are not using an old firmware?

This is the topic I am not quite familiar with, so may mistake...

Yes, the BSP I use is quite old, but I managed to run it on top of Xen...
Just to clarify, saying firmware you mean something running in Secure
World, like ARM TF, for example
and providing PSCI services? If yes, the BSP for R-Car Gen2 seems
doesn't contain it. Only U-Boot is available.
But U-Boot was modified to be able to switch A15 cores to HYP mode.
Here [1] you can see how it was done for Lager board,
something similar I did for Stout board.

So, in a nutshell, SMP bring-up under Xen is done in following way:
- U-Boot switches all cores to HYP mode and jumps to Xen on a boot
core, while non-boot cores are waiting in U-Boot.
- Platform SMP init code (rcar2.c) brings each non-boot core to Xen.

>
> If not, can you please point me to the code in Linux (upstream or BSP) doing
> the SMP bring-up for the R-Car?

BSP is based on + additional patches in Yocto layers:
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-backport.git/tree/arch/arm/boot/dts/r8a7790.dtsi?h=bsp/v3.10.31-ltsi/rcar-gen2-1.9.8
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-backport.git/tree/arch/arm/mach-shmobile/platsmp-apmu.c?h=bsp/v3.10.31-ltsi/rcar-gen2-1.9.8

Upstream code:
https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/r8a7790.dtsi
https://github.com/torvalds/linux/blob/master/arch/arm/mach-shmobile/platsmp-apmu.c

Could you point me a link to device-tree where PSCI is supported?

[1] https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Lager

>
> Cheers,
>
> --
> Julien Grall



-- 
Regards,

Oleksandr Tyshchenko

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 4/4] xen/arm: Reuse R-Car Gen2 platform code for Stout board

[Julien Grall]

Hi Oleksandr,

On 08/07/2018 08:13 PM, Oleksandr Tyshchenko wrote:
> On Tue, Aug 7, 2018 at 8:21 PM, Julien Grall <julien.grall@arm.com> wrote:
>> On 07/08/18 18:12, Oleksandr Tyshchenko wrote:
>>>
>>> Hi, Julien
>>
>>
>> Hi Oleksandr,
> Hi Julien
> 
>>
>>
>>>
>>> On Tue, Aug 7, 2018 at 6:18 PM, Julien Grall <julien.grall@arm.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
>>>>>
>>>>>
>>>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>>
>>>>> Renesas "Stout" development board (with different expansion boards)
>>>>> is also based on R-Car Gen2 SoC. So extend compat array with
>>>>> board's compatible strings.
>>>>>
>>>>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>> CC: Stefano Stabellini <sstabellini@kernel.org>
>>>>> CC: Julien Grall <julien.grall@arm.com>
>>>>> ---
>>>>>     xen/arch/arm/platforms/rcar2.c | 4 ++++
>>>>>     1 file changed, 4 insertions(+)
>>>>>
>>>>> diff --git a/xen/arch/arm/platforms/rcar2.c
>>>>> b/xen/arch/arm/platforms/rcar2.c
>>>>> index df0ac84..ee2ded0 100644
>>>>> --- a/xen/arch/arm/platforms/rcar2.c
>>>>> +++ b/xen/arch/arm/platforms/rcar2.c
>>>>> @@ -49,6 +49,10 @@ static int __init rcar2_smp_init(void)
>>>>>     static const char *const rcar2_dt_compat[] __initconst =
>>>>>     {
>>>>>         "renesas,lager",
>>>>> +    "renesas,r8a7790stout",
>>>>> +    "renesas,r8a7790stout-view",
>>>>> +    "renesas,r8a7790stout-had",
>>>>> +    "renesas,r8a7790stout-full",
>>>>
>>>>
>>>>
>>>> I am quite reluctant to add compatible that are not present in upstream
>>>> Linux. Looking at the DT upstreamed in Linux, the compatible for r8a7790
>>>> SoC
>>>> seem to be "renesas,r8a7790". Wouldn't it be sufficient to cover all the
>>>> boards? But ...
>>>
>>>
>>> This compatible came from official BSP for this board...
>>> https://elinux.org/R-Car/Boards/Yocto#Running
>>>
>>> I have just checked "renesas,r8a7790" and you was right, it covers
>>> these modifications. So, I will change.
>>> Moreover, we can just have only single compatible, which will cover (I
>>> hope) all boards based on R-Car H2 SoC, including Lager board
>>> (compatible = "renesas,lager", "renesas,r8a7790")
>>>
>>>    static const char *const rcar2_dt_compat[] __initconst =
>>>    {
>>> -    "renesas,lager",
>>> +    "renesas,r8a7790",
>>>        NULL
>>>    };
>>>
>>> What do you think?
>>
>>
>> That would be the best.
>>
>>>
>>>>
>>>> ... don't you have PSCI support on those platforms?
>>>
>>>
>>> AFAIK, no.
>>> This code is definitely needed for Stout board as well, since the SoC
>>> is the same (R-Car Gen2).
>>
>>
>> When I looked at the device-tree upstreamed for R-Car Gen2 (I think
>> r8a7790), PSCI is supported. So I am a bit surprised that the Stout (or even
>> lager) does not support it. Are you sure you are not using an old firmware?
> 
> This is the topic I am not quite familiar with, so may mistake...
> 
> Yes, the BSP I use is quite old, but I managed to run it on top of Xen...
> Just to clarify, saying firmware you mean something running in Secure
> World, like ARM TF, for example
> and providing PSCI services? If yes, the BSP for R-Car Gen2 seems
> doesn't contain it. Only U-Boot is available.
> But U-Boot was modified to be able to switch A15 cores to HYP mode.
> Here [1] you can see how it was done for Lager board,
> something similar I did for Stout board.
> 
> So, in a nutshell, SMP bring-up under Xen is done in following way:
> - U-Boot switches all cores to HYP mode and jumps to Xen on a boot
> core, while non-boot cores are waiting in U-Boot.
> - Platform SMP init code (rcar2.c) brings each non-boot core to Xen.
> 
>>
>> If not, can you please point me to the code in Linux (upstream or BSP) doing
>> the SMP bring-up for the R-Car?
> 
> BSP is based on + additional patches in Yocto layers:
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-backport.git/tree/arch/arm/boot/dts/r8a7790.dtsi?h=bsp/v3.10.31-ltsi/rcar-gen2-1.9.8
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-backport.git/tree/arch/arm/mach-shmobile/platsmp-apmu.c?h=bsp/v3.10.31-ltsi/rcar-gen2-1.9.8
> 
> Upstream code:
> https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/r8a7790.dtsi
> https://github.com/torvalds/linux/blob/master/arch/arm/mach-shmobile/platsmp-apmu.c
> 
> Could you point me a link to device-tree where PSCI is supported?

Somehow I thought the platform was 64-bit and found a SOC name very 
similar to it. Sorry for the confusion. PSCI seems indeed not supported 
for that platform.

However, the code looks fairly different than what we have in Xen. For 
instance secondary CPU seems to require to initialize CNTVOFF, the 
function to power on a CPU also looks different.

Could you explain why such differences?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 4/4] xen/arm: Reuse R-Car Gen2 platform code for Stout board

[Oleksandr Tyshchenko]

On Thu, Aug 9, 2018 at 7:10 PM, Julien Grall <julien.grall@arm.com> wrote:
> Hi Oleksandr,
Hi Julien.

>
>
> On 08/07/2018 08:13 PM, Oleksandr Tyshchenko wrote:
>>
>> On Tue, Aug 7, 2018 at 8:21 PM, Julien Grall <julien.grall@arm.com> wrote:
>>>
>>> On 07/08/18 18:12, Oleksandr Tyshchenko wrote:
>>>>
>>>>
>>>> Hi, Julien
>>>
>>>
>>>
>>> Hi Oleksandr,
>>
>> Hi Julien
>>
>>>
>>>
>>>>
>>>> On Tue, Aug 7, 2018 at 6:18 PM, Julien Grall <julien.grall@arm.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>>>
>>>>>> Renesas "Stout" development board (with different expansion boards)
>>>>>> is also based on R-Car Gen2 SoC. So extend compat array with
>>>>>> board's compatible strings.
>>>>>>
>>>>>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>>> CC: Stefano Stabellini <sstabellini@kernel.org>
>>>>>> CC: Julien Grall <julien.grall@arm.com>
>>>>>> ---
>>>>>>     xen/arch/arm/platforms/rcar2.c | 4 ++++
>>>>>>     1 file changed, 4 insertions(+)
>>>>>>
>>>>>> diff --git a/xen/arch/arm/platforms/rcar2.c
>>>>>> b/xen/arch/arm/platforms/rcar2.c
>>>>>> index df0ac84..ee2ded0 100644
>>>>>> --- a/xen/arch/arm/platforms/rcar2.c
>>>>>> +++ b/xen/arch/arm/platforms/rcar2.c
>>>>>> @@ -49,6 +49,10 @@ static int __init rcar2_smp_init(void)
>>>>>>     static const char *const rcar2_dt_compat[] __initconst =
>>>>>>     {
>>>>>>         "renesas,lager",
>>>>>> +    "renesas,r8a7790stout",
>>>>>> +    "renesas,r8a7790stout-view",
>>>>>> +    "renesas,r8a7790stout-had",
>>>>>> +    "renesas,r8a7790stout-full",
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I am quite reluctant to add compatible that are not present in upstream
>>>>> Linux. Looking at the DT upstreamed in Linux, the compatible for
>>>>> r8a7790
>>>>> SoC
>>>>> seem to be "renesas,r8a7790". Wouldn't it be sufficient to cover all
>>>>> the
>>>>> boards? But ...
>>>>
>>>>
>>>>
>>>> This compatible came from official BSP for this board...
>>>> https://elinux.org/R-Car/Boards/Yocto#Running
>>>>
>>>> I have just checked "renesas,r8a7790" and you was right, it covers
>>>> these modifications. So, I will change.
>>>> Moreover, we can just have only single compatible, which will cover (I
>>>> hope) all boards based on R-Car H2 SoC, including Lager board
>>>> (compatible = "renesas,lager", "renesas,r8a7790")
>>>>
>>>>    static const char *const rcar2_dt_compat[] __initconst =
>>>>    {
>>>> -    "renesas,lager",
>>>> +    "renesas,r8a7790",
>>>>        NULL
>>>>    };
>>>>
>>>> What do you think?
>>>
>>>
>>>
>>> That would be the best.
>>>
>>>>
>>>>>
>>>>> ... don't you have PSCI support on those platforms?
>>>>
>>>>
>>>>
>>>> AFAIK, no.
>>>> This code is definitely needed for Stout board as well, since the SoC
>>>> is the same (R-Car Gen2).
>>>
>>>
>>>
>>> When I looked at the device-tree upstreamed for R-Car Gen2 (I think
>>> r8a7790), PSCI is supported. So I am a bit surprised that the Stout (or
>>> even
>>> lager) does not support it. Are you sure you are not using an old
>>> firmware?
>>
>>
>> This is the topic I am not quite familiar with, so may mistake...
>>
>> Yes, the BSP I use is quite old, but I managed to run it on top of Xen...
>> Just to clarify, saying firmware you mean something running in Secure
>> World, like ARM TF, for example
>> and providing PSCI services? If yes, the BSP for R-Car Gen2 seems
>> doesn't contain it. Only U-Boot is available.
>> But U-Boot was modified to be able to switch A15 cores to HYP mode.
>> Here [1] you can see how it was done for Lager board,
>> something similar I did for Stout board.
>>
>> So, in a nutshell, SMP bring-up under Xen is done in following way:
>> - U-Boot switches all cores to HYP mode and jumps to Xen on a boot
>> core, while non-boot cores are waiting in U-Boot.
>> - Platform SMP init code (rcar2.c) brings each non-boot core to Xen.
>>
>>>
>>> If not, can you please point me to the code in Linux (upstream or BSP)
>>> doing
>>> the SMP bring-up for the R-Car?
>>
>>
>> BSP is based on + additional patches in Yocto layers:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-backport.git/tree/arch/arm/boot/dts/r8a7790.dtsi?h=bsp/v3.10.31-ltsi/rcar-gen2-1.9.8
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-backport.git/tree/arch/arm/mach-shmobile/platsmp-apmu.c?h=bsp/v3.10.31-ltsi/rcar-gen2-1.9.8
>>
>> Upstream code:
>>
>> https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/r8a7790.dtsi
>>
>> https://github.com/torvalds/linux/blob/master/arch/arm/mach-shmobile/platsmp-apmu.c
>>
>> Could you point me a link to device-tree where PSCI is supported?
>
>
> Somehow I thought the platform was 64-bit and found a SOC name very similar
> to it. Sorry for the confusion. PSCI seems indeed not supported for that
> platform.
R-Car Gen3 is ARM64 (H2 SoC -> r8a7790) and does support PSCI.
But R-Car Gen2 is ARM32 (H2 SoC -> r8a7790)

>
> However, the code looks fairly different than what we have in Xen. For
> instance secondary CPU seems to require to initialize CNTVOFF, the function
> to power on a CPU also looks different.
Sorry, which code you are taking about, U-Boot or Linux?

>
> Could you explain why such differences?
>
> Cheers,
>
> --
> Julien Grall



-- 
Regards,

Oleksandr Tyshchenko

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 4/4] xen/arm: Reuse R-Car Gen2 platform code for Stout board

[Oleksandr Tyshchenko]

On Thu, Aug 9, 2018 at 7:18 PM, Oleksandr Tyshchenko
<olekstysh@gmail.com> wrote:
> On Thu, Aug 9, 2018 at 7:10 PM, Julien Grall <julien.grall@arm.com> wrote:
>> Hi Oleksandr,
> Hi Julien.
Hi.

>
>>
>>
>> On 08/07/2018 08:13 PM, Oleksandr Tyshchenko wrote:
>>>
>>> On Tue, Aug 7, 2018 at 8:21 PM, Julien Grall <julien.grall@arm.com> wrote:
>>>>
>>>> On 07/08/18 18:12, Oleksandr Tyshchenko wrote:
>>>>>
>>>>>
>>>>> Hi, Julien
>>>>
>>>>
>>>>
>>>> Hi Oleksandr,
>>>
>>> Hi Julien
>>>
>>>>
>>>>
>>>>>
>>>>> On Tue, Aug 7, 2018 at 6:18 PM, Julien Grall <julien.grall@arm.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>>>>
>>>>>>> Renesas "Stout" development board (with different expansion boards)
>>>>>>> is also based on R-Car Gen2 SoC. So extend compat array with
>>>>>>> board's compatible strings.
>>>>>>>
>>>>>>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>>>> CC: Stefano Stabellini <sstabellini@kernel.org>
>>>>>>> CC: Julien Grall <julien.grall@arm.com>
>>>>>>> ---
>>>>>>>     xen/arch/arm/platforms/rcar2.c | 4 ++++
>>>>>>>     1 file changed, 4 insertions(+)
>>>>>>>
>>>>>>> diff --git a/xen/arch/arm/platforms/rcar2.c
>>>>>>> b/xen/arch/arm/platforms/rcar2.c
>>>>>>> index df0ac84..ee2ded0 100644
>>>>>>> --- a/xen/arch/arm/platforms/rcar2.c
>>>>>>> +++ b/xen/arch/arm/platforms/rcar2.c
>>>>>>> @@ -49,6 +49,10 @@ static int __init rcar2_smp_init(void)
>>>>>>>     static const char *const rcar2_dt_compat[] __initconst =
>>>>>>>     {
>>>>>>>         "renesas,lager",
>>>>>>> +    "renesas,r8a7790stout",
>>>>>>> +    "renesas,r8a7790stout-view",
>>>>>>> +    "renesas,r8a7790stout-had",
>>>>>>> +    "renesas,r8a7790stout-full",
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I am quite reluctant to add compatible that are not present in upstream
>>>>>> Linux. Looking at the DT upstreamed in Linux, the compatible for
>>>>>> r8a7790
>>>>>> SoC
>>>>>> seem to be "renesas,r8a7790". Wouldn't it be sufficient to cover all
>>>>>> the
>>>>>> boards? But ...
>>>>>
>>>>>
>>>>>
>>>>> This compatible came from official BSP for this board...
>>>>> https://elinux.org/R-Car/Boards/Yocto#Running
>>>>>
>>>>> I have just checked "renesas,r8a7790" and you was right, it covers
>>>>> these modifications. So, I will change.
>>>>> Moreover, we can just have only single compatible, which will cover (I
>>>>> hope) all boards based on R-Car H2 SoC, including Lager board
>>>>> (compatible = "renesas,lager", "renesas,r8a7790")
>>>>>
>>>>>    static const char *const rcar2_dt_compat[] __initconst =
>>>>>    {
>>>>> -    "renesas,lager",
>>>>> +    "renesas,r8a7790",
>>>>>        NULL
>>>>>    };
>>>>>
>>>>> What do you think?
>>>>
>>>>
>>>>
>>>> That would be the best.
>>>>
>>>>>
>>>>>>
>>>>>> ... don't you have PSCI support on those platforms?
>>>>>
>>>>>
>>>>>
>>>>> AFAIK, no.
>>>>> This code is definitely needed for Stout board as well, since the SoC
>>>>> is the same (R-Car Gen2).
>>>>
>>>>
>>>>
>>>> When I looked at the device-tree upstreamed for R-Car Gen2 (I think
>>>> r8a7790), PSCI is supported. So I am a bit surprised that the Stout (or
>>>> even
>>>> lager) does not support it. Are you sure you are not using an old
>>>> firmware?
>>>
>>>
>>> This is the topic I am not quite familiar with, so may mistake...
>>>
>>> Yes, the BSP I use is quite old, but I managed to run it on top of Xen...
>>> Just to clarify, saying firmware you mean something running in Secure
>>> World, like ARM TF, for example
>>> and providing PSCI services? If yes, the BSP for R-Car Gen2 seems
>>> doesn't contain it. Only U-Boot is available.
>>> But U-Boot was modified to be able to switch A15 cores to HYP mode.
>>> Here [1] you can see how it was done for Lager board,
>>> something similar I did for Stout board.
>>>
>>> So, in a nutshell, SMP bring-up under Xen is done in following way:
>>> - U-Boot switches all cores to HYP mode and jumps to Xen on a boot
>>> core, while non-boot cores are waiting in U-Boot.
>>> - Platform SMP init code (rcar2.c) brings each non-boot core to Xen.
>>>
>>>>
>>>> If not, can you please point me to the code in Linux (upstream or BSP)
>>>> doing
>>>> the SMP bring-up for the R-Car?
>>>
>>>
>>> BSP is based on + additional patches in Yocto layers:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-backport.git/tree/arch/arm/boot/dts/r8a7790.dtsi?h=bsp/v3.10.31-ltsi/rcar-gen2-1.9.8
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-backport.git/tree/arch/arm/mach-shmobile/platsmp-apmu.c?h=bsp/v3.10.31-ltsi/rcar-gen2-1.9.8
>>>
>>> Upstream code:
>>>
>>> https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/r8a7790.dtsi
>>>
>>> https://github.com/torvalds/linux/blob/master/arch/arm/mach-shmobile/platsmp-apmu.c
>>>
>>> Could you point me a link to device-tree where PSCI is supported?
>>
>>
>> Somehow I thought the platform was 64-bit and found a SOC name very similar
>> to it. Sorry for the confusion. PSCI seems indeed not supported for that
>> platform.
> R-Car Gen3 is ARM64 (H2 SoC -> r8a7790) and does support PSCI.
Sorry for the typo, should be:
R-Car Gen3 is ARM64 (H3 SoC -> r8a7795) and does support PSCI.

> But R-Car Gen2 is ARM32 (H2 SoC -> r8a7790)
>
>>
>> However, the code looks fairly different than what we have in Xen. For
>> instance secondary CPU seems to require to initialize CNTVOFF, the function
>> to power on a CPU also looks different.
> Sorry, which code you are taking about, U-Boot or Linux?
>
>>
>> Could you explain why such differences?
>>
>> Cheers,
>>
>> --
>> Julien Grall
>
>
>
> --
> Regards,
>
> Oleksandr Tyshchenko



-- 
Regards,

Oleksandr Tyshchenko

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 4/4] xen/arm: Reuse R-Car Gen2 platform code for Stout board

[Julien Grall]

On 08/09/2018 05:18 PM, Oleksandr Tyshchenko wrote:
> On Thu, Aug 9, 2018 at 7:10 PM, Julien Grall <julien.grall@arm.com> wrote:
>> Somehow I thought the platform was 64-bit and found a SOC name very similar
>> to it. Sorry for the confusion. PSCI seems indeed not supported for that
>> platform.
> R-Car Gen3 is ARM64 (H2 SoC -> r8a7790) and does support PSCI.
> But R-Car Gen2 is ARM32 (H2 SoC -> r8a7790)
> 
>>
>> However, the code looks fairly different than what we have in Xen. For
>> instance secondary CPU seems to require to initialize CNTVOFF, the function
>> to power on a CPU also looks different.
> Sorry, which code you are taking about, U-Boot or Linux?

The SMP code in Linux vs the SMP code in Xen for the R-Car. In most of 
the cases, Xen should replicate what Linux does.

I am trying to understand why such differences at the moment.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 4/4] xen/arm: Reuse R-Car Gen2 platform code for Stout board

[Oleksandr Tyshchenko]

Hi Julien.

On Thu, Aug 9, 2018 at 7:20 PM, Julien Grall <julien.grall@arm.com> wrote:
>
>
> On 08/09/2018 05:18 PM, Oleksandr Tyshchenko wrote:
>>
>> On Thu, Aug 9, 2018 at 7:10 PM, Julien Grall <julien.grall@arm.com> wrote:
>>>
>>> Somehow I thought the platform was 64-bit and found a SOC name very
>>> similar
>>> to it. Sorry for the confusion. PSCI seems indeed not supported for that
>>> platform.
>>
>> R-Car Gen3 is ARM64 (H2 SoC -> r8a7790) and does support PSCI.
>> But R-Car Gen2 is ARM32 (H2 SoC -> r8a7790)
>>
>>>
>>> However, the code looks fairly different than what we have in Xen. For
>>> instance secondary CPU seems to require to initialize CNTVOFF, the
>>> function
>>> to power on a CPU also looks different.
>>
>> Sorry, which code you are taking about, U-Boot or Linux?
>
>
> The SMP code in Linux vs the SMP code in Xen for the R-Car. In most of the
> cases, Xen should replicate what Linux does.
>
> I am trying to understand why such differences at the moment.

As I understand, the SMP code for Linux can't be used in Xen, since
the requirement is to boot into Xen with cores already being in
Hypervisor mode.
But, all cores seems to start in Monitor mode after powering them up.
So, they must be switched into Hypervisor mode beforehand, correct?

U-Boot brings non-boot cores up (using ported from Linux's
platsmp-apmu code functions). Then U-Boot switches all cores to HYP
mode.
While jump into Xen on a boot core, all non-boot cores are left in
U-Boot to wait to be "woken up by Xen" (actually rcar2_smp_init() is
used for).
Platform R-Car2 code in Xen doesn't power on cores, it just "brings
them to Xen".

Please correct me if I am wrong.

Also, U-Boot seems to reset to zero CNTVOFF on all cores before
leaving Monitor mode.

>
> Cheers,
>
> --
> Julien Grall



-- 
Regards,

Oleksandr Tyshchenko

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 4/4] xen/arm: Reuse R-Car Gen2 platform code for Stout board

[Julien Grall]

On 08/09/2018 07:18 PM, Oleksandr Tyshchenko wrote:
> Hi Julien.

Hi Oleksandr,

> On Thu, Aug 9, 2018 at 7:20 PM, Julien Grall <julien.grall@arm.com> wrote:
>>
>>
>> On 08/09/2018 05:18 PM, Oleksandr Tyshchenko wrote:
>>>
>>> On Thu, Aug 9, 2018 at 7:10 PM, Julien Grall <julien.grall@arm.com> wrote:
>>>>
>>>> Somehow I thought the platform was 64-bit and found a SOC name very
>>>> similar
>>>> to it. Sorry for the confusion. PSCI seems indeed not supported for that
>>>> platform.
>>>
>>> R-Car Gen3 is ARM64 (H2 SoC -> r8a7790) and does support PSCI.
>>> But R-Car Gen2 is ARM32 (H2 SoC -> r8a7790)
>>>
>>>>
>>>> However, the code looks fairly different than what we have in Xen. For
>>>> instance secondary CPU seems to require to initialize CNTVOFF, the
>>>> function
>>>> to power on a CPU also looks different.
>>>
>>> Sorry, which code you are taking about, U-Boot or Linux?
>>
>>
>> The SMP code in Linux vs the SMP code in Xen for the R-Car. In most of the
>> cases, Xen should replicate what Linux does.
>>
>> I am trying to understand why such differences at the moment.
> 
> As I understand, the SMP code for Linux can't be used in Xen, since
> the requirement is to boot into Xen with cores already being in
> Hypervisor mode.
> But, all cores seems to start in Monitor mode after powering them up.
> So, they must be switched into Hypervisor mode beforehand, correct?

I am quite confused here. If a CPU will be in hypervisor mode for Xen, 
how come the same CPU will boot in monitor mode for Linux? Surely there 
should be no difference in term of boot here. Are you using different 
firmware here?

> 
> U-Boot brings non-boot cores up (using ported from Linux's
> platsmp-apmu code functions). Then U-Boot switches all cores to HYP
> mode.

Who did the port? Is it upstream?

> While jump into Xen on a boot core, all non-boot cores are left in
> U-Boot to wait to be "woken up by Xen" (actually rcar2_smp_init() is
> used for).
> Platform R-Car2 code in Xen doesn't power on cores, it just "brings
> them to Xen".

What does the address 0xe63c0000 corresponds too? From the DT it seems 
it is part of the ICRAM. But it is not clear why you write in there.

Could you point to any relevant documentation?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 4/4] xen/arm: Reuse R-Car Gen2 platform code for Stout board

[Oleksandr Tyshchenko]

On Fri, Aug 10, 2018 at 12:44 PM, Julien Grall <julien.grall@arm.com> wrote:
> On 08/09/2018 07:18 PM, Oleksandr Tyshchenko wrote:
>>
>> Hi Julien.
>
>
> Hi Oleksandr,
Hi Julien

>
>> On Thu, Aug 9, 2018 at 7:20 PM, Julien Grall <julien.grall@arm.com> wrote:
>>>
>>>
>>>
>>> On 08/09/2018 05:18 PM, Oleksandr Tyshchenko wrote:
>>>>
>>>>
>>>> On Thu, Aug 9, 2018 at 7:10 PM, Julien Grall <julien.grall@arm.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> Somehow I thought the platform was 64-bit and found a SOC name very
>>>>> similar
>>>>> to it. Sorry for the confusion. PSCI seems indeed not supported for
>>>>> that
>>>>> platform.
>>>>
>>>>
>>>> R-Car Gen3 is ARM64 (H2 SoC -> r8a7790) and does support PSCI.
>>>> But R-Car Gen2 is ARM32 (H2 SoC -> r8a7790)
>>>>
>>>>>
>>>>> However, the code looks fairly different than what we have in Xen. For
>>>>> instance secondary CPU seems to require to initialize CNTVOFF, the
>>>>> function
>>>>> to power on a CPU also looks different.
>>>>
>>>>
>>>> Sorry, which code you are taking about, U-Boot or Linux?
>>>
>>>
>>>
>>> The SMP code in Linux vs the SMP code in Xen for the R-Car. In most of
>>> the
>>> cases, Xen should replicate what Linux does.
>>>
>>> I am trying to understand why such differences at the moment.
>>
>>
>> As I understand, the SMP code for Linux can't be used in Xen, since
>> the requirement is to boot into Xen with cores already being in
>> Hypervisor mode.
>> But, all cores seems to start in Monitor mode after powering them up.
>> So, they must be switched into Hypervisor mode beforehand, correct?
>
>
> I am quite confused here. If a CPU will be in hypervisor mode for Xen, how
> come the same CPU will boot in monitor mode for Linux? Surely there should
> be no difference in term of boot here. Are you using different firmware
> here?

Yes, in order to run modified U-Boot is used. You can see here what
exactly was modified.
This instruction [1] contains link to patches [2] (see "Apply
additional patches" step)
which should be applied to bare U-Boot.

[1] https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Lager
[2] https://lists.xenproject.org/archives/html/xen-devel/2015-01/msg02475.html

>
>>
>> U-Boot brings non-boot cores up (using ported from Linux's
>> platsmp-apmu code functions). Then U-Boot switches all cores to HYP
>> mode.
>
>
> Who did the port? Is it upstream?

AFAIR Iurii Konovalenko did this port, he is also an author of
xen/arch/arm/platforms/rcar2.c.
I don't think U-Boot changes are upsteamed. But anybody who wants to
run Xen on Lager board is able (I think) to apply
published patches [2] to U-Boot and build it.
The same way anybody who will want to run Xen on Stout board will be able
to apply U-Boot patches I will attach to the future Wiki page for Stout board.

>
>> While jump into Xen on a boot core, all non-boot cores are left in
>> U-Boot to wait to be "woken up by Xen" (actually rcar2_smp_init() is
>> used for).
>> Platform R-Car2 code in Xen doesn't power on cores, it just "brings
>> them to Xen".
>
>
> What does the address 0xe63c0000 corresponds too? From the DT it seems it is
> part of the ICRAM. But it is not clear why you write in there.
Yes, it is a part of the ICRAM.

Unfortunately, I am not an expert in such code to definitively say how
it is supposed to work.
But it seems that 0xE63C0FFC is an address which is being polled by
non-boot core in U-Boot. It was set to zero value
beforehand. So, writing an actual value to this address, Xen triggers
an action for bringing non-boot core up to Xen.

Waiting loop in U-Boot:

asm(".arm \n"
".align 2 \n"
".global smp_waitloop \n"
"smp_waitloop: \n"
"1: wfe \n"
"ldr r0, =0xE63C0FFC \n"
"ldr r0, [r0] \n"
"teq r0, #0x0 \n"
"beq 1b \n"
  "b _do_nonsec_entry \n"
".type smp_waitloop, %function \n"
".size smp_waitloop, .-smp_waitloop \n");

Trigger code in Xen:

writel(__pa(init_secondary), 0xE63C0FFC);

>
> Could you point to any relevant documentation?
I am afraid, I can't point to documentation.

>
> Cheers,
>
> --
> Julien Grall



-- 
Regards,

Oleksandr Tyshchenko

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 4/4] xen/arm: Reuse R-Car Gen2 platform code for Stout board

[Julien Grall]

Hi Oleksandr,

On 08/10/2018 12:47 PM, Oleksandr Tyshchenko wrote:
> On Fri, Aug 10, 2018 at 12:44 PM, Julien Grall <julien.grall@arm.com> wrote:
>> On 08/09/2018 07:18 PM, Oleksandr Tyshchenko wrote:
>>> On Thu, Aug 9, 2018 at 7:20 PM, Julien Grall <julien.grall@arm.com> wrote:
>>>> On 08/09/2018 05:18 PM, Oleksandr Tyshchenko wrote:
>> I am quite confused here. If a CPU will be in hypervisor mode for Xen, how
>> come the same CPU will boot in monitor mode for Linux? Surely there should
>> be no difference in term of boot here. Are you using different firmware
>> here?
> 
> Yes, in order to run modified U-Boot is used. You can see here what
> exactly was modified.
> This instruction [1] contains link to patches [2] (see "Apply
> additional patches" step)
> which should be applied to bare U-Boot.
> 

I don't think it is reasonable to request a specific U-boot just for 
Xen. What if the user decide to run Linux on baremetal? Will he have to 
switch back and forth between firmware?

> [1] https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Lager
> [2] https://lists.xenproject.org/archives/html/xen-devel/2015-01/msg02475.html
> 
>>
>>>
>>> U-Boot brings non-boot cores up (using ported from Linux's
>>> platsmp-apmu code functions). Then U-Boot switches all cores to HYP
>>> mode.
>>
>>
>> Who did the port? Is it upstream?
> 
> AFAIR Iurii Konovalenko did this port, he is also an author of
> xen/arch/arm/platforms/rcar2.c.
> I don't think U-Boot changes are upsteamed. But anybody who wants to
> run Xen on Lager board is able (I think) to apply
> published patches [2] to U-Boot and build it.
> The same way anybody who will want to run Xen on Stout board will be able
> to apply U-Boot patches I will attach to the future Wiki page for Stout board.

I am a bit concerned that patch for lager has never been upstreamed. Is 
it at least part of the Renesas BSP?

What's the plan for Stout support?

>>
>>> While jump into Xen on a boot core, all non-boot cores are left in
>>> U-Boot to wait to be "woken up by Xen" (actually rcar2_smp_init() is
>>> used for).
>>> Platform R-Car2 code in Xen doesn't power on cores, it just "brings
>>> them to Xen".
>>
>>
>> What does the address 0xe63c0000 corresponds too? From the DT it seems it is
>> part of the ICRAM. But it is not clear why you write in there.
> Yes, it is a part of the ICRAM.
> 
> Unfortunately, I am not an expert in such code to definitively say how
> it is supposed to work.
> But it seems that 0xE63C0FFC is an address which is being polled by
> non-boot core in U-Boot. It was set to zero value
> beforehand. So, writing an actual value to this address, Xen triggers
> an action for bringing non-boot core up to Xen.
> 
> Waiting loop in U-Boot:
> 
> asm(".arm \n"
> ".align 2 \n"
> ".global smp_waitloop \n"
> "smp_waitloop: \n"
> "1: wfe \n"
> "ldr r0, =0xE63C0FFC \n"
> "ldr r0, [r0] \n"
> "teq r0, #0x0 \n"
> "beq 1b \n"
>    "b _do_nonsec_entry \n"
> ".type smp_waitloop, %function \n"
> ".size smp_waitloop, .-smp_waitloop \n");
> 
> Trigger code in Xen:
> 
> writel(__pa(init_secondary), 0xE63C0FFC);
> 
>>
>> Could you point to any relevant documentation?
> I am afraid, I can't point to documentation.

While the code was added for Lager and you just piggy-back on it,
if you already hack U-boot to bring-up CPUs in hyp mode, then you better 
add PSCI support.

To be honest, the lager support was likely accepted based on the code 
would make the way to Upstream. It is now been 3 years without any 
change. If there are no plan to address that, then I will send a patch 
to drop the support for Lager in Xen.

Cheers,

-- 
Julien Gral

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 4/4] xen/arm: Reuse R-Car Gen2 platform code for Stout board

[Oleksandr Tyshchenko]

On Fri, Aug 10, 2018 at 3:50 PM, Julien Grall <julien.grall@arm.com> wrote:
> Hi Oleksandr,
Hi Julien.

>
> On 08/10/2018 12:47 PM, Oleksandr Tyshchenko wrote:
>>
>> On Fri, Aug 10, 2018 at 12:44 PM, Julien Grall <julien.grall@arm.com>
>> wrote:
>>>
>>> On 08/09/2018 07:18 PM, Oleksandr Tyshchenko wrote:
>>>>
>>>> On Thu, Aug 9, 2018 at 7:20 PM, Julien Grall <julien.grall@arm.com>
>>>> wrote:
>>>>>
>>>>> On 08/09/2018 05:18 PM, Oleksandr Tyshchenko wrote:
>>>
>>> I am quite confused here. If a CPU will be in hypervisor mode for Xen,
>>> how
>>> come the same CPU will boot in monitor mode for Linux? Surely there
>>> should
>>> be no difference in term of boot here. Are you using different firmware
>>> here?
>>
>>
>> Yes, in order to run modified U-Boot is used. You can see here what
>> exactly was modified.
>> This instruction [1] contains link to patches [2] (see "Apply
>> additional patches" step)
>> which should be applied to bare U-Boot.
>>
>
> I don't think it is reasonable to request a specific U-boot just for Xen.
> What if the user decide to run Linux on baremetal? Will he have to switch
> back and forth between firmware?

Unfortunately, yes. At least for now.

>
>> [1]
>> https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Lager
>> [2]
>> https://lists.xenproject.org/archives/html/xen-devel/2015-01/msg02475.html
>>
>>>
>>>>
>>>> U-Boot brings non-boot cores up (using ported from Linux's
>>>> platsmp-apmu code functions). Then U-Boot switches all cores to HYP
>>>> mode.
>>>
>>>
>>>
>>> Who did the port? Is it upstream?
>>
>>
>> AFAIR Iurii Konovalenko did this port, he is also an author of
>> xen/arch/arm/platforms/rcar2.c.
>> I don't think U-Boot changes are upsteamed. But anybody who wants to
>> run Xen on Lager board is able (I think) to apply
>> published patches [2] to U-Boot and build it.
>> The same way anybody who will want to run Xen on Stout board will be able
>> to apply U-Boot patches I will attach to the future Wiki page for Stout
>> board.
>
>
> I am a bit concerned that patch for lager has never been upstreamed. Is it
> at least part of the Renesas BSP?

U-Boot patches for Lager board for bringing not-boot cores up and
switching into HYP mode have never been up-streamed.
No, Renesas BSP doesn't contain it either.

>
> What's the plan for Stout support?
>
>
>>>
>>>> While jump into Xen on a boot core, all non-boot cores are left in
>>>> U-Boot to wait to be "woken up by Xen" (actually rcar2_smp_init() is
>>>> used for).
>>>> Platform R-Car2 code in Xen doesn't power on cores, it just "brings
>>>> them to Xen".
>>>
>>>
>>>
>>> What does the address 0xe63c0000 corresponds too? From the DT it seems it
>>> is
>>> part of the ICRAM. But it is not clear why you write in there.
>>
>> Yes, it is a part of the ICRAM.
>>
>> Unfortunately, I am not an expert in such code to definitively say how
>> it is supposed to work.
>> But it seems that 0xE63C0FFC is an address which is being polled by
>> non-boot core in U-Boot. It was set to zero value
>> beforehand. So, writing an actual value to this address, Xen triggers
>> an action for bringing non-boot core up to Xen.
>>
>> Waiting loop in U-Boot:
>>
>> asm(".arm \n"
>> ".align 2 \n"
>> ".global smp_waitloop \n"
>> "smp_waitloop: \n"
>> "1: wfe \n"
>> "ldr r0, =0xE63C0FFC \n"
>> "ldr r0, [r0] \n"
>> "teq r0, #0x0 \n"
>> "beq 1b \n"
>>    "b _do_nonsec_entry \n"
>> ".type smp_waitloop, %function \n"
>> ".size smp_waitloop, .-smp_waitloop \n");
>>
>> Trigger code in Xen:
>>
>> writel(__pa(init_secondary), 0xE63C0FFC);
>>
>>>
>>> Could you point to any relevant documentation?
>>
>> I am afraid, I can't point to documentation.
>
>
> While the code was added for Lager and you just piggy-back on it,
> if you already hack U-boot to bring-up CPUs in hyp mode, then you better add
> PSCI support.
>
> To be honest, the lager support was likely accepted based on the code would
> make the way to Upstream. It is now been 3 years without any change. If
> there are no plan to address that, then I will send a patch to drop the
> support for Lager in Xen.

Definitely we would like to address that. I don't now exactly what
direction we will stick to,
either adding PSCI support for Gen2 boards in U-Boot (which will cover
Stout board) or
using some firmware in SW for providing PSCI services (ARM TF for ARM
V7 or even OP-TEE), etc

I think, I will come up with something more concrete after some time...
For this period current patch series is postponed.

>
> Cheers,
>
> --
> Julien Gral

-- 
Regards,

Oleksandr Tyshchenko

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 0/4] Renesas Stout board support (R-Car Gen2)

[Julien Grall]

On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
> Hi, all.

Hi,

Can you CC relevant people on the cover letter? It would save me time to 
dig into my e-mail :).

> 
> The purpose of this patch series is to add required support to be able to run Xen on
> Renesas Stout board [1] which uses SCIFA compatible UART as a console interface.
> 
> Actually Xen already has support for SCIF compatible UARTs which are used on Renesas Lager (R-Car Gen2),
> Salvator-X, H3ULCB/M3ULCB (R-Car Gen3) and other development boards.
> So this patch series extends existing support to be able to handle both interfaces.
> 
> Tested on Stout (ARM32) and H3ULCB (ARM64) boards using current master.
> Have a plan to update Xen Wiki regarding this board.
> 
> You can find current patch series here:
> repo: https://github.com/otyshchenko1/xen.git branch: stout_xen_4.12_unstable
> 
> [1] https://elinux.org/R-Car/Boards/Stout
> 
> Oleksandr Tyshchenko (4):
>    xen/arm: drivers: scif: Remove unused #define-s

I have committed this patch. The rest requires a respin.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 0/4] Renesas Stout board support (R-Car Gen2)

[Oleksandr Tyshchenko]

On Wed, Aug 22, 2018 at 6:48 PM, Julien Grall <julien.grall@arm.com> wrote:
> On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
>>
>> Hi, all.
>
>
> Hi,
Hi, Julien

>
> Can you CC relevant people on the cover letter? It would save me time to dig
> into my e-mail :).
Sure.

>
>>
>> The purpose of this patch series is to add required support to be able to
>> run Xen on
>> Renesas Stout board [1] which uses SCIFA compatible UART as a console
>> interface.
>>
>> Actually Xen already has support for SCIF compatible UARTs which are used
>> on Renesas Lager (R-Car Gen2),
>> Salvator-X, H3ULCB/M3ULCB (R-Car Gen3) and other development boards.
>> So this patch series extends existing support to be able to handle both
>> interfaces.
>>
>> Tested on Stout (ARM32) and H3ULCB (ARM64) boards using current master.
>> Have a plan to update Xen Wiki regarding this board.
>>
>> You can find current patch series here:
>> repo: https://github.com/otyshchenko1/xen.git branch:
>> stout_xen_4.12_unstable
>>
>> [1] https://elinux.org/R-Car/Boards/Stout
>>
>> Oleksandr Tyshchenko (4):
>>    xen/arm: drivers: scif: Remove unused #define-s
>
>
> I have committed this patch. The rest requires a respin.
Thank you.

>
> Cheers,
>
> --
> Julien Grall



-- 
Regards,

Oleksandr Tyshchenko

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel