linaro-kernel

linaro-kernel@lists.linaro.org

10095 discussions

[PATCH] MM: Make Contiguous Memory Allocator depends on MMU

by Manjunath Goudar

This patch create CMA dependns on MMU.With the help MMU, page migration and CMA functionality is achieved. Signed-off-by: Manjunath Goudar <manjunath.goudar(a)linaro.org> Cc: IWAMOTO Toshihiro <iwamoto(a)valinux.co.jp> Cc: Hirokazu Takahashi <taka(a)valinux.co.jp> Cc: Dave Hansen <haveblue(a)us.ibm.com> Cc: linux-mm(a)kvack.org Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Michal Hocko <mhocko(a)suse.cz> Cc: Balbir Singh <bsingharora(a)gmail.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu(a)jp.fujitsu.com> --- mm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/Kconfig b/mm/Kconfig index 256bfd0..ad6b98e 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -522,7 +522,7 @@ config MEM_SOFT_DIRTY config CMA bool "Contiguous Memory Allocator" - depends on HAVE_MEMBLOCK + depends on MMU && HAVE_MEMBLOCK select MIGRATION select MEMORY_ISOLATION help -- 1.7.9.5

11 years, 11 months

Re: [RFC][PATCH] cpufreq: Do not hold driver module references for additional policy CPUs

by Viresh Kumar

On 1 August 2013 13:41, Srivatsa S. Bhat <srivatsa.bhat(a)linux.vnet.ibm.com> wrote: > On 08/01/2013 05:38 AM, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> >> >> The cpufreq core is a little inconsistent in the way it uses the >> driver module refcount. >> >> Namely, if __cpufreq_add_dev() is called for a CPU without siblings >> or generally a CPU for which a new policy object has to be created, >> it grabs a reference to the driver module to start with, but drops >> that reference before returning. As a result, the driver module >> refcount is then equal to 0 after __cpufreq_add_dev() has returned. >> >> On the other hand, if the given CPU is a sibling of some other >> CPU already having a policy, cpufreq_add_policy_cpu() is called >> to link the new CPU to the existing policy. In that case, >> cpufreq_cpu_get() is called to obtain that policy and grabs a >> reference to the driver module, but that reference is not >> released and the module refcount will be different from 0 after >> __cpufreq_add_dev() returns (unless there is an error). That >> prevents the driver module from being unloaded until >> __cpufreq_remove_dev() is called for all the CPUs that >> cpufreq_add_policy_cpu() was called for previously. >> >> To remove that inconsistency make cpufreq_add_policy_cpu() execute >> cpufreq_cpu_put() for the given policy before returning, which >> decrements the driver module refcount so that it will be 0 after >> __cpufreq_add_dev() returns, > > Removing the inconsistency is a good thing, but I think we should > make it consistent the other way around - make a CPU-online increment > the driver module refcount and decrement it only on CPU-offline. I took time to review to this mail as I was looking at the problem yesterday. I am sorry to say, but I have completely different views as compared to You and Rafael both :) First of all, Rafael's patch is incomplete as it hasn't fixed the issue completely. When we have multiple CPUs per policy and cpufreq_add_dev() is called for the first one, it call cpufreq_get_cpu() for all cpus of this policy(), so count is == x (no. of CPUs in this policy) + 1 (This is the initial value of .owner). And so we still have module count getting incremented for other cpus :) Now few lines about My point of view to this whole thing. I believe we should get rid of .owner field from struct cpufreq_driver completely. It doesn't make sense to me in doing all this management at all. Surprised? Shocked? Laughing at me? :) Well I may be wrong but this is what I think: - It looks stupid to me that I can't do this from userspace in one go: $ insmod cpufreq_driver.ko $ rmmod cpufreq_driver.ko What the hell changed in between that isn't visible to user? It looked completely stupid in that way.. Something like this sure makes sense: $ insmod ondemand-governor.ko $ change governor to ondemand for few CPUs $ rmmod ondemand-governor.ko as we have deliberately add few users of governor. And so without second step, rmmod should really work smoothly. And it does. Now, why shouldn't there be a problem with this approach? I will write that inline to the problems you just described. > The reason is, one should not be able to unload the back-end cpufreq > driver module when some CPUs are still being managed. Nasty things > will result if we allow that. For example, if we unload the module, > and then try to do a CPU offline, then the cpufreq hotplug notifier > won't even be called (because cpufreq_unregister_driver also > unregisters the hotplug notifier). And that might be troublesome. So what? Its simply equivalent to we have booted our system, haven't inserted cpufreq module and taken out a cpu. > Even worse, if we unload a cpufreq driver module and load a new > one and *then* try to offline the CPU, then the cpufreq_driver->exit() > function that we call during CPU offline will end up calling the > corresponding function of an entirely different driver! So the > ->init() and ->exit() calls won't match. That's not true. When we unload the module, it must call cpufreq_unregister_driver() which should call cpufreq_remove_cpu() for all cpus and so exit() is already called for last module. If we get something new now, it should simply work. What do you think gentlemen? -- viresh

