[PATCH v4 0/3] Add AMBA bus probing support to ACPI

[PATCH v4 0/3] Add AMBA bus probing support to ACPI

[Aleksey Makarov]

As discussed when Shannon Zhao sent a patch to add platform_device support
to pl061 driver. Russel and other maintainers prefered that ACPI learned
how to create AMBA devices rather than converting/adding platform_device
support to AMBA drivers.

http://comments.gmane.org/gmane.linux.ports.arm.kernel/431364

1) Adds basic AMBA device probing support to ACPI, it uses a whitelist of
device IDs as the number of AMBA devices is limited. Currently the two ids
present are those used in QEMU for arm64.

2) Adds the plumbing into ACPI probe sequence.

3) From ACPI pl011 is only defined (SBSA document) to be in SBSA mode which has
reduced functionality. There may be a better method to do this that I have
overlooked.

v4:
- A memory leak has been fixed (Vladimir Zapolskiy)
- ACPI_COMPANION() -> has_acpi_companion() (Andy Shevchenko)
- pr_err() -> dev_err() (Andy Shevchenko)
- The call to amba_register_dummy_clk() has been moved to to acpi_amba_init()
  (Vladimir Zapolskiy)
- Return value has been fixed (Vladimir Zapolskiy)

v3:
https://lkml.kernel.org/g/1450716100-13688-1-git-send-email-aleksey.makarov@linaro.org
- Compilation without CONFIG_ARM_AMBA has been fixed

v2:
https://lkml.kernel.org/g/1450709399-7246-1-git-send-email-aleksey.makarov@linaro.org
- A new ACPI scan handler for AMBA devices has been implemented
- The order of `if` branches in amba-pl011.c has been changed
- A couple of `static`s have been added
- The compilation of the acpi_amba.c unit has made conditional
- A comment on SBSA UART has been added

v1:
https://lkml.kernel.org/g/1443609530-21524-1-git-send-email-graeme.gregory@linaro.org

Graeme Gregory (3):
  ACPI: amba bus probing support
  ACPI: scan add in amba probing
  serial: amba-pl011: add ACPI support to AMBA probe

 drivers/acpi/Makefile           |   1 +
 drivers/acpi/acpi_amba.c        | 140 ++++++++++++++++++++++++++++++++++++++++
 drivers/acpi/internal.h         |   5 ++
 drivers/acpi/scan.c             |   1 +
 drivers/tty/serial/amba-pl011.c |  37 +++++++----
 5 files changed, 173 insertions(+), 11 deletions(-)
 create mode 100644 drivers/acpi/acpi_amba.c

-- 
2.6.4

[PATCH v4 1/3] ACPI: amba bus probing support

[Aleksey Makarov]

From: Graeme Gregory <graeme.gregory@linaro.org>

On ARM64 some devices use the AMBA device and not the platform bus for
probing so add support for this. Uses a dummy clock for apb_pclk as ACPI
does not have a suitable clock representation and to keep the core
AMBA bus code unchanged between probing methods.

Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
---
 drivers/acpi/Makefile    |   1 +
 drivers/acpi/acpi_amba.c | 140 +++++++++++++++++++++++++++++++++++++++++++++++
 drivers/acpi/internal.h  |   5 ++
 3 files changed, 146 insertions(+)
 create mode 100644 drivers/acpi/acpi_amba.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 675eaf3..3cf732f 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -43,6 +43,7 @@ acpi-y				+= pci_root.o pci_link.o pci_irq.o
 acpi-y				+= acpi_lpss.o acpi_apd.o
 acpi-y				+= acpi_platform.o
 acpi-y				+= acpi_pnp.o
+acpi-$(CONFIG_ARM_AMBA)	+= acpi_amba.o
 acpi-y				+= int340x_thermal.o
 acpi-y				+= power.o
 acpi-y				+= event.o
