* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
From: Andrey Rahmatullin @ 2012-04-21 21:51 UTC (permalink / raw)
To: Steven Rostedt
Cc: Alan Stern, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list
In-Reply-To: <1335034218.28106.91.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 372 bytes --]
On Sat, Apr 21, 2012 at 02:50:18PM -0400, Steven Rostedt wrote:
> > > (Does anybody know if USB wakeup works on these machines under
> > > Windows?)
> > Out of the box it doesn't work and "Allow this device to wake up the
> > computer" checkboxes on both root hubs are unchecked and grayed out.
> Where do you see those checkboxes?
Device Manager
--
WBR, wRAR
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
From: Andrey Rahmatullin @ 2012-04-21 21:54 UTC (permalink / raw)
To: Alan Stern
Cc: jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
Steven Rostedt
In-Reply-To: <Pine.LNX.4.44L0.1204211712430.3981-100000-pYrvlCTfrz9XsRXLowluHWD2FQJk+8+b@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 795 bytes --]
On Sat, Apr 21, 2012 at 05:15:14PM -0400, Alan Stern wrote:
> > > Okay, that's good. I assume the device you plugged in then
> > > functioned
> > > properly?
> >
> > Yes.
>
> All right. Maybe you posted this information earlier in the thread,
> but it's easier to ask again than try to find it. What output do you
> get from "lspci -nv -s 1a.0"?
00:1a.0 0c03: 8086:1c2d (rev 05) (prog-if 20 [EHCI])
Subsystem: 1043:1147
Flags: bus master, medium devsel, latency 0, IRQ 16
Memory at dfe08000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
Kernel driver in use: ehci_hcd
--
WBR, wRAR
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
From: Alan Stern @ 2012-04-23 16:29 UTC (permalink / raw)
To: Steven Rostedt
Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list
In-Reply-To: <20120421215459.GB4772-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
On Sun, 22 Apr 2012, Andrey Rahmatullin wrote:
> > All right. Maybe you posted this information earlier in the thread,
> > but it's easier to ask again than try to find it. What output do you
> > get from "lspci -nv -s 1a.0"?
> 00:1a.0 0c03: 8086:1c2d (rev 05) (prog-if 20 [EHCI])
> Subsystem: 1043:1147
> Flags: bus master, medium devsel, latency 0, IRQ 16
> Memory at dfe08000 (32-bit, non-prefetchable) [size=1K]
> Capabilities: [50] Power Management version 2
> Capabilities: [58] Debug port: BAR=1 offset=00a0
> Capabilities: [98] PCI Advanced Features
> Kernel driver in use: ehci_hcd
Steve, what about you? Do you get the same thing?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Steven Rostedt @ 2012-04-23 18:30 UTC (permalink / raw)
To: Alan Stern; +Cc: jrnieder, Andrey Rahmatullin, linux-pm, USB list
In-Reply-To: <Pine.LNX.4.44L0.1204231228370.1612-100000@iolanthe.rowland.org>
On Mon, 2012-04-23 at 12:29 -0400, Alan Stern wrote:
> On Sun, 22 Apr 2012, Andrey Rahmatullin wrote:
>
> > > All right. Maybe you posted this information earlier in the thread,
> > > but it's easier to ask again than try to find it. What output do you
> > > get from "lspci -nv -s 1a.0"?
> > 00:1a.0 0c03: 8086:1c2d (rev 05) (prog-if 20 [EHCI])
> > Subsystem: 1043:1147
> > Flags: bus master, medium devsel, latency 0, IRQ 16
> > Memory at dfe08000 (32-bit, non-prefetchable) [size=1K]
> > Capabilities: [50] Power Management version 2
> > Capabilities: [58] Debug port: BAR=1 offset=00a0
> > Capabilities: [98] PCI Advanced Features
> > Kernel driver in use: ehci_hcd
>
> Steve, what about you? Do you get the same thing?
>
00:1a.0 0c03: 8086:1c2d (rev 05) (prog-if 20 [EHCI])
Subsystem: 1043:1157
Flags: bus master, medium devsel, latency 0, IRQ 16
Memory at dfc08000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
Kernel driver in use: ehci_hcd
Almost, the Subsystem is 1157 instead of 1147. But the rest looks alike.
-- Steve
^ permalink raw reply
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
From: Alan Stern @ 2012-04-23 20:11 UTC (permalink / raw)
To: Steven Rostedt
Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list
In-Reply-To: <1335205839.28106.108.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
On Mon, 23 Apr 2012, Steven Rostedt wrote:
> On Mon, 2012-04-23 at 12:29 -0400, Alan Stern wrote:
> > On Sun, 22 Apr 2012, Andrey Rahmatullin wrote:
> >
> > > > All right. Maybe you posted this information earlier in the thread,
> > > > but it's easier to ask again than try to find it. What output do you
> > > > get from "lspci -nv -s 1a.0"?
> > > 00:1a.0 0c03: 8086:1c2d (rev 05) (prog-if 20 [EHCI])
> > > Subsystem: 1043:1147
> > > Flags: bus master, medium devsel, latency 0, IRQ 16
> > > Memory at dfe08000 (32-bit, non-prefetchable) [size=1K]
> > > Capabilities: [50] Power Management version 2
> > > Capabilities: [58] Debug port: BAR=1 offset=00a0
> > > Capabilities: [98] PCI Advanced Features
> > > Kernel driver in use: ehci_hcd
> >
> > Steve, what about you? Do you get the same thing?
> >
>
> 00:1a.0 0c03: 8086:1c2d (rev 05) (prog-if 20 [EHCI])
> Subsystem: 1043:1157
> Flags: bus master, medium devsel, latency 0, IRQ 16
> Memory at dfc08000 (32-bit, non-prefetchable) [size=1K]
> Capabilities: [50] Power Management version 2
> Capabilities: [58] Debug port: BAR=1 offset=00a0
> Capabilities: [98] PCI Advanced Features
> Kernel driver in use: ehci_hcd
>
> Almost, the Subsystem is 1157 instead of 1147. But the rest looks alike.
I don't have a very clear idea of how specific this needs to be. There
have been other bug reports of problems related to suspend that were
fixed by the same script you were using, but the symptoms weren't the
same. For example, see Bugzilla #42728.
Anyway, this patch is reasonably close to being a final version, and it
should work on both machines. You should be able to suspend and resume
with no problems, without using the script.
Alan Stern
Index: usb-3.4/include/linux/usb/hcd.h
===================================================================
--- usb-3.4.orig/include/linux/usb/hcd.h
+++ usb-3.4/include/linux/usb/hcd.h
@@ -126,6 +126,8 @@ struct usb_hcd {
unsigned wireless:1; /* Wireless USB HCD */
unsigned authorized_default:1;
unsigned has_tt:1; /* Integrated TT in root hub */
+ unsigned broken_pci_sleep:1; /* Don't put the
+ controller in PCI-D3 for system sleep */
unsigned int irq; /* irq allocated */
void __iomem *regs; /* device memory/io */
Index: usb-3.4/drivers/usb/core/hcd-pci.c
===================================================================
--- usb-3.4.orig/drivers/usb/core/hcd-pci.c
+++ usb-3.4/drivers/usb/core/hcd-pci.c
@@ -493,6 +493,15 @@ static int hcd_pci_suspend_noirq(struct
pci_save_state(pci_dev);
+ /*
+ * Some systems crash if an EHCI controller is in D3 during
+ * a sleep transition. We have to leave such controllers in D0.
+ */
+ if (hcd->broken_pci_sleep) {
+ dev_dbg(dev, "Staying in PCI D0\n");
+ return retval;
+ }
+
/* If the root hub is dead rather than suspended, disallow remote
* wakeup. usb_hc_died() should ensure that both hosts are marked as
* dying, so we only need to check the primary roothub.
Index: usb-3.4/drivers/usb/host/ehci-pci.c
===================================================================
--- usb-3.4.orig/drivers/usb/host/ehci-pci.c
+++ usb-3.4/drivers/usb/host/ehci-pci.c
@@ -144,6 +144,13 @@ static int ehci_pci_setup(struct usb_hcd
hcd->has_tt = 1;
tdi_reset(ehci);
}
+ if (pdev->subsystem_vendor == PCI_VENDOR_ID_ASUSTEK) {
+ /* EHCI #1 or #2 on 6 Series/C200 Series chipset */
+ if (pdev->device == 0x1c26 || pdev->device == 0x1c2d) {
+ ehci_info(ehci, "broken D3 during system sleep on ASUS\n");
+ hcd->broken_pci_sleep = 1;
+ }
+ }
break;
case PCI_VENDOR_ID_TDI:
if (pdev->device == PCI_DEVICE_ID_TDI_EHCI) {
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
From: Steven Rostedt @ 2012-04-24 3:01 UTC (permalink / raw)
To: Alan Stern
Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list
In-Reply-To: <Pine.LNX.4.44L0.1204231554210.1612-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
On Mon, 2012-04-23 at 16:11 -0400, Alan Stern wrote:
> I don't have a very clear idea of how specific this needs to be. There
> have been other bug reports of problems related to suspend that were
> fixed by the same script you were using, but the symptoms weren't the
> same. For example, see Bugzilla #42728.
>
> Anyway, this patch is reasonably close to being a final version, and it
> should work on both machines. You should be able to suspend and resume
> with no problems, without using the script.
>
Tested-by: Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>
Thanks!
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
From: Andrey Rahmatullin @ 2012-04-24 10:42 UTC (permalink / raw)
To: Alan Stern
Cc: Steven Rostedt, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list
In-Reply-To: <Pine.LNX.4.44L0.1204231554210.1612-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 625 bytes --]
On Mon, Apr 23, 2012 at 04:11:48PM -0400, Alan Stern wrote:
> I don't have a very clear idea of how specific this needs to be. There
> have been other bug reports of problems related to suspend that were
> fixed by the same script you were using, but the symptoms weren't the
> same. For example, see Bugzilla #42728.
>
> Anyway, this patch is reasonably close to being a final version, and it
> should work on both machines. You should be able to suspend and resume
> with no problems, without using the script.
Tested-by: Andrey Rahmatullin <wrar-Bxt/JK/G85ezQB+pC5nmwQ@public.gmane.org>
--
WBR, wRAR
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH V2 0/6] thermal: exynos: Add kernel thermal support for exynos platform
From: Amit Kachhap @ 2012-04-24 13:24 UTC (permalink / raw)
To: Zhang Rui
Cc: lenb, linux-pm, linux-samsung-soc, linux-kernel, mjg59,
linux-acpi, linaro-dev, lm-sensors, patches, eduardo.valentin,
durgadoss.r
In-Reply-To: <1334542022.2387.325.camel@rui.sh.intel.com>
On 16 April 2012 07:37, Zhang Rui <rui.zhang@intel.com> wrote:
> On 三, 2012-04-11 at 18:17 +0530, Amit Kachhap wrote:
>> Hi Rui,
>>
>> Thanks for looking into the patches.
>>
>> On 10 April 2012 06:28, Zhang Rui <rui.zhang@intel.com> wrote:
>> > Hi, Amit,
>> >
>> > On 三, 2012-04-04 at 10:02 +0530, Amit Kachhap wrote:
>> >> Hi Len/Rui,
>> >>
>> >> Any comment or feedback from your side about the status of this patch?
>> >> Is it merge-able or major re-work is needed? I have fixed most of the
>> >> comments in this patchset and currently working on some of the minor
>> >> comments received and will submit them shortly.
>> >>
>> > Sorry for the late response.
>> >
>> > First of all, it makes sense to me to introduce the generic cpufrq
>> > cooling implementation.
>> ok thanks
>> > But I still have some questions.
>> > I think the key reason why THERMAL_TRIP_STATE_INSTANCE is introduced is
>> > that the MONIROR_ZONE and WARN_ZONE on exynos4 can not fit into the
>> > current passive handling in the generic thermal layer well, right?
>> > e.g. there is no tc1/tc2 on exynos4.
>> >
>> > If yes, is it possible that we can enhance the passive cooling to
>> > support the generic processor cooling?
>> > say, introduce another way to throttle the processor in
>> > thermal_zone_device_passive when tc1 and tc2 are not available?
>>
>> I agree that this new trip type code can be moved into passive trip
>> type when tc1 and tc2 are 0. but this is special type of cooling
>> devices behaviour where only instances of the same cooling device is
>> binded to a trip point. The order of mapping is the only
>> differentiating criteria and there are some checks used to implement
>> this like
>> 1) The trip points should be in ascending order.(This is missing in my
>> original patch, so I added below)
>> 2) The set_cur_state has to be called for the exact temp range so
>> get_cur_state(&state) and set_cur_state(state ++/state--) logic is not
>> possible.
>> 3) set_cur_state is called as set_cur_state(cdev_instance).
>
> Do you really need two THERMAL_TRIP_STATE_INSTANCE trip points?
Sorry for late reply as I was off for vacation.
Yes we need 2 trip points of type THERMAL_TRIP_STATE_INSTANCE as we
need different cooling for these 2 zones. Anyways Do you feel that
these whole/partial patch series(cpufreq cooling api's, new trip type
etc) is ack-able or some modification is needed?
>
> I'm not sure if my understanding is right, but IMO, we can have one
> THERMAL_TRIP_STATE_INSTANCE only, for both MONIROR_ZONE and WARN_ZONE,
> and the trip temperature equals MONIROR_ZONE.
> The cpufreq cooling device will work in the same way, no?
>
> thanks,
> rui
>
>> There is a chance that people might confuse that these checks are
>> applicable for passive trip types also which is not the case here.
>>
>> @@ -1187,6 +1228,21 @@ struct thermal_zone_device
>> *thermal_zone_device_register(char *type,
>> tz->ops->get_trip_type(tz, count, &trip_type);
>> if (trip_type == THERMAL_TRIP_PASSIVE)
>> passive = 1;
>> + /*
>> + * For THERMAL_TRIP_STATE_INSTANCE trips, thermal zone should
>> + * be in ascending order.
>> + */
>> + if (trip_type == THERMAL_TRIP_STATE_INSTANCE) {
>> + tz->ops->get_trip_temp(tz, count, &trip_temp);
>> + if (first_trip_temp == 0)
>> + first_trip_temp = trip_temp;
>> + else if (first_trip_temp < trip_temp)
>> + first_trip_temp = trip_temp;
>> + else if (first_trip_temp > trip_temp) {
>> + pr_warn("Zone trip points should be in
>> ascending order\n");
>> + goto unregister;
>> + }
>> + }
>> }
>>
>> if (!passive)
>>
>> Anyway there is other alternative where this new trip type is not
>> needed and I can just use the existing trip type THERMAL_TRIP_ACTIVE
>> and create 2 separate cooling devices for MONITOR_ZONE and WARN_ZONE.
>> I had thought to make this generic and just to manage with 1 cooling
>> device.
>> What is your view?
>>
>> Thanks,
>> Amit Daniel
>>
>>
>> >
>> > thanks,
>> > rui
>> >
>> >> Regards,
>> >> Amit Daniel
>> >>
>> >> On 19 March 2012 11:47, Amit Daniel Kachhap <amit.kachhap@linaro.org> wrote:
>> >> > Changes since V1:
>> >> > *Moved the sensor driver to driver/thermal folder from driver/hwmon folder
>> >> > as suggested by Mark Brown and Guenter Roeck
>> >> > *Added notifier support to notify the registered drivers of any cpu cooling
>> >> > action. The driver can modify the default cooling behaviour(eg set different
>> >> > max clip frequency).
>> >> > *The percentage based frequency replaced with absolute clipped frequency.
>> >> > *Some more conditional checks when setting max frequency.
>> >> > *Renamed the new trip type THERMAL_TRIP_STATE_ACTIVE to
>> >> > THERMAL_TRIP_STATE_INSTANCE
>> >> > *Many review comments from R, Durgadoss <durgadoss.r@intel.com> and
>> >> > eduardo.valentin@ti.com implemented.
>> >> > *Removed cooling stats through debugfs patch
>> >> > *The V1 based can be found here,
>> >> > https://lkml.org/lkml/2012/2/22/123
>> >> > http://lkml.org/lkml/2012/3/3/32
>> >> >
>> >> > Changes since RFC:
>> >> > *Changed the cpu cooling registration/unregistration API's to instance based
>> >> > *Changed the STATE_ACTIVE trip type to pass correct instance id
>> >> > *Adding support to restore back the policy->max_freq after doing frequency
>> >> > clipping.
>> >> > *Moved the trip cooling stats from sysfs node to debugfs node as suggested
>> >> > by Greg KH greg@kroah.com
>> >> > *Incorporated several review comments from eduardo.valentin@ti.com
>> >> > *Moved the Temperature sensor driver from driver/hwmon/ to driver/mfd
>> >> > as discussed with Guenter Roeck <guenter.roeck@ericsson.com> and
>> >> > Donggeun Kim <dg77.kim@samsung.com> (https://lkml.org/lkml/2012/1/5/7)
>> >> > *Some changes according to the changes in common cpu cooling APIs
>> >> > *The RFC based patches can be found here,
>> >> > https://lkml.org/lkml/2011/12/13/186
>> >> > https://lkml.org/lkml/2011/12/21/169
>> >> >
>> >> >
>> >> > Brief Description:
>> >> >
>> >> > 1) The generic cooling devices code is placed inside driver/thermal/* as
>> >> > placing inside acpi folder will need un-necessary enabling of acpi code. This
>> >> > codes is architecture independent.
>> >> >
>> >> > 2) This patchset adds a new trip type THERMAL_TRIP_STATE_INSTANCE which passes
>> >> > cooling device instance number and may be helpful for cpufreq cooling devices
>> >> > to take the correct cooling action. This trip type avoids the temperature
>> >> > comparision check again inside the cooling handler.
>> >> >
>> >> > 3) This patchset adds generic cpu cooling low level implementation through
>> >> > frequency clipping and cpu hotplug. In future, other cpu related cooling
>> >> > devices may be added here. An ACPI version of this already exists
>> >> > (drivers/acpi/processor_thermal.c). But this will be useful for platforms
>> >> > like ARM using the generic thermal interface along with the generic cpu
>> >> > cooling devices. The cooling device registration API's return cooling device
>> >> > pointers which can be easily binded with the thermal zone trip points.
>> >> > The important APIs exposed are,
>> >> > a)struct thermal_cooling_device *cpufreq_cooling_register(
>> >> > struct freq_clip_table *tab_ptr, unsigned int tab_size,
>> >> > const struct cpumask *mask_val)
>> >> > b)void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
>> >> >
>> >> > 4) Samsung exynos platform thermal implementation is done using the generic
>> >> > cpu cooling APIs and the new trip type. The temperature sensor driver present
>> >> > in the hwmon folder(registered as hwmon driver) is moved to thermal folder
>> >> > and registered as a thermal driver.
>> >> >
>> >> > All this patchset is based on Kernel version 3.3-rc7
>> >> >
>> >> > A simple data/control flow diagrams is shown below,
>> >> >
>> >> > Core Linux thermal <-----> Exynos thermal interface <----- Temperature Sensor
>> >> > | |
>> >> > \|/ |
>> >> > Cpufreq cooling device <---------------
>> >> >
>> >> >
>> >> > Amit Daniel Kachhap (6):
>> >> > thermal: Add a new trip type to use cooling device instance number
>> >> > thermal: Add generic cpufreq cooling implementation
>> >> > thermal: Add generic cpuhotplug cooling implementation
>> >> > hwmon: exynos4: Move thermal sensor driver to driver/thermal
>> >> > directory
>> >> > thermal: exynos4: Register the tmu sensor with the kernel thermal
>> >> > layer
>> >> > ARM: exynos4: Add thermal sensor driver platform device support
>> >> >
>> >> > Documentation/hwmon/exynos4_tmu | 81 ---
>> >> > Documentation/thermal/cpu-cooling-api.txt | 76 +++
>> >> > Documentation/thermal/exynos4_tmu | 52 ++
>> >> > Documentation/thermal/sysfs-api.txt | 4 +-
>> >> > arch/arm/mach-exynos/Kconfig | 11 +
>> >> > arch/arm/mach-exynos/Makefile | 1 +
>> >> > arch/arm/mach-exynos/clock.c | 4 +
>> >> > arch/arm/mach-exynos/dev-tmu.c | 39 ++
>> >> > arch/arm/mach-exynos/include/mach/irqs.h | 2 +
>> >> > arch/arm/mach-exynos/include/mach/map.h | 1 +
>> >> > arch/arm/mach-exynos/mach-origen.c | 1 +
>> >> > arch/arm/plat-samsung/include/plat/devs.h | 1 +
>> >> > drivers/hwmon/Kconfig | 10 -
>> >> > drivers/hwmon/Makefile | 1 -
>> >> > drivers/hwmon/exynos4_tmu.c | 514 -------------------
>> >> > drivers/thermal/Kconfig | 21 +
>> >> > drivers/thermal/Makefile | 2 +
>> >> > drivers/thermal/cpu_cooling.c | 529 +++++++++++++++++++
>> >> > drivers/thermal/exynos4_thermal.c | 790 +++++++++++++++++++++++++++++
>> >> > drivers/thermal/thermal_sys.c | 45 ++-
>> >> > include/linux/cpu_cooling.h | 78 +++
>> >> > include/linux/platform_data/exynos4_tmu.h | 7 +
>> >> > include/linux/thermal.h | 1 +
>> >> > 23 files changed, 1660 insertions(+), 611 deletions(-)
>> >> > delete mode 100644 Documentation/hwmon/exynos4_tmu
>> >> > create mode 100644 Documentation/thermal/cpu-cooling-api.txt
>> >> > create mode 100644 Documentation/thermal/exynos4_tmu
>> >> > create mode 100644 arch/arm/mach-exynos/dev-tmu.c
>> >> > delete mode 100644 drivers/hwmon/exynos4_tmu.c
>> >> > create mode 100644 drivers/thermal/cpu_cooling.c
>> >> > create mode 100644 drivers/thermal/exynos4_thermal.c
>> >> > create mode 100644 include/linux/cpu_cooling.h
>> >> >
>> >
>> >
>
>
^ permalink raw reply
* udev/power_supply battery oscilates between remove and add
From: Adrian Fita @ 2012-04-24 23:24 UTC (permalink / raw)
To: linux-pm
[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]
Hi. I hope I'm addressing the appropriate mailinglist regarding this. If
not, please direct me to the right place where I should write.
I'm using Debian Wheezy/Testing, kernel 3.2.15-1 on a HP PowerBook 4515s
laptop.
I noticed that /var/log/syslog is getting spammed with messages like in
the attached syslog-laptop-mode_spam.log.gz file.
Also, at the same time, "upower --monitor" shows the messages from
upower-monitor.log.gz.
In Windows XP I don't see any issue with the battery and also running HP
Battery Check
(http://h20239.www2.hp.com/techcenter/battery/battery_ts.htm) I got the
result that the battery is functioning correctly, but is week
(admittedly it is more than a year old, but still holds a charge for 30
mins).
So it looks like a kernel issue. I started checking the udev events with
'udevadm monitor --property' and got the messages from the
udevadm_monitor.log.gz file.
This happens only when the battery and the power cable are connected.
When running with the battery removed or without the power cable
connected (running only on battery) this is not happening.
Here are some more discussions about this:
- a Debian Bug reported:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638970
- and also a thread on the Upower mailinglist:
http://lists.freedesktop.org/archives/devkit-devel/2012-February/001225.html
--
Fita Adrian
[-- Attachment #2: syslog-laptop-mode_spam.log.gz --]
[-- Type: application/x-gzip, Size: 160 bytes --]
[-- Attachment #3: upower-monitor.log.gz --]
[-- Type: application/x-gzip, Size: 240 bytes --]
[-- Attachment #4: udevadm_monitor.log.gz --]
[-- Type: application/x-gzip, Size: 616 bytes --]
[-- Attachment #5: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [REGRESSION]: hibernate/sleep regression w/ bisection
From: Andrew Watts @ 2012-04-25 20:04 UTC (permalink / raw)
To: Tejun Heo
Cc: Dmitry Torokhov, linux-kernel, linux-pm, David Airlie, dri-devel
In-Reply-To: <20111104161431.GZ4417@google.com>
Hello all.
I wanted to follow-up on a very peculiar yet highly reproducible bug
involving suspend/resume, radeon, and a seemingly unrelated patch to
input serio.
The last comment in the thread was from Jerome Glisse saying it was a tough
bug to fix. Has anyone had any good ideas on how to fix it since?
Thanks!
~ Andy
On Fri, Nov 04, 2011 at 09:14:31AM -0700, Tejun Heo wrote:
> (cc'ing David Airlie and dri-devel)
>
> Hello, the original thread can be read from
>
> http://thread.gmane.org/gmane.linux.kernel/1209587
>
> Full sysrq-t output at
>
> http://article.gmane.org/gmane.linux.kernel/1211256
>
> So, the problem is that after a seemingly unreated update to input
> serio driver (convert to use workqueue), X seems to lock up
> sporadically across suspend/resume cycles.
>
> I went through the full sysrq-t output but couldn't spot anything
> suspicious w/ anything else. No worker is stuck and nobody is waiting
> for flush to finish.
>
> Stack trace for X follows.
>
> > X S f499b944 5800 1652 1651 0x00400080
> > f499b9a8 00003086 00000000 f499b944 c100d4a4 00000000 00000000 f499b958
> > 00000000 f499b9a8 f5173140 d7857c56 00000057 f5173140 d8b69880 00000057
> > 00000001 00000000 f499b9b4 c104dd89 000f4240 00000000 00000000 f499ba68
> > Call Trace:
> > [<c1291301>] ttm_bo_wait_unreserved+0x5f/0x106
> > [<c129145f>] ttm_bo_reserve_locked+0xb7/0xe1
> > [<c1292c27>] ttm_bo_reserve+0x26/0x95
> > [<c12c3c97>] radeon_crtc_do_set_base+0xbd/0x6d2
> > [<c12c42e7>] radeon_crtc_set_base+0x1b/0x1d
> > [<c12c430d>] radeon_crtc_mode_set+0x24/0xdd7
> > [<c1279c57>] drm_crtc_helper_set_mode+0x32c/0x48b
> > [<c1279e2f>] drm_helper_resume_force_mode+0x79/0x23e
> > [<c12ace10>] radeon_gpu_reset+0x84/0x98
> > [<c12c0838>] radeon_fence_wait+0x2d1/0x311
> > [<c12c0e37>] radeon_sync_obj_wait+0xc/0xe
> > [<c12908be>] ttm_bo_wait+0xa1/0x108
> > [<c12d6e7b>] radeon_gem_wait_idle_ioctl+0x76/0xc4
> > [<c127e62e>] drm_ioctl+0x1c2/0x42c
> > [<c10e288e>] do_vfs_ioctl+0x79/0x54b
> > [<c10e2dcb>] sys_ioctl+0x6b/0x70
> > [<c1593813>] sysenter_do_call+0x12/0x22
>
> Do you guys have any ideas what's going on? It seems to be waiting
> for bo->reserved to go zero. Is it possible that someone there is
> forgetting to properly kick a work item after resume causing the wait
> to stall?
>
> Andrew, can you please kill the X server after the hang and see
> whether that brings the system back? I think sshd should still work
> and if not you can write a script to kill the X server after 30secs
> after resume (and kill that script if resume succeeds).
>
> Thank you.
>
> --
> tejun
^ permalink raw reply
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
From: Keerthy @ 2012-04-26 17:40 UTC (permalink / raw)
To: linux-omap, linux-arm-kernel, khilman, rjw, linux-kernel,
linux-pm
Cc: j-pihet, j-keerthy
From: J Keerthy <j-keerthy@ti.com>
AVS(Adaptive Voltage Scaling) is a power management technique which
controls the operating voltage of a device in order to optimize (i.e. reduce)
its power consumption. The voltage is adapted depending on static factors
(chip manufacturing process) and dynamic factors (temperature
depending performance).
The TI AVS solution is named Smartreflex.
To that end, create the AVS driver in drivers/power/avs and
move the OMAP SmartReflex code to the new directory. The
class driver is still retained in the mach-omap2 directory.
In preparation to the move of the OMAP code the following changes have been
made:
- fill in platform data from the device initialization code and pass
it to the driver,
- create CONFIG_AVS* config options accordingly.
The platform integration data for SmartReflex is passed from hwmod
and the voltage layer to the driver using pdata.
Tested on OMAP4430 SDP using omap2plus_defconfig with the
CONFIG_POWER_AVS* options set. Voltage correction seen
on oscilloscope on all three VDDs.
Based on master branch of the l-o git tree, commit
6bd61e8de0511dd9831eb9d89eea0b4603a10e9e.
Tree: git://gitorious.org/~keerthy05/omap-pm/keerthy-sr.git for_smartreflex_ip_driver_move
V3: rework after the comments on MLs
. Retain Efuse offsets check to identify a particular OPP.
. Introduce a common header file accessible both by arch/arm/mach-omap2/
and drivers/.
. Retain the class driver in mach-omap2/ and move IP driver to drivers/power/
avs since class driver needs voltage layer support.
History:
v2: rework after the comments on MLs
. Keep the OMAP Kconfig options in the arch dir (Rafael),
. Move the shared header file from plat-omap to
include/linux/power/ (Tony)
v1: initial revision
J Keerthy (1):
ARM: OMAP2+: Voltage: Move the omap_volt_data structure to plat
Jean Pihet (9):
ARM: OMAP2+: SmartReflex: move the smartreflex header to include/linux/power
ARM: OMAP3+: SmartReflex: class drivers should use struct omap_sr *
ARM: OMAP2+: smartreflex: Use the names from hwmod data instead of
voltage domains.
ARM: OMAP3: hwmod: rename the smartreflex entries
ARM: OMAP2+: SmartReflex: introduce a busy loop condition test macro
ARM: OMAP2+: SmartReflex: Use per-OPP data structure
ARM: OMAP2+: SmartReflex: Create per-opp debugfs node for errminlimit
ARM: OMAP2+: SmartReflex: add POWER_AVS Kconfig options
ARM: OMAP: SmartReflex: Move smartreflex driver to drivers/
arch/arm/mach-omap2/Makefile | 5 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12 +-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 3 +-
arch/arm/mach-omap2/pm.h | 2 +-
arch/arm/mach-omap2/smartreflex-class3.c | 29 ++--
arch/arm/mach-omap2/sr_device.c | 39 ++++-
arch/arm/mach-omap2/voltage.h | 21 +---
arch/arm/plat-omap/Kconfig | 31 ++--
arch/arm/plat-omap/include/plat/voltage.h | 21 +++-
drivers/power/Kconfig | 2 +
drivers/power/Makefile | 1 +
drivers/power/avs/Kconfig | 12 ++
drivers/power/avs/Makefile | 1 +
.../mach-omap2 => drivers/power/avs}/smartreflex.c | 161 ++++++++------------
.../linux/power}/smartreflex.h | 74 ++++++++--
15 files changed, 235 insertions(+), 179 deletions(-)
create mode 100644 drivers/power/avs/Kconfig
create mode 100644 drivers/power/avs/Makefile
rename {arch/arm/mach-omap2 => drivers/power/avs}/smartreflex.c (90%)
rename {arch/arm/mach-omap2 => include/linux/power}/smartreflex.h (79%)
--
1.7.5.4
^ permalink raw reply
* [PATCH V3 01/10] ARM: OMAP2+: SmartReflex: move the smartreflex header to include/linux/power
From: Keerthy @ 2012-04-26 17:40 UTC (permalink / raw)
To: linux-omap, linux-arm-kernel, khilman, rjw, linux-kernel,
linux-pm
Cc: j-keerthy, j-pihet
In-Reply-To: <1335462041-4949-1-git-send-email-j-keerthy@ti.com>
From: Jean Pihet <j-pihet@ti.com>
Move the smartreflex header file
(arch/arm/mach-omap2/smartreflex.h) in a new header file
include/linux/power/smartreflex.h.
This change makes the SmartReflex implementation ready for the move
to drivers/.
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: J Keerthy <j-keerthy@ti.com>
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 4 ++--
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 3 +--
arch/arm/mach-omap2/smartreflex-class3.c | 3 ++-
arch/arm/mach-omap2/smartreflex.c | 3 +--
arch/arm/mach-omap2/sr_device.c | 2 +-
.../linux/power}/smartreflex.h | 7 ++++---
6 files changed, 11 insertions(+), 11 deletions(-)
rename {arch/arm/mach-omap2 => include/linux/power}/smartreflex.h (98%)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 0c65079..144d118 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -14,6 +14,8 @@
*
* XXX these should be marked initdata for multi-OMAP kernels
*/
+#include <linux/power/smartreflex.h>
+
#include <plat/omap_hwmod.h>
#include <mach/irqs.h>
#include <plat/cpu.h>
@@ -29,8 +31,6 @@
#include <plat/dmtimer.h>
#include "omap_hwmod_common_data.h"
-
-#include "smartreflex.h"
#include "prm-regbits-34xx.h"
#include "cm-regbits-34xx.h"
#include "wd_timer.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 4906129..1079c79 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -19,6 +19,7 @@
*/
#include <linux/io.h>
+#include <linux/power/smartreflex.h>
#include <plat/omap_hwmod.h>
#include <plat/cpu.h>
@@ -32,8 +33,6 @@
#include <plat/common.h>
#include "omap_hwmod_common_data.h"
-
-#include "smartreflex.h"
#include "cm1_44xx.h"
#include "cm2_44xx.h"
#include "prm44xx.h"
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c b/arch/arm/mach-omap2/smartreflex-class3.c
index 955566e..ab8cf83 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -11,7 +11,8 @@
* published by the Free Software Foundation.
*/
-#include "smartreflex.h"
+#include <linux/power/smartreflex.h>
+#include "voltage.h"
static int sr_class3_enable(struct voltagedomain *voltdm)
{
diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
index 008fbd7..98309d3 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -25,11 +25,10 @@
#include <linux/delay.h>
#include <linux/slab.h>
#include <linux/pm_runtime.h>
+#include <linux/power/smartreflex.h>
#include "common.h"
-
#include "pm.h"
-#include "smartreflex.h"
#define SMARTREFLEX_NAME_LEN 16
#define NVALUE_NAME_LEN 40
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index a503e1e..86e438e 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -17,6 +17,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#include <linux/power/smartreflex.h>
#include <linux/err.h>
#include <linux/slab.h>
@@ -24,7 +25,6 @@
#include <plat/omap_device.h>
-#include "smartreflex.h"
#include "voltage.h"
#include "control.h"
#include "pm.h"
diff --git a/arch/arm/mach-omap2/smartreflex.h b/include/linux/power/smartreflex.h
similarity index 98%
rename from arch/arm/mach-omap2/smartreflex.h
rename to include/linux/power/smartreflex.h
index 5809141..69eb270 100644
--- a/arch/arm/mach-omap2/smartreflex.h
+++ b/include/linux/power/smartreflex.h
@@ -17,12 +17,13 @@
* published by the Free Software Foundation.
*/
-#ifndef __ASM_ARM_OMAP_SMARTREFLEX_H
-#define __ASM_ARM_OMAP_SMARTREFLEX_H
+#ifndef __POWER_SMARTREFLEX_H
+#define __POWER_SMARTREFLEX_H
+#include <linux/types.h>
#include <linux/platform_device.h>
-#include "voltage.h"
+#include <plat/voltage.h>
/*
* Different Smartreflex IPs version. The v1 is the 65nm version used in
--
1.7.5.4
^ permalink raw reply related
* [PATCH V3 02/10] ARM: OMAP3+: SmartReflex: class drivers should use struct omap_sr *
From: Keerthy @ 2012-04-26 17:40 UTC (permalink / raw)
To: linux-omap, linux-arm-kernel, khilman, rjw, linux-kernel,
linux-pm
Cc: j-pihet, j-keerthy, Paul Walmsley, Thara Gopinath, Nishanth Menon
In-Reply-To: <1335462041-4949-1-git-send-email-j-keerthy@ti.com>
From: Jean Pihet <j-pihet@ti.com>
Convert SmartReflex "class" functions to take a struct omap_sr *, rather than
a struct voltagedomain *. SmartReflex code should be driver code and not
tightly coupled to OMAP subarchitecture-specific structures.
Based on Paul's original code for the SmartReflex driver conversion.
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Thara Gopinath <thara@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/smartreflex-class3.c | 24 +++++++++---------
arch/arm/mach-omap2/smartreflex.c | 37 +++++------------------------
include/linux/power/smartreflex.h | 31 +++++++++++++++++++++---
3 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c b/arch/arm/mach-omap2/smartreflex-class3.c
index ab8cf83..9381654 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -14,34 +14,34 @@
#include <linux/power/smartreflex.h>
#include "voltage.h"
-static int sr_class3_enable(struct voltagedomain *voltdm)
+static int sr_class3_enable(struct omap_sr *sr)
{
- unsigned long volt = voltdm_get_voltage(voltdm);
+ unsigned long volt = voltdm_get_voltage(sr->voltdm);
if (!volt) {
pr_warning("%s: Curr voltage unknown. Cannot enable sr_%s\n",
- __func__, voltdm->name);
+ __func__, sr->voltdm->name);
return -ENODATA;
}
- omap_vp_enable(voltdm);
- return sr_enable(voltdm, volt);
+ omap_vp_enable(sr->voltdm);
+ return sr_enable(sr->voltdm, volt);
}
-static int sr_class3_disable(struct voltagedomain *voltdm, int is_volt_reset)
+static int sr_class3_disable(struct omap_sr *sr, int is_volt_reset)
{
- sr_disable_errgen(voltdm);
- omap_vp_disable(voltdm);
- sr_disable(voltdm);
+ sr_disable_errgen(sr->voltdm);
+ omap_vp_disable(sr->voltdm);
+ sr_disable(sr->voltdm);
if (is_volt_reset)
- voltdm_reset(voltdm);
+ voltdm_reset(sr->voltdm);
return 0;
}
-static int sr_class3_configure(struct voltagedomain *voltdm)
+static int sr_class3_configure(struct omap_sr *sr)
{
- return sr_configure_errgen(voltdm);
+ return sr_configure_errgen(sr->voltdm);
}
/* SR class3 structure */
diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
index 98309d3..82bdd28 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -34,29 +34,6 @@
#define NVALUE_NAME_LEN 40
#define SR_DISABLE_TIMEOUT 200
-struct omap_sr {
- struct list_head node;
- struct platform_device *pdev;
- struct omap_sr_nvalue_table *nvalue_table;
- struct voltagedomain *voltdm;
- struct dentry *dbg_dir;
- unsigned int irq;
- int srid;
- int ip_type;
- int nvalue_count;
- bool autocomp_active;
- u32 clk_length;
- u32 err_weight;
- u32 err_minlimit;
- u32 err_maxlimit;
- u32 accum_data;
- u32 senn_avgweight;
- u32 senp_avgweight;
- u32 senp_mod;
- u32 senn_mod;
- void __iomem *base;
-};
-
/* sr_list contains all the instances of smartreflex module */
static LIST_HEAD(sr_list);
@@ -147,7 +124,7 @@ static irqreturn_t sr_interrupt(int irq, void *data)
}
if (sr_class->notify)
- sr_class->notify(sr_info->voltdm, status);
+ sr_class->notify(sr_info, status);
return IRQ_HANDLED;
}
@@ -225,7 +202,7 @@ static void sr_start_vddautocomp(struct omap_sr *sr)
return;
}
- if (!sr_class->enable(sr->voltdm))
+ if (!sr_class->enable(sr))
sr->autocomp_active = true;
}
@@ -239,7 +216,7 @@ static void sr_stop_vddautocomp(struct omap_sr *sr)
}
if (sr->autocomp_active) {
- sr_class->disable(sr->voltdm, 1);
+ sr_class->disable(sr, 1);
sr->autocomp_active = false;
}
}
@@ -654,7 +631,7 @@ int sr_enable(struct voltagedomain *voltdm, unsigned long volt)
return 0;
/* Configure SR */
- ret = sr_class->configure(voltdm);
+ ret = sr_class->configure(sr);
if (ret)
return ret;
@@ -772,7 +749,7 @@ void omap_sr_enable(struct voltagedomain *voltdm)
return;
}
- sr_class->enable(voltdm);
+ sr_class->enable(sr);
}
/**
@@ -805,7 +782,7 @@ void omap_sr_disable(struct voltagedomain *voltdm)
return;
}
- sr_class->disable(voltdm, 0);
+ sr_class->disable(sr, 0);
}
/**
@@ -838,7 +815,7 @@ void omap_sr_disable_reset_volt(struct voltagedomain *voltdm)
return;
}
- sr_class->disable(voltdm, 1);
+ sr_class->disable(sr, 1);
}
/**
diff --git a/include/linux/power/smartreflex.h b/include/linux/power/smartreflex.h
index 69eb270..4224698 100644
--- a/include/linux/power/smartreflex.h
+++ b/include/linux/power/smartreflex.h
@@ -143,6 +143,29 @@
#define OMAP3430_SR_ERRWEIGHT 0x04
#define OMAP3430_SR_ERRMAXLIMIT 0x02
+struct omap_sr {
+ struct list_head node;
+ struct platform_device *pdev;
+ struct omap_sr_nvalue_table *nvalue_table;
+ struct voltagedomain *voltdm;
+ struct dentry *dbg_dir;
+ unsigned int irq;
+ int srid;
+ int ip_type;
+ int nvalue_count;
+ bool autocomp_active;
+ u32 clk_length;
+ u32 err_weight;
+ u32 err_minlimit;
+ u32 err_maxlimit;
+ u32 accum_data;
+ u32 senn_avgweight;
+ u32 senp_avgweight;
+ u32 senp_mod;
+ u32 senn_mod;
+ void __iomem *base;
+};
+
/**
* struct omap_sr_pmic_data - Strucutre to be populated by pmic code to pass
* pmic specific info to smartreflex driver
@@ -187,10 +210,10 @@ struct omap_smartreflex_dev_attr {
* based decisions.
*/
struct omap_sr_class_data {
- int (*enable)(struct voltagedomain *voltdm);
- int (*disable)(struct voltagedomain *voltdm, int is_volt_reset);
- int (*configure)(struct voltagedomain *voltdm);
- int (*notify)(struct voltagedomain *voltdm, u32 status);
+ int (*enable)(struct omap_sr *sr);
+ int (*disable)(struct omap_sr *sr, int is_volt_reset);
+ int (*configure)(struct omap_sr *sr);
+ int (*notify)(struct omap_sr *sr, u32 status);
u8 notify_flags;
u8 class_type;
};
--
1.7.5.4
^ permalink raw reply related
* [PATCH V3 03/10] ARM: OMAP2+: smartreflex: Use the names from hwmod data instead of voltage domains.
From: Keerthy @ 2012-04-26 17:40 UTC (permalink / raw)
To: linux-omap, linux-arm-kernel, khilman, rjw, linux-kernel,
linux-pm
Cc: j-keerthy, j-pihet
In-Reply-To: <1335462041-4949-1-git-send-email-j-keerthy@ti.com>
From: Jean Pihet <j-pihet@ti.com>
Associate a name with each SmartReflex instance from the hwmod data,
rather than attempting to reuse the name of a voltage domain. The name
from hwmod better reflects the smartreflex integration in the system.
Also have the name passed to the drivers using pdata, which helps to remove
any dependencies on SoC-specific structures.
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: J Keerthy <j-keerthy@ti.com>
---
arch/arm/mach-omap2/smartreflex-class3.c | 4 +-
arch/arm/mach-omap2/smartreflex.c | 65 ++++++++++++------------------
arch/arm/mach-omap2/sr_device.c | 1 +
include/linux/power/smartreflex.h | 3 +
4 files changed, 32 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c b/arch/arm/mach-omap2/smartreflex-class3.c
index 9381654..1da8f03 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -19,8 +19,8 @@ static int sr_class3_enable(struct omap_sr *sr)
unsigned long volt = voltdm_get_voltage(sr->voltdm);
if (!volt) {
- pr_warning("%s: Curr voltage unknown. Cannot enable sr_%s\n",
- __func__, sr->voltdm->name);
+ pr_warning("%s: Curr voltage unknown. Cannot enable %s\n",
+ __func__, sr->name);
return -ENODATA;
}
diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
index 82bdd28..2edd1e2 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -183,7 +183,7 @@ static void sr_set_regfields(struct omap_sr *sr)
sr->err_weight = OMAP3430_SR_ERRWEIGHT;
sr->err_maxlimit = OMAP3430_SR_ERRMAXLIMIT;
sr->accum_data = OMAP3430_SR_ACCUMDATA;
- if (!(strcmp(sr->voltdm->name, "mpu"))) {
+ if (!(strcmp(sr->name, "sr1"))) {
sr->senn_avgweight = OMAP3430_SR1_SENNAVGWEIGHT;
sr->senp_avgweight = OMAP3430_SR1_SENPAVGWEIGHT;
} else {
@@ -234,19 +234,13 @@ static void sr_stop_vddautocomp(struct omap_sr *sr)
*/
static int sr_late_init(struct omap_sr *sr_info)
{
- char *name;
struct omap_sr_data *pdata = sr_info->pdev->dev.platform_data;
struct resource *mem;
int ret = 0;
if (sr_class->notify && sr_class->notify_flags && sr_info->irq) {
- name = kasprintf(GFP_KERNEL, "sr_%s", sr_info->voltdm->name);
- if (name == NULL) {
- ret = -ENOMEM;
- goto error;
- }
ret = request_irq(sr_info->irq, sr_interrupt,
- 0, name, sr_info);
+ 0, sr_info->name, sr_info);
if (ret)
goto error;
disable_irq(sr_info->irq);
@@ -265,7 +259,6 @@ error:
dev_err(&sr_info->pdev->dev, "%s: ERROR in registering"
"interrupt handler. Smartreflex will"
"not function as desired\n", __func__);
- kfree(name);
kfree(sr_info);
return ret;
@@ -395,8 +388,7 @@ int sr_configure_errgen(struct voltagedomain *voltdm)
struct omap_sr *sr = _sr_lookup(voltdm);
if (IS_ERR(sr)) {
- pr_warning("%s: omap_sr struct for sr_%s not found\n",
- __func__, voltdm->name);
+ pr_warning("%s: omap_sr struct for voltdm not found\n", __func__);
return PTR_ERR(sr);
}
@@ -463,8 +455,7 @@ int sr_disable_errgen(struct voltagedomain *voltdm)
struct omap_sr *sr = _sr_lookup(voltdm);
if (IS_ERR(sr)) {
- pr_warning("%s: omap_sr struct for sr_%s not found\n",
- __func__, voltdm->name);
+ pr_warning("%s: omap_sr struct for voltdm not found\n", __func__);
return PTR_ERR(sr);
}
@@ -514,8 +505,7 @@ int sr_configure_minmax(struct voltagedomain *voltdm)
struct omap_sr *sr = _sr_lookup(voltdm);
if (IS_ERR(sr)) {
- pr_warning("%s: omap_sr struct for sr_%s not found\n",
- __func__, voltdm->name);
+ pr_warning("%s: omap_sr struct for voltdm not found\n", __func__);
return PTR_ERR(sr);
}
@@ -600,8 +590,7 @@ int sr_enable(struct voltagedomain *voltdm, unsigned long volt)
int ret;
if (IS_ERR(sr)) {
- pr_warning("%s: omap_sr struct for sr_%s not found\n",
- __func__, voltdm->name);
+ pr_warning("%s: omap_sr struct for voltdm not found\n", __func__);
return PTR_ERR(sr);
}
@@ -654,8 +643,7 @@ void sr_disable(struct voltagedomain *voltdm)
struct omap_sr *sr = _sr_lookup(voltdm);
if (IS_ERR(sr)) {
- pr_warning("%s: omap_sr struct for sr_%s not found\n",
- __func__, voltdm->name);
+ pr_warning("%s: omap_sr struct for voltdm not found\n", __func__);
return;
}
@@ -735,8 +723,7 @@ void omap_sr_enable(struct voltagedomain *voltdm)
struct omap_sr *sr = _sr_lookup(voltdm);
if (IS_ERR(sr)) {
- pr_warning("%s: omap_sr struct for sr_%s not found\n",
- __func__, voltdm->name);
+ pr_warning("%s: omap_sr struct for voltdm not found\n", __func__);
return;
}
@@ -768,8 +755,7 @@ void omap_sr_disable(struct voltagedomain *voltdm)
struct omap_sr *sr = _sr_lookup(voltdm);
if (IS_ERR(sr)) {
- pr_warning("%s: omap_sr struct for sr_%s not found\n",
- __func__, voltdm->name);
+ pr_warning("%s: omap_sr struct for voltdm not found\n", __func__);
return;
}
@@ -801,8 +787,7 @@ void omap_sr_disable_reset_volt(struct voltagedomain *voltdm)
struct omap_sr *sr = _sr_lookup(voltdm);
if (IS_ERR(sr)) {
- pr_warning("%s: omap_sr struct for sr_%s not found\n",
- __func__, voltdm->name);
+ pr_warning("%s: omap_sr struct for voltdm not found\n", __func__);
return;
}
@@ -889,7 +874,6 @@ static int __init omap_sr_probe(struct platform_device *pdev)
struct dentry *nvalue_dir;
struct omap_volt_data *volt_data;
int i, ret = 0;
- char *name;
sr_info = kzalloc(sizeof(struct omap_sr), GFP_KERNEL);
if (!sr_info) {
@@ -926,6 +910,14 @@ static int __init omap_sr_probe(struct platform_device *pdev)
pm_runtime_enable(&pdev->dev);
pm_runtime_irq_safe(&pdev->dev);
+ sr_info->name = kasprintf(GFP_KERNEL, "%s", pdata->name);
+ if (!sr_info->name) {
+ dev_err(&pdev->dev, "%s: Unable to alloc SR instance name\n",
+ __func__);
+ ret = -ENOMEM;
+ goto err_release_region;
+ }
+
sr_info->pdev = pdev;
sr_info->srid = pdev->id;
sr_info->voltdm = pdata->voltdm;
@@ -973,20 +965,12 @@ static int __init omap_sr_probe(struct platform_device *pdev)
}
}
- name = kasprintf(GFP_KERNEL, "sr_%s", sr_info->voltdm->name);
- if (!name) {
- dev_err(&pdev->dev, "%s: Unable to alloc debugfs name\n",
- __func__);
- ret = -ENOMEM;
- goto err_iounmap;
- }
- sr_info->dbg_dir = debugfs_create_dir(name, sr_dbg_dir);
- kfree(name);
+ sr_info->dbg_dir = debugfs_create_dir(sr_info->name, sr_dbg_dir);
if (IS_ERR_OR_NULL(sr_info->dbg_dir)) {
dev_err(&pdev->dev, "%s: Unable to create debugfs directory\n",
__func__);
ret = PTR_ERR(sr_info->dbg_dir);
- goto err_iounmap;
+ goto err_free_name;
}
(void) debugfs_create_file("autocomp", S_IRUGO | S_IWUSR,
@@ -1008,10 +992,10 @@ static int __init omap_sr_probe(struct platform_device *pdev)
omap_voltage_get_volttable(sr_info->voltdm, &volt_data);
if (!volt_data) {
- dev_warn(&pdev->dev, "%s: No Voltage table for the"
- " corresponding vdd vdd_%s. Cannot create debugfs"
+ dev_warn(&pdev->dev, "%s: %s: No Voltage table for the"
+ " corresponding vdd. Cannot create debugfs"
"entries for n-values\n",
- __func__, sr_info->voltdm->name);
+ __func__, sr_info->name);
ret = -ENODATA;
goto err_debugfs;
}
@@ -1029,6 +1013,8 @@ static int __init omap_sr_probe(struct platform_device *pdev)
err_debugfs:
debugfs_remove_recursive(sr_info->dbg_dir);
+err_free_name:
+ kfree(sr_info->name);
err_iounmap:
list_del(&sr_info->node);
iounmap(sr_info->base);
@@ -1065,6 +1051,7 @@ static int __devexit omap_sr_remove(struct platform_device *pdev)
list_del(&sr_info->node);
iounmap(sr_info->base);
+ kfree(sr_info->name);
kfree(sr_info);
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
release_mem_region(mem->start, resource_size(mem));
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index 86e438e..e081174 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -93,6 +93,7 @@ static int __init sr_dev_init(struct omap_hwmod *oh, void *user)
goto exit;
}
+ sr_data->name = oh->name;
sr_data->ip_type = oh->class->rev;
sr_data->senn_mod = 0x1;
sr_data->senp_mod = 0x1;
diff --git a/include/linux/power/smartreflex.h b/include/linux/power/smartreflex.h
index 4224698..884eaee 100644
--- a/include/linux/power/smartreflex.h
+++ b/include/linux/power/smartreflex.h
@@ -144,6 +144,7 @@
#define OMAP3430_SR_ERRMAXLIMIT 0x02
struct omap_sr {
+ char *name;
struct list_head node;
struct platform_device *pdev;
struct omap_sr_nvalue_table *nvalue_table;
@@ -232,6 +233,7 @@ struct omap_sr_nvalue_table {
/**
* struct omap_sr_data - Smartreflex platform data.
*
+ * @name: instance name
* @ip_type: Smartreflex IP type.
* @senp_mod: SENPENABLE value for the sr
* @senn_mod: SENNENABLE value for sr
@@ -243,6 +245,7 @@ struct omap_sr_nvalue_table {
* @voltdm: Pointer to the voltage domain associated with the SR
*/
struct omap_sr_data {
+ const char *name;
int ip_type;
u32 senp_mod;
u32 senn_mod;
--
1.7.5.4
^ permalink raw reply related
* [PATCH V3 04/10] ARM: OMAP3: hwmod: rename the smartreflex entries
From: Keerthy @ 2012-04-26 17:40 UTC (permalink / raw)
To: linux-omap, linux-arm-kernel, khilman, rjw, linux-kernel,
linux-pm
Cc: j-pihet, j-keerthy
In-Reply-To: <1335462041-4949-1-git-send-email-j-keerthy@ti.com>
From: Jean Pihet <j-pihet@ti.com>
Change the name field value to better reflect the smartreflex
integration in the system.
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: J Keerthy <j-keerthy@ti.com>
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 8 ++++----
arch/arm/mach-omap2/smartreflex.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 144d118..15907b0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1324,7 +1324,7 @@ static struct omap_hwmod_irq_info omap3_smartreflex_mpu_irqs[] = {
};
static struct omap_hwmod omap34xx_sr1_hwmod = {
- .name = "sr1",
+ .name = "smartreflex_mpu_iva",
.class = &omap34xx_smartreflex_hwmod_class,
.main_clk = "sr1_fck",
.prcm = {
@@ -1342,7 +1342,7 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
};
static struct omap_hwmod omap36xx_sr1_hwmod = {
- .name = "sr1",
+ .name = "smartreflex_mpu_iva",
.class = &omap36xx_smartreflex_hwmod_class,
.main_clk = "sr1_fck",
.prcm = {
@@ -1369,7 +1369,7 @@ static struct omap_hwmod_irq_info omap3_smartreflex_core_irqs[] = {
};
static struct omap_hwmod omap34xx_sr2_hwmod = {
- .name = "sr2",
+ .name = "smartreflex_core",
.class = &omap34xx_smartreflex_hwmod_class,
.main_clk = "sr2_fck",
.prcm = {
@@ -1387,7 +1387,7 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
};
static struct omap_hwmod omap36xx_sr2_hwmod = {
- .name = "sr2",
+ .name = "smartreflex_core",
.class = &omap36xx_smartreflex_hwmod_class,
.main_clk = "sr2_fck",
.prcm = {
diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
index 2edd1e2..d859277 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -183,7 +183,7 @@ static void sr_set_regfields(struct omap_sr *sr)
sr->err_weight = OMAP3430_SR_ERRWEIGHT;
sr->err_maxlimit = OMAP3430_SR_ERRMAXLIMIT;
sr->accum_data = OMAP3430_SR_ACCUMDATA;
- if (!(strcmp(sr->name, "sr1"))) {
+ if (!(strcmp(sr->name, "smartreflex_mpu_iva"))) {
sr->senn_avgweight = OMAP3430_SR1_SENNAVGWEIGHT;
sr->senp_avgweight = OMAP3430_SR1_SENPAVGWEIGHT;
} else {
--
1.7.5.4
^ permalink raw reply related
* [PATCH V3 05/10] ARM: OMAP2+: SmartReflex: introduce a busy loop condition test macro
From: Keerthy @ 2012-04-26 17:40 UTC (permalink / raw)
To: linux-omap, linux-arm-kernel, khilman, rjw, linux-kernel,
linux-pm
Cc: j-keerthy, j-pihet
In-Reply-To: <1335462041-4949-1-git-send-email-j-keerthy@ti.com>
From: Jean Pihet <j-pihet@ti.com>
Now that omap_test_timeout is only accessible from mach-omap2/,
introduce a similar function for SR.
This change makes the SmartReflex implementation ready for the move
to drivers/.
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: J Keerthy <j-keerthy@ti.com>
---
arch/arm/mach-omap2/smartreflex.c | 12 ++++++------
include/linux/power/smartreflex.h | 23 ++++++++++++++++++++++-
2 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
index d859277..acef08d 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -289,9 +289,9 @@ static void sr_v1_disable(struct omap_sr *sr)
* Wait for SR to be disabled.
* wait until ERRCONFIG.MCUDISACKINTST = 1. Typical latency is 1us.
*/
- omap_test_timeout((sr_read_reg(sr, ERRCONFIG_V1) &
- ERRCONFIG_MCUDISACKINTST), SR_DISABLE_TIMEOUT,
- timeout);
+ sr_test_cond_timeout((sr_read_reg(sr, ERRCONFIG_V1) &
+ ERRCONFIG_MCUDISACKINTST), SR_DISABLE_TIMEOUT,
+ timeout);
if (timeout >= SR_DISABLE_TIMEOUT)
dev_warn(&sr->pdev->dev, "%s: Smartreflex disable timedout\n",
@@ -334,9 +334,9 @@ static void sr_v2_disable(struct omap_sr *sr)
* Wait for SR to be disabled.
* wait until IRQSTATUS.MCUDISACKINTST = 1. Typical latency is 1us.
*/
- omap_test_timeout((sr_read_reg(sr, IRQSTATUS) &
- IRQSTATUS_MCUDISABLEACKINT), SR_DISABLE_TIMEOUT,
- timeout);
+ sr_test_cond_timeout((sr_read_reg(sr, IRQSTATUS) &
+ IRQSTATUS_MCUDISABLEACKINT), SR_DISABLE_TIMEOUT,
+ timeout);
if (timeout >= SR_DISABLE_TIMEOUT)
dev_warn(&sr->pdev->dev, "%s: Smartreflex disable timedout\n",
diff --git a/include/linux/power/smartreflex.h b/include/linux/power/smartreflex.h
index 884eaee..78b795e 100644
--- a/include/linux/power/smartreflex.h
+++ b/include/linux/power/smartreflex.h
@@ -22,7 +22,7 @@
#include <linux/types.h>
#include <linux/platform_device.h>
-
+#include <linux/delay.h>
#include <plat/voltage.h>
/*
@@ -168,6 +168,27 @@ struct omap_sr {
};
/**
+ * test_cond_timeout - busy-loop, testing a condition
+ * @cond: condition to test until it evaluates to true
+ * @timeout: maximum number of microseconds in the timeout
+ * @index: loop index (integer)
+ *
+ * Loop waiting for @cond to become true or until at least @timeout
+ * microseconds have passed. To use, define some integer @index in the
+ * calling code. After running, if @index == @timeout, then the loop has
+ * timed out.
+ *
+ * Copied from omap_test_timeout */
+#define sr_test_cond_timeout(cond, timeout, index) \
+({ \
+ for (index = 0; index < timeout; index++) { \
+ if (cond) \
+ break; \
+ udelay(1); \
+ } \
+})
+
+/**
* struct omap_sr_pmic_data - Strucutre to be populated by pmic code to pass
* pmic specific info to smartreflex driver
*
--
1.7.5.4
^ permalink raw reply related
* [PATCH V3 06/10] ARM: OMAP2+: Voltage: Move the omap_volt_data structure to plat
From: Keerthy @ 2012-04-26 17:40 UTC (permalink / raw)
To: linux-omap, linux-arm-kernel, khilman, rjw, linux-kernel,
linux-pm
Cc: j-pihet, j-keerthy
In-Reply-To: <1335462041-4949-1-git-send-email-j-keerthy@ti.com>
From: J Keerthy <j-keerthy@ti.com>
Move the omap_volt_data structure from mach-omap2/ directory
to arch/arm/plat-omap/include/plat/ so that it is accessible
from both mach-omap2 and drivers directories.
Signed-off-by: J Keerthy <j-keerthy@ti.com>
---
arch/arm/mach-omap2/voltage.h | 21 ++-------------------
arch/arm/plat-omap/include/plat/voltage.h | 21 ++++++++++++++++++++-
2 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 16a1b09..34ef504 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -16,6 +16,8 @@
#include <linux/err.h>
+#include <plat/voltage.h>
+
#include "vc.h"
#include "vp.h"
@@ -91,25 +93,6 @@ struct voltagedomain {
};
/**
- * struct omap_volt_data - Omap voltage specific data.
- * @voltage_nominal: The possible voltage value in uV
- * @sr_efuse_offs: The offset of the efuse register(from system
- * control module base address) from where to read
- * the n-target value for the smartreflex module.
- * @sr_errminlimit: Error min limit value for smartreflex. This value
- * differs at differnet opp and thus is linked
- * with voltage.
- * @vp_errorgain: Error gain value for the voltage processor. This
- * field also differs according to the voltage/opp.
- */
-struct omap_volt_data {
- u32 volt_nominal;
- u32 sr_efuse_offs;
- u8 sr_errminlimit;
- u8 vp_errgain;
-};
-
-/**
* struct omap_voltdm_pmic - PMIC specific data required by voltage driver.
* @slew_rate: PMIC slew rate (in uv/us)
* @step_size: PMIC voltage step size (in uv)
diff --git a/arch/arm/plat-omap/include/plat/voltage.h b/arch/arm/plat-omap/include/plat/voltage.h
index 0a6a482..5be4d5d 100644
--- a/arch/arm/plat-omap/include/plat/voltage.h
+++ b/arch/arm/plat-omap/include/plat/voltage.h
@@ -11,10 +11,29 @@
#ifndef __ARCH_ARM_OMAP_VOLTAGE_H
#define __ARCH_ARM_OMAP_VOLTAGE_H
+/**
+ * struct omap_volt_data - Omap voltage specific data.
+ * @voltage_nominal: The possible voltage value in uV
+ * @sr_efuse_offs: The offset of the efuse register(from system
+ * control module base address) from where to read
+ * the n-target value for the smartreflex module.
+ * @sr_errminlimit: Error min limit value for smartreflex. This value
+ * differs at differnet opp and thus is linked
+ * with voltage.
+ * @vp_errorgain: Error gain value for the voltage processor. This
+ * field also differs according to the voltage/opp.
+ */
+struct omap_volt_data {
+ u32 volt_nominal;
+ u32 sr_efuse_offs;
+ u8 sr_errminlimit;
+ u8 vp_errgain;
+};
struct voltagedomain;
struct voltagedomain *voltdm_lookup(const char *name);
int voltdm_scale(struct voltagedomain *voltdm, unsigned long target_volt);
unsigned long voltdm_get_voltage(struct voltagedomain *voltdm);
-
+struct omap_volt_data *omap_voltage_get_voltdata(struct voltagedomain *voltdm,
+ unsigned long volt);
#endif
--
1.7.5.4
^ permalink raw reply related
* [PATCH V3 07/10] ARM: OMAP2+: SmartReflex: Use per-OPP data structure
From: Keerthy @ 2012-04-26 17:40 UTC (permalink / raw)
To: linux-omap, linux-arm-kernel, khilman, rjw, linux-kernel,
linux-pm
Cc: j-pihet, j-keerthy, Paul Walmsley, Thara Gopinath, Nishanth Menon
In-Reply-To: <1335462041-4949-1-git-send-email-j-keerthy@ti.com>
From: Jean Pihet <j-pihet@ti.com>
The SmartReflex driver incorrectly treats some per-OPP data as data
common to all OPPs (e.g., ERRMINLIMIT). Move this data into a per-OPP
data structure.
Furthermore, in order to make the SmartReflex implementation ready for
the move to drivers/, remove the dependency from the SR driver code
to the voltage layer by querying the data tables only from the SR device
init code.
Based on Paul's original code for the SmartReflex driver conversion.
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: J Keerthy <j-keerthy@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Thara Gopinath <thara@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/smartreflex.c | 38 +++++++++++++++++-------------------
arch/arm/mach-omap2/sr_device.c | 36 +++++++++++++++++++++++++++++-----
include/linux/power/smartreflex.h | 8 +++++-
3 files changed, 54 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
index acef08d..20075de 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -347,22 +347,23 @@ static void sr_v2_disable(struct omap_sr *sr)
sr_write_reg(sr, IRQSTATUS, IRQSTATUS_MCUDISABLEACKINT);
}
-static u32 sr_retrieve_nvalue(struct omap_sr *sr, u32 efuse_offs)
+static struct omap_sr_nvalue_table *sr_retrieve_nvalue_row(
+ struct omap_sr *sr, u32 efuse_offs)
{
int i;
if (!sr->nvalue_table) {
dev_warn(&sr->pdev->dev, "%s: Missing ntarget value table\n",
__func__);
- return 0;
+ return NULL;
}
for (i = 0; i < sr->nvalue_count; i++) {
if (sr->nvalue_table[i].efuse_offs == efuse_offs)
- return sr->nvalue_table[i].nvalue;
+ return &sr->nvalue_table[i];
}
- return 0;
+ return NULL;
}
/* Public Functions */
@@ -586,7 +587,7 @@ int sr_enable(struct voltagedomain *voltdm, unsigned long volt)
{
struct omap_volt_data *volt_data;
struct omap_sr *sr = _sr_lookup(voltdm);
- u32 nvalue_reciprocal;
+ struct omap_sr_nvalue_table *nvalue_row;
int ret;
if (IS_ERR(sr)) {
@@ -602,16 +603,16 @@ int sr_enable(struct voltagedomain *voltdm, unsigned long volt)
return PTR_ERR(volt_data);
}
- nvalue_reciprocal = sr_retrieve_nvalue(sr, volt_data->sr_efuse_offs);
+ nvalue_row = sr_retrieve_nvalue_row(sr, volt_data->sr_efuse_offs);
- if (!nvalue_reciprocal) {
- dev_warn(&sr->pdev->dev, "%s: NVALUE = 0 at voltage %ld\n",
- __func__, volt);
+ if (!nvalue_row) {
+ dev_warn(&sr->pdev->dev, "%s: failure getting SR data for this voltage %ld\n",
+ __func__, volt);
return -ENODATA;
}
/* errminlimit is opp dependent and hence linked to voltage */
- sr->err_minlimit = volt_data->sr_errminlimit;
+ sr->err_minlimit = nvalue_row->errminlimit;
pm_runtime_get_sync(&sr->pdev->dev);
@@ -624,7 +625,7 @@ int sr_enable(struct voltagedomain *voltdm, unsigned long volt)
if (ret)
return ret;
- sr_write_reg(sr, NVALUERECIPROCAL, nvalue_reciprocal);
+ sr_write_reg(sr, NVALUERECIPROCAL, nvalue_row->nvalue);
/* SRCONFIG - enable SR */
sr_modify_reg(sr, SRCONFIG, SRCONFIG_SRENABLE, SRCONFIG_SRENABLE);
@@ -872,7 +873,6 @@ static int __init omap_sr_probe(struct platform_device *pdev)
struct omap_sr_data *pdata = pdev->dev.platform_data;
struct resource *mem, *irq;
struct dentry *nvalue_dir;
- struct omap_volt_data *volt_data;
int i, ret = 0;
sr_info = kzalloc(sizeof(struct omap_sr), GFP_KERNEL);
@@ -990,12 +990,10 @@ static int __init omap_sr_probe(struct platform_device *pdev)
goto err_debugfs;
}
- omap_voltage_get_volttable(sr_info->voltdm, &volt_data);
- if (!volt_data) {
- dev_warn(&pdev->dev, "%s: %s: No Voltage table for the"
- " corresponding vdd. Cannot create debugfs"
- "entries for n-values\n",
- __func__, sr_info->name);
+ if (sr_info->nvalue_count == 0 || !sr_info->nvalue_table) {
+ dev_warn(&pdev->dev, "%s: %s: No Voltage table for the corresponding vdd. Cannot create debugfs entries for n-values\n",
+ __func__, sr_info->name);
+
ret = -ENODATA;
goto err_debugfs;
}
@@ -1003,8 +1001,8 @@ static int __init omap_sr_probe(struct platform_device *pdev)
for (i = 0; i < sr_info->nvalue_count; i++) {
char name[NVALUE_NAME_LEN + 1];
- snprintf(name, sizeof(name), "volt_%d",
- volt_data[i].volt_nominal);
+ snprintf(name, sizeof(name), "volt_%lu",
+ sr_info->nvalue_table[i].volt_nominal);
(void) debugfs_create_x32(name, S_IRUGO | S_IWUSR, nvalue_dir,
&(sr_info->nvalue_table[i].nvalue));
}
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index e081174..e107e39 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -36,7 +36,10 @@ static void __init sr_set_nvalues(struct omap_volt_data *volt_data,
struct omap_sr_data *sr_data)
{
struct omap_sr_nvalue_table *nvalue_table;
- int i, count = 0;
+ int i, j, count = 0;
+
+ sr_data->nvalue_count = 0;
+ sr_data->nvalue_table = NULL;
while (volt_data[count].volt_nominal)
count++;
@@ -44,8 +47,14 @@ static void __init sr_set_nvalues(struct omap_volt_data *volt_data,
nvalue_table = kzalloc(sizeof(struct omap_sr_nvalue_table)*count,
GFP_KERNEL);
- for (i = 0; i < count; i++) {
+ if (!nvalue_table) {
+ pr_err("OMAP: SmartReflex: cannot allocate memory for n-value table\n");
+ return;
+ }
+
+ for (i = 0, j = 0; i < count; i++) {
u32 v;
+
/*
* In OMAP4 the efuse registers are 24 bit aligned.
* A __raw_readl will fail for non-32 bit aligned address
@@ -58,15 +67,30 @@ static void __init sr_set_nvalues(struct omap_volt_data *volt_data,
omap_ctrl_readb(offset + 1) << 8 |
omap_ctrl_readb(offset + 2) << 16;
} else {
- v = omap_ctrl_readl(volt_data[i].sr_efuse_offs);
+ v = omap_ctrl_readl(volt_data[i].sr_efuse_offs);
}
- nvalue_table[i].efuse_offs = volt_data[i].sr_efuse_offs;
- nvalue_table[i].nvalue = v;
+ /*
+ * Many OMAP SoCs don't have the eFuse values set.
+ * For example, pretty much all OMAP3xxx before
+ * ES3.something.
+ *
+ * XXX There needs to be some way for board files or
+ * userspace to add these in.
+ */
+ if (v == 0)
+ continue;
+
+ nvalue_table[j].nvalue = v;
+ nvalue_table[j].efuse_offs = volt_data[i].sr_efuse_offs;
+ nvalue_table[j].errminlimit = volt_data[i].sr_errminlimit;
+ nvalue_table[j].volt_nominal = volt_data[i].volt_nominal;
+
+ j++;
}
sr_data->nvalue_table = nvalue_table;
- sr_data->nvalue_count = count;
+ sr_data->nvalue_count = j;
}
static int __init sr_dev_init(struct omap_hwmod *oh, void *user)
diff --git a/include/linux/power/smartreflex.h b/include/linux/power/smartreflex.h
index 78b795e..222f901 100644
--- a/include/linux/power/smartreflex.h
+++ b/include/linux/power/smartreflex.h
@@ -243,12 +243,16 @@ struct omap_sr_class_data {
/**
* struct omap_sr_nvalue_table - Smartreflex n-target value info
*
- * @efuse_offs: The offset of the efuse where n-target values are stored.
- * @nvalue: The n-target value.
+ * @efuse_offs: The offset of the efuse where n-target values are stored.
+ * @nvalue: The n-target value.
+ * @errminlimit: The value of the ERRMINLIMIT bitfield for this n-target
+ * @volt_nominal: microvolts DC that the VDD is initially programmed to
*/
struct omap_sr_nvalue_table {
u32 efuse_offs;
u32 nvalue;
+ u32 errminlimit;
+ unsigned long volt_nominal;
};
/**
--
1.7.5.4
^ permalink raw reply related
* [PATCH V3 08/10] ARM: OMAP2+: SmartReflex: Create per-opp debugfs node for errminlimit
From: Keerthy @ 2012-04-26 17:40 UTC (permalink / raw)
To: linux-omap, linux-arm-kernel, khilman, rjw, linux-kernel,
linux-pm
Cc: j-pihet, j-keerthy
In-Reply-To: <1335462041-4949-1-git-send-email-j-keerthy@ti.com>
From: Jean Pihet <j-pihet@ti.com>
Remove the global errminlimit debugfs entry and create per-voltage
entries from the data tables.
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: J Keerthy <j-keerthy@ti.com>
---
arch/arm/mach-omap2/smartreflex.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
index 20075de..515041c 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -979,8 +979,6 @@ static int __init omap_sr_probe(struct platform_device *pdev)
&sr_info->err_weight);
(void) debugfs_create_x32("errmaxlimit", S_IRUGO, sr_info->dbg_dir,
&sr_info->err_maxlimit);
- (void) debugfs_create_x32("errminlimit", S_IRUGO, sr_info->dbg_dir,
- &sr_info->err_minlimit);
nvalue_dir = debugfs_create_dir("nvalue", sr_info->dbg_dir);
if (IS_ERR_OR_NULL(nvalue_dir)) {
@@ -1005,6 +1003,11 @@ static int __init omap_sr_probe(struct platform_device *pdev)
sr_info->nvalue_table[i].volt_nominal);
(void) debugfs_create_x32(name, S_IRUGO | S_IWUSR, nvalue_dir,
&(sr_info->nvalue_table[i].nvalue));
+ snprintf(name, sizeof(name), "errminlimit_%lu",
+ sr_info->nvalue_table[i].volt_nominal);
+ (void) debugfs_create_x32(name, S_IRUGO | S_IWUSR, nvalue_dir,
+ &(sr_info->nvalue_table[i].errminlimit));
+
}
return ret;
--
1.7.5.4
^ permalink raw reply related
* [PATCH V3 09/10] ARM: OMAP2+: SmartReflex: add POWER_AVS Kconfig options
From: Keerthy @ 2012-04-26 17:40 UTC (permalink / raw)
To: linux-omap, linux-arm-kernel, khilman, rjw, linux-kernel,
linux-pm
Cc: j-pihet, j-keerthy
In-Reply-To: <1335462041-4949-1-git-send-email-j-keerthy@ti.com>
From: Jean Pihet <j-pihet@ti.com>
Add a Kconfig menu (POWER_AVS) and rename the Kconfig options
for the OMAP SmartReflex implementation:
CONFIG_OMAP_SMARTREFLEX renames to CONFIG_POWER_AVS_OMAP
CONFIG_OMAP_SMARTREFLEX_CLASS3 renames to CONFIG_POWER_AVS_OMAP_CLASS3
This change makes the SmartReflex implementation ready for the move
to drivers/.
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: J Keerthy <j-keerthy@ti.com>
---
arch/arm/mach-omap2/Makefile | 5 ++-
arch/arm/mach-omap2/pm.h | 2 +-
arch/arm/plat-omap/Kconfig | 45 ++++++++++++++++++++++++------------
include/linux/power/smartreflex.h | 2 +-
4 files changed, 35 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d8604a3..85ca797 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -69,8 +69,9 @@ obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o \
obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o \
cpuidle44xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
-obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o
-obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o
+
+obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o smartreflex.o
+obj-$(CONFIG_POWER_AVS_OMAP_CLASS3) += smartreflex-class3.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 36fa90b..77c8c85 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -109,7 +109,7 @@ extern void enable_omap3630_toggle_l2_on_restore(void);
static inline void enable_omap3630_toggle_l2_on_restore(void) { }
#endif /* defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP3) */
-#ifdef CONFIG_OMAP_SMARTREFLEX
+#ifdef CONFIG_POWER_AVS_OMAP
extern int omap_devinit_smartreflex(void);
extern void omap_enable_smartreflex_on_init(void);
#else
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index ad95c7a..bba384d 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -45,37 +45,52 @@ config OMAP_DEBUG_LEDS
depends on OMAP_DEBUG_DEVICES
default y if LEDS_CLASS
-config OMAP_SMARTREFLEX
- bool "SmartReflex support"
- depends on (ARCH_OMAP3 || ARCH_OMAP4) && PM
+menuconfig POWER_AVS
+ tristate "Adaptive Voltage Scaling class support"
help
- Say Y if you want to enable SmartReflex.
+ AVS(Adaptive Voltage Scaling) is a power management technique which
+ finely controls the operating voltage of a device in order to optimize
+ (i.e. reduce) its power consumption.
+ At a given operating point the voltage is adapted depending on
+ static factors (chip manufacturing process) and dynamic factors
+ (temperature depending performance).
+ AVS is also called SmartReflex on OMAP devices.
+
+ Say Y here to enable Adaptive Voltage Scaling class support.
+
+if POWER_AVS
- SmartReflex can perform continuous dynamic voltage
- scaling around the nominal operating point voltage
- according to silicon characteristics and operating
- conditions. Enabling SmartReflex reduces power
- consumption.
+config POWER_AVS_OMAP
+ bool "AVS(Adaptive Voltage Scaling) support for OMAP IP versions 1&2"
+ depends on (ARCH_OMAP3 || ARCH_OMAP4) && PM
+ help
+ Say Y to enable AVS support on OMAP containing the version 1 or
+ version 2 of the SmartReflex IP.
+ V1 is the 65nm version used in OMAP3430.
+ V2 is the update for the 45nm version of the IP used in OMAP3630
+ and OMAP4430
Please note, that by default SmartReflex is only
- initialized. To enable the automatic voltage
- compensation for vdd mpu and vdd core from user space,
+ initialized and not enabled. To enable the automatic voltage
+ compensation for vdd mpu and vdd core from user space,
user must write 1 to
- /debug/voltage/vdd_<X>/smartreflex/autocomp,
- where X is mpu or core for OMAP3.
+ /debug/smartreflex/sr_<X>/autocomp,
+ where X is mpu_iva or core for OMAP3.
Optionally autocompensation can be enabled in the kernel
by default during system init via the enable_on_init flag
which an be passed as platform data to the smartreflex driver.
-config OMAP_SMARTREFLEX_CLASS3
+config POWER_AVS_OMAP_CLASS3
bool "Class 3 mode of Smartreflex Implementation"
- depends on OMAP_SMARTREFLEX && TWL4030_CORE
+ depends on POWER_AVS_OMAP && TWL4030_CORE
help
Say Y to enable Class 3 implementation of Smartreflex
Class 3 implementation of Smartreflex employs continuous hardware
voltage calibration.
+endif # POWER_AVS
+
config OMAP_RESET_CLOCKS
bool "Reset unused clocks during boot"
depends on ARCH_OMAP
diff --git a/include/linux/power/smartreflex.h b/include/linux/power/smartreflex.h
index 222f901..3101e62 100644
--- a/include/linux/power/smartreflex.h
+++ b/include/linux/power/smartreflex.h
@@ -207,7 +207,7 @@ struct omap_smartreflex_dev_attr {
const char *sensor_voltdm_name;
};
-#ifdef CONFIG_OMAP_SMARTREFLEX
+#ifdef CONFIG_POWER_AVS_OMAP
/*
* The smart reflex driver supports CLASS1 CLASS2 and CLASS3 SR.
* The smartreflex class driver should pass the class type.
--
1.7.5.4
^ permalink raw reply related
* [PATCH V3 10/10] ARM: OMAP: SmartReflex: Move smartreflex driver to drivers/
From: Keerthy @ 2012-04-26 17:40 UTC (permalink / raw)
To: linux-omap, linux-arm-kernel, khilman, rjw, linux-kernel,
linux-pm
Cc: j-pihet, j-keerthy
In-Reply-To: <1335462041-4949-1-git-send-email-j-keerthy@ti.com>
From: Jean Pihet <j-pihet@ti.com>
After a clean-up of the interfaces the OMAP Smartreflex IP driver is now a
generic driver. Move it to drivers/power/avs/.
The build is controlled by the following Kconfig options:
. CONFIG_POWER_AVS: general knob for Adaptive Voltage Scaling support,
. CONFIG_POWER_AVS_OMAP: AVS(Adaptive Voltage Scaling)
support on OMAP containing the version 1 or version 2 of the SmartReflex IP,
. CONFIG_POWER_AVS_OMAP_CLASS3: Class 3 implementation of Smartreflex.
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: J Keerthy <j-keerthy@ti.com>
---
arch/arm/mach-omap2/Makefile | 4 +-
arch/arm/plat-omap/Kconfig | 22 ++-----------------
drivers/power/Kconfig | 2 +
drivers/power/Makefile | 1 +
drivers/power/avs/Kconfig | 12 ++++++++++
drivers/power/avs/Makefile | 1 +
.../mach-omap2 => drivers/power/avs}/smartreflex.c | 5 +---
7 files changed, 22 insertions(+), 25 deletions(-)
create mode 100644 drivers/power/avs/Kconfig
create mode 100644 drivers/power/avs/Makefile
rename {arch/arm/mach-omap2 => drivers/power/avs}/smartreflex.c (99%)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 85ca797..43ffde4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -70,8 +70,8 @@ obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o \
cpuidle44xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
-obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o smartreflex.o
-obj-$(CONFIG_POWER_AVS_OMAP_CLASS3) += smartreflex-class3.o
+obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o
+obj-$(CONFIG_POWER_AVS_OMAP_CLASS3) += smartreflex-class3.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec)
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index bba384d..816dec0 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -45,26 +45,12 @@ config OMAP_DEBUG_LEDS
depends on OMAP_DEBUG_DEVICES
default y if LEDS_CLASS
-menuconfig POWER_AVS
- tristate "Adaptive Voltage Scaling class support"
- help
- AVS(Adaptive Voltage Scaling) is a power management technique which
- finely controls the operating voltage of a device in order to optimize
- (i.e. reduce) its power consumption.
- At a given operating point the voltage is adapted depending on
- static factors (chip manufacturing process) and dynamic factors
- (temperature depending performance).
- AVS is also called SmartReflex on OMAP devices.
-
- Say Y here to enable Adaptive Voltage Scaling class support.
-
-if POWER_AVS
-
config POWER_AVS_OMAP
bool "AVS(Adaptive Voltage Scaling) support for OMAP IP versions 1&2"
- depends on (ARCH_OMAP3 || ARCH_OMAP4) && PM
+ depends on POWER_AVS && (ARCH_OMAP3 || ARCH_OMAP4) && PM
help
- Say Y to enable AVS support on OMAP containing the version 1 or
+ Say Y to enable AVS(Adaptive Voltage Scaling)
+ support on OMAP containing the version 1 or
version 2 of the SmartReflex IP.
V1 is the 65nm version used in OMAP3430.
V2 is the update for the 45nm version of the IP used in OMAP3630
@@ -89,8 +75,6 @@ config POWER_AVS_OMAP_CLASS3
Class 3 implementation of Smartreflex employs continuous hardware
voltage calibration.
-endif # POWER_AVS
-
config OMAP_RESET_CLOCKS
bool "Reset unused clocks during boot"
depends on ARCH_OMAP
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 99dc29f..d416773 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -308,3 +308,5 @@ config AB8500_BATTERY_THERM_ON_BATCTRL
Say Y to enable battery temperature measurements using
thermistor connected on BATCTRL ADC.
endif # POWER_SUPPLY
+
+source "drivers/power/avs/Kconfig"
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index b6b2434..ee58afb 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -43,4 +43,5 @@ obj-$(CONFIG_CHARGER_GPIO) += gpio-charger.o
obj-$(CONFIG_CHARGER_MANAGER) += charger-manager.o
obj-$(CONFIG_CHARGER_MAX8997) += max8997_charger.o
obj-$(CONFIG_CHARGER_MAX8998) += max8998_charger.o
+obj-$(CONFIG_POWER_AVS) += avs/
obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o
diff --git a/drivers/power/avs/Kconfig b/drivers/power/avs/Kconfig
new file mode 100644
index 0000000..18493f7
--- /dev/null
+++ b/drivers/power/avs/Kconfig
@@ -0,0 +1,12 @@
+menuconfig POWER_AVS
+ tristate "Adaptive Voltage Scaling class support"
+ help
+ AVS is a power management technique which finely controls the
+ operating voltage of a device in order to optimize (i.e. reduce)
+ its power consumption.
+ At a given operating point the voltage is adapted depending on
+ static factors (chip manufacturing process) and dynamic factors
+ (temperature depending performance).
+ AVS is also called SmartReflex on OMAP devices.
+
+ Say Y here to enable Adaptive Voltage Scaling class support.
diff --git a/drivers/power/avs/Makefile b/drivers/power/avs/Makefile
new file mode 100644
index 0000000..0843386
--- /dev/null
+++ b/drivers/power/avs/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_POWER_AVS_OMAP) += smartreflex.o
diff --git a/arch/arm/mach-omap2/smartreflex.c b/drivers/power/avs/smartreflex.c
similarity index 99%
rename from arch/arm/mach-omap2/smartreflex.c
rename to drivers/power/avs/smartreflex.c
index 515041c..44efc6e 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/drivers/power/avs/smartreflex.c
@@ -3,7 +3,7 @@
*
* Author: Thara Gopinath <thara@ti.com>
*
- * Copyright (C) 2010 Texas Instruments, Inc.
+ * Copyright (C) 2012 Texas Instruments, Inc.
* Thara Gopinath <thara@ti.com>
*
* Copyright (C) 2008 Nokia Corporation
@@ -27,9 +27,6 @@
#include <linux/pm_runtime.h>
#include <linux/power/smartreflex.h>
-#include "common.h"
-#include "pm.h"
-
#define SMARTREFLEX_NAME_LEN 16
#define NVALUE_NAME_LEN 40
#define SR_DISABLE_TIMEOUT 200
--
1.7.5.4
^ permalink raw reply related
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
From: Keerthy @ 2012-04-26 18:05 UTC (permalink / raw)
To: linux-omap, linux-arm-kernel, khilman, rjw, linux-kernel,
linux-pm
Cc: j-pihet, j-keerthy
From: J Keerthy <j-keerthy@ti.com>
AVS(Adaptive Voltage Scaling) is a power management technique which
controls the operating voltage of a device in order to optimize (i.e. reduce)
its power consumption. The voltage is adapted depending on static factors
(chip manufacturing process) and dynamic factors (temperature
depending performance).
The TI AVS solution is named Smartreflex.
To that end, create the AVS driver in drivers/power/avs and
move the OMAP SmartReflex code to the new directory. The
class driver is still retained in the mach-omap2 directory.
In preparation to the move of the OMAP code the following changes have been
made:
- fill in platform data from the device initialization code and pass
it to the driver,
- create CONFIG_AVS* config options accordingly.
The platform integration data for SmartReflex is passed from hwmod
and the voltage layer to the driver using pdata.
Tested on OMAP4430 SDP using omap2plus_defconfig with the
CONFIG_POWER_AVS* options set. Voltage correction seen
on oscilloscope on all three VDDs.
Based on master branch of the l-o git tree, commit
6bd61e8de0511dd9831eb9d89eea0b4603a10e9e.
Tree: git://gitorious.org/~keerthy05/omap-pm/keerthy-sr.git for_smartreflex_ip_driver_move
V3: rework after the comments on MLs
. Retain Efuse offsets check to identify a particular OPP.
. Introduce a common header file accessible both by arch/arm/mach-omap2/
and drivers/.
. Retain the class driver in mach-omap2/ and move IP driver to drivers/power/
avs since class driver needs voltage layer support.
History:
v2: rework after the comments on MLs
. Keep the OMAP Kconfig options in the arch dir (Rafael),
. Move the shared header file from plat-omap to
include/linux/power/ (Tony)
v1: initial revision
J Keerthy (1):
ARM: OMAP2+: Voltage: Move the omap_volt_data structure to plat
Jean Pihet (9):
ARM: OMAP2+: SmartReflex: move the smartreflex header to include/linux/power
ARM: OMAP3+: SmartReflex: class drivers should use struct omap_sr *
ARM: OMAP2+: smartreflex: Use the names from hwmod data instead of
voltage domains.
ARM: OMAP3: hwmod: rename the smartreflex entries
ARM: OMAP2+: SmartReflex: introduce a busy loop condition test macro
ARM: OMAP2+: SmartReflex: Use per-OPP data structure
ARM: OMAP2+: SmartReflex: Create per-opp debugfs node for errminlimit
ARM: OMAP2+: SmartReflex: add POWER_AVS Kconfig options
ARM: OMAP: SmartReflex: Move smartreflex driver to drivers/
arch/arm/mach-omap2/Makefile | 5 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12 +-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 3 +-
arch/arm/mach-omap2/pm.h | 2 +-
arch/arm/mach-omap2/smartreflex-class3.c | 29 ++--
arch/arm/mach-omap2/sr_device.c | 39 ++++-
arch/arm/mach-omap2/voltage.h | 21 +---
arch/arm/plat-omap/Kconfig | 31 ++--
arch/arm/plat-omap/include/plat/voltage.h | 21 +++-
drivers/power/Kconfig | 2 +
drivers/power/Makefile | 1 +
drivers/power/avs/Kconfig | 12 ++
drivers/power/avs/Makefile | 1 +
.../mach-omap2 => drivers/power/avs}/smartreflex.c | 161 ++++++++------------
.../linux/power}/smartreflex.h | 74 ++++++++--
15 files changed, 235 insertions(+), 179 deletions(-)
create mode 100644 drivers/power/avs/Kconfig
create mode 100644 drivers/power/avs/Makefile
rename {arch/arm/mach-omap2 => drivers/power/avs}/smartreflex.c (90%)
rename {arch/arm/mach-omap2 => include/linux/power}/smartreflex.h (79%)
--
1.7.5.4
^ permalink raw reply
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
From: Mark Brown @ 2012-04-26 19:11 UTC (permalink / raw)
To: Keerthy
Cc: khilman, linux-kernel, linux-pm, linux-omap, j-pihet,
linux-arm-kernel
In-Reply-To: <1335462041-4949-1-git-send-email-j-keerthy@ti.com>
On Thu, Apr 26, 2012 at 11:10:31PM +0530, Keerthy wrote:
> From: J Keerthy <j-keerthy@ti.com>
>
> AVS(Adaptive Voltage Scaling) is a power management technique which
> controls the operating voltage of a device in order to optimize (i.e. reduce)
> its power consumption. The voltage is adapted depending on static factors
> (chip manufacturing process) and dynamic factors (temperature
> depending performance).
> The TI AVS solution is named Smartreflex.
What's the relationship between this and existing things like devfreq
and cpufreq? It'd be better if the changelogs made this clear and
provided an overview of how all these different subsystems are intended
to fit together.
^ permalink raw reply
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
From: J, KEERTHY @ 2012-04-27 5:39 UTC (permalink / raw)
To: Mark Brown
Cc: linux-omap, linux-arm-kernel, khilman, rjw, linux-kernel,
linux-pm, j-pihet
In-Reply-To: <20120426191159.GA9415@sirena.org.uk>
Hello Mark,
On Fri, Apr 27, 2012 at 12:41 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Thu, Apr 26, 2012 at 11:10:31PM +0530, Keerthy wrote:
>> From: J Keerthy <j-keerthy@ti.com>
>>
>> AVS(Adaptive Voltage Scaling) is a power management technique which
>> controls the operating voltage of a device in order to optimize (i.e. reduce)
>> its power consumption. The voltage is adapted depending on static factors
>> (chip manufacturing process) and dynamic factors (temperature
>> depending performance).
>> The TI AVS solution is named Smartreflex.
>
> What's the relationship between this and existing things like devfreq
> and cpufreq? It'd be better if the changelogs made this clear and
> provided an overview of how all these different subsystems are intended
> to fit together.
Devfreq and cpufreq are related to dynamic frequency/voltage switching between
pre defined Operating Performance Points or the OPPs. Every OPP being
a voltage/frequency pair. Smartreflex is a different
power management technique.
SmartReflex is a technology that uses adaptive
power supply to achieve the goal of reducing active power consumption.
With SmartReflex, the power supply voltage can be adapted to the silicon
performance either statically (for example, adapted to the manufacturing process
of a given device), or dynamically (for example, adapted to the temperature
induced current performance of the device).
So for every OPP(voltage/frequency pair) depending on the silicon process and
temperature the Smartreflex tries to get the voltage to an optimal
value at which
the corresponding frequency can be sustained.
--
Regards and Thanks,
Keerthy
^ permalink raw reply
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
From: Mark Brown @ 2012-04-27 17:56 UTC (permalink / raw)
To: J, KEERTHY
Cc: khilman, linux-kernel, linux-pm, linux-omap, j-pihet,
linux-arm-kernel
In-Reply-To: <CAJ6a13a6WN9h1QZynpEOf-R6RXwWBZ2eOPkTeNc15JX_YfAz_w@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 454 bytes --]
On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote:
> Devfreq and cpufreq are related to dynamic frequency/voltage switching between
> pre defined Operating Performance Points or the OPPs. Every OPP being
> a voltage/frequency pair. Smartreflex is a different
> power management technique.
But presumably these things should integrate somehow - for example,
should devfreq and cpufreq be providing inputs into what AVS is doing,
and if so how?
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ 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