11 years, 11 months

Re: BUG_ON(irqs_disabled()) in cpufreq.c

by Viresh Kumar

More lists cc'd On Thu, Aug 1, 2013 at 6:08 PM, Michael Giardino <giardino(a)ece.gatech.edu> wrote: > Hi, > > I hope this is the right spot to ask this. > > Is there any way to change the cpu frequency using the cpufreq driver > from within an hrtimer callback function? I encounter a kernel panic > at cpufreq.c line 255 (260 in 3.9.5) > > void __cpufreq_notify_transition(struct cpufreq_policy *policy, > 253 struct cpufreq_freqs *freqs, unsigned int state) > 254 { > 255 BUG_ON(irqs_disabled()); > > > I'm assuming this is due to the cpufreq_notify_transition needs > interrupts to notify? Is there a way around this? It appears that > acpi-cpufreq.c is calling the notifier both before and after the > transition (CPUFREQ_PRECHANGE and CPUFREQ_POSTCHANGE). > > Are there any frequency change functions that can operate without interrupts? > > The background is this: > > For the past few days I have been trying to get to the bottom of a > problem involving a nonSMP governor I have written. The goal of this > governor is to change the frequency on a predefined schedule (in the > ms scale). The basic breakdown is this: > > 1. The external scheduler computes schedules and then passes them to > the governor (with much code appropriated from the userspace governor) > via an exported function. > 2. The governor sets the frequency, then sets a timer to call the next > frequency change when it goes off > > In order to do this, I was using hrtimers. These timer's callback > functions run with interrupts disabled. > > Michael Giardino > <giardino(a)ece.gatech.edu> > <michael.giardino(a)gmail.com> > -- > To unsubscribe from this list: send the line "unsubscribe cpufreq" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html

11 years, 11 months

[PATCH 0/3] nohz/full: final Kconfig bits for ARM support

by Kevin Hilman

As of v3.10, the core ARM support is in mainline for NO_HZ_FULL. The only remaining part is the removal of the hard-coded Kconfig requirement on 64-bit platforms, which I believe can now be removed after the nsec granularity cputime was made to work on non 64_BIT (c.f. commit 8c23b80e, cputime_nsecs: use math64.h for nsec resolution conversion helpers.) This series makes the final Kconfig changes to bring NO_HZ_FULL support to ARM. Series applies to v3.10. I will queue up the arch/arm patch for Russell separately once the generic changes are accepted. Kevin arch/arm/Kconfig | 1 + init/Kconfig | 2 +- kernel/time/Kconfig | 2 -- 3 files changed, 2 insertions(+), 3 deletions(-) -- 1.8.3

11 years, 11 months

[PATCH] ASoC: samsung: Make secondary I2S DAI device a child of primary

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> More for neatness than for any great utility. Really we shouldn't be creating the child device at all, refactoring will follow. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- sound/soc/samsung/i2s.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c index a3e4b49..47e08dd 100644 --- a/sound/soc/samsung/i2s.c +++ b/sound/soc/samsung/i2s.c @@ -1019,6 +1019,8 @@ static struct i2s_dai *i2s_alloc_dai(struct platform_device *pdev, bool sec) if (IS_ERR(i2s->pdev)) return NULL; + i2s->pdev->dev.parent = &pdev->dev; + platform_set_drvdata(i2s->pdev, i2s); ret = platform_device_add(i2s->pdev); if (ret < 0) -- 1.8.3.2

11 years, 11 months

[PATCH] cpufreq: Re-arrange header files