diff --git a/drivers/acpi/acpi_amba.c b/drivers/acpi/acpi_amba.c
new file mode 100644
index 0000000..4b77d47
--- /dev/null
+++ b/drivers/acpi/acpi_amba.c
@@ -0,0 +1,140 @@
+
+/*
+ * ACPI support for platform bus type.
+ *
+ * Copyright (C) 2015, Linaro Ltd
+ * Authors: Graeme Gregory <graeme.gregory@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/acpi.h>
+#include <linux/amba/bus.h>
+#include <linux/clkdev.h>
+#include <linux/clk-provider.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/ioport.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+
+#include "internal.h"
+
+static const struct acpi_device_id amba_id_list[] = {
+	{"ARMH0011", 0}, /* PL011 SBSA Uart */
+	{"ARMH0061", 0}, /* PL061 GPIO Device */
+	{"", 0},
+};
+
+static struct clk *amba_dummy_clk;
+
+static void amba_register_dummy_clk(void)
+{
+	struct clk *clk;
+
+	/* If clock already registered */
+	if (amba_dummy_clk)
+		return;
+
+	clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL, CLK_IS_ROOT, 0);
+	clk_register_clkdev(clk, "apb_pclk", NULL);
+
+	amba_dummy_clk = clk;
+}
+
+static int amba_handler_attach(struct acpi_device *adev,
+				const struct acpi_device_id *id)
+{
+	struct amba_device *dev = NULL;
+	struct acpi_device *acpi_parent;
+	struct resource_entry *rentry;
+	struct list_head resource_list;
+	bool address_found = false;
+	int ret, irq_no = 0;
+
+	/* If the ACPI node already has a physical device attached, skip it. */
+	if (adev->physical_node_count)
+		return 0;
+
+	dev = amba_device_alloc(NULL, 0, 0);
+	if (!dev) {
+		dev_err(&adev->dev, "%s(): amba_device_alloc() failed\n",
+			__func__);
+		return -ENOMEM;
+	}
+
+	INIT_LIST_HEAD(&resource_list);
+	ret = acpi_dev_get_resources(adev, &resource_list, NULL, NULL);
+	if (ret < 0)
+		goto err_free;
+
+	list_for_each_entry(rentry, &resource_list, node) {
+		switch (resource_type(rentry->res)) {
+		case IORESOURCE_MEM:
+			if (!address_found) {
+				dev->res = *rentry->res;
+				address_found = true;
+			}
+			break;
+		case IORESOURCE_IRQ:
+			if (irq_no < AMBA_NR_IRQS)
+				dev->irq[irq_no++] = rentry->res->start;
+			break;
+		default:
+			dev_warn(&adev->dev, "Invalid resource\n");
+		}
+	}
+
+	acpi_dev_free_resource_list(&resource_list);
+
+	/*
+	 * If the ACPI node has a parent and that parent has a physical device
+	 * attached to it, that physical device should be the parent of the
+	 * platform device we are about to create.
+	 */
+	dev->dev.parent = NULL;
+	acpi_parent = adev->parent;
+	if (acpi_parent) {
+		struct acpi_device_physical_node *entry;
+		struct list_head *list;
+
+		mutex_lock(&acpi_parent->physical_node_lock);
+		list = &acpi_parent->physical_node_list;
+		if (!list_empty(list)) {
+			entry = list_first_entry(list,
+					struct acpi_device_physical_node,
+					node);
+			dev->dev.parent = entry->dev;
+		}
+		mutex_unlock(&acpi_parent->physical_node_lock);
+	}
+
+	dev_set_name(&dev->dev, "%s", dev_name(&adev->dev));
+	ACPI_COMPANION_SET(&dev->dev, adev);
+
+	ret = amba_device_add(dev, &iomem_resource);
+	if (ret) {
+		dev_err(&adev->dev, "%s(): amba_device_add() failed (%d)\n",
+		       __func__, ret);
+		goto err_free;
+	}
+
+	return 1;
+
+err_free:
+	amba_device_put(dev);
+	return ret;
+}
+
+static struct acpi_scan_handler amba_handler = {
+	.ids = amba_id_list,
+	.attach = amba_handler_attach,
+};
+
+void __init acpi_amba_init(void)
+{
+	amba_register_dummy_clk();
+	acpi_scan_add_handler(&amba_handler);
+}
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 11d87bf..9d58f0c 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -29,6 +29,11 @@ void acpi_processor_init(void);
 void acpi_platform_init(void);
 void acpi_pnp_init(void);
 void acpi_int340x_thermal_init(void);
+#ifdef CONFIG_ARM_AMBA
+void acpi_amba_init(void);
+#else
+static inline void acpi_amba_init(void) {}
+#endif
 int acpi_sysfs_init(void);
 void acpi_container_init(void);
 void acpi_memory_hotplug_init(void);
-- 
2.6.4

[PATCH v4 2/3] ACPI: scan add in amba probing

[Aleksey Makarov]

From: Graeme Gregory <graeme.gregory@linaro.org>

Add a new ACPI scan handler for AMBA devices.

Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
---
 drivers/acpi/scan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 78d5f02..20c8cba 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1922,6 +1922,7 @@ int __init acpi_scan_init(void)
 	acpi_memory_hotplug_init();
 	acpi_pnp_init();
 	acpi_int340x_thermal_init();
+	acpi_amba_init();
 
 	acpi_scan_add_handler(&generic_device_handler);
 
-- 
2.6.4

[PATCH v4 3/3] serial: amba-pl011: add ACPI support to AMBA probe

[Aleksey Makarov]

From: Graeme Gregory <graeme.gregory@linaro.org>

In ACPI this device is only defined in SBSA mode so
if we are coming from ACPI use this mode.

Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
---
 drivers/tty/serial/amba-pl011.c | 37 ++++++++++++++++++++++++++-----------
 1 file changed, 26 insertions(+), 11 deletions(-)

diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 899a771..974cb9e 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2368,18 +2368,33 @@ static int pl011_probe(struct amba_device *dev, const struct amba_id *id)
 	if (!uap)
 		return -ENOMEM;
 
-	uap->clk = devm_clk_get(&dev->dev, NULL);
-	if (IS_ERR(uap->clk))
-		return PTR_ERR(uap->clk);
-
-	uap->vendor = vendor;
-	uap->lcrh_rx = vendor->lcrh_rx;
-	uap->lcrh_tx = vendor->lcrh_tx;
-	uap->fifosize = vendor->get_fifosize(dev);
-	uap->port.irq = dev->irq[0];
-	uap->port.ops = &amba_pl011_pops;
+	/* ACPI only defines SBSA variant */
+	if (has_acpi_companion(&dev->dev)) {
+		/*
+		 * According to ARM ARMH0011 is currently the only mapping
+		 * of pl011 in ACPI and it's mapped to SBSA UART mode
+		 */
+		uap->vendor	= &vendor_sbsa;
+		uap->fifosize	= 32;
+		uap->port.ops	= &sbsa_uart_pops;
+		uap->fixed_baud = 115200;
 
-	snprintf(uap->type, sizeof(uap->type), "PL011 rev%u", amba_rev(dev));
+		snprintf(uap->type, sizeof(uap->type), "SBSA");
+	} else {
+		uap->clk = devm_clk_get(&dev->dev, NULL);
+		if (IS_ERR(uap->clk))
+			return PTR_ERR(uap->clk);
+
+		uap->vendor = vendor;
+		uap->lcrh_rx = vendor->lcrh_rx;
+		uap->lcrh_tx = vendor->lcrh_tx;
+		uap->fifosize = vendor->get_fifosize(dev);
+		uap->port.ops = &amba_pl011_pops;
+
+		snprintf(uap->type, sizeof(uap->type), "PL011 rev%u",
+				amba_rev(dev));
+	}
+	uap->port.irq = dev->irq[0];
 
 	ret = pl011_setup_port(&dev->dev, uap, &dev->res, portnr);
 	if (ret)
-- 
2.6.4

Re: [PATCH v4 1/3] ACPI: amba bus probing support

[Andy Shevchenko]

On Wed, Dec 23, 2015 at 4:19 PM, Aleksey Makarov
<aleksey.makarov@linaro.org> wrote:
> From: Graeme Gregory <graeme.gregory@linaro.org>
>
> On ARM64 some devices use the AMBA device and not the platform bus for
> probing so add support for this. Uses a dummy clock for apb_pclk as ACPI
> does not have a suitable clock representation and to keep the core
> AMBA bus code unchanged between probing methods.
>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
> ---
>  drivers/acpi/Makefile    |   1 +
>  drivers/acpi/acpi_amba.c | 140 +++++++++++++++++++++++++++++++++++++++++++++++
>  drivers/acpi/internal.h  |   5 ++
>  3 files changed, 146 insertions(+)
>  create mode 100644 drivers/acpi/acpi_amba.c
>
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 675eaf3..3cf732f 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -43,6 +43,7 @@ acpi-y                                += pci_root.o pci_link.o pci_irq.o
>  acpi-y                         += acpi_lpss.o acpi_apd.o
>  acpi-y                         += acpi_platform.o
>  acpi-y                         += acpi_pnp.o
> +acpi-$(CONFIG_ARM_AMBA)        += acpi_amba.o
>  acpi-y                         += int340x_thermal.o
>  acpi-y                         += power.o
>  acpi-y                         += event.o
> diff --git a/drivers/acpi/acpi_amba.c b/drivers/acpi/acpi_amba.c
> new file mode 100644
> index 0000000..4b77d47
> --- /dev/null
> +++ b/drivers/acpi/acpi_amba.c
> @@ -0,0 +1,140 @@
> +
> +/*
> + * ACPI support for platform bus type.
> + *
> + * Copyright (C) 2015, Linaro Ltd
> + * Authors: Graeme Gregory <graeme.gregory@linaro.org>

Plural form implies more then one author which makes sense after what
you did to the code.

> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/acpi.h>
> +#include <linux/amba/bus.h>
> +#include <linux/clkdev.h>
> +#include <linux/clk-provider.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/ioport.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +
> +#include "internal.h"
> +
> +static const struct acpi_device_id amba_id_list[] = {
> +       {"ARMH0011", 0}, /* PL011 SBSA Uart */
> +       {"ARMH0061", 0}, /* PL061 GPIO Device */
> +       {"", 0},
> +};
> +
> +static struct clk *amba_dummy_clk;

