Russell King - ARM Linux wrote:

Well, it looks a bit weird, because we use 16-bit accesses for other
values, and there isn't a UPIO_MEM16 type.

Fair enough, but I don't think it's that weird that the absence of 
UPIO_MEM32 means that we can use non-32-bit accessors.

Although that could be
added, it's extending the scope of the patch to touching core files.

How is it touching core files?  Granted, we might still need access_32b 
in vendor_data, but not for SBSA, since SBSA already has a mechanism to 
determine what 32-bit is needed or not.

Then in pl011_probe(), just have:

	uap->port.iotype = vendor->access_32b ? UPIO_MEM32 : 0;

For sbsa_uart_probe(), we would just the set that field if we detect 
subtype 13 debug port.  That depends on Leif Lindholm's patches: 
https://lkml.org/lkml/2015/9/8/287

This also has the advantage of being able to use the existing "mmio32" 
option to earlycon, as I have in my other patch:

  static void pl011_putc(struct uart_port *port, int c)
  {
	while (readl(port->membase + UART01x_FR) & UART01x_FR_TXFF)
  		;
-	writeb(c, port->membase + REG_DR);
+	if (port->iotype == UPIO_MEM32)
+		writel(c, port->membase + UART01x_DR);
+	else
+		writeb(c, port->membase + UART01x_DR);
	while (readl(port->membase + UART01x_FR) & UART01x_FR_BUSY)
  		;
  }


-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.