by Viresh Kumar

This exercise has been done earlier but hasn't been done for few files. Lets do it now. It targets to fix following problems: - Include headers in ascending order, so that we don't add same multiple times by mistake. - <asm/> must be included after <linux/>, so that they override whatever they need. Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- drivers/cpufreq/cpufreq.c | 23 +++++++++++------------ drivers/cpufreq/cpufreq_governor.c | 2 +- drivers/cpufreq/cpufreq_ondemand.c | 2 +- drivers/cpufreq/cpufreq_performance.c | 4 ++-- drivers/cpufreq/cpufreq_powersave.c | 4 ++-- drivers/cpufreq/cpufreq_stats.c | 12 ++++++------ include/linux/cpufreq.h | 10 +++++----- 7 files changed, 28 insertions(+), 29 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 170d344..d5f2a09 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -17,25 +17,24 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt -#include <asm/cputime.h> +#include <linux/cpu.h> +#include <linux/cpufreq.h> +#include <linux/completion.h> +#include <linux/delay.h> +#include <linux/device.h> +#include <linux/init.h> +#include <linux/interrupt.h> #include <linux/kernel.h> #include <linux/kernel_stat.h> #include <linux/module.h> -#include <linux/init.h> +#include <linux/mutex.h> #include <linux/notifier.h> -#include <linux/cpufreq.h> -#include <linux/delay.h> -#include <linux/interrupt.h> -#include <linux/spinlock.h> -#include <linux/tick.h> -#include <linux/device.h> #include <linux/slab.h> -#include <linux/cpu.h> -#include <linux/completion.h> -#include <linux/mutex.h> +#include <linux/spinlock.h> #include <linux/syscore_ops.h> - +#include <linux/tick.h> #include <trace/events/power.h> +#include <asm/cputime.h> /** * The "cpufreq driver" - the arch- or hardware-dependent low diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c index 7409dbd..5876788 100644 --- a/drivers/cpufreq/cpufreq_governor.c +++ b/drivers/cpufreq/cpufreq_governor.c @@ -16,7 +16,6 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt -#include <asm/cputime.h> #include <linux/cpufreq.h> #include <linux/cpumask.h> #include <linux/export.h> @@ -25,6 +24,7 @@ #include <linux/slab.h> #include <linux/types.h> #include <linux/workqueue.h> +#include <asm/cputime.h> #include "cpufreq_governor.h" diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c index a3c5574..d3344b5 100644 --- a/drivers/cpufreq/cpufreq_ondemand.c +++ b/drivers/cpufreq/cpufreq_ondemand.c @@ -12,6 +12,7 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt +#include <linux/cpu.h> #include <linux/cpufreq.h> #include <linux/init.h> #include <linux/kernel.h> @@ -24,7 +25,6 @@ #include <linux/sysfs.h> #include <linux/tick.h> #include <linux/types.h> -#include <linux/cpu.h> #include "cpufreq_governor.h" diff --git a/drivers/cpufreq/cpufreq_performance.c b/drivers/cpufreq/cpufreq_performance.c index 9fef7d6..bdfda75 100644 --- a/drivers/cpufreq/cpufreq_performance.c +++ b/drivers/cpufreq/cpufreq_performance.c @@ -12,10 +12,10 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt -#include <linux/kernel.h> -#include <linux/module.h> #include <linux/cpufreq.h> #include <linux/init.h> +#include <linux/kernel.h> +#include <linux/module.h> static int cpufreq_governor_performance(struct cpufreq_policy *policy, unsigned int event) diff --git a/drivers/cpufreq/cpufreq_powersave.c b/drivers/cpufreq/cpufreq_powersave.c index 32109a1..47235e2 100644 --- a/drivers/cpufreq/cpufreq_powersave.c +++ b/drivers/cpufreq/cpufreq_powersave.c @@ -12,10 +12,10 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt -#include <linux/kernel.h> -#include <linux/module.h> #include <linux/cpufreq.h> #include <linux/init.h> +#include <linux/kernel.h> +#include <linux/module.h> static int cpufreq_governor_powersave(struct cpufreq_policy *policy, unsigned int event) diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c index cb38413..7610e4b 100644 --- a/drivers/cpufreq/cpufreq_stats.c +++ b/drivers/cpufreq/cpufreq_stats.c @@ -9,17 +9,17 @@ * published by the Free Software Foundation. */ -#include <linux/kernel.h> -#include <linux/slab.h> #include <linux/cpu.h> -#include <linux/sysfs.h> #include <linux/cpufreq.h> -#include <linux/module.h> #include <linux/jiffies.h> -#include <linux/percpu.h> +#include <linux/kernel.h> #include <linux/kobject.h> -#include <linux/spinlock.h> +#include <linux/module.h> #include <linux/notifier.h> +#include <linux/percpu.h> +#include <linux/slab.h> +#include <linux/spinlock.h> +#include <linux/sysfs.h> #include <asm/cputime.h> static spinlock_t cpufreq_stats_lock; diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index e1fd215..247d83a 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -11,15 +11,15 @@ #ifndef _LINUX_CPUFREQ_H #define _LINUX_CPUFREQ_H -#include <asm/cputime.h> +#include <linux/cpumask.h> +#include <linux/completion.h> +#include <linux/kobject.h> #include <linux/mutex.h> #include <linux/notifier.h> -#include <linux/threads.h> -#include <linux/kobject.h> #include <linux/sysfs.h> -#include <linux/completion.h> +#include <linux/threads.h> #include <linux/workqueue.h> -#include <linux/cpumask.h> +#include <asm/cputime.h> #include <asm/div64.h> #define CPUFREQ_NAME_LEN 16 -- 1.7.12.rc2.18.g61b472e

