[PATCH 1/2] drivers/serial: Add driver for Aspeed virtual UART
Joel Stanley
joel at jms.id.au
Sat Jan 30 13:20:58 AEDT 2016
On Fri, Jan 29, 2016 at 3:25 PM, Jeremy Kerr <jk at ozlabs.org> wrote:
> This change adds a driver for the 16550-based Aspeed virtual UART
> device. We use a similar process to the of_serial driver for device
> probe, but expose some VUART-specific functions through sysfs too.
Looks good to go! Some minor comments below.
>
> Signed-off-by: Jeremy Kerr <jk at ozlabs.org>
> ---
> Documentation/devicetree/bindings/serial/8250.txt | 1 +
> drivers/tty/serial/Kconfig | 10 +
> drivers/tty/serial/Makefile | 1 +
> drivers/tty/serial/aspeed-vuart.c | 313 ++++++++++++++++++++++
> 4 files changed, 325 insertions(+)
> create mode 100644 drivers/tty/serial/aspeed-vuart.c
>
> +#define AST_VUART_GCRA 0x20
> +#define AST_VUART_GCRA_VUART_EN 0x1
> +#define AST_VUART_GCRB 0x24
> +#define AST_VUART_GCRB_HOST_SIRQ_MASK 0xf0
> +#define AST_VUART_GCRB_HOST_SIRQ_SHIFT 4
> +#define AST_VUART_ADDRL 0x28
> +#define AST_VUART_ADDRH 0x2c
Many of our other drivers use aspeed_ as the prefix. I do prefer the
shorter ast_, but it's something we should settle on before
upstreaming.
> +
> +struct ast_vuart {
> + struct platform_device *pdev;
> + void __iomem *regs;
I prefer *base, but there's nothing wrong with *regs.
> + struct clk *clk;
> + int line;
> +};
> +
> +
> +static DEVICE_ATTR(sirq, S_IWUSR | S_IRUGO,
> + ast_vuart_show_sirq, ast_vuart_set_sirq);
> +
> +/**
> + * The device tree parsinc code here is heavily based on that of the of_serial
Typo: parsing
> + * driver, but we have a few core differences, as we need to use our own
> + * ioremapping for extra register support
> + */
> +static int ast_vuart_probe(struct platform_device *pdev)
> +{
> + struct uart_8250_port port;
> + struct resource resource;
> + struct ast_vuart *vuart;
> + struct device_node *np;
> + u32 clk, prop;
> + int rc;
> +
> + np = pdev->dev.of_node;
> +
> + vuart = devm_kzalloc(&pdev->dev, sizeof(*vuart), GFP_KERNEL);
> + if (!vuart)
> + return -ENOMEM;
> +
> + vuart->pdev = pdev;
> + rc = of_address_to_resource(np, 0, &resource);
> + if (rc) {
> + dev_warn(&pdev->dev, "invalid address\n");
> + return rc;
> + }
A common pattern instead of these four lines is:
resource = platform_get_resource(pdev, IORESOURCE_MEM, 0);
The upside of this over of_address_to_resource is the of platform code
(drivers/of/platform.c) has already done the parsing of the device
tree for us, so we can use the already populated dev->resource[]
table.
Then devm_ioremap_resource below will do the error checking for us (it
checks that resource is valid and does a dev_err()).
> +
> + /* create our own mapping for VUART-specific registers */
> + vuart->regs = devm_ioremap_resource(&pdev->dev, &resource);
> + if (IS_ERR(vuart->regs)) {
> + dev_warn(&pdev->dev, "failed to map registers\n");
> + return PTR_ERR(vuart->regs);
> + }
> +
> + memset(&port, 0, sizeof(port));
> + port.port.membase = vuart->regs;
> + port.port.mapbase = resource.start;
> + port.port.mapsize = resource_size(&resource);
Could we call the local "uart" or something, so it's not a port.port?
> +
> + if (of_property_read_u32(np, "clock-frequency", &clk)) {
> + vuart->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(vuart->clk)) {
> + dev_warn(&pdev->dev,
> + "clk or clock-frequency not defined\n");
> + return PTR_ERR(vuart->clk);
> + }
> +
> + rc = clk_prepare_enable(vuart->clk);
> + if (rc < 0)
> + return rc;
> +
> + clk = clk_get_rate(vuart->clk);
> + }
We don't warn nor error if clock-frequency is missing from the device
tree. Is that okay?
> +
> + /* If current-speed was set, then try not to change it. */
> + if (of_property_read_u32(np, "current-speed", &prop) == 0)
> + port.port.custom_divisor = clk / (16 * prop);
> +
> + /* Check for shifted address mapping */
> + if (of_property_read_u32(np, "reg-offset", &prop) == 0)
> + port.port.mapbase += prop;
> +
> + /* Check for registers offset within the devices address range */
> + if (of_property_read_u32(np, "reg-shift", &prop) == 0)
> + port.port.regshift = prop;
> +
> + /* Check for fifo size */
> + if (of_property_read_u32(np, "fifo-size", &prop) == 0)
> + port.port.fifosize = prop;
> +
> + /* Check for a fixed line number */
> + rc = of_alias_get_id(np, "serial");
> + if (rc >= 0)
> + port.port.line = rc;
> +
> + port.port.irq = irq_of_parse_and_map(np, 0);
> + port.port.iotype = UPIO_MEM;
> + if (of_property_read_u32(np, "reg-io-width", &prop) == 0) {
> + switch (prop) {
> + case 1:
> + port.port.iotype = UPIO_MEM;
> + break;
> + case 4:
> + port.port.iotype = of_device_is_big_endian(np) ?
> + UPIO_MEM32BE : UPIO_MEM32;
> + break;
> + default:
> + dev_warn(&pdev->dev, "unsupported reg-io-width (%d)\n",
> + prop);
> + rc = -EINVAL;
> + goto err_clk_disable;
> + }
> + }
> +
> + port.port.type = PORT_16550A;
> + port.port.uartclk = clk;
> + port.port.flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF
> + | UPF_FIXED_PORT | UPF_FIXED_TYPE;
> +
> + if (of_find_property(np, "no-loopback-test", NULL))
> + port.port.flags |= UPF_SKIP_TEST;
> +
> + port.port.dev = &pdev->dev;
> +
> + if (port.port.fifosize)
> + port.capabilities = UART_CAP_FIFO;
> +
> + if (of_property_read_bool(pdev->dev.of_node,
> + "auto-flow-control"))
> + port.capabilities |= UART_CAP_AFE;
> +
> + rc = serial8250_register_8250_port(&port);
Could this be:
vuart->line = serial8250_register_8250_port(&port);
if ( vuart->line < 0)
...
So it's clear that the register call is giving us the line number?
> + if (rc < 0)
> + goto err_clk_disable;
> +
> +
Extra whitespace line here.
> + vuart->line = rc;
> + platform_set_drvdata(pdev, vuart);
More information about the openbmc
mailing list