You may move this into the function, it will be still global, but
hidden from the namespace.

> +
> +static void amba_register_dummy_clk(void)
> +{
> +       struct clk *clk;
> +
> +       /* If clock already registered */
> +       if (amba_dummy_clk)
> +               return;
> +
> +       clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL, CLK_IS_ROOT, 0);
> +       clk_register_clkdev(clk, "apb_pclk", NULL);
> +
> +       amba_dummy_clk = clk;
> +}
> +
> +static int amba_handler_attach(struct acpi_device *adev,
> +                               const struct acpi_device_id *id)
> +{
> +       struct amba_device *dev = NULL;

Redundant assignment.

> +       struct acpi_device *acpi_parent;
> +       struct resource_entry *rentry;
> +       struct list_head resource_list;
> +       bool address_found = false;
> +       int ret, irq_no = 0;

Better to split, they are not about the same by meaning.

> +
> +       /* If the ACPI node already has a physical device attached, skip it. */
> +       if (adev->physical_node_count)
> +               return 0;
> +
> +       dev = amba_device_alloc(NULL, 0, 0);
> +       if (!dev) {
> +               dev_err(&adev->dev, "%s(): amba_device_alloc() failed\n",
> +                       __func__);
> +               return -ENOMEM;
> +       }
> +
> +       INIT_LIST_HEAD(&resource_list);
> +       ret = acpi_dev_get_resources(adev, &resource_list, NULL, NULL);
> +       if (ret < 0)
> +               goto err_free;
> +
> +       list_for_each_entry(rentry, &resource_list, node) {
> +               switch (resource_type(rentry->res)) {
> +               case IORESOURCE_MEM:
> +                       if (!address_found) {
> +                               dev->res = *rentry->res;
> +                               address_found = true;
> +                       }
> +                       break;
> +               case IORESOURCE_IRQ:
> +                       if (irq_no < AMBA_NR_IRQS)
> +                               dev->irq[irq_no++] = rentry->res->start;
> +                       break;
> +               default:
> +                       dev_warn(&adev->dev, "Invalid resource\n");

Better to use break here as well.

> +               }
> +       }
> +
> +       acpi_dev_free_resource_list(&resource_list);
> +
> +       /*
> +        * If the ACPI node has a parent and that parent has a physical device
> +        * attached to it, that physical device should be the parent of the
> +        * platform device we are about to create.
> +        */
> +       dev->dev.parent = NULL;
> +       acpi_parent = adev->parent;
> +       if (acpi_parent) {
> +               struct acpi_device_physical_node *entry;
> +               struct list_head *list;
> +
> +               mutex_lock(&acpi_parent->physical_node_lock);
> +               list = &acpi_parent->physical_node_list;
> +               if (!list_empty(list)) {
> +                       entry = list_first_entry(list,
> +                                       struct acpi_device_physical_node,
> +                                       node);

There are couple of users already of the similar.
I would suggest for now to create local helper which we might easily
to move to one of drivers/acpi/ header.

static inline struct acpi_device_physical_node
*to_physical_node(struct acpi_dev *adev)
{
  if (list_empty(adev->physical_node_list))
    return NULL;
  return list_first_entry(adev->physical_node_list, struct
acpi_device_physical_node, node);
}

Rafael, what do you think?

> +                       dev->dev.parent = entry->dev;
> +               }
> +               mutex_unlock(&acpi_parent->physical_node_lock);
> +       }
> +
> +       dev_set_name(&dev->dev, "%s", dev_name(&adev->dev));
> +       ACPI_COMPANION_SET(&dev->dev, adev);
> +
> +       ret = amba_device_add(dev, &iomem_resource);
> +       if (ret) {
> +               dev_err(&adev->dev, "%s(): amba_device_add() failed (%d)\n",
> +                      __func__, ret);
> +               goto err_free;
> +       }
> +

Might be worth to comment out what 1 means here.

> +       return 1;
> +
> +err_free:
> +       amba_device_put(dev);
> +       return ret;
> +}
> +
> +static struct acpi_scan_handler amba_handler = {
> +       .ids = amba_id_list,
> +       .attach = amba_handler_attach,
> +};
> +
> +void __init acpi_amba_init(void)
> +{
> +       amba_register_dummy_clk();
> +       acpi_scan_add_handler(&amba_handler);
> +}
> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> index 11d87bf..9d58f0c 100644
> --- a/drivers/acpi/internal.h
> +++ b/drivers/acpi/internal.h
> @@ -29,6 +29,11 @@ void acpi_processor_init(void);
>  void acpi_platform_init(void);
>  void acpi_pnp_init(void);

>  void acpi_int340x_thermal_init(void);

Hmm… Looks like we need specific header where drivers can put their
stuff and share with other internal ACPI modules.

> +#ifdef CONFIG_ARM_AMBA
> +void acpi_amba_init(void);
> +#else
> +static inline void acpi_amba_init(void) {}
> +#endif

Same.

>  int acpi_sysfs_init(void);
>  void acpi_container_init(void);
>  void acpi_memory_hotplug_init(void);
> --
> 2.6.4
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 0/3] Add AMBA bus probing support to ACPI

[Rafael J. Wysocki]

On Wednesday, December 23, 2015 05:19:39 PM Aleksey Makarov wrote:
> As discussed when Shannon Zhao sent a patch to add platform_device support
> to pl061 driver. Russel and other maintainers prefered that ACPI learned
> how to create AMBA devices rather than converting/adding platform_device
> support to AMBA drivers.
> 
> http://comments.gmane.org/gmane.linux.ports.arm.kernel/431364
> 
> 1) Adds basic AMBA device probing support to ACPI, it uses a whitelist of
> device IDs as the number of AMBA devices is limited. Currently the two ids
> present are those used in QEMU for arm64.
> 
> 2) Adds the plumbing into ACPI probe sequence.
> 
> 3) From ACPI pl011 is only defined (SBSA document) to be in SBSA mode which has
> reduced functionality. There may be a better method to do this that I have
> overlooked.
> 
> v4:
> - A memory leak has been fixed (Vladimir Zapolskiy)
> - ACPI_COMPANION() -> has_acpi_companion() (Andy Shevchenko)
> - pr_err() -> dev_err() (Andy Shevchenko)
> - The call to amba_register_dummy_clk() has been moved to to acpi_amba_init()
>   (Vladimir Zapolskiy)
> - Return value has been fixed (Vladimir Zapolskiy)
> 
> v3:
> https://lkml.kernel.org/g/1450716100-13688-1-git-send-email-aleksey.makarov@linaro.org
> - Compilation without CONFIG_ARM_AMBA has been fixed
> 
> v2:
> https://lkml.kernel.org/g/1450709399-7246-1-git-send-email-aleksey.makarov@linaro.org
> - A new ACPI scan handler for AMBA devices has been implemented
> - The order of `if` branches in amba-pl011.c has been changed
> - A couple of `static`s have been added
> - The compilation of the acpi_amba.c unit has made conditional
> - A comment on SBSA UART has been added
> 
> v1:
> https://lkml.kernel.org/g/1443609530-21524-1-git-send-email-graeme.gregory@linaro.org
> 
> Graeme Gregory (3):
>   ACPI: amba bus probing support
>   ACPI: scan add in amba probing
>   serial: amba-pl011: add ACPI support to AMBA probe

The ACPI part looks OK to me, but I'd really like to know whether or not the
ARM maintainers like this series too.

Thanks,
Rafael

Re: [PATCH v4 1/3] ACPI: amba bus probing support

[Russell King - ARM Linux]

On Wed, Dec 23, 2015 at 05:19:40PM +0300, Aleksey Makarov wrote:
> +	dev = amba_device_alloc(NULL, 0, 0);
> +	if (!dev) {
> +		dev_err(&adev->dev, "%s(): amba_device_alloc() failed\n",
> +			__func__);
> +		return -ENOMEM;
> +	}
...
> +	/*
> +	 * If the ACPI node has a parent and that parent has a physical device
> +	 * attached to it, that physical device should be the parent of the
> +	 * platform device we are about to create.
> +	 */
> +	dev->dev.parent = NULL;

No need to initialise this; amba_device_alloc() uses kzalloc(), and so
dev->dev.parent will already be NULL.

...
> +	dev_set_name(&dev->dev, "%s", dev_name(&adev->dev));

Is there a reason not to use:

	dev = amba_device_alloc(dev_name(&adev->dev), 0, 0);

above?

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v4 3/3] serial: amba-pl011: add ACPI support to AMBA probe

[Timur Tabi]

On Wed, Dec 23, 2015 at 8:19 AM, Aleksey Makarov
<aleksey.makarov@linaro.org> wrote:
> From: Graeme Gregory <graeme.gregory@linaro.org>
>
> In ACPI this device is only defined in SBSA mode so
> if we are coming from ACPI use this mode.
>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
> ---
>  drivers/tty/serial/amba-pl011.c | 37 ++++++++++++++++++++++++++-----------
>  1 file changed, 26 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
> index 899a771..974cb9e 100644
> --- a/drivers/tty/serial/amba-pl011.c
> +++ b/drivers/tty/serial/amba-pl011.c
> @@ -2368,18 +2368,33 @@ static int pl011_probe(struct amba_device *dev, const struct amba_id *id)
>         if (!uap)
>                 return -ENOMEM;
>
> -       uap->clk = devm_clk_get(&dev->dev, NULL);
> -       if (IS_ERR(uap->clk))
> -               return PTR_ERR(uap->clk);
> -
> -       uap->vendor = vendor;
> -       uap->lcrh_rx = vendor->lcrh_rx;
> -       uap->lcrh_tx = vendor->lcrh_tx;
> -       uap->fifosize = vendor->get_fifosize(dev);
> -       uap->port.irq = dev->irq[0];
> -       uap->port.ops = &amba_pl011_pops;
> +       /* ACPI only defines SBSA variant */
> +       if (has_acpi_companion(&dev->dev)) {
> +               /*
> +                * According to ARM ARMH0011 is currently the only mapping
> +                * of pl011 in ACPI and it's mapped to SBSA UART mode
> +                */
> +               uap->vendor     = &vendor_sbsa;
> +               uap->fifosize   = 32;
> +               uap->port.ops   = &sbsa_uart_pops;
> +               uap->fixed_baud = 115200;

I'm confused by this patch.  We already have code like this in
tty-next, in the form of sbsa_uart_probe():

https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/tty/+/tty-next/drivers/tty/serial/amba-pl011.c#2553

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

Re: [PATCH v4 3/3] serial: amba-pl011: add ACPI support to AMBA probe

[G Gregory]

On 4 January 2016 at 23:13, Timur Tabi <timur@codeaurora.org> wrote:
> On Wed, Dec 23, 2015 at 8:19 AM, Aleksey Makarov
> <aleksey.makarov@linaro.org> wrote:
>> From: Graeme Gregory <graeme.gregory@linaro.org>
>>
>> In ACPI this device is only defined in SBSA mode so
>> if we are coming from ACPI use this mode.
>>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
>> ---
>>  drivers/tty/serial/amba-pl011.c | 37 ++++++++++++++++++++++++++-----------
>>  1 file changed, 26 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
>> index 899a771..974cb9e 100644
>> --- a/drivers/tty/serial/amba-pl011.c
>> +++ b/drivers/tty/serial/amba-pl011.c
>> @@ -2368,18 +2368,33 @@ static int pl011_probe(struct amba_device *dev, const struct amba_id *id)
>>         if (!uap)
>>                 return -ENOMEM;
>>
>> -       uap->clk = devm_clk_get(&dev->dev, NULL);
>> -       if (IS_ERR(uap->clk))
>> -               return PTR_ERR(uap->clk);
>> -
>> -       uap->vendor = vendor;
>> -       uap->lcrh_rx = vendor->lcrh_rx;
>> -       uap->lcrh_tx = vendor->lcrh_tx;
>> -       uap->fifosize = vendor->get_fifosize(dev);
>> -       uap->port.irq = dev->irq[0];
>> -       uap->port.ops = &amba_pl011_pops;
>> +       /* ACPI only defines SBSA variant */
>> +       if (has_acpi_companion(&dev->dev)) {
>> +               /*
>> +                * According to ARM ARMH0011 is currently the only mapping
>> +                * of pl011 in ACPI and it's mapped to SBSA UART mode
>> +                */
>> +               uap->vendor     = &vendor_sbsa;
>> +               uap->fifosize   = 32;
>> +               uap->port.ops   = &sbsa_uart_pops;
>> +               uap->fixed_baud = 115200;
>
> I'm confused by this patch.  We already have code like this in
> tty-next, in the form of sbsa_uart_probe():
>
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/tty/+/tty-next/drivers/tty/serial/amba-pl011.c#2553
>
Because Russell expressed unhappiness at that code existing. So this
is an alternative method to do same thing with ACPI.

If the "arm,sbsa-uart" id was added to drivers/of/platform.c as an
AMBA id then the same could be done for DT as well.

Ultimately this patch is optional depending on maintainers opinion!

Graeme

Re: [PATCH v4 3/3] serial: amba-pl011: add ACPI support to AMBA probe

[Timur Tabi]

G Gregory wrote:
>> >I'm confused by this patch.  We already have code like this in
>> >tty-next, in the form of sbsa_uart_probe():
>> >
>> >https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/tty/+/tty-next/drivers/tty/serial/amba-pl011.c#2553
>> >
> Because Russell expressed unhappiness at that code existing. So this
> is an alternative method to do same thing with ACPI.

FYI, this patch doesn't apply on tty-next as-is, so it would need to be 
updated anyway.  Then again, considering the latest drama with that 
driver, who knows what it will look like?

> If the "arm,sbsa-uart" id was added to drivers/of/platform.c as an
> AMBA id then the same could be done for DT as well.
>
> Ultimately this patch is optional depending on maintainers opinion!

So with this patch, what is the difference between sbsa_uart_probe and 
pl011_probe?  Shouldn't the patch also remove sbsa_uart_probe?

Re: [PATCH v4 3/3] serial: amba-pl011: add ACPI support to AMBA probe

[Graeme Gregory]

On Tue, Jan 05, 2016 at 10:23:08AM -0600, Timur Tabi wrote:
> G Gregory wrote:
> >>>I'm confused by this patch.  We already have code like this in
> >>>tty-next, in the form of sbsa_uart_probe():
> >>>
> >>>https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/tty/+/tty-next/drivers/tty/serial/amba-pl011.c#2553
> >>>
> >Because Russell expressed unhappiness at that code existing. So this
> >is an alternative method to do same thing with ACPI.
> 
> FYI, this patch doesn't apply on tty-next as-is, so it would need to be
> updated anyway.  Then again, considering the latest drama with that driver,
> who knows what it will look like?
> 
> >If the "arm,sbsa-uart" id was added to drivers/of/platform.c as an
> >AMBA id then the same could be done for DT as well.
> >
> >Ultimately this patch is optional depending on maintainers opinion!
> 
> So with this patch, what is the difference between sbsa_uart_probe and
> pl011_probe?  Shouldn't the patch also remove sbsa_uart_probe?
> 

One is for amba_device and one is for platform_device and one maintainer
indicated displeasure at platfrom device being in an AMBA driver. So we would
like some guidance from maintainers what direction they would like to take.

We can either drop this patch and leave situation as is (and remove
ARMH0011 from scan handler) or add followup patches to also convert DT
usage of sbsa-uart to amba_device.

Graeme

Re: [PATCH v4 3/3] serial: amba-pl011: add ACPI support to AMBA probe

[Timur Tabi]

Graeme Gregory wrote:
>> >
>> >So with this patch, what is the difference between sbsa_uart_probe and
>> >pl011_probe?  Shouldn't the patch also remove sbsa_uart_probe?
>> >
> One is for amba_device and one is for platform_device and one maintainer
> indicated displeasure at platfrom device being in an AMBA driver.

Ok, I'm still a little confused, but it sounds to me like your patch 
should have also removed sbsa_uart_probe().

With your patches applied, under what circumstance would 
sbsa_uart_probe() still be called?  The amba-pl011.c driver already 
probes on ARMH0011, so shouldn't that be removed, to avoid a double probe?