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.
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
