RE: [PATCH V2] ACPI: APD: Add device HID for future AMD UART controller
> From: Wang Hongcheng [mailto:annie.w...@amd.com]
> Sent: Friday, March 11, 2016 5:28 PM
> To: Rafael J. Wysocki; Len Brown; linux-a...@vger.kernel.org; linux-
> ker...@vger.kernel.org; SPG_Linux_Kernel
> Cc: Wang, Annie
> Subject: [PATCH V2] ACPI: APD: Add device HID for future AMD UART
> controller
>
> Add device HID AMDI0020 to match the AMD ACPI Vendor ID (AMDI) as
> registered in http://www.uefi.org/acpi_id_list, and the UART controller on
> future AMD paltform will use the HID instead of AMD0020.
>
> Signed-off-by: Wang Hongcheng <annie.w...@amd.com>
Acked-by: Ken Xue <ken@amd.com>
Hi Rafael,
Can you help apply and queue this patch into V4.6 like patch "i2c: designware:
Add device HID for future AMD I2C controller"?
Thanks.
> ---
> drivers/acpi/acpi_apd.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c index
> a450e7a..dc2d8a5 100644
> --- a/drivers/acpi/acpi_apd.c
> +++ b/drivers/acpi/acpi_apd.c
> @@ -134,6 +134,7 @@ static const struct acpi_device_id
> acpi_apd_device_ids[] = {
> /* Generic apd devices */
> { "AMD0010", APD_ADDR(cz_i2c_desc) },
> { "AMD0020", APD_ADDR(cz_uart_desc) },
> + { "AMDI0020", APD_ADDR(cz_uart_desc) },
> { "AMD0030", },
> { }
> };
> --
> 1.9.1
RE: [PATCH V2] ACPI: APD: Add device HID for future AMD UART controller
> From: Wang Hongcheng [mailto:annie.w...@amd.com]
> Sent: Friday, March 11, 2016 5:28 PM
> To: Rafael J. Wysocki; Len Brown; linux-a...@vger.kernel.org; linux-
> ker...@vger.kernel.org; SPG_Linux_Kernel
> Cc: Wang, Annie
> Subject: [PATCH V2] ACPI: APD: Add device HID for future AMD UART
> controller
>
> Add device HID AMDI0020 to match the AMD ACPI Vendor ID (AMDI) as
> registered in http://www.uefi.org/acpi_id_list, and the UART controller on
> future AMD paltform will use the HID instead of AMD0020.
>
> Signed-off-by: Wang Hongcheng
Acked-by: Ken Xue
Hi Rafael,
Can you help apply and queue this patch into V4.6 like patch "i2c: designware:
Add device HID for future AMD I2C controller"?
Thanks.
> ---
> drivers/acpi/acpi_apd.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c index
> a450e7a..dc2d8a5 100644
> --- a/drivers/acpi/acpi_apd.c
> +++ b/drivers/acpi/acpi_apd.c
> @@ -134,6 +134,7 @@ static const struct acpi_device_id
> acpi_apd_device_ids[] = {
> /* Generic apd devices */
> { "AMD0010", APD_ADDR(cz_i2c_desc) },
> { "AMD0020", APD_ADDR(cz_uart_desc) },
> + { "AMDI0020", APD_ADDR(cz_uart_desc) },
> { "AMD0030", },
> { }
> };
> --
> 1.9.1
RE: [PATCH] pinctrl: amd:Add device HID for future AMD GPIO controller
> From: Wang Hongcheng [mailto:annie.w...@amd.com]
> Sent: Friday, March 11, 2016 10:59 AM
> To: Linus Walleij; linux-g...@vger.kernel.org; linux-kernel@vger.kernel.org;
> SPG_Linux_Kernel
> Cc: Wang, Annie
> Subject: [PATCH] pinctrl: amd:Add device HID for future AMD GPIO controller
>
> Add device HID AMDI0030 to match the AMD ACPI Vendor ID (AMDI) as
> registered in http://www.uefi.org/acpi_id_list, and the GPIO controller on
> future AMD paltform will use the HID instead of AMD0030.
>
> Signed-off-by: Wang Hongcheng <annie.w...@amd.com>
> ---
Acked-by: Ken Xue <ken@amd.com>
Hi Linus,
Can you please help apply and queue this patch into V4.6?
Thanks.
> drivers/pinctrl/pinctrl-amd.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers/pinctrl/pinctrl-amd.c
> index
> 3318f1d..d7eb9ad 100644
> --- a/drivers/pinctrl/pinctrl-amd.c
> +++ b/drivers/pinctrl/pinctrl-amd.c
> @@ -849,6 +849,7 @@ static int amd_gpio_remove(struct platform_device
> *pdev)
>
> static const struct acpi_device_id amd_gpio_acpi_match[] = {
> { "AMD0030", 0 },
> + { "AMDI0030", 0},
> { },
> };
> MODULE_DEVICE_TABLE(acpi, amd_gpio_acpi_match);
> --
> 1.9.1
RE: [PATCH] pinctrl: amd:Add device HID for future AMD GPIO controller
> From: Wang Hongcheng [mailto:annie.w...@amd.com]
> Sent: Friday, March 11, 2016 10:59 AM
> To: Linus Walleij; linux-g...@vger.kernel.org; linux-kernel@vger.kernel.org;
> SPG_Linux_Kernel
> Cc: Wang, Annie
> Subject: [PATCH] pinctrl: amd:Add device HID for future AMD GPIO controller
>
> Add device HID AMDI0030 to match the AMD ACPI Vendor ID (AMDI) as
> registered in http://www.uefi.org/acpi_id_list, and the GPIO controller on
> future AMD paltform will use the HID instead of AMD0030.
>
> Signed-off-by: Wang Hongcheng
> ---
Acked-by: Ken Xue
Hi Linus,
Can you please help apply and queue this patch into V4.6?
Thanks.
> drivers/pinctrl/pinctrl-amd.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers/pinctrl/pinctrl-amd.c
> index
> 3318f1d..d7eb9ad 100644
> --- a/drivers/pinctrl/pinctrl-amd.c
> +++ b/drivers/pinctrl/pinctrl-amd.c
> @@ -849,6 +849,7 @@ static int amd_gpio_remove(struct platform_device
> *pdev)
>
> static const struct acpi_device_id amd_gpio_acpi_match[] = {
> { "AMD0030", 0 },
> + { "AMDI0030", 0},
> { },
> };
> MODULE_DEVICE_TABLE(acpi, amd_gpio_acpi_match);
> --
> 1.9.1
Re: [PATCH 1/2]Revert "SCSI: Fix NULL pointer dereference in runtime PM"
On 四, 2015-09-10 at 10:23 +0800, Ken Xue wrote:
Can someone help to apply this patch series? Thanks.
http://marc.info/?l=linux-scsi=144185206825609=2
http://marc.info/?l=linux-scsi=144185208525611=2
> Revert "SCSI: Fix NULL pointer dereference in runtime PM"
>
> This reverts commit 49718f0fb8c9 ("SCSI: Fix NULL pointer dereference
> in
> runtime PM")
>
> The old commit may lead to a issue that
> blk_{pre|post}_runtime_suspend and
> blk_{pre|post}_runtime_resume can not be called in pairs.
>
> Take sr device as example, when sr device goes to runtime suspend,
> blk_{pre|post}_runtime_suspend will be called since sr device defined
> pm->runtime_suspend. But blk_{pre|post}_runtime_resume will not be
> called
> since sr device doesn't have pm->runtime_resume. Then sr device can
> not
> resume correctly anymore.
>
> Signed-off-by: Ken Xue
> Acked-by: Alan Stern
> Cc: sta...@vger.kernel.org
>
> ---
> drivers/scsi/scsi_pm.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
> index e4b7998..459abe1 100644
> --- a/drivers/scsi/scsi_pm.c
> +++ b/drivers/scsi/scsi_pm.c
> @@ -219,13 +219,13 @@ static int sdev_runtime_suspend(struct device
> *dev)
> struct scsi_device *sdev = to_scsi_device(dev);
> int err = 0;
>
> - if (pm && pm->runtime_suspend) {
> - err = blk_pre_runtime_suspend(sdev->request_queue);
> - if (err)
> - return err;
> + err = blk_pre_runtime_suspend(sdev->request_queue);
> + if (err)
> + return err;
> + if (pm && pm->runtime_suspend)
> err = pm->runtime_suspend(dev);
> - blk_post_runtime_suspend(sdev->request_queue, err);
> - }
> + blk_post_runtime_suspend(sdev->request_queue, err);
> +
> return err;
> }
>
> @@ -248,11 +248,11 @@ static int sdev_runtime_resume(struct device
> *dev)
> const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm
> : NULL;
> int err = 0;
>
> - if (pm && pm->runtime_resume) {
> - blk_pre_runtime_resume(sdev->request_queue);
> + blk_pre_runtime_resume(sdev->request_queue);
> + if (pm && pm->runtime_resume)
> err = pm->runtime_resume(dev);
> - blk_post_runtime_resume(sdev->request_queue, err);
> - }
> + blk_post_runtime_resume(sdev->request_queue, err);
> +
> return err;
> }
>
> N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
> 0��h���i
Re: [PATCH 1/2]Revert "SCSI: Fix NULL pointer dereference in runtime PM"
On 四, 2015-09-10 at 10:23 +0800, Ken Xue wrote:
Can someone help to apply this patch series? Thanks.
http://marc.info/?l=linux-scsi=144185206825609=2
http://marc.info/?l=linux-scsi=144185208525611=2
> Revert "SCSI: Fix NULL pointer dereference in runtime PM"
>
> This reverts commit 49718f0fb8c9 ("SCSI: Fix NULL pointer dereference
> in
> runtime PM")
>
> The old commit may lead to a issue that
> blk_{pre|post}_runtime_suspend and
> blk_{pre|post}_runtime_resume can not be called in pairs.
>
> Take sr device as example, when sr device goes to runtime suspend,
> blk_{pre|post}_runtime_suspend will be called since sr device defined
> pm->runtime_suspend. But blk_{pre|post}_runtime_resume will not be
> called
> since sr device doesn't have pm->runtime_resume. Then sr device can
> not
> resume correctly anymore.
>
> Signed-off-by: Ken Xue <ken@amd.com>
> Acked-by: Alan Stern <st...@rowland.harvard.edu>
> Cc: sta...@vger.kernel.org
>
> ---
> drivers/scsi/scsi_pm.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
> index e4b7998..459abe1 100644
> --- a/drivers/scsi/scsi_pm.c
> +++ b/drivers/scsi/scsi_pm.c
> @@ -219,13 +219,13 @@ static int sdev_runtime_suspend(struct device
> *dev)
> struct scsi_device *sdev = to_scsi_device(dev);
> int err = 0;
>
> - if (pm && pm->runtime_suspend) {
> - err = blk_pre_runtime_suspend(sdev->request_queue);
> - if (err)
> - return err;
> + err = blk_pre_runtime_suspend(sdev->request_queue);
> + if (err)
> + return err;
> + if (pm && pm->runtime_suspend)
> err = pm->runtime_suspend(dev);
> - blk_post_runtime_suspend(sdev->request_queue, err);
> - }
> + blk_post_runtime_suspend(sdev->request_queue, err);
> +
> return err;
> }
>
> @@ -248,11 +248,11 @@ static int sdev_runtime_resume(struct device
> *dev)
> const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm
> : NULL;
> int err = 0;
>
> - if (pm && pm->runtime_resume) {
> - blk_pre_runtime_resume(sdev->request_queue);
> + blk_pre_runtime_resume(sdev->request_queue);
> + if (pm && pm->runtime_resume)
> err = pm->runtime_resume(dev);
> - blk_post_runtime_resume(sdev->request_queue, err);
> - }
> + blk_post_runtime_resume(sdev->request_queue, err);
> +
> return err;
> }
>
> N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
> 0��h���i
RE: [PATCH 1/3 V3] acpi:soc: merge common codes for creating platform device
Hi Rafael,
I looked into your patch in https://patchwork.kernel.org/patch/5677461/.
I found that "XXX_platform_notify" should be implemented separately in
LPSS and APD driver instead of "acpi_soc_platform_notify" in acpi_soc.
Because there is WA can't be share with two drivers. And it can make
LPSS or APD driver more flexible.
Then only "acpi_soc_create_device" can be shared by LPSS and APD.
Maybe, the meaning of acpi_soc becomes less than what we expected.
So, can we go back to two separated drivers without any binding? And
try thoughts about acpi_soc, if there were more common features.
Regards,
Ken
-Original Message-
From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
Sent: Friday, January 23, 2015 6:57 AM
To: Xue, Ken
Cc: andy.shevche...@gmail.com; mika.westerb...@linux.intel.com;
linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3 V3] acpi:soc: merge common codes for creating platform
device
On Thursday, December 18, 2014 04:44:45 PM Ken Xue wrote:
>
> This patch is supposed to deliver some common codes for AMD APD and
> intel LPSS. It can help to convert some specific acpi devices to be
> platform devices.
>
> Signed-off-by: Ken Xue
> ---
> drivers/acpi/Makefile | 2 +-
> drivers/acpi/acpi_soc.c | 228
>
> drivers/acpi/acpi_soc.h | 104 ++
> 3 files changed, 333 insertions(+), 1 deletion(-) create mode 100644
> drivers/acpi/acpi_soc.c create mode 100644 drivers/acpi/acpi_soc.h
>
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile index
> f74317c..66c7457 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -40,7 +40,7 @@ acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
> acpi-y += ec.o
> acpi-$(CONFIG_ACPI_DOCK) += dock.o
> acpi-y += pci_root.o pci_link.o pci_irq.o
> -acpi-y += acpi_lpss.o
> +acpi-y += acpi_soc.o acpi_lpss.o
> acpi-y += acpi_platform.o
> acpi-y += acpi_pnp.o
> acpi-y += int340x_thermal.o
> diff --git a/drivers/acpi/acpi_soc.c b/drivers/acpi/acpi_soc.c new
> file mode 100644 index 000..2abbac9
> --- /dev/null
> +++ b/drivers/acpi/acpi_soc.c
> @@ -0,0 +1,228 @@
> +/*
> + * ACPI SOC support for Intel Lynxpoint LPSS and AMD APD.
> + *
> + * Copyright (C) 2013, 2014, Intel Corporation
> + * Copyright (C) 2014, AMD Corporation
> + * Authors: Ken Xue
> + * Mika Westerberg
> + * Rafael J. Wysocki
> + *
> + * 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
> +#include
> +#include
> +#include
> +
> +#include "acpi_soc.h"
> +#include "internal.h"
> +
> +ACPI_MODULE_NAME("acpi_soc");
> +
> +/* A list for all ACPI SOC device */
> +static LIST_HEAD(a_soc_list);
> +
> +static int is_memory(struct acpi_resource *res, void *not_used) {
> + struct resource r;
> +
> + return !acpi_dev_resource_memory(res, ); }
> +
> +static int acpi_soc_create_device(struct acpi_device *adev,
> +const struct acpi_device_id *id) {
> + struct acpi_soc_dev_private_data *pdata;
> + struct acpi_soc_dev_desc *dev_desc;
> + struct resource_list_entry *rentry;
> + struct list_head resource_list;
> + struct platform_device *pdev;
> + int ret;
> +
> + dev_desc = (struct acpi_soc_dev_desc *)id->driver_data;
> + if (!dev_desc) {
> + pdev = acpi_create_platform_device(adev);
> + return IS_ERR_OR_NULL(pdev) ? PTR_ERR(pdev) : 1;
> + }
> + pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
> +
> + INIT_LIST_HEAD(_list);
> + ret = acpi_dev_get_resources(adev, _list, is_memory, NULL);
> + if (ret < 0)
> + goto err_out;
> +
> + list_for_each_entry(rentry, _list, node)
> + if (resource_type(>res) == IORESOURCE_MEM) {
> + if (dev_desc->mem_size_override)
> + pdata->mmio_size = dev_desc->mem_size_override;
> + else
> + pdata->mmio_size = resource_size(>res);
> + pdata->mmio_base = ioremap(rentry->res.start,
&g
RE: [PATCH 1/3 V3] acpi:soc: merge common codes for creating platform device
Hi Rafael,
I looked into your patch in https://patchwork.kernel.org/patch/5677461/.
I found that XXX_platform_notify should be implemented separately in
LPSS and APD driver instead of acpi_soc_platform_notify in acpi_soc.
Because there is WA can't be share with two drivers. And it can make
LPSS or APD driver more flexible.
Then only acpi_soc_create_device can be shared by LPSS and APD.
Maybe, the meaning of acpi_soc becomes less than what we expected.
So, can we go back to two separated drivers without any binding? And
try thoughts about acpi_soc, if there were more common features.
Regards,
Ken
-Original Message-
From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
Sent: Friday, January 23, 2015 6:57 AM
To: Xue, Ken
Cc: andy.shevche...@gmail.com; mika.westerb...@linux.intel.com;
linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3 V3] acpi:soc: merge common codes for creating platform
device
On Thursday, December 18, 2014 04:44:45 PM Ken Xue wrote:
This patch is supposed to deliver some common codes for AMD APD and
intel LPSS. It can help to convert some specific acpi devices to be
platform devices.
Signed-off-by: Ken Xue ken@amd.com
---
drivers/acpi/Makefile | 2 +-
drivers/acpi/acpi_soc.c | 228
drivers/acpi/acpi_soc.h | 104 ++
3 files changed, 333 insertions(+), 1 deletion(-) create mode 100644
drivers/acpi/acpi_soc.c create mode 100644 drivers/acpi/acpi_soc.h
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile index
f74317c..66c7457 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -40,7 +40,7 @@ acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
acpi-y += ec.o
acpi-$(CONFIG_ACPI_DOCK) += dock.o
acpi-y += pci_root.o pci_link.o pci_irq.o
-acpi-y += acpi_lpss.o
+acpi-y += acpi_soc.o acpi_lpss.o
acpi-y += acpi_platform.o
acpi-y += acpi_pnp.o
acpi-y += int340x_thermal.o
diff --git a/drivers/acpi/acpi_soc.c b/drivers/acpi/acpi_soc.c new
file mode 100644 index 000..2abbac9
--- /dev/null
+++ b/drivers/acpi/acpi_soc.c
@@ -0,0 +1,228 @@
+/*
+ * ACPI SOC support for Intel Lynxpoint LPSS and AMD APD.
+ *
+ * Copyright (C) 2013, 2014, Intel Corporation
+ * Copyright (C) 2014, AMD Corporation
+ * Authors: Ken Xue ken@amd.com
+ * Mika Westerberg mika.westerb...@linux.intel.com
+ * Rafael J. Wysocki rafael.j.wyso...@intel.com
+ *
+ * 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/err.h
+#include linux/list.h
+#include linux/pm_domain.h
+#include linux/platform_device.h
+
+#include acpi_soc.h
+#include internal.h
+
+ACPI_MODULE_NAME(acpi_soc);
+
+/* A list for all ACPI SOC device */
+static LIST_HEAD(a_soc_list);
+
+static int is_memory(struct acpi_resource *res, void *not_used) {
+ struct resource r;
+
+ return !acpi_dev_resource_memory(res, r); }
+
+static int acpi_soc_create_device(struct acpi_device *adev,
+const struct acpi_device_id *id) {
+ struct acpi_soc_dev_private_data *pdata;
+ struct acpi_soc_dev_desc *dev_desc;
+ struct resource_list_entry *rentry;
+ struct list_head resource_list;
+ struct platform_device *pdev;
+ int ret;
+
+ dev_desc = (struct acpi_soc_dev_desc *)id-driver_data;
+ if (!dev_desc) {
+ pdev = acpi_create_platform_device(adev);
+ return IS_ERR_OR_NULL(pdev) ? PTR_ERR(pdev) : 1;
+ }
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ INIT_LIST_HEAD(resource_list);
+ ret = acpi_dev_get_resources(adev, resource_list, is_memory, NULL);
+ if (ret 0)
+ goto err_out;
+
+ list_for_each_entry(rentry, resource_list, node)
+ if (resource_type(rentry-res) == IORESOURCE_MEM) {
+ if (dev_desc-mem_size_override)
+ pdata-mmio_size = dev_desc-mem_size_override;
+ else
+ pdata-mmio_size = resource_size(rentry-res);
+ pdata-mmio_base = ioremap(rentry-res.start,
+pdata-mmio_size);
+ break;
+ }
+
+ acpi_dev_free_resource_list(resource_list);
+
+ pdata-adev = adev;
+ pdata-dev_desc = dev_desc;
+
+ if (dev_desc-setup) {
+ ret = dev_desc-setup(pdata);
+ if (ret
RE: [PATCH] acpi:apd:add AMD ACPI2Platform device support for x86 system.
On Tuesday, November 18, 2014 01:58:11 PM Ken Xue wrote:
> This new feature is to interpret AMD specific ACPI device to platform
> device such as I2C, UART found on AMD CZ and later chipsets. It is
> based on example INTEL LPSS. Now, it can support AMD I2C & UART.
>
> Signed-off-by: Ken Xue
> Signed-off-by: Jeff Wu
Generally speaking, this seems to duplicate much code from acpi_lpss which
should be re-used instead. What about moving the code that will be common
between acpi_lpss and the new driver into a new file (say acpi_soc.c)?
Also, you need to avoid automatic creation of platform devices when
!X86_AMD_PLATFORM_DEVICE in analogy with what acpi_lpss does, or bad things
will happen.
[ken] sounds fair enough. Let me take action to merge drivers to acpi_soc.c ?
or you have other plan?
[...]
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH] acpi:apd:add AMD ACPI2Platform device support for x86 system.
On Tuesday, November 18, 2014 01:58:11 PM Ken Xue wrote:
This new feature is to interpret AMD specific ACPI device to platform
device such as I2C, UART found on AMD CZ and later chipsets. It is
based on example INTEL LPSS. Now, it can support AMD I2C UART.
Signed-off-by: Ken Xue ken@amd.com
Signed-off-by: Jeff Wu jeff...@amd.com
Generally speaking, this seems to duplicate much code from acpi_lpss which
should be re-used instead. What about moving the code that will be common
between acpi_lpss and the new driver into a new file (say acpi_soc.c)?
Also, you need to avoid automatic creation of platform devices when
!X86_AMD_PLATFORM_DEVICE in analogy with what acpi_lpss does, or bad things
will happen.
[ken] sounds fair enough. Let me take action to merge drivers to acpi_soc.c ?
or you have other plan?
[...]
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH] acpi:apd:add AMD ACPI2Platform device support for x86 system.
Hi Len, Rafael J & Mika,
Please help to review this patch. And tell me any of your concern.
Thanks.
I understand it is a trend that convert a ACPI device to be a platform
device.
For AMD, we try to use this patch to match this trend well. The patch
based on INTEL LPSS .
But we cannot reuse LPSS, because of specific definition of
"lpss_device_desc" for LPSS.
Regards,
Ken
-Original Message-
From: Ken Xue [mailto:ken@amd.com]
Sent: Tuesday, November 18, 2014 1:58 PM
To: r...@rjwysocki.net; l...@kernel.org
Cc: linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org; Xue, Ken; Wu, Jeff
Subject: [PATCH] acpi:apd:add AMD ACPI2Platform device support for x86 system.
This new feature is to interpret AMD specific ACPI device to platform device
such as I2C, UART found on AMD CZ and later chipsets. It is based on example
INTEL LPSS. Now, it can support AMD I2C & UART.
Signed-off-by: Ken Xue
Signed-off-by: Jeff Wu
---
arch/x86/Kconfig| 11 +++
drivers/acpi/Makefile | 1 +
drivers/acpi/acpi_apd.c | 245
drivers/acpi/internal.h | 6 ++
drivers/acpi/scan.c | 1 +
5 files changed, 264 insertions(+)
create mode 100644 drivers/acpi/acpi_apd.c
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index ded8a67..6402c79f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -495,6 +495,17 @@ config X86_INTEL_LPSS
things like clock tree (common clock framework) and pincontrol
which are needed by the LPSS peripheral drivers.
+config X86_AMD_PLATFORM_DEVICE
+ bool "AMD ACPI2Platform devices support"
+ depends on ACPI
+ select COMMON_CLK
+ select PINCTRL
+ ---help---
+ Select to interpret AMD specific ACPI device to platform device
+ such as I2C, UART found on AMD CARRIZO and later chipset. Selecting
+ this option enables things like clock tree (common clock framework)
+ and pinctrl.
+
config IOSF_MBI
tristate "Intel SoC IOSF Sideband support for SoC platforms"
depends on PCI
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile index
c3b2fcb..91fc1c2 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -41,6 +41,7 @@ acpi-y+= ec.o
acpi-$(CONFIG_ACPI_DOCK) += dock.o
acpi-y += pci_root.o pci_link.o pci_irq.o
acpi-y += acpi_lpss.o
+acpi-$(CONFIG_X86_AMD_PLATFORM_DEVICE) += acpi_apd.o
acpi-y += acpi_platform.o
acpi-y += acpi_pnp.o
acpi-y += int340x_thermal.o
diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c new file mode
100644 index 000..994b7db
--- /dev/null
+++ b/drivers/acpi/acpi_apd.c
@@ -0,0 +1,245 @@
+/*
+ * AMD ACPI support for ACPI2platform device.
+ *
+ * Copyright (c) 2014, AMD Corporation.
+ * Authors: Ken Xue
+ * Jeff Wu
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "internal.h"
+
+ACPI_MODULE_NAME("acpi_apd");
+struct apd_private_data;
+
+struct apd_device_desc {
+ bool clk_required;
+ bool fixed_root_clock;
+ const char *clk_name;
+ unsigned long rate;
+ size_t prv_size_override;
+ void (*setup)(struct apd_private_data *pdata); };
+
+struct apd_private_data {
+ void __iomem *mmio_base;
+ resource_size_t mmio_size;
+ struct clk *clk;
+ const struct apd_device_desc *dev_desc; };
+
+static struct apd_device_desc amd_i2c_desc = {
+ .clk_required = true,
+ .fixed_root_clock = true,
+ .clk_name = "i2c_clk",
+ .rate = 13300, /*(133 * 1000 * 1000)*/ };
+
+static struct apd_device_desc amd_uart_desc = {
+ .clk_required = true,
+ .fixed_root_clock = true,
+ .clk_name = "uart_clk",
+ .rate = 4800,
+};
+
+static const struct acpi_device_id acpi_apd_device_ids[] = {
+ /* Generic apd devices */
+ { "AMD0010", (unsigned long)_i2c_desc },
+ { "AMD0020", (unsigned long)_uart_desc },
+ { }
+};
+
+static int is_memory(struct acpi_resource *res, void *not_used) {
+ struct resource r;
+
+ return !acpi_dev_resource_memory(res, ); }
+
+static int register_device_clock(struct acpi_device *adev,
+struct apd_private_data *pdata)
+{
+ const struct apd_device_desc *dev_desc = pdata->dev_desc;
+ struct clk *clk = ERR_PTR(-ENODEV);
+
+ clk = pdata->clk;
+ if (!clk && dev_desc->fixed_root_clock) {
+ clk = clk_register_fixed_rate(&g
RE: [PATCH] acpi:apd:add AMD ACPI2Platform device support for x86 system.
Hi Len, Rafael J Mika,
Please help to review this patch. And tell me any of your concern.
Thanks.
I understand it is a trend that convert a ACPI device to be a platform
device.
For AMD, we try to use this patch to match this trend well. The patch
based on INTEL LPSS .
But we cannot reuse LPSS, because of specific definition of
lpss_device_desc for LPSS.
Regards,
Ken
-Original Message-
From: Ken Xue [mailto:ken@amd.com]
Sent: Tuesday, November 18, 2014 1:58 PM
To: r...@rjwysocki.net; l...@kernel.org
Cc: linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org; Xue, Ken; Wu, Jeff
Subject: [PATCH] acpi:apd:add AMD ACPI2Platform device support for x86 system.
This new feature is to interpret AMD specific ACPI device to platform device
such as I2C, UART found on AMD CZ and later chipsets. It is based on example
INTEL LPSS. Now, it can support AMD I2C UART.
Signed-off-by: Ken Xue ken@amd.com
Signed-off-by: Jeff Wu jeff...@amd.com
---
arch/x86/Kconfig| 11 +++
drivers/acpi/Makefile | 1 +
drivers/acpi/acpi_apd.c | 245
drivers/acpi/internal.h | 6 ++
drivers/acpi/scan.c | 1 +
5 files changed, 264 insertions(+)
create mode 100644 drivers/acpi/acpi_apd.c
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index ded8a67..6402c79f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -495,6 +495,17 @@ config X86_INTEL_LPSS
things like clock tree (common clock framework) and pincontrol
which are needed by the LPSS peripheral drivers.
+config X86_AMD_PLATFORM_DEVICE
+ bool AMD ACPI2Platform devices support
+ depends on ACPI
+ select COMMON_CLK
+ select PINCTRL
+ ---help---
+ Select to interpret AMD specific ACPI device to platform device
+ such as I2C, UART found on AMD CARRIZO and later chipset. Selecting
+ this option enables things like clock tree (common clock framework)
+ and pinctrl.
+
config IOSF_MBI
tristate Intel SoC IOSF Sideband support for SoC platforms
depends on PCI
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile index
c3b2fcb..91fc1c2 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -41,6 +41,7 @@ acpi-y+= ec.o
acpi-$(CONFIG_ACPI_DOCK) += dock.o
acpi-y += pci_root.o pci_link.o pci_irq.o
acpi-y += acpi_lpss.o
+acpi-$(CONFIG_X86_AMD_PLATFORM_DEVICE) += acpi_apd.o
acpi-y += acpi_platform.o
acpi-y += acpi_pnp.o
acpi-y += int340x_thermal.o
diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c new file mode
100644 index 000..994b7db
--- /dev/null
+++ b/drivers/acpi/acpi_apd.c
@@ -0,0 +1,245 @@
+/*
+ * AMD ACPI support for ACPI2platform device.
+ *
+ * Copyright (c) 2014, AMD Corporation.
+ * Authors: Ken Xue ken@amd.com
+ * Jeff Wu jeff...@amd.com
+ *
+ * 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/clk.h
+#include linux/clkdev.h
+#include linux/clk-provider.h
+#include linux/err.h
+#include linux/io.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+
+#include internal.h
+
+ACPI_MODULE_NAME(acpi_apd);
+struct apd_private_data;
+
+struct apd_device_desc {
+ bool clk_required;
+ bool fixed_root_clock;
+ const char *clk_name;
+ unsigned long rate;
+ size_t prv_size_override;
+ void (*setup)(struct apd_private_data *pdata); };
+
+struct apd_private_data {
+ void __iomem *mmio_base;
+ resource_size_t mmio_size;
+ struct clk *clk;
+ const struct apd_device_desc *dev_desc; };
+
+static struct apd_device_desc amd_i2c_desc = {
+ .clk_required = true,
+ .fixed_root_clock = true,
+ .clk_name = i2c_clk,
+ .rate = 13300, /*(133 * 1000 * 1000)*/ };
+
+static struct apd_device_desc amd_uart_desc = {
+ .clk_required = true,
+ .fixed_root_clock = true,
+ .clk_name = uart_clk,
+ .rate = 4800,
+};
+
+static const struct acpi_device_id acpi_apd_device_ids[] = {
+ /* Generic apd devices */
+ { AMD0010, (unsigned long)amd_i2c_desc },
+ { AMD0020, (unsigned long)amd_uart_desc },
+ { }
+};
+
+static int is_memory(struct acpi_resource *res, void *not_used) {
+ struct resource r;
+
+ return !acpi_dev_resource_memory(res, r); }
+
+static int register_device_clock(struct acpi_device *adev,
+struct apd_private_data *pdata)
+{
+ const struct apd_device_desc *dev_desc = pdata-dev_desc;
+ struct clk *clk = ERR_PTR(-ENODEV);
+
+ clk = pdata-clk;
+ if (!clk dev_desc-fixed_root_clock