11 years, 11 months

[PATCH V4 0/6] USB: OHCI: more bus glues as separate modules

by Manjunath Goudar

These patches are for separating the SOC On-Chip ohci host controller from ohci-hcd host code into its own driver module. This work is part of enabling multi-platform kernels on ARM; it would be nice to have in 3.12. V2: In patch 5/6 and 6/6: -Set non-standard fields in hc_driver manually, rather than relying on an expanded struct ohci_driver_overrides. -Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than relying on ohci_hub_control and hub_status_data being exported. In patch 1/6 to 4/6 -ohci_setup() has been removed because it is called in .reset member of the ohci_hc_driver structure. V3: In patch 5/6 and 6/6: -ohci_setup() has been removed because it is called in .reset member of the ohci_hc_driver structure. In patch 5/6: -The ohci_restart() function is not required in current scenario, only discarding connection state of integrated transceivers is sufficient, for this directly handling ohci->hc_control. In patch 2/6 : -rewritten if (config->otg || config->rwc) block statements into two separate 'if blocks' to handle below scenarios 1. config->otg set scenario. 2. if any of these (config->otg, config->rwc) are set, this scenario should be handled only after ohci_setup() In patch 1/6 and 4/6: No change. V4: In patch 1/6 and 4/6: No change. In patch 2/6 : -usb_remove_hcd() function is required a valid clock that is what omap_ohci_clock_power(0) is called after hcd shutdown. In patch 3/6 : -V3 modification revert back, only ohci->regs setting write() function has been removed because ohci->regs doesn't get set until usb_add_hcd. In patch 5/6 : - Removed extra space after "tristate". - Removed extra space between function name and '(' characters. - MODULE_ALIAS line moved to last statement of ohci-at91 file. In patch 6/6 : - Removed extra space before the '='. - Moved /* forward definitions */ line before the declarations of functions. Manjunath Goudar (6): USB: OHCI: make ohci-exynos a separate driver USB: OHCI: make ohci-omap a separate driver USB: OHCI: make ohci-omap3 a separate driver USB: OHCI: make ohci-spear a separate driver USB: OHCI: make ohci-at91 a separate driver USB: OHCI: make ohci-s3c2410 a separate driver drivers/usb/host/Kconfig | 30 ++++++- drivers/usb/host/Makefile | 6 ++ drivers/usb/host/ohci-at91.c | 153 ++++++++++++++++------------------- drivers/usb/host/ohci-exynos.c | 167 ++++++++++++++++----------------------- drivers/usb/host/ohci-hcd.c | 108 ------------------------- drivers/usb/host/ohci-omap.c | 156 +++++++++++++----------------------- drivers/usb/host/ohci-omap3.c | 118 +++++++++------------------ drivers/usb/host/ohci-s3c2410.c | 128 +++++++++++++----------------- drivers/usb/host/ohci-spear.c | 140 +++++++++++++------------------- 9 files changed, 374 insertions(+), 632 deletions(-) -- 1.7.9.5

11 years, 11 months

[PATCH V2] USB: EHCI: make ehci-w90X900 a separate driver

by Manjunath Goudar

Separate the W90X900(W90P910) on-chip host controller driver from ehci-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; however, note that other changes are still needed before W90X900(W90P910) can be booted with a multi-platform kernel and an ehci driver that only works on one of them. With the infrastructure added by Alan Stern in patch 3e0232039 "USB: EHCI: prepare to make ehci-hcd a library module", we can avoid this problem by turning a bus glue into a separate module, as we do here for the w90X900 bus glue. Signed-off-by: Manjunath Goudar <manjunath.goudar(a)linaro.org> Acked-by: Arnd Bergmann <arnd(a)arndb.de> Cc: Greg KH <greg(a)kroah.com> Cc: Alan Stern <stern(a)rowland.harvard.edu> Cc: Wan ZongShun <mcuos.com(a)gmail.com> Cc: linux-usb(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org V2: -Arranged #include's in alphabetical order. -Replaced "w90p910" by "w90x900" because it is supports all series of w90x900. --- drivers/usb/host/Kconfig | 2 +- drivers/usb/host/Makefile | 1 + drivers/usb/host/ehci-hcd.c | 5 --- drivers/usb/host/ehci-w90x900.c | 85 ++++++++++++++++----------------------- 4 files changed, 37 insertions(+), 56 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index ba52912..7bc598b 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -244,7 +244,7 @@ config USB_EHCI_MV SoCs, see USB_EHCI_HCD_ORION for those. config USB_W90X900_EHCI - bool "W90X900(W90P910) EHCI support" + tristate "W90X900(W90P910) EHCI support" depends on ARCH_W90X900 ---help--- Enables support for the W90X900 USB controller diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index 7664db8..28adb3f 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -35,6 +35,7 @@ obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o obj-$(CONFIG_USB_EHCI_MSM) += ehci-msm.o obj-$(CONFIG_USB_EHCI_TEGRA) += ehci-tegra.o obj-$(CONFIG_USB_EHCI_MV) += ehci-mv.o +obj-$(CONFIG_USB_W90X900_EHCI) += ehci-w90x900.o obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 5717dcd..4a5644e 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -1249,11 +1249,6 @@ MODULE_LICENSE ("GPL"); #define XILINX_OF_PLATFORM_DRIVER ehci_hcd_xilinx_of_driver #endif -#ifdef CONFIG_USB_W90X900_EHCI -#include "ehci-w90x900.c" -#define PLATFORM_DRIVER ehci_hcd_w90x900_driver -#endif - #ifdef CONFIG_USB_OCTEON_EHCI #include "ehci-octeon.c" #define PLATFORM_DRIVER ehci_octeon_driver diff --git a/drivers/usb/host/ehci-w90x900.c b/drivers/usb/host/ehci-w90x900.c index 59e0e24..4d6631d 100644 --- a/drivers/usb/host/ehci-w90x900.c +++ b/drivers/usb/host/ehci-w90x900.c @@ -11,13 +11,28 @@ * */ +#include <linux/dma-mapping.h> +#include <linux/io.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/of.h> #include <linux/platform_device.h> +#include <linux/usb.h> +#include <linux/usb/hcd.h> + +#include "ehci.h" /* enable phy0 and phy1 for w90p910 */ #define ENPHY (0x01<<8) #define PHY0_CTR (0xA4) #define PHY1_CTR (0xA8) +#define DRIVER_DESC "EHCI w90x900 driver" + +static const char hcd_name[] = "ehci-w90x900 "; + +static struct hc_driver __read_mostly ehci_w90x900_hc_driver; + static int usb_w90x900_probe(const struct hc_driver *driver, struct platform_device *pdev) { @@ -99,54 +114,6 @@ void usb_w90x900_remove(struct usb_hcd *hcd, struct platform_device *pdev) usb_put_hcd(hcd); } -static const struct hc_driver ehci_w90x900_hc_driver = { - .description = hcd_name, - .product_desc = "Nuvoton w90x900 EHCI Host Controller", - .hcd_priv_size = sizeof(struct ehci_hcd), - - /* - * generic hardware linkage - */ - .irq = ehci_irq, - .flags = HCD_USB2|HCD_MEMORY, - - /* - * basic lifecycle operations - */ - .reset = ehci_setup, - .start = ehci_run, - - .stop = ehci_stop, - .shutdown = ehci_shutdown, - - /* - * managing i/o requests and associated device resources - */ - .urb_enqueue = ehci_urb_enqueue, - .urb_dequeue = ehci_urb_dequeue, - .endpoint_disable = ehci_endpoint_disable, - .endpoint_reset = ehci_endpoint_reset, - - /* - * scheduling support - */ - .get_frame_number = ehci_get_frame, - - /* - * root hub support - */ - .hub_status_data = ehci_hub_status_data, - .hub_control = ehci_hub_control, -#ifdef CONFIG_PM - .bus_suspend = ehci_bus_suspend, - .bus_resume = ehci_bus_resume, -#endif - .relinquish_port = ehci_relinquish_port, - .port_handed_over = ehci_port_handed_over, - - .clear_tt_buffer_complete = ehci_clear_tt_buffer_complete, -}; - static int ehci_w90x900_probe(struct platform_device *pdev) { if (usb_disabled()) @@ -173,7 +140,25 @@ static struct platform_driver ehci_hcd_w90x900_driver = { }, }; +static int __init ehci_w90X900_init(void) +{ + if (usb_disabled()) + return -ENODEV; + + pr_info("%s: " DRIVER_DESC "\n", hcd_name); + + ehci_init_driver(&ehci_w90x900_hc_driver, NULL); + return platform_driver_register(&ehci_hcd_w90x900_driver); +} +module_init(ehci_w90X900_init); + +static void __exit ehci_w90X900_cleanup(void) +{ + platform_driver_unregister(&ehci_hcd_w90x900_driver); +} +module_exit(ehci_w90X900_cleanup); + +MODULE_DESCRIPTION(DRIVER_DESC); MODULE_AUTHOR("Wan ZongShun <mcuos.com(a)gmail.com>"); -MODULE_DESCRIPTION("w90p910 usb ehci driver!"); -MODULE_LICENSE("GPL"); MODULE_ALIAS("platform:w90p910-ehci"); +MODULE_LICENSE("GPL v2"); -- 1.7.9.5

11 years, 11 months

[PATCH 1/5] regulator: core: Provide hints to the core about optional supplies

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> While the majority of supplies on devices are mandatory and can't be physically omitted for electrical reasons some devices do have optional supplies and need to know if they are missing, MMC being the most common of these. Currently the core accurately reports all errors when regulators are requested since it does not know if the supply is one that must be provided even if by a regulator software does not know about or if it is one that may genuinely be disconnected. In order to allow this behaviour to be changed and stub regulators to be provided in the former case add a new regulator request function regulator_get_optional() which provides a hint to the core that the regulator may genuinely not be connected. Currently the implementation is identical to the current behaviour, future patches will add support in the core for returning stub regulators in the case where normal regulator_get() fails and the board has requested it. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- drivers/regulator/core.c | 59 ++++++++++++++++++++++++++++++++++++++ include/linux/regulator/consumer.h | 18 +++++++++++- 2 files changed, 76 insertions(+), 1 deletion(-) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 61e4060..f24f401 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -1414,6 +1414,65 @@ struct regulator *regulator_get_exclusive(struct device *dev, const char *id) } EXPORT_SYMBOL_GPL(regulator_get_exclusive); +/** + * regulator_get_optional - obtain optional access to a regulator. + * @dev: device for regulator "consumer" + * @id: Supply name or regulator ID. + * + * Returns a struct regulator corresponding to the regulator producer, + * or IS_ERR() condition containing errno. Other consumers will be + * unable to obtain this reference is held and the use count for the + * regulator will be initialised to reflect the current state of the + * regulator. + * + * This is intended for use by consumers for devices which can have + * some supplies unconnected in normal use, such as some MMC devices. + * It can allow the regulator core to provide stub supplies for other + * supplies requested using normal regulator_get() calls without + * disrupting the operation of drivers that can handle absent + * supplies. + * + * Use of supply names configured via regulator_set_device_supply() is + * strongly encouraged. It is recommended that the supply name used + * should match the name used for the supply and/or the relevant + * device pins in the datasheet. + */ +struct regulator *regulator_get_optional(struct device *dev, const char *id) +{ + return _regulator_get(dev, id, 0); +} +EXPORT_SYMBOL_GPL(regulator_get_optional); + +/** + * devm_regulator_get_optional - Resource managed regulator_get_optional() + * @dev: device for regulator "consumer" + * @id: Supply name or regulator ID. + * + * Managed regulator_get_optional(). Regulators returned from this + * function are automatically regulator_put() on driver detach. See + * regulator_get_optional() for more information. + */ +struct regulator *devm_regulator_get_optional(struct device *dev, + const char *id) +{ + struct regulator **ptr, *regulator; + + ptr = devres_alloc(devm_regulator_release, sizeof(*ptr), GFP_KERNEL); + if (!ptr) + return ERR_PTR(-ENOMEM); + + regulator = regulator_get_optional(dev, id); + if (!IS_ERR(regulator)) { + *ptr = regulator; + devres_add(dev, ptr); + } else { + devres_free(ptr); + } + + return regulator; +} +EXPORT_SYMBOL_GPL(devm_regulator_get_optional); + /* Locks held by regulator_put() */ static void _regulator_put(struct regulator *regulator) { diff --git a/include/linux/regulator/consumer.h b/include/linux/regulator/consumer.h index 1ccc889..2582e41 100644 --- a/include/linux/regulator/consumer.h +++ b/include/linux/regulator/consumer.h @@ -137,6 +137,10 @@ struct regulator *__must_check devm_regulator_get(struct device *dev, const char *id); struct regulator *__must_check regulator_get_exclusive(struct device *dev, const char *id); +struct regulator *__must_check regulator_get_optional(struct device *dev, + const char *id); +struct regulator *__must_check devm_regulator_get_optional(struct device *dev, + const char *id); void regulator_put(struct regulator *regulator); void devm_regulator_put(struct regulator *regulator); @@ -212,14 +216,26 @@ static inline struct regulator *__must_check regulator_get(struct device *dev, } static inline struct regulator *__must_check +devm_regulator_get(struct device *dev, const char *id) +{ + return NULL; +} + +static inline struct regulator *__must_check regulator_get_exclusive(struct device *dev, const char *id) { return NULL; } +static inline struct regulator *__must_check +regulator_get_optional(struct device *dev, const char *id) +{ + return NULL; +} + static inline struct regulator *__must_check -devm_regulator_get(struct device *dev, const char *id) +devm_regulator_get_optional(struct device *dev, const char *id) { return NULL; } -- 1.8.3.2

11 years, 11 months

[PATCH 0/5] Optional regulator support

by Mark Brown

This patch series adds a variant of regulator_get() which allows regulator consumers to tell the core that the supply they are requesting may genuinely be absent in the system. The goal is to help address some of the problems with handling errors in regulator_get() in drivers that are newly converted to the regulator API by allowing the core to provide stub regulators for supplies that aren't hooked up without disrupting the operation of drivers like MMC drivers which may genuinely not have some of their supplies hooked up. Currently the code simply introduces a new API call with exactly the same implementation as regulator_get() so there should be zero impact from the series other than a slightly larger kernel. Right now all the MMC users are converted over as-is, though it does look like drivers such as sdhci really ought to be insisting on having a regulator for VMMC in the same way that the MMC core helper does (and indeed in that case it looks like it ought to be converted over to the core code). If this series is OK I'd like to merge it via the regulator tree so that the functionality to make use of the optional regulators can be built out on top of it. Mark Brown (5): regulator: core: Provide hints to the core about optional supplies mmc: core: Indicate that vmmcq may be absent mmc: sdhci: Indicate that regulators may be absent mmc: dw_mmc: Indicate that regulators may be absent mmc: pxamci: Indicate that regulators may be absent drivers/mmc/core/core.c | 2 +- drivers/mmc/host/dw_mmc.c | 2 +- drivers/mmc/host/pxamci.c | 2 +- drivers/mmc/host/sdhci.c | 4 +-- drivers/regulator/core.c | 59 ++++++++++++++++++++++++++++++++++++++ include/linux/regulator/consumer.h | 18 +++++++++++- 6 files changed, 81 insertions(+), 6 deletions(-)

11 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel