* [PATCH 5/5] ACPI: Add support for platform bus type
From: Rafael J. Wysocki @ 2012-10-31 9:36 UTC (permalink / raw)
To: LKML
Cc: Linux PM list, Greg Kroah-Hartman, ACPI Devel Maling List,
Len Brown, Mathias Nyman, Mika Westerberg, Lv Zheng, Huang Ying,
Andy Shevchenko, H. Peter Anvin, x86 list, Tony Luck
In-Reply-To: <1421417.rIOjExM5Pt@vostro.rjw.lan>
From: Mika Westerberg <mika.westerberg@linux.intel.com>
With ACPI 5 it is now possible to enumerate traditional SoC
peripherals, like serial bus controllers and slave devices behind
them. These devices are typically based on IP-blocks used in many
existing SoC platforms and platform drivers for them may already
be present in the kernel tree.
To make driver "porting" more straightforward, add ACPI support to
the platform bus type. Instead of writing ACPI "glue" drivers for
the existing platform drivers, register the platform bus type with
ACPI to create platform device objects for the drivers and bind the
corresponding ACPI handles to those platform devices.
This should allow us to reuse the existing platform drivers for the
devices in question with the minimum amount of modifications.
This changeset is based on Mika Westerberg's and Mathias Nyman's
work.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/acpi/Makefile | 1
drivers/acpi/acpi_platform.c | 285 +++++++++++++++++++++++++++++++++++++++++++
drivers/acpi/internal.h | 7 +
drivers/acpi/scan.c | 16 ++
drivers/base/platform.c | 5
5 files changed, 313 insertions(+), 1 deletion(-)
create mode 100644 drivers/acpi/acpi_platform.c
Index: linux/drivers/acpi/Makefile
===================================================================
--- linux.orig/drivers/acpi/Makefile
+++ linux/drivers/acpi/Makefile
@@ -37,6 +37,7 @@ acpi-y += processor_core.o
acpi-y += ec.o
acpi-$(CONFIG_ACPI_DOCK) += dock.o
acpi-y += pci_root.o pci_link.o pci_irq.o pci_bind.o
+acpi-y += acpi_platform.o
acpi-y += power.o
acpi-y += event.o
acpi-y += sysfs.o
Index: linux/drivers/acpi/acpi_platform.c
===================================================================
--- /dev/null
+++ linux/drivers/acpi/acpi_platform.c
@@ -0,0 +1,285 @@
+/*
+ * ACPI support for platform bus type.
+ *
+ * Copyright (C) 2012, Intel Corporation
+ * Authors: Mika Westerberg <mika.westerberg@linux.intel.com>
+ * Mathias Nyman <mathias.nyman@linux.intel.com>
+ * Rafael J. Wysocki <rafael.j.wysocki@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/acpi.h>
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+
+ACPI_MODULE_NAME("platform");
+
+struct resource_info {
+ struct device *dev;
+ struct resource *res;
+ size_t n, cur;
+};
+
+static acpi_status acpi_platform_count_resources(struct acpi_resource *res,
+ void *data)
+{
+ struct acpi_resource_extended_irq *acpi_xirq;
+ struct resource_info *ri = data;
+
+ switch (res->type) {
+ case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
+ case ACPI_RESOURCE_TYPE_IRQ:
+ ri->n++;
+ break;
+ case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
+ acpi_xirq = &res->data.extended_irq;
+ ri->n += acpi_xirq->interrupt_count;
+ break;
+ case ACPI_RESOURCE_TYPE_ADDRESS32:
+ if (res->data.address32.resource_type == ACPI_IO_RANGE)
+ ri->n++;
+ break;
+ }
+
+ return AE_OK;
+}
+
+static acpi_status acpi_platform_add_resources(struct acpi_resource *res,
+ void *data)
+{
+ struct acpi_resource_fixed_memory32 *acpi_mem;
+ struct acpi_resource_address32 *acpi_add32;
+ struct acpi_resource_extended_irq *acpi_xirq;
+ struct acpi_resource_irq *acpi_irq;
+ struct resource_info *ri = data;
+ struct resource *r;
+ int irq, i;
+
+ switch (res->type) {
+ case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
+ acpi_mem = &res->data.fixed_memory32;
+ r = &ri->res[ri->cur++];
+
+ r->start = acpi_mem->address;
+ r->end = r->start + acpi_mem->address_length - 1;
+ r->flags = IORESOURCE_MEM;
+
+ dev_dbg(ri->dev, "Memory32Fixed %pR\n", r);
+ break;
+
+ case ACPI_RESOURCE_TYPE_ADDRESS32:
+ acpi_add32 = &res->data.address32;
+
+ if (acpi_add32->resource_type == ACPI_IO_RANGE) {
+ r = &ri->res[ri->cur++];
+ r->start = acpi_add32->minimum;
+ r->end = r->start + acpi_add32->address_length - 1;
+ r->flags = IORESOURCE_IO;
+ dev_dbg(ri->dev, "Address32 %pR\n", r);
+ }
+ break;
+
+ case ACPI_RESOURCE_TYPE_IRQ:
+ acpi_irq = &res->data.irq;
+ r = &ri->res[ri->cur++];
+
+ irq = acpi_register_gsi(ri->dev,
+ acpi_irq->interrupts[0],
+ acpi_irq->triggering,
+ acpi_irq->polarity);
+
+ r->start = r->end = irq;
+ r->flags = IORESOURCE_IRQ;
+
+ dev_dbg(ri->dev, "IRQ %pR\n", r);
+ break;
+
+ case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
+ acpi_xirq = &res->data.extended_irq;
+
+ for (i = 0; i < acpi_xirq->interrupt_count; i++, ri->cur++) {
+ r = &ri->res[ri->cur];
+ irq = acpi_register_gsi(ri->dev,
+ acpi_xirq->interrupts[i],
+ acpi_xirq->triggering,
+ acpi_xirq->polarity);
+
+ r->start = r->end = irq;
+ r->flags = IORESOURCE_IRQ;
+
+ dev_dbg(ri->dev, "Interrupt %pR\n", r);
+ }
+ break;
+ }
+
+ return AE_OK;
+}
+
+static acpi_status acpi_platform_get_device_uid(struct acpi_device *adev,
+ int *uid)
+{
+ struct acpi_device_info *info;
+ acpi_status status;
+
+ status = acpi_get_object_info(adev->handle, &info);
+ if (ACPI_FAILURE(status))
+ return status;
+
+ status = AE_NOT_EXIST;
+ if ((info->valid & ACPI_VALID_UID) &&
+ !kstrtoint(info->unique_id.string, 0, uid))
+ status = AE_OK;
+
+ kfree(info);
+ return status;
+}
+
+/**
+ * acpi_create_platform_device - Create platform device for ACPI device node
+ * @adev: ACPI device node to create a platform device for.
+ *
+ * Check if the given @adev can be represented as a platform device and, if
+ * that's the case, create and register a platform device, populate its common
+ * resources and returns a pointer to it. Otherwise, return %NULL.
+ *
+ * The platform device's name will be taken from the @adev's _HID and _UID.
+ */
+struct platform_device *acpi_create_platform_device(struct acpi_device *adev)
+{
+ struct platform_device *pdev = NULL;
+ struct acpi_device *acpi_parent;
+ struct device *parent = NULL;
+ struct resource_info ri;
+ acpi_status status;
+ int devid;
+
+ /* If the ACPI node already has a physical device attached, skip it. */
+ if (adev->physical_node_count)
+ return NULL;
+
+ /* Use the UID of the device as the new platform device id if found. */
+ status = acpi_platform_get_device_uid(adev, &devid);
+ if (ACPI_FAILURE(status))
+ devid = -1;
+
+ memset(&ri, 0, sizeof(ri));
+
+ /* First, count the resources. */
+ status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS,
+ acpi_platform_count_resources, &ri);
+ if (ACPI_FAILURE(status) || !ri.n)
+ return NULL;
+
+ /* Next, allocate memory for all the resources and populate it. */
+ ri.dev = &adev->dev;
+ ri.res = kzalloc(ri.n * sizeof(struct resource), GFP_KERNEL);
+ if (!ri.res) {
+ dev_err(&adev->dev,
+ "failed to allocate memory for resources\n");
+ return NULL;
+ }
+
+ status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS,
+ acpi_platform_add_resources, &ri);
+ if (ACPI_FAILURE(status)) {
+ dev_err(&adev->dev, "failed to walk resources\n");
+ goto out;
+ }
+
+ if (WARN_ON(ri.n != ri.cur))
+ goto out;
+
+ /*
+ * 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.
+ */
+ 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);
+ parent = entry->dev;
+ }
+ mutex_unlock(&acpi_parent->physical_node_lock);
+ }
+ pdev = platform_device_register_resndata(parent, acpi_device_hid(adev),
+ devid, ri.res, ri.n, NULL, 0);
+ if (IS_ERR(pdev)) {
+ dev_err(&adev->dev, "platform device creation failed: %ld\n",
+ PTR_ERR(pdev));
+ pdev = NULL;
+ } else {
+ dev_dbg(&adev->dev, "created platform device %s\n",
+ dev_name(&pdev->dev));
+ }
+
+ out:
+ kfree(ri.res);
+ return pdev;
+}
+
+static acpi_status acpi_platform_match(acpi_handle handle, u32 depth,
+ void *data, void **return_value)
+{
+ struct platform_device *pdev = data;
+ struct acpi_device *adev;
+ acpi_status status;
+
+ status = acpi_bus_get_device(handle, &adev);
+ if (ACPI_FAILURE(status))
+ return status;
+
+ /* Skip ACPI devices that have physical device attached */
+ if (adev->physical_node_count)
+ return AE_OK;
+
+ if (!strcmp(pdev->name, acpi_device_hid(adev))) {
+ int devid;
+
+ /* Check that both name and UID match if it exists */
+ status = acpi_platform_get_device_uid(adev, &devid);
+ if (ACPI_FAILURE(status))
+ devid = -1;
+
+ if (pdev->id != devid)
+ return AE_OK;
+
+ *(acpi_handle *)return_value = handle;
+ return AE_CTRL_TERMINATE;
+ }
+
+ return AE_OK;
+}
+
+static int acpi_platform_find_device(struct device *dev, acpi_handle *handle)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+
+ *handle = NULL;
+ acpi_get_devices(pdev->name, acpi_platform_match, pdev, handle);
+
+ return *handle ? 0 : -ENODEV;
+}
+
+static struct acpi_bus_type acpi_platform_bus = {
+ .bus = &platform_bus_type,
+ .find_device = acpi_platform_find_device,
+};
+
+static int __init acpi_platform_init(void)
+{
+ return register_acpi_bus_type(&acpi_platform_bus);
+}
+arch_initcall(acpi_platform_init);
Index: linux/drivers/acpi/internal.h
===================================================================
--- linux.orig/drivers/acpi/internal.h
+++ linux/drivers/acpi/internal.h
@@ -93,4 +93,11 @@ static inline int suspend_nvs_save(void)
static inline void suspend_nvs_restore(void) {}
#endif
+/*--------------------------------------------------------------------------
+ Platform bus support
+ -------------------------------------------------------------------------- */
+struct platform_device;
+
+struct platform_device *acpi_create_platform_device(struct acpi_device *adev);
+
#endif /* _ACPI_INTERNAL_H_ */
Index: linux/drivers/acpi/scan.c
===================================================================
--- linux.orig/drivers/acpi/scan.c
+++ linux/drivers/acpi/scan.c
@@ -29,6 +29,15 @@ extern struct acpi_device *acpi_root;
static const char *dummy_hid = "device";
+/*
+ * The following ACPI IDs are known to be suitable for representing as
+ * platform devices.
+ */
+static const struct acpi_device_id acpi_platform_device_ids[] = {
+
+ { }
+};
+
static LIST_HEAD(acpi_device_list);
static LIST_HEAD(acpi_bus_id_list);
DEFINE_MUTEX(acpi_device_lock);
@@ -1544,8 +1553,13 @@ static acpi_status acpi_bus_check_add(ac
*/
device = NULL;
acpi_bus_get_device(handle, &device);
- if (ops->acpi_op_add && !device)
+ if (ops->acpi_op_add && !device) {
acpi_add_single_object(&device, handle, type, sta, ops);
+ /* Is the device a known good platform device? */
+ if (device
+ && !acpi_match_device_ids(device, acpi_platform_device_ids))
+ acpi_create_platform_device(device);
+ }
if (!device)
return AE_CTRL_DEPTH;
Index: linux/drivers/base/platform.c
===================================================================
--- linux.orig/drivers/base/platform.c
+++ linux/drivers/base/platform.c
@@ -21,6 +21,7 @@
#include <linux/slab.h>
#include <linux/pm_runtime.h>
#include <linux/idr.h>
+#include <linux/acpi.h>
#include "base.h"
#include "power/power.h"
@@ -702,6 +703,10 @@ static int platform_match(struct device
if (of_driver_match_device(dev, drv))
return 1;
+ /* Then try ACPI style match */
+ if (acpi_driver_match_device(dev, drv))
+ return 1;
+
/* Then try to match against the id table */
if (pdrv->id_table)
return platform_match_id(pdrv->id_table, pdev) != NULL;
^ permalink raw reply
* [PATCH 4/5] ACPI / ia64: Export acpi_[un]register_gsi()
From: Rafael J. Wysocki @ 2012-10-31 9:35 UTC (permalink / raw)
To: LKML
Cc: Linux PM list, Greg Kroah-Hartman, ACPI Devel Maling List,
Len Brown, Mathias Nyman, Mika Westerberg, Lv Zheng, Huang Ying,
Andy Shevchenko, H. Peter Anvin, x86 list, Tony Luck
In-Reply-To: <1421417.rIOjExM5Pt@vostro.rjw.lan>
From: Mika Westerberg <mika.westerberg@linux.intel.com>
These functions might be called from modules as well so make sure
they are exported.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
arch/ia64/kernel/acpi.c | 2 ++
1 file changed, 2 insertions(+)
Index: linux/arch/ia64/kernel/acpi.c
===================================================================
--- linux.orig/arch/ia64/kernel/acpi.c
+++ linux/arch/ia64/kernel/acpi.c
@@ -633,6 +633,7 @@ int acpi_register_gsi(struct device *dev
ACPI_EDGE_SENSITIVE) ? IOSAPIC_EDGE :
IOSAPIC_LEVEL);
}
+EXPORT_SYMBOL_GPL(acpi_register_gsi);
void acpi_unregister_gsi(u32 gsi)
{
@@ -644,6 +645,7 @@ void acpi_unregister_gsi(u32 gsi)
iosapic_unregister_intr(gsi);
}
+EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
static int __init acpi_parse_fadt(struct acpi_table_header *table)
{
^ permalink raw reply
* [PATCH 3/5] ACPI / x86: Export acpi_[un]register_gsi()
From: Rafael J. Wysocki @ 2012-10-31 9:34 UTC (permalink / raw)
To: LKML
Cc: Linux PM list, Greg Kroah-Hartman, ACPI Devel Maling List,
Len Brown, Mathias Nyman, Mika Westerberg, Lv Zheng, Huang Ying,
Andy Shevchenko, H. Peter Anvin, x86 list, Tony Luck
In-Reply-To: <1421417.rIOjExM5Pt@vostro.rjw.lan>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
These functions might be called from modules as well so make sure
they are exported.
In addition, implement empty version of acpi_unregister_gsi() and
remove the one from pci_irq.c.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
arch/x86/kernel/acpi/boot.c | 6 ++++++
drivers/acpi/pci_irq.c | 5 -----
2 files changed, 6 insertions(+), 5 deletions(-)
Index: linux/arch/x86/kernel/acpi/boot.c
===================================================================
--- linux.orig/arch/x86/kernel/acpi/boot.c
+++ linux/arch/x86/kernel/acpi/boot.c
@@ -574,6 +574,12 @@ int acpi_register_gsi(struct device *dev
return irq;
}
+EXPORT_SYMBOL_GPL(acpi_register_gsi);
+
+void acpi_unregister_gsi(u32 gsi)
+{
+}
+EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
void __init acpi_set_irq_model_pic(void)
{
Index: linux/drivers/acpi/pci_irq.c
===================================================================
--- linux.orig/drivers/acpi/pci_irq.c
+++ linux/drivers/acpi/pci_irq.c
@@ -495,11 +495,6 @@ int acpi_pci_irq_enable(struct pci_dev *
return 0;
}
-/* FIXME: implement x86/x86_64 version */
-void __attribute__ ((weak)) acpi_unregister_gsi(u32 i)
-{
-}
-
void acpi_pci_irq_disable(struct pci_dev *dev)
{
struct acpi_prt_entry *entry;
^ permalink raw reply
* [PATCH 2/5] ACPI: Provide generic functions for matching ACPI device nodes
From: Rafael J. Wysocki @ 2012-10-31 9:33 UTC (permalink / raw)
To: LKML
Cc: Linux PM list, Greg Kroah-Hartman, ACPI Devel Maling List,
Len Brown, Mathias Nyman, Mika Westerberg, Lv Zheng, Huang Ying,
Andy Shevchenko, H. Peter Anvin, x86 list, Tony Luck
In-Reply-To: <1421417.rIOjExM5Pt@vostro.rjw.lan>
From: Mika Westerberg <mika.westerberg@linux.intel.com>
Introduce function acpi_match_device() allowing callers to match
struct device objects with populated acpi_handle fields against
arrays of ACPI device IDs. Also introduce function
acpi_driver_match_device() using acpi_match_device() internally and
allowing callers to match a struct device object against an array of
ACPI device IDs provided by a device driver.
Additionally, introduce macro ACPI_PTR() that may be used by device
drivers to escape pointers to data structures whose definitions
depend on CONFIG_ACPI.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/acpi/scan.c | 40 +++++++++++++++++++++++++++++++++++-----
include/linux/acpi.h | 28 ++++++++++++++++++++++++++++
2 files changed, 63 insertions(+), 5 deletions(-)
Index: linux/drivers/acpi/scan.c
===================================================================
--- linux.orig/drivers/acpi/scan.c
+++ linux/drivers/acpi/scan.c
@@ -372,8 +372,8 @@ static void acpi_device_remove_files(str
ACPI Bus operations
-------------------------------------------------------------------------- */
-int acpi_match_device_ids(struct acpi_device *device,
- const struct acpi_device_id *ids)
+static const struct acpi_device_id *__acpi_match_device(
+ struct acpi_device *device, const struct acpi_device_id *ids)
{
const struct acpi_device_id *id;
struct acpi_hardware_id *hwid;
@@ -383,14 +383,44 @@ int acpi_match_device_ids(struct acpi_de
* driver for it.
*/
if (!device->status.present)
- return -ENODEV;
+ return NULL;
for (id = ids; id->id[0]; id++)
list_for_each_entry(hwid, &device->pnp.ids, list)
if (!strcmp((char *) id->id, hwid->id))
- return 0;
+ return id;
+
+ return NULL;
+}
+
+/**
+ * acpi_match_device - Match a struct device against a given list of ACPI IDs
+ * @ids: Array of struct acpi_device_id object to match against.
+ * @dev: The device structure to match.
+ *
+ * Check if @dev has a valid ACPI handle and if there is a struct acpi_device
+ * object for that handle and use that object to match against a given list of
+ * device IDs.
+ *
+ * Return a pointer to the first matching ID on success or %NULL on failure.
+ */
+const struct acpi_device_id *acpi_match_device(const struct acpi_device_id *ids,
+ const struct device *dev)
+{
+ struct acpi_device *adev;
- return -ENOENT;
+ if (!ids || !dev->acpi_handle
+ || ACPI_FAILURE(acpi_bus_get_device(dev->acpi_handle, &adev)))
+ return NULL;
+
+ return __acpi_match_device(adev, ids);
+}
+EXPORT_SYMBOL_GPL(acpi_match_device);
+
+int acpi_match_device_ids(struct acpi_device *device,
+ const struct acpi_device_id *ids)
+{
+ return __acpi_match_device(device, ids) ? 0 : -ENOENT;
}
EXPORT_SYMBOL(acpi_match_device_ids);
Index: linux/include/linux/acpi.h
===================================================================
--- linux.orig/include/linux/acpi.h
+++ linux/include/linux/acpi.h
@@ -26,6 +26,7 @@
#define _LINUX_ACPI_H
#include <linux/ioport.h> /* for struct resource */
+#include <linux/device.h>
#ifdef CONFIG_ACPI
@@ -368,6 +369,17 @@ extern int acpi_nvs_register(__u64 start
extern int acpi_nvs_for_each_region(int (*func)(__u64, __u64, void *),
void *data);
+const struct acpi_device_id *acpi_match_device(const struct acpi_device_id *ids,
+ const struct device *dev);
+
+static inline bool acpi_driver_match_device(struct device *dev,
+ const struct device_driver *drv)
+{
+ return !!acpi_match_device(drv->acpi_match_table, dev);
+}
+
+#define ACPI_PTR(_ptr) (_ptr)
+
#else /* !CONFIG_ACPI */
#define acpi_disabled 1
@@ -422,6 +434,22 @@ static inline int acpi_nvs_for_each_regi
return 0;
}
+struct acpi_device_id;
+
+static inline const struct acpi_device_id *acpi_match_device(
+ const struct acpi_device_id *ids, const struct device *dev)
+{
+ return NULL;
+}
+
+static inline bool acpi_driver_match_device(struct device *dev,
+ const struct device_driver *drv)
+{
+ return false;
+}
+
+#define ACPI_PTR(_ptr) (NULL)
+
#endif /* !CONFIG_ACPI */
#ifdef CONFIG_ACPI
^ permalink raw reply
* [PATCH 0/5] ACPI-based enumeration of devices that are not discoverable natively
From: Rafael J. Wysocki @ 2012-10-31 9:31 UTC (permalink / raw)
To: LKML
Cc: Linux PM list, Greg Kroah-Hartman, ACPI Devel Maling List,
Len Brown, Mathias Nyman, Mika Westerberg, Lv Zheng, Huang Ying,
Andy Shevchenko, H. Peter Anvin, x86 list, Tony Luck
Hi All,
The following patch series adds support for ACPI-based enumeration of devices
that aren't discoverable natively to the driver core and ACPI subsystem. It
covers the generic part and the platform bus type support.
Since in this case the role of ACPI is analogous to the role of Device Trees,
the idea is to follow what Device Trees did previously.
[1/5] Move ACPI handle to struct device and add device IDs table to
struct device_driver.
[2/5] Generic functions for matching ACPI device nodes.
[3/5] Export GSI registration/unregistration functions on x86 (needed by [5/5]).
[4/5] Export GSI registration/unregistration functions on ia64 (needed by [5/5]).
[5/5] ACPI-based device enumeration support for platform devices.
The patches are on top of the linux-next branch of the linux-pm.git tree
with the "ACPI / PM: ACPI power management callback routines for subsystems"
patch series applied (although that series is not strictly necessary for them
to work). They have been tested by Mika.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [linux-next PATCH] PM / devfreq: documentation cleanups for devfreq header
From: Rafael J. Wysocki @ 2012-10-31 9:13 UTC (permalink / raw)
To: myungjoo.ham
Cc: Randy Dunlap, Nishanth Menon, linux-pm@vger.kernel.org,
Rajagopal Venkat, 박경민, Kevin Hilman,
linux-kernel@vger.kernel.org, 이종화
In-Reply-To: <29176137.554861351650430580.JavaMail.weblogic@epv6ml03>
On Wednesday, October 31, 2012 02:27:10 AM 함명주 wrote:
> > On Tuesday, October 30, 2012 08:09:09 AM MyungJoo Ham wrote:
> []
> > >
> > > Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
> > >
> > > Applying to git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git for-rafael, which is based on rafael's linux-pm.git / linux-next.
> > >
> > > http://git.kernel.org/?p=linux/kernel/git/mzx/devfreq.git;a=shortlog;h=refs/heads/for-rafael
> > >
> > > I'll apply your "Add sysfs node ..." patch after refactoring with Jonghwa's (devfreq trans_stat) as the two patches use the same data (list of available freqs).
> >
> > May I assume that you'll handle all of the subsequent devfreq patches too?
> >
> > Rafael
>
> Yes, you may. I'll apply the patches (currently at http://git.kernel.org/?p=linux/kernel/git/mzx/devfreq.git;a=shortlog;h=refs/heads/for-rafael ) and send pull requests to you or Linus.
>
> Anyway, do you want me to keep sending pull requests to you as you've told
> last time?
Yes, please.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [for-next PATCH V2] PM / devfreq: Add sysfs node to expose available frequencies
From: Rafael J. Wysocki @ 2012-10-31 9:15 UTC (permalink / raw)
To: myungjoo.ham
Cc: Nishanth Menon, linux-pm, Rajagopal Venkat,
박경민, Kevin Hilman,
linux-kernel@vger.kernel.org
In-Reply-To: <3578820.552041351649466344.JavaMail.weblogic@epv6ml03>
On Wednesday, October 31, 2012 02:11:06 AM MyungJoo Ham wrote:
> > On Friday, October 26, 2012 06:16:36 AM MyungJoo Ham wrote:
> > > > devfreq governors such as ondemand are controlled by a min and
> > > > max frequency, while governors like userspace governor allow us
> > > > to set a specific frequency.
> > > > However, for the same specific device, depending on the SoC, the
> > > > available frequencies can vary.
> > > >
> > > > So expose the available frequencies as a snapshot over sysfs to
> > > > allow informed decisions.
> > > >
> > > > This was inspired by cpufreq framework's equivalent for similar
> > > > usage sysfs node: scaling_available_frequencies.
> > > >
> > > > Cc: Rajagopal Venkat <rajagopal.venkat@linaro.org>
> > > > Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
> > > > Cc: Kyungmin Park <kyungmin.park@samsung.com>
> > > > Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
> > > > Cc: Kevin Hilman <khilman@ti.com>
> > > > Cc: linux-pm@vger.kernel.org
> > > > Cc: linux-kernel@vger.kernel.org
> > > >
> > > > Signed-off-by: Nishanth Menon <nm@ti.com>
> > >
> > > Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
> >
> > Are you going to handle this patch?
>
> Yes, I've just setup the git repository this week
> and I'm willing to handle this one.
>
> It is applied at
> http://git.kernel.org/?p=linux/kernel/git/mzx/devfreq.git;a=shortlog;h=refs/heads/for-rafael
OK
Please let me know when you want me to pull from your tree.
Please also note that the release of v3.7-rc6 is the deadline for non-bugfix
changes targeted at v3.8. :-)
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* RE: [PATCH v2] Thermal: exynos: Add sysfs node supporting exynos's emulation mode.
From: R, Durgadoss @ 2012-10-31 8:49 UTC (permalink / raw)
To: jonghwa3.lee@samsung.com
Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
Brown, Len, Rafael J. Wysocki, Amit Dinel Kachhap
In-Reply-To: <5090D6F7.5040401@samsung.com>
Hi,
[A big cut.]
> >> +
> >> + mutex_lock(&data->lock);
> >> + clk_enable(data->clk);
> >> +
> >> + reg = readl(data->base + EXYNOS_EMUL_CON);
> >> + enable = reg & EXYNOS_EMUL_ENABLE;
> >> + if (!enable && !temp)
> >> + goto out;
> > I think you what you are trying to do here is this:
> > If the emulation is already disabled, and 'this' write tries to
> > disable it again, you jump to 'out' as an optimization.
> > Please correct me if I am wrong.
> Yes, you're right. If we try to disable the emulation mode despite it already is
> disabled,
> then emulation mode will be failed and we can't use it. Because emulation
> mode has some
> strange characteristic.
> Let me explain more detail. Emulation mode requires synchronous of any
> value changing and
> enabling. It means you can't change any value (next target temperature,
> sensing time delay)
> without enabling. In this code, disabling overlapping makes problem at initial
> state. At the initial,
> there is no next target temperature and only value 1 for delay time. But if
> you try to write 0 again
> to sysfs node, temp, then it write delay time with 938us and next
> temperature with minimum
> temperature automatically. Value is changed but enable bit is still disabled.
> This is what the
> problem is happened.
Thanks for the detailed Explanation.
> >> }
> >> +#ifdef CONFIG_EXYNOS_THERMAL_EMUL
> >> + device_create_file(&pdev->dev, &dev_attr_emulation);
> > Don't we want to capture the return value here ?
> > Also, if we conditionally create this, we should remove this conditionally
> also.
> > I did not see a corresponding device_remove_file for this attr.
> Sorry, It's my mistake. I'll fix it.
> >> +#endif
> > Can we club all the code inside CONFIG_*_EMUL at one place ?
> > This will make it neat, and not spread the #ifdefs all over the driver.
> I'd like to do either. But I just couldn't find a way.
> Could you give me any idea how to do it ?
I was thinking something like below:
inside #ifdef CONFIG_*_EMUL
int register_emulation_mode(...) { device_create_file(...) };
int unregister_emulation_mode(...) { device_remove_file(...) };
#else
static inline int register..(...) { return 0; }
static inline int unregister..(...) { return 0; }
#endif
Then the rest of the driver can just use register/unregister,
without worrying about #ifdef.
Thanks,
Durga
^ permalink raw reply
* Re: [PATCH v3 2/6] PM / Runtime: introduce pm_runtime_set[get]_memalloc_noio()
From: Oliver Neukum @ 2012-10-31 8:37 UTC (permalink / raw)
To: Ming Lei
Cc: Alan Stern, linux-kernel, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm
In-Reply-To: <CACVXFVNxucCVLS-=EQkmVop3LQMkeXW7RbZq4yfkiq_MUGndvg@mail.gmail.com>
On Wednesday 31 October 2012 11:05:33 Ming Lei wrote:
> On Wed, Oct 31, 2012 at 10:08 AM, Ming Lei <ming.lei@canonical.com> wrote:
> >> I am afraid it is, because a disk may just have been probed as the deviceis being reset.
> >
> > Yes, it is probable, and sounds like similar with 'root_wait' problem, see
> > prepare_namespace(): init/do_mounts.c, so looks no good solution
> > for the problem, and maybe we have to set the flag always before resetting
> > usb device.
>
> The below idea may help the problem which 'memalloc_noio' flag isn't set during
> usb_reset_device().
>
> - for usb mass storage device, call pm_runtime_set_memalloc_noio(true)
> inside usb_stor_probe2() and uas_probe(), and call
> pm_runtime_set_memalloc_noio(false) inside uas_disconnect()
> and usb_stor_disconnect().
>
> - for usb network device, register_netdev() is always called inside usb
> interface's probe(), looks no such problem.
This still leaves networking done over PPP in the cold.
Regards
Oliver
^ permalink raw reply
* Re: [PATCH v2] Thermal: exynos: Add sysfs node supporting exynos's emulation mode.
From: jonghwa3.lee @ 2012-10-31 7:44 UTC (permalink / raw)
To: R, Durgadoss
Cc: Jonghwa Lee, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, Brown, Len, Rafael J. Wysocki,
Amit Dinel Kachhap
In-Reply-To: <4D68720C2E767A4AA6A8796D42C8EB591FDE36@BGSMSX101.gar.corp.intel.com>
On 2012년 10월 31일 15:45, R, Durgadoss wrote:
> Hi,
>
> Looks like a nice feature :-)
> Without something like this, we had been spending time on
> writing test drivers, to actually test our thermal framework code.
Yes, fortunately, Exynos SOCs emulation mode makes our life better. ; )
> BTW, against which tree this patch was generated ?
> Rui's -next or master or Linux-next ?
>
> Some comments below, on a quick glance..
It is based on Rui's -next branch.
>> -----Original Message-----
>> From: Jonghwa Lee [mailto:jonghwa3.lee@samsung.com]
>> Sent: Wednesday, October 31, 2012 9:49 AM
>> To: linux-pm@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org; Brown, Len; R, Durgadoss; Rafael J.
>> Wysocki; Amit Dinel Kachhap; Jonghwa Lee
>> Subject: [PATCH v2] Thermal: exynos: Add sysfs node supporting exynos's
>> emulation mode.
>>
>> This patch supports exynos's emulation mode with newly created sysfs node.
>> Exynos 4x12 (4212, 4412) and 5 series provide emulation mode for thermal
>> management unit. Thermal emulation mode supports software debug for
>> TMU's
>> operation. User can set temperature manually with software code and TMU
>> will read current temperature from user value not from sensor's value.
>> This patch includes also documentary placed under
>> Documentation/thermal/.
>>
>> Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
>> ---
>> v2
>> exynos_thermal.c
>> - Fix build error occured by wrong emulation control register name.
>> - Remove exynos5410 dependent codes.
>> exynos_theraml_emulation
>> - Align indentation.
>>
>> Documentation/thermal/exynos_thermal_emulation | 49 +++++++++++++
>> drivers/thermal/Kconfig | 9 +++
>> drivers/thermal/exynos_thermal.c | 88
>> ++++++++++++++++++++++++
>> 3 files changed, 146 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/thermal/exynos_thermal_emulation
>>
>> diff --git a/Documentation/thermal/exynos_thermal_emulation
>> b/Documentation/thermal/exynos_thermal_emulation
>> new file mode 100644
>> index 0000000..062d867
>> --- /dev/null
>> +++ b/Documentation/thermal/exynos_thermal_emulation
>> @@ -0,0 +1,49 @@
>> +EXYNOS EMULATION MODE
>> +========================
>> +
>> +Copyright (C) 2012 Samsung Electronics
>> +
>> +Writen by Jonghwa Lee <jonghwa3.lee@samsung.com>
>> +
>> +Description
>> +-----------
>> +
>> +Exynos 4x12 (4212, 4412) and 5 series provide emulation mode for thermal
>> management unit.
>> +Thermal emulation mode supports software debug for TMU's operation.
>> User can set temperature
>> +manually with software code and TMU will read current temperature from
>> user value not from
>> +sensor's value.
>> +
>> +Enabling CONFIG_EXYNOS_THERMAL_EMUL option will make this support
>> in available.
>> +When it's enabled, sysfs node will be created under
>> +/sys/bus/platform/devices/'exynos device name'/ with name of
>> 'emulation'.
>> +
>> +The sysfs node, 'emulation', will contain value 0 for the initial state. When
>> you input any
>> +temperature you want to update to sysfs node, it automatically enable
>> emulation mode and
>> +current temperature will be changed into it.
>> +(Exynos also supports user changable delay time which would be used to
>> delay of
>> + changing temperature. However, this node only uses same delay of real
>> sensing time, 938us.)
>> +
>> +Disabling emulation mode only requires writing value 0 to sysfs node.
>> +
>> +
>> +TEMP 120 |
>> + |
>> + 100 |
>> + |
>> + 80 |
>> + | +-----------
>> + 60 | | |
>> + | +-------------| |
>> + 40 | | | |
>> + | | | |
>> + 20 | | | +----------
>> + | | | | |
>> + 0
>> |______________|_____________|__________|__________|_______
>> __
>> + A A A A TIME
>> + |<----->| |<----->| |<----->| |
>> + | 938us | | | | | |
>> +emulation : 0 50 | 70 | 20 | 0
>> +current temp : sensor 50 70 20 sensor
> Thanks for the documentation. Is there a publicly available data sheet for this?
> If so, please provide the link here.
I'm sorry it isn't.
>> +
>> +
>> +
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index e1cb6bd..c02a66c 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -55,3 +55,12 @@ config EXYNOS_THERMAL
>> help
>> If you say yes here you get support for TMU (Thermal Managment
>> Unit) on SAMSUNG EXYNOS series of SoC.
>> +
>> +config EXYNOS_THERMAL_EMUL
>> + bool "EXYNOS TMU emulation mode support"
>> + depends on !CPU_EXYNOS4210 && EXYNOS_THERMAL
>> + help
>> + Exynos 4412 and 4414 and 5 series has emulation mode on TMU.
>> + Enable this option will be make sysfs node in exynos thermal
>> platform
>> + device directory to support emulation mode. With emulation mode
>> sysfs
>> + node, you can manually input temperature to TMU for simulation
>> purpose.
>> diff --git a/drivers/thermal/exynos_thermal.c
>> b/drivers/thermal/exynos_thermal.c
>> index fd03e85..9e3c150 100644
>> --- a/drivers/thermal/exynos_thermal.c
>> +++ b/drivers/thermal/exynos_thermal.c
>> @@ -99,6 +99,15 @@
>> #define IDLE_INTERVAL 10000
>> #define MCELSIUS 1000
>>
>> +#ifdef CONFIG_EXYNOS_THERMAL_EMUL
>> +#define EXYNOS_EMUL_TIME 0x57F0
>> +#define EXYNOS_EMUL_TIME_SHIFT 16
>> +#define EXYNOS_EMUL_DATA_SHIFT 8
>> +#define EXYNOS_EMUL_DATA_MASK 0xFF
>> +#define EXYNOS_EMUL_DISABLE 0x0
>> +#define EXYNOS_EMUL_ENABLE 0x1
>> +#endif /* CONFIG_EXYNOS_THERMAL_EMUL */
>> +
>> /* CPU Zone information */
>> #define PANIC_ZONE 4
>> #define WARN_ZONE 3
>> @@ -832,6 +841,82 @@ static inline struct exynos_tmu_platform_data
>> *exynos_get_driver_data(
>> return (struct exynos_tmu_platform_data *)
>> platform_get_device_id(pdev)->driver_data;
>> }
>> +
>> +#ifdef CONFIG_EXYNOS_THERMAL_EMUL
>> +static ssize_t exynos_tmu_emulation_show(struct device *dev,
>> + struct device_attribute *attr,
>> + char *buf)
>> +{
>> + struct platform_device *pdev = container_of(dev,
>> + struct platform_device, dev);
>> + struct exynos_tmu_data *data = platform_get_drvdata(pdev);
>> + unsigned int reg;
>> + u8 temp_code;
>> + int temp, enable;
>> +
>> + mutex_lock(&data->lock);
>> + clk_enable(data->clk);
>> + reg = readl(data->base + EXYNOS_EMUL_CON);
>> + clk_disable(data->clk);
>> + mutex_unlock(&data->lock);
>> +
>> + enable = reg & EXYNOS_EMUL_ENABLE;
> Looks like we don't need this variable 'enable'.
> Also, initialize temp to 0 in the beginning, which will save the
> else part of the code.
Some maintainers warn me off using 0 initializing at beginning.
Anyway, I'll follow you this time.
>> +
>> + if (enable) {
>> + reg >>= EXYNOS_EMUL_DATA_SHIFT;
>> + temp_code = reg & EXYNOS_EMUL_DATA_MASK;
>> + temp = code_to_temp(data, temp_code);
>> + } else {
>> + temp = 0;
>> + }
>> +
>> + return sprintf(buf, "%d\n", temp);
>> +}
>> +
>> +static ssize_t exynos_tmu_emulation_store(struct device *dev,
>> + struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + struct platform_device *pdev = container_of(dev,
>> + struct platform_device, dev);
>> + struct exynos_tmu_data *data = platform_get_drvdata(pdev);
>> + unsigned int reg;
>> + u8 temp_code;
>> + int temp, enable, i;
>> +
>> + if (!sscanf(buf, "%d\n", &temp))
>> + return -EINVAL;
>> +
>> + if (temp < 0)
>> + return -EINVAL;
> Why not combine both the if s using || ?
Okay, I'll fix it.
>> +
>> + mutex_lock(&data->lock);
>> + clk_enable(data->clk);
>> +
>> + reg = readl(data->base + EXYNOS_EMUL_CON);
>> + enable = reg & EXYNOS_EMUL_ENABLE;
>> + if (!enable && !temp)
>> + goto out;
> I think you what you are trying to do here is this:
> If the emulation is already disabled, and 'this' write tries to
> disable it again, you jump to 'out' as an optimization.
> Please correct me if I am wrong.
Yes, you're right. If we try to disable the emulation mode despite it already is disabled,
then emulation mode will be failed and we can't use it. Because emulation mode has some
strange characteristic.
Let me explain more detail. Emulation mode requires synchronous of any value changing and
enabling. It means you can't change any value (next target temperature, sensing time delay)
without enabling. In this code, disabling overlapping makes problem at initial state. At the initial,
there is no next target temperature and only value 1 for delay time. But if you try to write 0 again
to sysfs node, temp, then it write delay time with 938us and next temperature with minimum
temperature automatically. Value is changed but enable bit is still disabled. This is what the
problem is happened.
> In this case, name the variable is_enabled or something like
> that, which makes the check more explicit.
Okay, I'll consider of it.
>> +
>> + temp_code = (reg >> EXYNOS_EMUL_DATA_SHIFT) &
>> EXYNOS_EMUL_DATA_MASK;
>> + temp_code = temp == 0 ? temp_code : temp_to_code(data, temp);
>> +
>> + reg = (EXYNOS_EMUL_TIME << EXYNOS_EMUL_TIME_SHIFT) |
>> + (temp_code << EXYNOS_EMUL_DATA_SHIFT) |
>> + (temp > 0 ? EXYNOS_EMUL_ENABLE :
>> EXYNOS_EMUL_DISABLE);
> 2 things here:
> 1. Can we make the temp > 0 comparison as a separate statement, so that
> it is easy to read/maintain ?
>
> 2. you are comparing temp > 0 here, but above you return when temp < 0.
> Looks like, in this case, the flow will never reach here, when temp < 0.
Yes, The case, temp < 0 , will never get here. but I want to separate the case, temp = 0 and
temp > 0. I'll modify this to be more clear.
>> +
>> + writel(reg, data->base + EXYNOS_EMUL_CON);
>> +out:
>> + clk_disable(data->clk);
>> + mutex_unlock(&data->lock);
>> +
>> + return count;
>> +}
>> +
>> +static DEVICE_ATTR(emulation, 0644, exynos_tmu_emulation_show,
>> + exynos_tmu_emulation_store);
>> +#endif
>> +
>> static int __devinit exynos_tmu_probe(struct platform_device *pdev)
>> {
>> struct exynos_tmu_data *data;
>> @@ -930,6 +1015,9 @@ static int __devinit exynos_tmu_probe(struct
>> platform_device *pdev)
>> dev_err(&pdev->dev, "Failed to register thermal
>> interface\n");
>> goto err_clk;
>> }
>> +#ifdef CONFIG_EXYNOS_THERMAL_EMUL
>> + device_create_file(&pdev->dev, &dev_attr_emulation);
> Don't we want to capture the return value here ?
> Also, if we conditionally create this, we should remove this conditionally also.
> I did not see a corresponding device_remove_file for this attr.
Sorry, It's my mistake. I'll fix it.
>> +#endif
> Can we club all the code inside CONFIG_*_EMUL at one place ?
> This will make it neat, and not spread the #ifdefs all over the driver.
I'd like to do either. But I just couldn't find a way.
Could you give me any idea how to do it ?
Best regards,
Jonghwa Lee.
> Thanks,
> Durga
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* RE: [PATCH v2] Thermal: exynos: Add sysfs node supporting exynos's emulation mode.
From: R, Durgadoss @ 2012-10-31 6:45 UTC (permalink / raw)
To: Jonghwa Lee, linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Brown, Len, Rafael J. Wysocki,
Amit Dinel Kachhap
In-Reply-To: <1351657147-26092-1-git-send-email-jonghwa3.lee@samsung.com>
Hi,
Looks like a nice feature :-)
Without something like this, we had been spending time on
writing test drivers, to actually test our thermal framework code.
BTW, against which tree this patch was generated ?
Rui's -next or master or Linux-next ?
Some comments below, on a quick glance..
> -----Original Message-----
> From: Jonghwa Lee [mailto:jonghwa3.lee@samsung.com]
> Sent: Wednesday, October 31, 2012 9:49 AM
> To: linux-pm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Brown, Len; R, Durgadoss; Rafael J.
> Wysocki; Amit Dinel Kachhap; Jonghwa Lee
> Subject: [PATCH v2] Thermal: exynos: Add sysfs node supporting exynos's
> emulation mode.
>
> This patch supports exynos's emulation mode with newly created sysfs node.
> Exynos 4x12 (4212, 4412) and 5 series provide emulation mode for thermal
> management unit. Thermal emulation mode supports software debug for
> TMU's
> operation. User can set temperature manually with software code and TMU
> will read current temperature from user value not from sensor's value.
> This patch includes also documentary placed under
> Documentation/thermal/.
>
> Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
> ---
> v2
> exynos_thermal.c
> - Fix build error occured by wrong emulation control register name.
> - Remove exynos5410 dependent codes.
> exynos_theraml_emulation
> - Align indentation.
>
> Documentation/thermal/exynos_thermal_emulation | 49 +++++++++++++
> drivers/thermal/Kconfig | 9 +++
> drivers/thermal/exynos_thermal.c | 88
> ++++++++++++++++++++++++
> 3 files changed, 146 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/thermal/exynos_thermal_emulation
>
> diff --git a/Documentation/thermal/exynos_thermal_emulation
> b/Documentation/thermal/exynos_thermal_emulation
> new file mode 100644
> index 0000000..062d867
> --- /dev/null
> +++ b/Documentation/thermal/exynos_thermal_emulation
> @@ -0,0 +1,49 @@
> +EXYNOS EMULATION MODE
> +========================
> +
> +Copyright (C) 2012 Samsung Electronics
> +
> +Writen by Jonghwa Lee <jonghwa3.lee@samsung.com>
> +
> +Description
> +-----------
> +
> +Exynos 4x12 (4212, 4412) and 5 series provide emulation mode for thermal
> management unit.
> +Thermal emulation mode supports software debug for TMU's operation.
> User can set temperature
> +manually with software code and TMU will read current temperature from
> user value not from
> +sensor's value.
> +
> +Enabling CONFIG_EXYNOS_THERMAL_EMUL option will make this support
> in available.
> +When it's enabled, sysfs node will be created under
> +/sys/bus/platform/devices/'exynos device name'/ with name of
> 'emulation'.
> +
> +The sysfs node, 'emulation', will contain value 0 for the initial state. When
> you input any
> +temperature you want to update to sysfs node, it automatically enable
> emulation mode and
> +current temperature will be changed into it.
> +(Exynos also supports user changable delay time which would be used to
> delay of
> + changing temperature. However, this node only uses same delay of real
> sensing time, 938us.)
> +
> +Disabling emulation mode only requires writing value 0 to sysfs node.
> +
> +
> +TEMP 120 |
> + |
> + 100 |
> + |
> + 80 |
> + | +-----------
> + 60 | | |
> + | +-------------| |
> + 40 | | | |
> + | | | |
> + 20 | | | +----------
> + | | | | |
> + 0
> |______________|_____________|__________|__________|_______
> __
> + A A A A TIME
> + |<----->| |<----->| |<----->| |
> + | 938us | | | | | |
> +emulation : 0 50 | 70 | 20 | 0
> +current temp : sensor 50 70 20 sensor
Thanks for the documentation. Is there a publicly available data sheet for this?
If so, please provide the link here.
> +
> +
> +
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index e1cb6bd..c02a66c 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -55,3 +55,12 @@ config EXYNOS_THERMAL
> help
> If you say yes here you get support for TMU (Thermal Managment
> Unit) on SAMSUNG EXYNOS series of SoC.
> +
> +config EXYNOS_THERMAL_EMUL
> + bool "EXYNOS TMU emulation mode support"
> + depends on !CPU_EXYNOS4210 && EXYNOS_THERMAL
> + help
> + Exynos 4412 and 4414 and 5 series has emulation mode on TMU.
> + Enable this option will be make sysfs node in exynos thermal
> platform
> + device directory to support emulation mode. With emulation mode
> sysfs
> + node, you can manually input temperature to TMU for simulation
> purpose.
> diff --git a/drivers/thermal/exynos_thermal.c
> b/drivers/thermal/exynos_thermal.c
> index fd03e85..9e3c150 100644
> --- a/drivers/thermal/exynos_thermal.c
> +++ b/drivers/thermal/exynos_thermal.c
> @@ -99,6 +99,15 @@
> #define IDLE_INTERVAL 10000
> #define MCELSIUS 1000
>
> +#ifdef CONFIG_EXYNOS_THERMAL_EMUL
> +#define EXYNOS_EMUL_TIME 0x57F0
> +#define EXYNOS_EMUL_TIME_SHIFT 16
> +#define EXYNOS_EMUL_DATA_SHIFT 8
> +#define EXYNOS_EMUL_DATA_MASK 0xFF
> +#define EXYNOS_EMUL_DISABLE 0x0
> +#define EXYNOS_EMUL_ENABLE 0x1
> +#endif /* CONFIG_EXYNOS_THERMAL_EMUL */
> +
> /* CPU Zone information */
> #define PANIC_ZONE 4
> #define WARN_ZONE 3
> @@ -832,6 +841,82 @@ static inline struct exynos_tmu_platform_data
> *exynos_get_driver_data(
> return (struct exynos_tmu_platform_data *)
> platform_get_device_id(pdev)->driver_data;
> }
> +
> +#ifdef CONFIG_EXYNOS_THERMAL_EMUL
> +static ssize_t exynos_tmu_emulation_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct platform_device *pdev = container_of(dev,
> + struct platform_device, dev);
> + struct exynos_tmu_data *data = platform_get_drvdata(pdev);
> + unsigned int reg;
> + u8 temp_code;
> + int temp, enable;
> +
> + mutex_lock(&data->lock);
> + clk_enable(data->clk);
> + reg = readl(data->base + EXYNOS_EMUL_CON);
> + clk_disable(data->clk);
> + mutex_unlock(&data->lock);
> +
> + enable = reg & EXYNOS_EMUL_ENABLE;
Looks like we don't need this variable 'enable'.
Also, initialize temp to 0 in the beginning, which will save the
else part of the code.
> +
> + if (enable) {
> + reg >>= EXYNOS_EMUL_DATA_SHIFT;
> + temp_code = reg & EXYNOS_EMUL_DATA_MASK;
> + temp = code_to_temp(data, temp_code);
> + } else {
> + temp = 0;
> + }
> +
> + return sprintf(buf, "%d\n", temp);
> +}
> +
> +static ssize_t exynos_tmu_emulation_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct platform_device *pdev = container_of(dev,
> + struct platform_device, dev);
> + struct exynos_tmu_data *data = platform_get_drvdata(pdev);
> + unsigned int reg;
> + u8 temp_code;
> + int temp, enable, i;
> +
> + if (!sscanf(buf, "%d\n", &temp))
> + return -EINVAL;
> +
> + if (temp < 0)
> + return -EINVAL;
Why not combine both the if s using || ?
> +
> + mutex_lock(&data->lock);
> + clk_enable(data->clk);
> +
> + reg = readl(data->base + EXYNOS_EMUL_CON);
> + enable = reg & EXYNOS_EMUL_ENABLE;
> + if (!enable && !temp)
> + goto out;
I think you what you are trying to do here is this:
If the emulation is already disabled, and 'this' write tries to
disable it again, you jump to 'out' as an optimization.
Please correct me if I am wrong.
In this case, name the variable is_enabled or something like
that, which makes the check more explicit.
> +
> + temp_code = (reg >> EXYNOS_EMUL_DATA_SHIFT) &
> EXYNOS_EMUL_DATA_MASK;
> + temp_code = temp == 0 ? temp_code : temp_to_code(data, temp);
> +
> + reg = (EXYNOS_EMUL_TIME << EXYNOS_EMUL_TIME_SHIFT) |
> + (temp_code << EXYNOS_EMUL_DATA_SHIFT) |
> + (temp > 0 ? EXYNOS_EMUL_ENABLE :
> EXYNOS_EMUL_DISABLE);
2 things here:
1. Can we make the temp > 0 comparison as a separate statement, so that
it is easy to read/maintain ?
2. you are comparing temp > 0 here, but above you return when temp < 0.
Looks like, in this case, the flow will never reach here, when temp < 0.
> +
> + writel(reg, data->base + EXYNOS_EMUL_CON);
> +out:
> + clk_disable(data->clk);
> + mutex_unlock(&data->lock);
> +
> + return count;
> +}
> +
> +static DEVICE_ATTR(emulation, 0644, exynos_tmu_emulation_show,
> + exynos_tmu_emulation_store);
> +#endif
> +
> static int __devinit exynos_tmu_probe(struct platform_device *pdev)
> {
> struct exynos_tmu_data *data;
> @@ -930,6 +1015,9 @@ static int __devinit exynos_tmu_probe(struct
> platform_device *pdev)
> dev_err(&pdev->dev, "Failed to register thermal
> interface\n");
> goto err_clk;
> }
> +#ifdef CONFIG_EXYNOS_THERMAL_EMUL
> + device_create_file(&pdev->dev, &dev_attr_emulation);
Don't we want to capture the return value here ?
Also, if we conditionally create this, we should remove this conditionally also.
I did not see a corresponding device_remove_file for this attr.
> +#endif
Can we club all the code inside CONFIG_*_EMUL at one place ?
This will make it neat, and not spread the #ifdefs all over the driver.
Thanks,
Durga
^ permalink raw reply
* [PATCH] cpufreq: remove the unnecessary initialization of a local variable
From: Jingoo Han @ 2012-10-31 5:49 UTC (permalink / raw)
To: 'Rafael J. Wysocki'
Cc: cpufreq, linux-pm, linux-kernel, 'Jingoo Han'
This patch removes unnecessary initializer for the 'ret' variable.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/cpufreq/cpufreq.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 261ef65..4e9fcc5 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -404,7 +404,7 @@ static int __cpufreq_set_policy(struct cpufreq_policy *data,
static ssize_t store_##file_name \
(struct cpufreq_policy *policy, const char *buf, size_t count) \
{ \
- unsigned int ret = -EINVAL; \
+ unsigned int ret; \
struct cpufreq_policy new_policy; \
\
ret = cpufreq_get_policy(&new_policy, policy->cpu); \
@@ -459,7 +459,7 @@ static ssize_t show_scaling_governor(struct cpufreq_policy *policy, char *buf)
static ssize_t store_scaling_governor(struct cpufreq_policy *policy,
const char *buf, size_t count)
{
- unsigned int ret = -EINVAL;
+ unsigned int ret;
char str_governor[16];
struct cpufreq_policy new_policy;
--
1.7.1
^ permalink raw reply related
* [PATCH v2] Thermal: exynos: Add sysfs node supporting exynos's emulation mode.
From: Jonghwa Lee @ 2012-10-31 4:19 UTC (permalink / raw)
To: linux-pm
Cc: linux-kernel, Len Brown, Durgadoss R, Rafael J. Wysocki,
Amit Dinel Kachhap, Jonghwa Lee
This patch supports exynos's emulation mode with newly created sysfs node.
Exynos 4x12 (4212, 4412) and 5 series provide emulation mode for thermal
management unit. Thermal emulation mode supports software debug for TMU's
operation. User can set temperature manually with software code and TMU
will read current temperature from user value not from sensor's value.
This patch includes also documentary placed under Documentation/thermal/.
Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
---
v2
exynos_thermal.c
- Fix build error occured by wrong emulation control register name.
- Remove exynos5410 dependent codes.
exynos_theraml_emulation
- Align indentation.
Documentation/thermal/exynos_thermal_emulation | 49 +++++++++++++
drivers/thermal/Kconfig | 9 +++
drivers/thermal/exynos_thermal.c | 88 ++++++++++++++++++++++++
3 files changed, 146 insertions(+), 0 deletions(-)
create mode 100644 Documentation/thermal/exynos_thermal_emulation
diff --git a/Documentation/thermal/exynos_thermal_emulation b/Documentation/thermal/exynos_thermal_emulation
new file mode 100644
index 0000000..062d867
--- /dev/null
+++ b/Documentation/thermal/exynos_thermal_emulation
@@ -0,0 +1,49 @@
+EXYNOS EMULATION MODE
+========================
+
+Copyright (C) 2012 Samsung Electronics
+
+Writen by Jonghwa Lee <jonghwa3.lee@samsung.com>
+
+Description
+-----------
+
+Exynos 4x12 (4212, 4412) and 5 series provide emulation mode for thermal management unit.
+Thermal emulation mode supports software debug for TMU's operation. User can set temperature
+manually with software code and TMU will read current temperature from user value not from
+sensor's value.
+
+Enabling CONFIG_EXYNOS_THERMAL_EMUL option will make this support in available.
+When it's enabled, sysfs node will be created under
+/sys/bus/platform/devices/'exynos device name'/ with name of 'emulation'.
+
+The sysfs node, 'emulation', will contain value 0 for the initial state. When you input any
+temperature you want to update to sysfs node, it automatically enable emulation mode and
+current temperature will be changed into it.
+(Exynos also supports user changable delay time which would be used to delay of
+ changing temperature. However, this node only uses same delay of real sensing time, 938us.)
+
+Disabling emulation mode only requires writing value 0 to sysfs node.
+
+
+TEMP 120 |
+ |
+ 100 |
+ |
+ 80 |
+ | +-----------
+ 60 | | |
+ | +-------------| |
+ 40 | | | |
+ | | | |
+ 20 | | | +----------
+ | | | | |
+ 0 |______________|_____________|__________|__________|_________
+ A A A A TIME
+ |<----->| |<----->| |<----->| |
+ | 938us | | | | | |
+emulation : 0 50 | 70 | 20 | 0
+current temp : sensor 50 70 20 sensor
+
+
+
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index e1cb6bd..c02a66c 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -55,3 +55,12 @@ config EXYNOS_THERMAL
help
If you say yes here you get support for TMU (Thermal Managment
Unit) on SAMSUNG EXYNOS series of SoC.
+
+config EXYNOS_THERMAL_EMUL
+ bool "EXYNOS TMU emulation mode support"
+ depends on !CPU_EXYNOS4210 && EXYNOS_THERMAL
+ help
+ Exynos 4412 and 4414 and 5 series has emulation mode on TMU.
+ Enable this option will be make sysfs node in exynos thermal platform
+ device directory to support emulation mode. With emulation mode sysfs
+ node, you can manually input temperature to TMU for simulation purpose.
diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index fd03e85..9e3c150 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -99,6 +99,15 @@
#define IDLE_INTERVAL 10000
#define MCELSIUS 1000
+#ifdef CONFIG_EXYNOS_THERMAL_EMUL
+#define EXYNOS_EMUL_TIME 0x57F0
+#define EXYNOS_EMUL_TIME_SHIFT 16
+#define EXYNOS_EMUL_DATA_SHIFT 8
+#define EXYNOS_EMUL_DATA_MASK 0xFF
+#define EXYNOS_EMUL_DISABLE 0x0
+#define EXYNOS_EMUL_ENABLE 0x1
+#endif /* CONFIG_EXYNOS_THERMAL_EMUL */
+
/* CPU Zone information */
#define PANIC_ZONE 4
#define WARN_ZONE 3
@@ -832,6 +841,82 @@ static inline struct exynos_tmu_platform_data *exynos_get_driver_data(
return (struct exynos_tmu_platform_data *)
platform_get_device_id(pdev)->driver_data;
}
+
+#ifdef CONFIG_EXYNOS_THERMAL_EMUL
+static ssize_t exynos_tmu_emulation_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct platform_device *pdev = container_of(dev,
+ struct platform_device, dev);
+ struct exynos_tmu_data *data = platform_get_drvdata(pdev);
+ unsigned int reg;
+ u8 temp_code;
+ int temp, enable;
+
+ mutex_lock(&data->lock);
+ clk_enable(data->clk);
+ reg = readl(data->base + EXYNOS_EMUL_CON);
+ clk_disable(data->clk);
+ mutex_unlock(&data->lock);
+
+ enable = reg & EXYNOS_EMUL_ENABLE;
+
+ if (enable) {
+ reg >>= EXYNOS_EMUL_DATA_SHIFT;
+ temp_code = reg & EXYNOS_EMUL_DATA_MASK;
+ temp = code_to_temp(data, temp_code);
+ } else {
+ temp = 0;
+ }
+
+ return sprintf(buf, "%d\n", temp);
+}
+
+static ssize_t exynos_tmu_emulation_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct platform_device *pdev = container_of(dev,
+ struct platform_device, dev);
+ struct exynos_tmu_data *data = platform_get_drvdata(pdev);
+ unsigned int reg;
+ u8 temp_code;
+ int temp, enable, i;
+
+ if (!sscanf(buf, "%d\n", &temp))
+ return -EINVAL;
+
+ if (temp < 0)
+ return -EINVAL;
+
+ mutex_lock(&data->lock);
+ clk_enable(data->clk);
+
+ reg = readl(data->base + EXYNOS_EMUL_CON);
+ enable = reg & EXYNOS_EMUL_ENABLE;
+ if (!enable && !temp)
+ goto out;
+
+ temp_code = (reg >> EXYNOS_EMUL_DATA_SHIFT) & EXYNOS_EMUL_DATA_MASK;
+ temp_code = temp == 0 ? temp_code : temp_to_code(data, temp);
+
+ reg = (EXYNOS_EMUL_TIME << EXYNOS_EMUL_TIME_SHIFT) |
+ (temp_code << EXYNOS_EMUL_DATA_SHIFT) |
+ (temp > 0 ? EXYNOS_EMUL_ENABLE : EXYNOS_EMUL_DISABLE);
+
+ writel(reg, data->base + EXYNOS_EMUL_CON);
+out:
+ clk_disable(data->clk);
+ mutex_unlock(&data->lock);
+
+ return count;
+}
+
+static DEVICE_ATTR(emulation, 0644, exynos_tmu_emulation_show,
+ exynos_tmu_emulation_store);
+#endif
+
static int __devinit exynos_tmu_probe(struct platform_device *pdev)
{
struct exynos_tmu_data *data;
@@ -930,6 +1015,9 @@ static int __devinit exynos_tmu_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "Failed to register thermal interface\n");
goto err_clk;
}
+#ifdef CONFIG_EXYNOS_THERMAL_EMUL
+ device_create_file(&pdev->dev, &dev_attr_emulation);
+#endif
return 0;
err_clk:
platform_set_drvdata(pdev, NULL);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH v3 2/6] PM / Runtime: introduce pm_runtime_set[get]_memalloc_noio()
From: Ming Lei @ 2012-10-31 3:05 UTC (permalink / raw)
To: Oliver Neukum
Cc: Alan Stern, linux-kernel, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm
In-Reply-To: <CACVXFVMRJPfPSC_4ZamqfYUSYNsMEVYXMFmcs26T=4MdB_Kntw@mail.gmail.com>
On Wed, Oct 31, 2012 at 10:08 AM, Ming Lei <ming.lei@canonical.com> wrote:
>> I am afraid it is, because a disk may just have been probed as the deviceis being reset.
>
> Yes, it is probable, and sounds like similar with 'root_wait' problem, see
> prepare_namespace(): init/do_mounts.c, so looks no good solution
> for the problem, and maybe we have to set the flag always before resetting
> usb device.
The below idea may help the problem which 'memalloc_noio' flag isn't set during
usb_reset_device().
- for usb mass storage device, call pm_runtime_set_memalloc_noio(true)
inside usb_stor_probe2() and uas_probe(), and call
pm_runtime_set_memalloc_noio(false) inside uas_disconnect()
and usb_stor_disconnect().
- for usb network device, register_netdev() is always called inside usb
interface's probe(), looks no such problem.
Thanks,
--
Ming Lei
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH V3 4/5] Thermal: Add ST-Ericsson DB8500 thermal driver.
From: Viresh Kumar @ 2012-10-31 2:33 UTC (permalink / raw)
To: hongbo.zhang
Cc: linaro-dev, linux-kernel, linux-pm, rui.zhang, amit.kachhap,
STEricsson_nomadik_linux, kernel, linaro-kernel, hongbo.zhang,
patches
In-Reply-To: <1351615741-24134-5-git-send-email-hongbo.zhang@linaro.com>
Sorry for late comments :(
On 30 October 2012 22:19, hongbo.zhang <hongbo.zhang@linaro.org> wrote:
> From: "hongbo.zhang" <hongbo.zhang@linaro.com>
>
> This diver is based on the thermal management framework in thermal_sys.c. A
s/diver/driver
> thermal zone device is created with the trip points to which cooling devices
> can be bound, the current cooling device is cpufreq, e.g. CPU frequency is
> clipped down to cool the CPU, and other cooling devices can be added and bound
> to the trip points dynamically. The platform specific PRCMU interrupts are
> used to active thermal update when trip points are reached.
>
> Signed-off-by: hongbo.zhang <hongbo.zhang@linaro.com>
> ---
> .../devicetree/bindings/thermal/db8500-thermal.txt | 40 ++
> drivers/thermal/Kconfig | 20 +
> drivers/thermal/Makefile | 2 +
> drivers/thermal/db8500_cpufreq_cooling.c | 108 +++++
> drivers/thermal/db8500_thermal.c | 531 +++++++++++++++++++++
> include/linux/platform_data/db8500_thermal.h | 38 ++
> 6 files changed, 739 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/thermal/db8500-thermal.txt
> create mode 100644 drivers/thermal/db8500_cpufreq_cooling.c
> create mode 100644 drivers/thermal/db8500_thermal.c
> create mode 100644 include/linux/platform_data/db8500_thermal.h
>
> diff --git a/Documentation/devicetree/bindings/thermal/db8500-thermal.txt b/Documentation/devicetree/bindings/thermal/db8500-thermal.txt
> new file mode 100644
> index 0000000..cab6916
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/db8500-thermal.txt
> @@ -0,0 +1,40 @@
> +* ST-Ericsson DB8500 Thermal
> +
> +** Thermal node properties:
> +
> +- compatible : "stericsson,db8500-thermal";
> +- reg : address range of the thermal sensor registers;
> +- interrupts : interrupts generated from PRCMU;
> +- interrupt-names : "IRQ_HOTMON_LOW" and "IRQ_HOTMON_HIGH";
Just mention here that below properties are optional or required.
> +- num-trips : number of total trip points;
> +- tripN-temp : temperature of trip point N, should be in ascending order;
> +- tripN-type : type of trip point N, should be one of "active" "passive" "hot" "critical";
> +- tripN-cdev-num : number of the cooling devices which can be bound to trip point N;
> +- tripN-cdev-nameM : name of the No. M cooling device of trip point N;
> diff --git a/drivers/thermal/db8500_thermal.c b/drivers/thermal/db8500_thermal.c
> +static int db8500_thermal_match_cdev(struct thermal_cooling_device *cdev,
> + struct db8500_trip_point *trip_points)
> +{
> + int i;
> + char *cdev_name;
> +
> + if (!strlen(cdev->type))
> + return -EINVAL;
> +
> + for (i = 0; i < COOLING_DEV_MAX; i++) {
> + cdev_name = trip_points->cdev_name[i];
> + if (!strcmp(cdev_name, cdev->type))
You can actually remove cdev_name variable. and use
if (!strcmp(trip_points->cdev_name[i], cdev->type))
> + return 0;
> + }
> +
> + return -ENODEV;
> +}
> +#ifdef CONFIG_OF
> +static struct db8500_thsens_platform_data*
> + db8500_thermal_parse_dt(struct platform_device *pdev)
> +{
> + for (j = 0; j < tmp_data; j++) {
> + sprintf(prop_name, "trip%d-cdev-name%d", i, j);
> + if (of_property_read_string(np, prop_name, &tmp_str))
> + goto err_parse_dt;
> +
> + if (strlen(tmp_str) > THERMAL_NAME_LENGTH)
> + goto err_parse_dt;
> +
> + strcpy(ptrips->trip_points[i].cdev_name[j], tmp_str);
want to check if it is copied or not??
> + }
> + }
> + return ptrips;
> +
> +err_parse_dt:
> + dev_err(&pdev->dev, "Parsing device tree data error.\n");
> + return NULL;
> +}
After these please add my:
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply
* Re: Re: [linux-next PATCH] PM / devfreq: documentation cleanups for devfreq header
From: 함명주 @ 2012-10-31 2:27 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Randy Dunlap, Nishanth Menon, linux-pm@vger.kernel.org,
Rajagopal Venkat, 박경민, Kevin Hilman,
linux-kernel@vger.kernel.org, 이종화
> On Tuesday, October 30, 2012 08:09:09 AM MyungJoo Ham wrote:
[]
> >
> > Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
> >
> > Applying to git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git for-rafael, which is based on rafael's linux-pm.git / linux-next.
> >
> > http://git.kernel.org/?p=linux/kernel/git/mzx/devfreq.git;a=shortlog;h=refs/heads/for-rafael
> >
> > I'll apply your "Add sysfs node ..." patch after refactoring with Jonghwa's (devfreq trans_stat) as the two patches use the same data (list of available freqs).
>
> May I assume that you'll handle all of the subsequent devfreq patches too?
>
> Rafael
Yes, you may. I'll apply the patches (currently at http://git.kernel.org/?p=linux/kernel/git/mzx/devfreq.git;a=shortlog;h=refs/heads/for-rafael ) and send pull requests to you or Linus.
Anyway, do you want me to keep sending pull requests to you as you've told
last time?
Cheers,
MyungJoo
^ permalink raw reply
* Re: [PATCH V3 5/5] Thermal: Add ST-Ericsson DB8500 thermal properties and platform data.
From: viresh kumar @ 2012-10-31 2:18 UTC (permalink / raw)
To: hongbo.zhang
Cc: linaro-dev, linux-kernel, linux-pm, rui.zhang, amit.kachhap,
patches, linaro-kernel, STEricsson_nomadik_linux, kernel,
hongbo.zhang
In-Reply-To: <1351615741-24134-6-git-send-email-hongbo.zhang@linaro.com>
On Tue, Oct 30, 2012 at 10:19 PM, hongbo.zhang <hongbo.zhang@linaro.org> wrote:
> From: "hongbo.zhang" <hongbo.zhang@linaro.com>
Just a minor comment below.
> This patch adds device tree properties for ST-Ericsson DB8500 thermal driver,
> also adds the platform data to support the old fashion.
>
> Signed-off-by: hongbo.zhang <hongbo.zhang@linaro.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> arch/arm/boot/dts/dbx5x0.dtsi | 14 +++++++++
> arch/arm/boot/dts/snowball.dts | 31 ++++++++++++++++++
> arch/arm/configs/u8500_defconfig | 4 +++
> arch/arm/mach-ux500/board-mop500.c | 64 ++++++++++++++++++++++++++++++++++++++
> 4 files changed, 113 insertions(+)
> diff --git a/arch/arm/configs/u8500_defconfig b/arch/arm/configs/u8500_defconfig
> index cc5e7a8..34918c4 100644
> --- a/arch/arm/configs/u8500_defconfig
> +++ b/arch/arm/configs/u8500_defconfig
> @@ -118,3 +118,7 @@ CONFIG_DEBUG_KERNEL=y
> CONFIG_DEBUG_INFO=y
> # CONFIG_FTRACE is not set
> CONFIG_DEBUG_USER=y
> +CONFIG_THERMAL=y
> +CONFIG_CPU_THERMAL=y
> +CONFIG_DB8500_THERMAL=y
> +CONFIG_DB8500_CPUFREQ_COOLING=y
Have you entered these manually?? Or used make savedefconfig?
^ permalink raw reply
* Re: Re: [for-next PATCH V2] PM / devfreq: Add sysfs node to expose available frequencies
From: MyungJoo Ham @ 2012-10-31 2:11 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Nishanth Menon, linux-pm, Rajagopal Venkat,
박경민, Kevin Hilman,
linux-kernel@vger.kernel.org
> On Friday, October 26, 2012 06:16:36 AM MyungJoo Ham wrote:
> > > devfreq governors such as ondemand are controlled by a min and
> > > max frequency, while governors like userspace governor allow us
> > > to set a specific frequency.
> > > However, for the same specific device, depending on the SoC, the
> > > available frequencies can vary.
> > >
> > > So expose the available frequencies as a snapshot over sysfs to
> > > allow informed decisions.
> > >
> > > This was inspired by cpufreq framework's equivalent for similar
> > > usage sysfs node: scaling_available_frequencies.
> > >
> > > Cc: Rajagopal Venkat <rajagopal.venkat@linaro.org>
> > > Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
> > > Cc: Kyungmin Park <kyungmin.park@samsung.com>
> > > Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
> > > Cc: Kevin Hilman <khilman@ti.com>
> > > Cc: linux-pm@vger.kernel.org
> > > Cc: linux-kernel@vger.kernel.org
> > >
> > > Signed-off-by: Nishanth Menon <nm@ti.com>
> >
> > Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
>
> Are you going to handle this patch?
Yes, I've just setup the git repository this week
and I'm willing to handle this one.
It is applied at
http://git.kernel.org/?p=linux/kernel/git/mzx/devfreq.git;a=shortlog;h=refs/heads/for-rafael
Thanks,
MyungJoo
>
> Rafael
>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
>
>
>
>
>
>
>
^ permalink raw reply
* Re: [PATCH v3 2/6] PM / Runtime: introduce pm_runtime_set[get]_memalloc_noio()
From: Ming Lei @ 2012-10-31 2:08 UTC (permalink / raw)
To: Oliver Neukum
Cc: Alan Stern, linux-kernel, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm
In-Reply-To: <2504263.kbM6W9JoH9@linux-lqwf.site>
On Wed, Oct 31, 2012 at 12:30 AM, Oliver Neukum <oneukum@suse.de> wrote:
>> If the USB mass-storage device is being reseted, the flag should be set
>> already generally. If the flag is still unset, that means the disk/network
>> device isn't added into system(or removed just now), so memory allocation
>> with block I/O should be allowed during the reset. Looks it isn't one problem,
>> isn't it?
>
> I am afraid it is, because a disk may just have been probed as the deviceis being reset.
Yes, it is probable, and sounds like similar with 'root_wait' problem, see
prepare_namespace(): init/do_mounts.c, so looks no good solution
for the problem, and maybe we have to set the flag always before resetting
usb device.
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH V3 0/5] Fix thermal bugs and Upstream ST-Ericsson thermal driver
From: viresh kumar @ 2012-10-31 2:08 UTC (permalink / raw)
To: hongbo.zhang
Cc: linaro-dev, linux-kernel, linux-pm, rui.zhang, amit.kachhap,
patches, linaro-kernel, STEricsson_nomadik_linux, kernel,
hongbo.zhang
In-Reply-To: <1351615741-24134-1-git-send-email-hongbo.zhang@linaro.com>
On Tue, Oct 30, 2012 at 10:18 PM, hongbo.zhang <hongbo.zhang@linaro.org> wrote:
> From: "hongbo.zhang" <hongbo.zhang@linaro.com>
>
> V2->V3 Changes:
>
> 2. Update ST-Ericsson thermal driver due to review comments from Viresh Kumar
> and Francesco Lavra.
You expect people, who want to know what has changed, to go and check our
comments? That never happens and so above statement from you must have
been more descriptive, detailing all the fixes you have done.
--
viresh
^ permalink raw reply
* [PATCH] Thermal: exynos: Add sysfs node supporting exynos's emulation mode.
From: Jonghwa Lee @ 2012-10-31 1:59 UTC (permalink / raw)
To: linux-pm
Cc: linux-kernel, Len Brown, Durgadoss R, Rafael J. Wysocki,
Amit Dinel Kachhap, Jonghwa Lee
This patch supports exynos's emulation mode with newly created sysfs node.
Exynos 4x12 (4212, 4412) and 5 series provide emulation mode for thermal
management unit. Thermal emulation mode supports software debug for TMU's
operation. User can set temperature manually with software code and TMU
will read current temperature from user value not from sensor's value.
This patch includes also documentary placed under Documentation/thermal/.
Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
---
Documentation/thermal/exynos_thermal_emulation | 49 +++++++++++++
drivers/thermal/Kconfig | 9 +++
drivers/thermal/exynos_thermal.c | 89 ++++++++++++++++++++++++
3 files changed, 147 insertions(+), 0 deletions(-)
create mode 100644 Documentation/thermal/exynos_thermal_emulation
diff --git a/Documentation/thermal/exynos_thermal_emulation b/Documentation/thermal/exynos_thermal_emulation
new file mode 100644
index 0000000..daf3216
--- /dev/null
+++ b/Documentation/thermal/exynos_thermal_emulation
@@ -0,0 +1,49 @@
+EXYNOS EMULATION MODE
+========================
+
+Copyright (C) 2012 Samsung Electronics
+
+Writen by Jonghwa Lee <jonghwa3.lee@samsung.com>
+
+Description
+-----------
+
+Exynos 4x12 (4212, 4412) and 5 series provide emulation mode for thermal management unit.
+Thermal emulation mode supports software debug for TMU's operation. User can set temperature
+manually with software code and TMU will read current temperature from user value not from
+sensor's value.
+
+Enabling CONFIG_EXYNOS_THERMAL_EMUL option will make this support in available.
+When it's enabled, sysfs node will be created under
+/sys/bus/platform/devices/'exynos device name'/ with name of 'emulation'.
+
+The sysfs node, 'emulation', will contain value 0 for the initial state. When you input any
+temperature you want to update to sysfs node, it automatically enable emulation mode and
+current temperature will be changed into it.
+(Exynos also supports user changable delay time which would be used to delay of
+ changing temperature. However, this node only uses same delay of real sensing time, 938us.)
+
+Disabling emulation mode only requires writing value 0 to sysfs node.
+
+
+TEMP 120 |
+ |
+ 100 |
+ |
+ 80 |
+ | +-----------
+ 60 | | |
+ | +-------------| |
+ 40 | | | |
+ | | | |
+ 20 | | | +----------
+ | | | | |
+ 0 |______________|_____________|__________|__________|_________
+ A A A A TIME
+ |<----->| |<----->| |<----->| |
+ | 938us | | | | | |
+emulation : 0 50 | 70 | 20 | 0
+current temp : sensor 50 70 20 sensor
+
+
+
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index e1cb6bd..c02a66c 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -55,3 +55,12 @@ config EXYNOS_THERMAL
help
If you say yes here you get support for TMU (Thermal Managment
Unit) on SAMSUNG EXYNOS series of SoC.
+
+config EXYNOS_THERMAL_EMUL
+ bool "EXYNOS TMU emulation mode support"
+ depends on !CPU_EXYNOS4210 && EXYNOS_THERMAL
+ help
+ Exynos 4412 and 4414 and 5 series has emulation mode on TMU.
+ Enable this option will be make sysfs node in exynos thermal platform
+ device directory to support emulation mode. With emulation mode sysfs
+ node, you can manually input temperature to TMU for simulation purpose.
diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index fd03e85..baa9108 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -99,6 +99,15 @@
#define IDLE_INTERVAL 10000
#define MCELSIUS 1000
+#ifdef CONFIG_EXYNOS_THERMAL_EMUL
+#define EXYNOS_EMUL_TIME 0x57F0
+#define EXYNOS_EMUL_TIME_SHIFT 16
+#define EXYNOS_EMUL_DATA_SHIFT 8
+#define EXYNOS_EMUL_DATA_MASK 0xFF
+#define EXYNOS_EMUL_DISABLE 0x0
+#define EXYNOS_EMUL_ENABLE 0x1
+#endif /* CONFIG_EXYNOS_THERMAL_EMUL */
+
/* CPU Zone information */
#define PANIC_ZONE 4
#define WARN_ZONE 3
@@ -832,6 +841,83 @@ static inline struct exynos_tmu_platform_data *exynos_get_driver_data(
return (struct exynos_tmu_platform_data *)
platform_get_device_id(pdev)->driver_data;
}
+
+#ifdef CONFIG_EXYNOS_THERMAL_EMUL
+static ssize_t exynos_tmu_emulation_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct platform_device *pdev = container_of(dev,
+ struct platform_device, dev);
+ struct exynos_tmu_data *data = platform_get_drvdata(pdev);
+ unsigned int reg;
+ u8 temp_code;
+ int temp, enable;
+
+ mutex_lock(&data->lock);
+ clk_enable(data->clk);
+ reg = readl(data->base[0] + EXYNOS5_EMUL_CON);
+ clk_disable(data->clk);
+ mutex_unlock(&data->lock);
+
+ enable = reg & EXYNOS_EMUL_ENABLE;
+
+ if (enable) {
+ reg >>= EXYNOS_EMUL_DATA_SHIFT;
+ temp_code = reg & EXYNOS_EMUL_DATA_MASK;
+ temp = code_to_temp(data, temp_code);
+ } else {
+ temp = 0;
+ }
+
+ return sprintf(buf, "%d\n", temp);
+}
+
+static ssize_t exynos_tmu_emulation_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct platform_device *pdev = container_of(dev,
+ struct platform_device, dev);
+ struct exynos_tmu_data *data = platform_get_drvdata(pdev);
+ unsigned int reg;
+ u8 temp_code;
+ int temp, enable, i;
+
+ if (!sscanf(buf, "%d\n", &temp))
+ return -EINVAL;
+
+ if (temp < 0)
+ return -EINVAL;
+
+ mutex_lock(&data->lock);
+ clk_enable(data->clk);
+
+ reg = readl(data->base[0] + EXYNOS5_EMUL_CON);
+ enable = reg & EXYNOS_EMUL_ENABLE;
+ if (!enable && !temp)
+ goto out;
+
+ temp_code = (reg >> EXYNOS_EMUL_DATA_SHIFT) & EXYNOS_EMUL_DATA_MASK;
+ temp_code = temp == 0 ? temp_code : temp_to_code(data, temp);
+
+ reg = (EXYNOS_EMUL_TIME << EXYNOS_EMUL_TIME_SHIFT) |
+ (temp_code << EXYNOS_EMUL_DATA_SHIFT) |
+ (temp > 0 ? EXYNOS_EMUL_ENABLE : EXYNOS_EMUL_DISABLE);
+
+ for (i = 0; i < EXYNOS_TMU_COUNT; i++)
+ writel(reg, data->base[i] + EXYNOS5_EMUL_CON);
+out:
+ clk_disable(data->clk);
+ mutex_unlock(&data->lock);
+
+ return count;
+}
+
+static DEVICE_ATTR(emulation, 0644, exynos_tmu_emulation_show,
+ exynos_tmu_emulation_store);
+#endif
+
static int __devinit exynos_tmu_probe(struct platform_device *pdev)
{
struct exynos_tmu_data *data;
@@ -930,6 +1016,9 @@ static int __devinit exynos_tmu_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "Failed to register thermal interface\n");
goto err_clk;
}
+#ifdef CONFIG_EXYNOS_THERMAL_EMUL
+ device_create_file(&pdev->dev, &dev_attr_emulation);
+#endif
return 0;
err_clk:
platform_set_drvdata(pdev, NULL);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 5/6] power: export opp cpufreq functions
From: Nishanth Menon @ 2012-10-31 1:17 UTC (permalink / raw)
To: Mark Langsdorf; +Cc: linux-kernel, linux-pm
In-Reply-To: <1351631056-25938-6-git-send-email-mark.langsdorf@calxeda.com>
On 16:04-20121030, Mark Langsdorf wrote:
$subject
PM / OPP:
Also adding info that this allows cpufreq drivers to be used as module
might be helpful.
> Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
> Cc: linux-pm@vger.kernel.org
Side note:
Applies on v3.7-rc3
on rafael's linux-next branch:
linux-next 2b7f449 Merge branch 'pm-opp-next' into linux-next
on git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
needs a rebase as it probably conflicts with
https://patchwork.kernel.org/patch/1582091/
Otherwise, approach:
Acked-by: Nishanth Menon <nm@ti.com>
--
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [for-next PATCH V2] PM / devfreq: Add sysfs node to expose available frequencies
From: Rafael J. Wysocki @ 2012-10-31 0:45 UTC (permalink / raw)
To: myungjoo.ham
Cc: Nishanth Menon, linux-pm, Rajagopal Venkat,
박경민, Kevin Hilman,
linux-kernel@vger.kernel.org
In-Reply-To: <16123783.160701351232196244.JavaMail.weblogic@epv6ml08>
On Friday, October 26, 2012 06:16:36 AM MyungJoo Ham wrote:
> > devfreq governors such as ondemand are controlled by a min and
> > max frequency, while governors like userspace governor allow us
> > to set a specific frequency.
> > However, for the same specific device, depending on the SoC, the
> > available frequencies can vary.
> >
> > So expose the available frequencies as a snapshot over sysfs to
> > allow informed decisions.
> >
> > This was inspired by cpufreq framework's equivalent for similar
> > usage sysfs node: scaling_available_frequencies.
> >
> > Cc: Rajagopal Venkat <rajagopal.venkat@linaro.org>
> > Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
> > Cc: Kyungmin Park <kyungmin.park@samsung.com>
> > Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
> > Cc: Kevin Hilman <khilman@ti.com>
> > Cc: linux-pm@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> >
> > Signed-off-by: Nishanth Menon <nm@ti.com>
>
> Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Are you going to handle this patch?
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH] cpufreq: Avoid calling cpufreq driver's target() routine if target_freq == policy->cur
From: Rafael J. Wysocki @ 2012-10-31 0:44 UTC (permalink / raw)
To: Viresh Kumar
Cc: linaro-dev-cunTk1MwBs8s++Sfvej+rw, patches-QSEj5FYQhm4dnm+yROfE0A,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
cpufreq-u79uwXL29TY76Z2rM5mHXA, pdsw-power-team-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <5056958.0bPciFrxt5-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>
On Friday, October 26, 2012 01:17:12 PM Rafael J. Wysocki wrote:
> On Friday, October 26, 2012 03:06:26 PM Viresh Kumar wrote:
> > Avoid calling cpufreq driver's target() routine if new frequency is same as
> > policies current frequency.
> >
> > Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> Looks reasonable.
>
> Any objection from anyone?
OK, no objections.
Applied to the linux-next branch of linux-pm.git as v3.8 material.
Thanks,
Rafael
> > ---
> > drivers/cpufreq/cpufreq.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 261ef65..28dc134 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -1476,6 +1476,10 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
> >
> > pr_debug("target for CPU %u: %u kHz, relation %u\n", policy->cpu,
> > target_freq, relation);
> > +
> > + if (target_freq == policy->cur)
> > + return 0;
> > +
> > if (cpu_online(policy->cpu) && cpufreq_driver->target)
> > retval = cpufreq_driver->target(policy, target_freq, relation);
> >
> >
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH RESEND] cpufreq: Make sure target freq is within limits
From: Rafael J. Wysocki @ 2012-10-31 0:44 UTC (permalink / raw)
To: Viresh Kumar
Cc: linaro-dev-cunTk1MwBs8s++Sfvej+rw, patches-QSEj5FYQhm4dnm+yROfE0A,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
cpufreq-u79uwXL29TY76Z2rM5mHXA, pdsw-power-team-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <f79c0841be1ae16e1f2bd9084ed9a158eb171eb0.1351254846.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Friday, October 26, 2012 06:05:21 PM Viresh Kumar wrote:
> __cpufreq_driver_target() must not pass target frequency beyond the limits of
> current policy.
>
> Today most of cpufreq platform drivers are doing this check in their target
> routines. Why not move it to __cpufreq_driver_target().
>
> Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> Hi Rafael,
>
> Resend doesn't contain any change, but fixed commit log
Applied to the linux-next branch of linux-pm.git as v3.8 material.
Thanks,
Rafael
> drivers/cpufreq/cpufreq.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 28dc134..2f5ac2d 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1470,12 +1470,19 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
> unsigned int relation)
> {
> int retval = -EINVAL;
> + unsigned int old_target_freq = target_freq;
>
> if (cpufreq_disabled())
> return -ENODEV;
>
> - pr_debug("target for CPU %u: %u kHz, relation %u\n", policy->cpu,
> - target_freq, relation);
> + /* Make sure that target_freq is within supported range */
> + if (target_freq > policy->max)
> + target_freq = policy->max;
> + if (target_freq < policy->min)
> + target_freq = policy->min;
> +
> + pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n",
> + policy->cpu, target_freq, relation, old_target_freq);
>
> if (target_freq == policy->cur)
> return 0;
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox