linaro-kernel July 2013

linaro-kernel@lists.linaro.org

73 participants
90 discussions

[PATCH] regulator: lp8755: Provide map_voltage()

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> Improve performance when setting voltages by avoiding a scan through the selectors when we can simply calculate the selector we want. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- drivers/regulator/lp8755.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/regulator/lp8755.c b/drivers/regulator/lp8755.c index d9e38b4..b37ef30 100644 --- a/drivers/regulator/lp8755.c +++ b/drivers/regulator/lp8755.c @@ -228,6 +228,7 @@ err_i2c: } static struct regulator_ops lp8755_buck_ops = { + .map_voltage = regulator_map_voltage_linear, .list_voltage = regulator_list_voltage_linear, .set_voltage_sel = regulator_set_voltage_sel_regmap, .get_voltage_sel = regulator_get_voltage_sel_regmap, -- 1.8.3.1

11 years, 8 months

[PATCH 1/4] regulator: core: Add helpers for multiple linear ranges

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> Many regulators have several linear ranges of selector with different step sizes, for example offering better resolution at lower voltages. Provide regulator_{map,list}_voltage_linear_range() allowing these regulators to use generic code. To do so a table of regulator_linear_range structs needs to be pointed to from the descriptor. This was inspired by similar code included in a driver submission from Chao Xie and Yi Zhang at Marvell. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- drivers/regulator/core.c | 87 ++++++++++++++++++++++++++++++++++++++++ include/linux/regulator/driver.h | 25 ++++++++++++ 2 files changed, 112 insertions(+) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 288c75a..e8604be 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -2079,6 +2079,43 @@ int regulator_list_voltage_linear(struct regulator_dev *rdev, EXPORT_SYMBOL_GPL(regulator_list_voltage_linear); /** + * regulator_list_voltage_linear_range - List voltages for linear ranges + * + * @rdev: Regulator device + * @selector: Selector to convert into a voltage + * + * Regulators with a series of simple linear mappings between voltages + * and selectors can set linear_ranges in the regulator descriptor and + * then use this function as their list_voltage() operation, + */ +int regulator_list_voltage_linear_range(struct regulator_dev *rdev, + unsigned int selector) +{ + const struct regulator_linear_range *range; + int i; + + if (!rdev->desc->n_linear_ranges) { + BUG_ON(!rdev->desc->n_linear_ranges); + return -EINVAL; + } + + for (i = 0; i < rdev->desc->n_linear_ranges; i++) { + range = &rdev->desc->linear_ranges[i]; + + if (!(selector >= range->min_sel && + selector <= range->max_sel)) + continue; + + selector -= range->min_sel; + + return range->min_uV + (range->uV_step * selector); + } + + return -EINVAL; +} +EXPORT_SYMBOL_GPL(regulator_list_voltage_linear_range); + +/** * regulator_list_voltage_table - List voltages with table based mapping * * @rdev: Regulator device @@ -2368,6 +2405,56 @@ int regulator_map_voltage_linear(struct regulator_dev *rdev, } EXPORT_SYMBOL_GPL(regulator_map_voltage_linear); +/** + * regulator_map_voltage_linear - map_voltage() for multiple linear ranges + * + * @rdev: Regulator to operate on + * @min_uV: Lower bound for voltage + * @max_uV: Upper bound for voltage + * + * Drivers providing linear_ranges in their descriptor can use this as + * their map_voltage() callback. + */ +int regulator_map_voltage_linear_range(struct regulator_dev *rdev, + int min_uV, int max_uV) +{ + const struct regulator_linear_range *range; + int ret = -EINVAL; + int voltage, i; + + if (!rdev->desc->n_linear_ranges) { + BUG_ON(!rdev->desc->n_linear_ranges); + return -EINVAL; + } + + for (i = 0; i < rdev->desc->n_linear_ranges; i++) { + range = &rdev->desc->linear_ranges[i]; + + if (!(min_uV <= range->max_uV && max_uV >= range->min_uV)) + continue; + + if (min_uV <= range->min_uV) + min_uV = range->min_uV; + + ret = DIV_ROUND_UP(min_uV - range->min_uV, range->uV_step); + if (ret < 0) + return ret; + + break; + } + + if (i == rdev->desc->n_linear_ranges) + return -EINVAL; + + /* Map back into a voltage to verify we're still in bounds */ + voltage = rdev->desc->ops->list_voltage(rdev, ret); + if (voltage < min_uV || voltage > max_uV) + return -EINVAL; + + return ret; +} +EXPORT_SYMBOL_GPL(regulator_map_voltage_linear_range); + static int _regulator_do_set_voltage(struct regulator_dev *rdev, int min_uV, int max_uV) { diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h index 6700cc9..67e13aa 100644 --- a/include/linux/regulator/driver.h +++ b/include/linux/regulator/driver.h @@ -40,6 +40,24 @@ enum regulator_status { }; /** + * Specify a range of voltages for regulator_map_linar_range() and + * regulator_list_linear_range(). + * + * @min_uV: Lowest voltage in range + * @max_uV: Highest voltage in range + * @min_sel: Lowest selector for range + * @max_sel: Highest selector for range + * @uV_step: Step size + */ +struct regulator_linear_range { + unsigned int min_uV; + unsigned int max_uV; + unsigned int min_sel; + unsigned int max_sel; + unsigned int uV_step; +}; + +/** * struct regulator_ops - regulator operations. * * @enable: Configure the regulator as enabled. @@ -223,6 +241,9 @@ struct regulator_desc { unsigned int linear_min_sel; unsigned int ramp_delay; + const struct regulator_linear_range *linear_ranges; + int n_linear_ranges; + const unsigned int *volt_table; unsigned int vsel_reg; @@ -326,10 +347,14 @@ int regulator_mode_to_status(unsigned int); int regulator_list_voltage_linear(struct regulator_dev *rdev, unsigned int selector); +int regulator_list_voltage_linear_range(struct regulator_dev *rdev, + unsigned int selector); int regulator_list_voltage_table(struct regulator_dev *rdev, unsigned int selector); int regulator_map_voltage_linear(struct regulator_dev *rdev, int min_uV, int max_uV); +int regulator_map_voltage_linear_range(struct regulator_dev *rdev, + int min_uV, int max_uV); int regulator_map_voltage_iterate(struct regulator_dev *rdev, int min_uV, int max_uV); int regulator_map_voltage_ascend(struct regulator_dev *rdev, -- 1.8.3.1

11 years, 8 months

[PATCH] USB: OHCI: make ohci-da8xx a separate driver

by Manjunath Goudar

Separate the Davinci OHCI host controller driver from ohci-hcd host code so that it can be built as a separate driver module. This work is part of enabling multi-platform kernels on ARM; it would be nice to have in 3.11. One preexisting error: "da8xx_syscfg0_base" [drivers/usb/host/ohci-da8xx.ko] undefined! Fixed eventually using below modification: added EXPORT_SYMBOL_GPL(da8xx_syscfg0_base) in arch/arm/mach-davinci/devices-da8xx.c. Signed-off-by: Manjunath Goudar <manjunath.goudar(a)linaro.org> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Alan Stern <stern(a)rowland.harvard.edu> Cc: Sergei Shtylyov <sshtylyov(a)ru.mvista.com> Cc: Kevin Hilman <kjh(a)hilman.org> Cc: Greg KH <greg(a)kroah.com> Cc: linux-usb(a)vger.kernel.org --- drivers/usb/host/Kconfig | 8 +++ drivers/usb/host/Makefile | 1 + drivers/usb/host/ohci-da8xx.c | 139 +++++++++++++++++++---------------------- drivers/usb/host/ohci-hcd.c | 18 ------ 4 files changed, 75 insertions(+), 91 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 002bf73..bf2689d 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -406,6 +406,14 @@ config USB_OHCI_HCD_LPC32XX Enables support for the on-chip OHCI controller on NXP chips. +config USB_OHCI_HCD_DA8XX + tristate "Support for DAVINCI on-chip OHCI USB controller" + depends on USB_OHCI_HCD && ARCH_DAVINCI_DA8XX + default y + ---help--- + Enables support for the on-chip OHCI controller on + Davinci chips. + config USB_OHCI_HCD_AT91 tristate "Support for Atmel on-chip OHCI USB controller" depends on USB_OHCI_HCD && ARCH_AT91 diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index edc0909..f8d59371 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -53,6 +53,7 @@ obj-$(CONFIG_USB_OHCI_HCD_SPEAR) += ohci-spear.o obj-$(CONFIG_USB_OHCI_HCD_AT91) += ohci-at91.o obj-$(CONFIG_USB_OHCI_HCD_S3CXXXX) += ohci-s3c2410.o obj-$(CONFIG_USB_OHCI_HCD_LPC32XX) += ohci-nxp.o +obj-$(CONFIG_USB_OHCI_HCD_DA8XX) += ohci-da8xx.o obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o obj-$(CONFIG_USB_FHCI_HCD) += fhci.o diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c index c649a35..9b4d1e4 100644 --- a/drivers/usb/host/ohci-da8xx.c +++ b/drivers/usb/host/ohci-da8xx.c @@ -11,20 +11,35 @@ * kind, whether express or implied. */ +#include <linux/clk.h> +#include <linux/io.h> #include <linux/interrupt.h> #include <linux/jiffies.h> +#include <linux/kernel.h> +#include <linux/module.h> #include <linux/platform_device.h> -#include <linux/clk.h> +#include <linux/platform_data/usb-davinci.h> +#include <linux/usb.h> +#include <linux/usb/hcd.h> + #include <mach/da8xx.h> -#include <linux/platform_data/usb-davinci.h> +#include <asm/unaligned.h> -#ifndef CONFIG_ARCH_DAVINCI_DA8XX -#error "This file is DA8xx bus glue. Define CONFIG_ARCH_DAVINCI_DA8XX." -#endif +#include "ohci.h" #define CFGCHIP2 DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG) +#define DRIVER_DESC "OHCI DA8XX driver" + +static const char hcd_name[] = "ohci-da8xx"; + +static struct hc_driver __read_mostly ohci_da8xx_hc_driver; + +static int (*orig_ohci_hub_control)(struct usb_hcd *hcd, u16 typeReq, + u16 wValue, u16 wIndex, char *buf, u16 wLength); +static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char *buf); + static struct clk *usb11_clk; static struct clk *usb20_clk; @@ -82,7 +97,7 @@ static void ohci_da8xx_ocic_handler(struct da8xx_ohci_root_hub *hub, hub->set_power(port, 0); } -static int ohci_da8xx_init(struct usb_hcd *hcd) +static int ohci_da8xx_reset(struct usb_hcd *hcd) { struct device *dev = hcd->self.controller; struct da8xx_ohci_root_hub *hub = dev->platform_data; @@ -100,7 +115,7 @@ static int ohci_da8xx_init(struct usb_hcd *hcd) */ ohci->num_ports = 1; - result = ohci_init(ohci); + result = ohci_setup(hcd); if (result < 0) return result; @@ -126,30 +141,12 @@ static int ohci_da8xx_init(struct usb_hcd *hcd) return result; } -static void ohci_da8xx_stop(struct usb_hcd *hcd) -{ - ohci_stop(hcd); - ohci_da8xx_clock(0); -} - -static int ohci_da8xx_start(struct usb_hcd *hcd) -{ - struct ohci_hcd *ohci = hcd_to_ohci(hcd); - int result; - - result = ohci_run(ohci); - if (result < 0) - ohci_da8xx_stop(hcd); - - return result; -} - /* * Update the status data from the hub with the over-current indicator change. */ static int ohci_da8xx_hub_status_data(struct usb_hcd *hcd, char *buf) { - int length = ohci_hub_status_data(hcd, buf); + int length = orig_ohci_hub_status_data(hcd, buf); /* See if we have OCIC bit set on port 1 */ if (ocic_mask & (1 << 1)) { @@ -231,53 +228,10 @@ check_port: } } - return ohci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength); + return orig_ohci_hub_control(hcd, typeReq, wValue, + wIndex, buf, wLength); } -static const struct hc_driver ohci_da8xx_hc_driver = { - .description = hcd_name, - .product_desc = "DA8xx OHCI", - .hcd_priv_size = sizeof(struct ohci_hcd), - - /* - * generic hardware linkage - */ - .irq = ohci_irq, - .flags = HCD_USB11 | HCD_MEMORY, - - /* - * basic lifecycle operations - */ - .reset = ohci_da8xx_init, - .start = ohci_da8xx_start, - .stop = ohci_da8xx_stop, - .shutdown = ohci_shutdown, - - /* - * managing i/o requests and associated device resources - */ - .urb_enqueue = ohci_urb_enqueue, - .urb_dequeue = ohci_urb_dequeue, - .endpoint_disable = ohci_endpoint_disable, - - /* - * scheduling support - */ - .get_frame_number = ohci_get_frame, - - /* - * root hub support - */ - .hub_status_data = ohci_da8xx_hub_status_data, - .hub_control = ohci_da8xx_hub_control, - -#ifdef CONFIG_PM - .bus_suspend = ohci_bus_suspend, - .bus_resume = ohci_bus_resume, -#endif - .start_port_reset = ohci_start_port_reset, -}; - /*-------------------------------------------------------------------------*/ @@ -337,8 +291,6 @@ static int usb_hcd_da8xx_probe(const struct hc_driver *driver, goto err3; } - ohci_hcd_init(hcd_to_ohci(hcd)); - irq = platform_get_irq(pdev, 0); if (irq < 0) { error = -ENODEV; @@ -383,6 +335,7 @@ usb_hcd_da8xx_remove(struct usb_hcd *hcd, struct platform_device *pdev) struct da8xx_ohci_root_hub *hub = pdev->dev.platform_data; hub->ocic_notify(NULL); + ohci_da8xx_clock(0); usb_remove_hcd(hcd); iounmap(hcd->regs); release_mem_region(hcd->rsrc_start, hcd->rsrc_len); @@ -444,6 +397,11 @@ static int ohci_da8xx_resume(struct platform_device *dev) } #endif +static const struct ohci_driver_overrides da8xx_overrides __initconst = { + .reset = ohci_da8xx_reset +}; + + /* * Driver definition to register with platform structure. */ @@ -461,4 +419,39 @@ static struct platform_driver ohci_hcd_da8xx_driver = { }, }; +static int __init ohci_da8xx_init(void) +{ + if (usb_disabled()) + return -ENODEV; + + pr_info("%s: " DRIVER_DESC "\n", hcd_name); + ohci_init_driver(&ohci_da8xx_hc_driver, &da8xx_overrides); + + /* + * The Davinci da8xx HW has some unusual quirks, which require + * da8xx-specific workarounds. We override certain hc_driver + * functions here to achieve that. We explicitly do not enhance + * ohci_driver_overrides to allow this more easily, since this + * is an unusual case, and we don't want to encourage others to + * override these functions by making it too easy. + */ + + orig_ohci_hub_control = ohci_da8xx_hc_driver.hub_control; + orig_ohci_hub_status_data = ohci_da8xx_hc_driver.hub_status_data; + + ohci_da8xx_hc_driver.hub_status_data = ohci_da8xx_hub_status_data; + ohci_da8xx_hc_driver.hub_control = ohci_da8xx_hub_control; + + return platform_driver_register(&ohci_hcd_da8xx_driver); +} +module_init(ohci_da8xx_init); + +static void __exit ohci_da8xx_cleanup(void) +{ + platform_driver_unregister(&ohci_hcd_da8xx_driver); +} +module_exit(ohci_da8xx_cleanup); + +MODULE_DESCRIPTION(DRIVER_DESC); +MODULE_LICENSE("GPL"); MODULE_ALIAS("platform:ohci"); diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c index 9a0b023..8ae7a1b 100644 --- a/drivers/usb/host/ohci-hcd.c +++ b/drivers/usb/host/ohci-hcd.c @@ -1194,11 +1194,6 @@ MODULE_LICENSE ("GPL"); #define EP93XX_PLATFORM_DRIVER ohci_hcd_ep93xx_driver #endif -#ifdef CONFIG_ARCH_DAVINCI_DA8XX -#include "ohci-da8xx.c" -#define DAVINCI_PLATFORM_DRIVER ohci_hcd_da8xx_driver -#endif - #ifdef CONFIG_USB_OHCI_HCD_PPC_OF #include "ohci-ppc-of.c" #define OF_PLATFORM_DRIVER ohci_hcd_ppc_of_driver @@ -1296,19 +1291,9 @@ static int __init ohci_hcd_mod_init(void) goto error_ep93xx; #endif -#ifdef DAVINCI_PLATFORM_DRIVER - retval = platform_driver_register(&DAVINCI_PLATFORM_DRIVER); - if (retval < 0) - goto error_davinci; -#endif - return retval; /* Error path */ -#ifdef DAVINCI_PLATFORM_DRIVER - platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER); - error_davinci: -#endif #ifdef EP93XX_PLATFORM_DRIVER platform_driver_unregister(&EP93XX_PLATFORM_DRIVER); error_ep93xx: @@ -1350,9 +1335,6 @@ module_init(ohci_hcd_mod_init); static void __exit ohci_hcd_mod_exit(void) { -#ifdef DAVINCI_PLATFORM_DRIVER - platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER); -#endif #ifdef NXP_PLATFORM_DRIVER platform_driver_unregister(&NXP_PLATFORM_DRIVER); #endif -- 1.7.9.5

11 years, 8 months

[PATCH] cpufreq: Fix serialization of frequency transitions

by Viresh Kumar

Commit 7c30ed ("cpufreq: make sure frequency transitions are serialized") interacts poorly with systems that have a single core freqency for all cores. On such systems we have a single policy for all cores with several CPUs. When we do a frequency transition the governor calls the pre and post change notifiers which causes cpufreq_notify_transition() per CPU. Since the policy is the same for all of them all CPUs after the first and the warnings added are generated by checking a per-policy flag the warnings will be triggered for all cores after the first. Fix this by allowing notifier to be called for n times. Where n is the number of cpus in policy->cpus. Reported-and-Tested-by: Mark Brown <broonie(a)linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- Hi Rafael, This is a fix for 3.11. drivers/cpufreq/cpufreq.c | 7 ++++--- include/linux/cpufreq.h | 2 +- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index b557503..b7bda8d 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -312,11 +312,12 @@ static void __cpufreq_notify_transition(struct cpufreq_policy *policy, switch (state) { case CPUFREQ_PRECHANGE: - if (WARN(policy->transition_ongoing, + if (WARN(policy->transition_ongoing == + cpumask_weight(policy->cpus), "In middle of another frequency transition\n")) return; - policy->transition_ongoing = true; + policy->transition_ongoing++; /* detect if the driver reported a value as "old frequency" * which is not equal to what the cpufreq core thinks is @@ -341,7 +342,7 @@ static void __cpufreq_notify_transition(struct cpufreq_policy *policy, "No frequency transition in progress\n")) return; - policy->transition_ongoing = false; + policy->transition_ongoing--; adjust_jiffies(CPUFREQ_POSTCHANGE, freqs); pr_debug("FREQ: %lu - CPU: %lu", (unsigned long)freqs->new, diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index 4d7390b..90d5a15 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -119,7 +119,7 @@ struct cpufreq_policy { struct kobject kobj; struct completion kobj_unregister; - bool transition_ongoing; /* Tracks transition status */ + int transition_ongoing; /* Tracks transition status */ }; #define CPUFREQ_ADJUST (0) -- 1.7.12.rc2.18.g61b472e

11 years, 8 months

VIRTIO OASIS Standardization Effort

by Rusty Russell

Hi all, Just wanted to make sure everyone interested in virtualization was aware that we are bootstrapping a VIRTIO Technical Committee over at OASIS. All welcome! http://www.oasis-open.org/committees/virtio Cheers, Rusty.

11 years, 8 months

[PATCH] ARM: vexpress_defconfig: Enable voltage regulators

by Christoffer Dall

Enable the Versatile Express voltage regulators by default. This should work on all verstatile express platforms and not enabling it prevents a defconfig'ed kernel from using the SD card controller on the qemu emulated platform, which is unfortunate for first-time casual users. Cc: Peter Maydell <peter.maydell(a)linaro.org> Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org> --- arch/arm/configs/vexpress_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/vexpress_defconfig b/arch/arm/configs/vexpress_defconfig index f2de51f..17104d9 100644 --- a/arch/arm/configs/vexpress_defconfig +++ b/arch/arm/configs/vexpress_defconfig @@ -138,3 +138,6 @@ CONFIG_DEBUG_LL=y CONFIG_EARLY_PRINTK=y # CONFIG_CRYPTO_ANSI_CPRNG is not set # CONFIG_CRYPTO_HW is not set +CONFIG_REGULATOR=y +CONFIG_REGULATOR_FIXED_VOLTAGE=y +CONFIG_REGULATOR_VEXPRESS=y -- 1.7.9.5

11 years, 8 months

[PATCH] ACPI/fan: Initialize acpi_state variable

by naresh.bhat＠linaro.org

From: Naresh Bhat <naresh.bhat(a)linaro.org> CC drivers/acpi/fan.o drivers/acpi/fan.c: In function ‘fan_get_cur_state’: drivers/acpi/fan.c:96:9: warning: ‘acpi_state’ may be used uninitialized in this function [-Wuninitialized] --- drivers/acpi/fan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c index f815da8..f961435 100644 --- a/drivers/acpi/fan.c +++ b/drivers/acpi/fan.c @@ -84,7 +84,7 @@ static int fan_get_cur_state(struct thermal_cooling_device *cdev, unsigned long { struct acpi_device *device = cdev->devdata; int result; - int acpi_state; + int acpi_state = ACPI_STATE_D0; if (!device) return -EINVAL; -- 1.7.9.5

11 years, 8 months

[PATCH] ACPI/fan: Initialize acpi_state variable

by naresh.bhat＠linaro.org

From: Naresh Bhat <naresh.bhat(a)linaro.org> CC drivers/acpi/fan.o drivers/acpi/fan.c: In function ‘fan_get_cur_state’: drivers/acpi/fan.c:96:9: warning: ‘acpi_state’ may be used uninitialized in this function [-Wuninitialized] Signed-off-by: Naresh Bhat <naresh.bhat(a)linaro.org> --- drivers/acpi/fan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c index 8d1c010..5b02a0a 100644 --- a/drivers/acpi/fan.c +++ b/drivers/acpi/fan.c @@ -84,7 +84,7 @@ static int fan_get_cur_state(struct thermal_cooling_device *cdev, unsigned long { struct acpi_device *device = cdev->devdata; int result; - int acpi_state; + int acpi_state = ACPI_STATE_D0; if (!device) return -EINVAL; -- 1.7.9.5

11 years, 8 months

Re: [Query]: CPUFREQ: Affected and related cpus in cpufreq

by Viresh Kumar

On 10 October 2012 19:37, Viresh Kumar <viresh.kumar(a)linaro.org> wrote: > On 10 October 2012 19:14, Sudeep KarkadaNagesha > <Sudeep.KarkadaNagesha(a)arm.com> wrote: >> Here is my understanding on this patch. This change is closely related >> to ACPI cpufreq driver(used mostly on Intel cores). This change was >> introduced to keep track of the related cpus as returned by ACPI >> firmware along with affected cpus as imposed by SW. I don't understand >> the exact difference in Intel cores. >> I believe it's just for tracking and not used much in the driver. > > Then i believe we shouldn't fill the related_cpus field for ARM cores. As anyway > the show_related_cpus will pick affected cpus in that case. Ahh, I was searching for something in my Archives and found this old unanswered mail. As I have understood the difference between between these two variables (affected and related cpus) now until this happened: 951fc5f4 (in v3.9). I thought it would be good to bury the actual answers somewhere in Archives so that somebody looking for the answer can find it easily. What it was: Affected CPUs: List of CPUs which share clock domain and s/w was responsible to managing these. Related CPUs: List of CPUs which share clock domain and only h/w was responsible for managing these. What do we mean by software and hardware managed stuff? It was specific for acpi-cpufreq driver and nobody else :) The firmware below kernel layer for hardware using this driver wanted to manage cpus (sharing clock domain) by itself. i.e. It wanted the actual freq request to go to it, it will then pick the highest freq requested for a clock domain and set it for all cpus under policy->cpus. But kernel wouldn't know these details at all. CPUFreq core would think that these cores don't actually share clock line and so are independent. Then there were some user space applications (like DVFS controllers), which wanted to know the exact hardware coordination details rather than what is present with cpufreq core. And so related_cpus was created for them with this commit: e8628dd06d66f2e3965ec9742029b401d63434f1 related_cpus wasn't used in making kernel decisions at all and was only for the applications who want to know exact hardware details. As it didn't make sense to keep acpi-cpufreq specific stuff in CPUFreq core, it was eventually moved into acpi-cpufreq driver with the name: freqdomain_cpus in 3.11. related_cpus was kept in kernel but its meaning is now changed. affected_cpus: List of Online CPUs that require software coordination of frequency. related_cpus: List of Online + Offline CPUs that need software coordination of frequency. -- viresh

11 years, 8 months

[PATCH] i2c: iop3xxx: fix build failure after waitqueue changes

by Kevin Hilman

There has long been a syntax problem in iop3xx_i2c_wait_event() which has been somehow hidden by the macros in <linux/wait.h>. After some recent cleanup/rework of the wait_event_* helpers, the bug has come out from hiding and now results in build failure: /work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c: In function 'iop3xx_i2c_wait_event': /work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:143: error: expected ')' before ';' token /work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:157: error: expected ')' before ';' token /work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:213: error: expected ')' before ';' token /work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:291: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] /work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:551: error: expected ')' before ';' token /work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:565: error: expected ')' before ';' token /work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:764: error: expected ')' before ';' token /work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:778: error: expected ')' b Fix by removing stray ';' Signed-off-by: Kevin Hilman <khilman(a)linaro.org> --- Discovered in new build failure of iop32xx_defconfig with next-20130628 drivers/i2c/busses/i2c-iop3xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-iop3xx.c b/drivers/i2c/busses/i2c-iop3xx.c index bc99333..dd24aa0 100644 --- a/drivers/i2c/busses/i2c-iop3xx.c +++ b/drivers/i2c/busses/i2c-iop3xx.c @@ -176,7 +176,7 @@ iop3xx_i2c_wait_event(struct i2c_algo_iop3xx_data *iop3xx_adap, interrupted = wait_event_interruptible_timeout ( iop3xx_adap->waitq, (done = compare( sr = iop3xx_i2c_get_srstat(iop3xx_adap) ,flags )), - 1 * HZ; + 1 * HZ ); if ((rc = iop3xx_i2c_error(sr)) < 0) { *status = sr; -- 1.8.3

11 years, 8 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel July 2013