This patch series is untested from the mmc point of view.
While testing some other modules on OMAP4 random behavior
crash/hang was observed.
The patch 3 [remove pm_runtime_get_sync/put sync from
suspend/resume ]
Fixed the echo mem /sys/power/state
This patchset does the following
- remove
Currently the suspend/resume functions depend on CONFIG_PM however
the callers have no such dependency.
This patch tries to fix the same by using SET_SYSTEM_SLEEP_PM_OPS
and making the functions depend on CONFIG_PM_SLEEP.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
currently omap_hsmmc_context_restore depends on CONFIG_PM.
However the caller runtime resume has no such dependency.
This patch intends to fix the same.
omap_hsmmc_context_save is called from probe
unconditionally. However the defined under CONFIG_PM flag.
Signed-off-by: Shubhrajyoti D
The pm_runtime_get_sync/put_sync may not be needed in the latest
code as it is taken care in the framework.
Cc: Govindraj.R govindraj.r...@ti.com
Cc: Keshava Munegowda keshava_mgo...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |5 -
1 files
EMU domain is part of MPU subsystem, save and restore CM_CLKSTCTRL of
EMU domain across MPU OFF instead of CORE OFF. Though CM belongs to CORE
power domain, this register is of cold reset type and gets reset upon
MPU domain wakeup from OFF.
Embedded trace debug tools like Serial Trace
cc Tero, Govindraj
On Thu, 12 Jan 2012, NeilBrown wrote:
On Wed, 11 Jan 2012 06:43:04 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
I spent some time exploring why cpuidle never drops below state 0 and found
out that the code explicitly disables other states when uart is active - for
a
On Thu, Jan 12, 2012 at 10:00 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, Jan 12, 2012 at 09:32:40PM +0100, Shilimkar, Santosh wrote:
OK. Point taken.
Can you also explain this in the code:
size = ALIGN(PAGE_SIZE, SZ_1M);
Isn't that just SZ_1M written in a
Hi Vaibhav,
On 1/13/2012 7:14 AM, Hiremath, Vaibhav wrote:
On Tue, Dec 20, 2011 at 19:09:57, Cousson, Benoit wrote:
[...]
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -54,10 +54,12 @@
ranges;
ti,hwmods = l3_main;
- intc: interrupt-controller@1 {
-
On Wed, Jan 11, 2012 at 03:28:11PM +0200, Ohad Ben-Cohen wrote:
omap3isp depends on CONFIG_IOMMU_API, so avoid registering its
device (and defining its configuration structs) on !CONFIG_IOMMU_API.
This is generally nice to have, but more importantly, it fixes:
On Thu, 12 Jan 2012, NeilBrown wrote:
On Wed, 11 Jan 2012 06:43:04 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
Not off-mode - just retention.
Okay. It's expected that the UART will drop the first byte also when CORE
is in retention, due to the delay involved in waking up the chip. But
On Fri, 13 Jan 2012 03:05:03 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
cc Tero, Govindraj
On Thu, 12 Jan 2012, NeilBrown wrote:
On Wed, 11 Jan 2012 06:43:04 -0700 (MST) Paul Walmsley p...@pwsan.com
wrote:
I spent some time exploring why cpuidle never drops below state 0 and
On Fri, 13 Jan 2012, NeilBrown wrote:
Also, the HDQ access to the battery 'fuel gauge' is working fine, so
presumably that gets disturbed by one of the lower power states (3,4,5).
I guess it is 4,5,6 when CORE goes to RET or OFF. So we need some way for
HDQ to say I'm busy just like UART
On Fri, Jan 13, 2012 at 3:35 PM, Paul Walmsley p...@pwsan.com wrote:
cc Tero, Govindraj
On Thu, 12 Jan 2012, NeilBrown wrote:
On Wed, 11 Jan 2012 06:43:04 -0700 (MST) Paul Walmsley p...@pwsan.com
wrote:
I spent some time exploring why cpuidle never drops below state 0 and found
out that
This patch set implements fifomerge and a naive version for fifo threshold
calculation when fifomerge is in use. The strategy is simple: keep the low
threshold the same for both fifomerge and non-fifomerge cases, but calculate
the high threshold using the combined fifo size when fifomerge is in
Add feature flag for fifo merge. OMAP2 doesn't contain fifo merge, later
OMAPs do.
dispc_enable_fifomerge() checks for the flag when called, and gives a
WARN if fifo merge is being enabled when it is not supported.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
Add mechanism to set/unset the DISPC fifo-merge:
Add new fields to dss_data, fifo_merge and fifo_merge_dirty. These are
similar to the other info/dirty flags in ovl_priv_data and ovl_mgr_data,
but fifo merge is a common attribute to all managers and thus outside
the ovl_mgr_data.
The fifo-merge
Add fifo-merge support. This is done mainly in four functions:
mgr_enable/disable and ovl_enable/disable. These are the functions where
overlays are taken into and out of active use.
The process to enable and disable fifo-merge is not simple. We need to
do it in steps, waiting in between for
Fifo thresholds are calculated using bytes, but the debug print prints
values in buffer units. Change the prints to use bytes to be in line
with the calculations, and also to print in the same units on all OMAPs.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
Move fifo threshold calculation into dispc.c, as the thresholds are
really dispc internal thing.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/apply.c | 34 ++
drivers/video/omap2/dss/dispc.c | 22 --
Take fifo merge into use by implementing a rather naive fifo merge
threshold calculation: keep the low threshold always the same, but
increase the high threshold when fifo merge is used.
This should greatly increase the time between pixel data fetches from
SDRAM, as the usable fifo size is much
Hi,
In case of AM33xx family of devices, we do not have 32K Sync timer
(32K Counter) available; and the current implementation is based on
compile-time option, where clock-source is chosen by something like,
File - arch/arm/mach-omap2/timer.c
#ifdef CONFIG_OMAP_32K_TIMER
static void __init
On Fri, Jan 13, 2012 at 16:33:07, Cousson, Benoit wrote:
Hi Vaibhav,
On 1/13/2012 7:14 AM, Hiremath, Vaibhav wrote:
On Tue, Dec 20, 2011 at 19:09:57, Cousson, Benoit wrote:
[...]
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -54,10 +54,12 @@
ranges;
ti,hwmods =
On Fri, Jan 13, 2012 at 1:21 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
Hi,
In case of AM33xx family of devices, we do not have 32K Sync timer
(32K Counter) available; and the current implementation is based on
compile-time option, where clock-source is chosen by something like,
File -
On 1/13/2012 1:31 PM, Hiremath, Vaibhav wrote:
On Fri, Jan 13, 2012 at 16:33:07, Cousson, Benoit wrote:
Hi Vaibhav,
On 1/13/2012 7:14 AM, Hiremath, Vaibhav wrote:
On Tue, Dec 20, 2011 at 19:09:57, Cousson, Benoit wrote:
[...]
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -54,10 +54,12 @@
On Fri, 13 Jan 2012, Govindraj wrote:
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 942bb4f..4ef32d4 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -183,6 +183,9 @@ static int
Hi Linus,
I have been working in an HSI framework. The High Speed Synchronous Serial
Interface (HSI) is a serial interface mainly used for connecting application
engines (APE) with cellular modem engines (CMT) in cellular handsets.
The framework is currently being used for some people and we
On Fri, Jan 13, 2012 at 18:19:24, Shilimkar, Santosh wrote:
On Fri, Jan 13, 2012 at 1:21 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
Hi,
In case of AM33xx family of devices, we do not have 32K Sync timer
(32K Counter) available; and the current implementation is based on
compile-time
On Thu, Jan 12, 2012 at 11:59:51AM -0800, Tony Lindgren wrote:
* Nicolas Pitre n...@fluxnic.net [120112 11:15]:
On Thu, 12 Jan 2012, Nicolas Pitre wrote:
Do you really need that return code?
It was initially hooked to core_initcall() which requires a return code.
Now that you
On Fri, Jan 13, 2012 at 18:31:24, Cousson, Benoit wrote:
On 1/13/2012 1:31 PM, Hiremath, Vaibhav wrote:
On Fri, Jan 13, 2012 at 16:33:07, Cousson, Benoit wrote:
Hi Vaibhav,
On 1/13/2012 7:14 AM, Hiremath, Vaibhav wrote:
On Tue, Dec 20, 2011 at 19:09:57, Cousson, Benoit wrote:
[...]
On Fri, Jan 13, 2012 at 2:42 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Fri, Jan 13, 2012 at 18:19:24, Shilimkar, Santosh wrote:
On Fri, Jan 13, 2012 at 1:21 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
Hi,
In case of AM33xx family of devices, we do not have 32K Sync timer
(32K
On Thu, Jan 12, 2012 at 04:04:23PM -0800, Saravana Kannan wrote:
While the original clk_hw suggestion was well intentioned, it just
forces too many unnecessary dereferences and indirection. It also
prevents static init of some fields as others have mentioned.
Overall, it made the MSM clock
On Fri, Jan 13, 2012 at 20:11:04, Shilimkar, Santosh wrote:
On Fri, Jan 13, 2012 at 2:42 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Fri, Jan 13, 2012 at 18:19:24, Shilimkar, Santosh wrote:
On Fri, Jan 13, 2012 at 1:21 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
Hi,
In case of
On Fri, Jan 13, 2012 at 02:05:20PM +, Russell King - ARM Linux wrote:
From: Russell King rmk+ker...@arm.linux.org.uk
ARM: Add arm_memblock_steal() to allocate memory away from the kernel
Several platforms are now using the memblock_alloc+memblock_free+
memblock_remove trick to obtain
On 1/13/2012 1:21 PM, Hiremath, Vaibhav wrote:
Hi,
In case of AM33xx family of devices, we do not have 32K Sync timer
(32K Counter) available; and the current implementation is based on
compile-time option, where clock-source is chosen by something like,
File - arch/arm/mach-omap2/timer.c
With the help of Mike Turquette I have integrated Kevin's PM work on
3.0.10-rt27. cpufreq-omap work independently of rt patches.
Antonio
---
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index e10ff2b..8e6c8bc 100644
--- a/arch/arm/mach-omap2/clock.h
+++
The discussion I had with Mike follows..
Antonio
1.
In the Linux kernel the available MPU frequencies and voltages are
listed in arch/arm/mach-omap2/opp4xxx_data.c in the struct
omap_opp_defq.
Considering that the MPU can be driven by all the different frequencies that
someone can
On Fri, Jan 13, 2012 at 20:49:35, Cousson, Benoit wrote:
On 1/13/2012 1:21 PM, Hiremath, Vaibhav wrote:
Hi,
In case of AM33xx family of devices, we do not have 32K Sync timer
(32K Counter) available; and the current implementation is based on
compile-time option, where clock-source is
On Fri, Jan 13, 2012 at 1:07 PM, Joerg Roedel joerg.roe...@amd.com wrote:
Will apply it as soon as the merge window closes.
Thanks.
Though we might want to consider sending this to Linus before rc1, to
eliminate global developers' pain as much as possible :)
--
To unsubscribe from this list:
On 1/13/2012 4:52 PM, Hiremath, Vaibhav wrote:
On Fri, Jan 13, 2012 at 20:49:35, Cousson, Benoit wrote:
[...]
A series was sent to do that by Felipe last year, but we somehow forgot
to rebase it on newer kernel and thus never reposted it.
If you are ok, I can help you here.
Thanks it
I have some more questions inline..
Note that the previous patches I have submitted so far are not tight
to freq table values (any freq values can be selected).
1.
In the Linux kernel the available MPU frequencies and voltages are
listed in arch/arm/mach-omap2/opp4xxx_data.c in the
* Russell King - ARM Linux li...@arm.linux.org.uk [120113 06:31]:
On Fri, Jan 13, 2012 at 02:05:20PM +, Russell King - ARM Linux wrote:
From: Russell King rmk+ker...@arm.linux.org.uk
ARM: Add arm_memblock_steal() to allocate memory away from the kernel
Several platforms are now using
On Fri, Jan 13, 2012 at 05:54:10PM +0200, Ohad Ben-Cohen wrote:
On Fri, Jan 13, 2012 at 1:07 PM, Joerg Roedel joerg.roe...@amd.com wrote:
Will apply it as soon as the merge window closes.
Though we might want to consider sending this to Linus before rc1, to
eliminate global developers' pain
On Fri, Jan 13, 2012 at 6:46 PM, Joerg Roedel joerg.roe...@amd.com wrote:
Okay, so I will send out the fix early next week :)
Thanks a lot :)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
* Shilimkar, Santosh santosh.shilim...@ti.com [120113 06:08]:
On Fri, Jan 13, 2012 at 2:42 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Fri, Jan 13, 2012 at 18:19:24, Shilimkar, Santosh wrote:
...
};
We need to have similar entries in all devices where 32K timer is
* Ohad Ben-Cohen o...@wizery.com [120113 08:16]:
On Fri, Jan 13, 2012 at 6:46 PM, Joerg Roedel joerg.roe...@amd.com wrote:
Okay, so I will send out the fix early next week :)
Thanks a lot :)
Thanks, here's my ack if you did not apply it yet:
Acked-by: Tony Lindgren t...@atomide.com
--
To
Paul Walmsley p...@pwsan.com writes:
cc Tero, Govindraj
On Thu, 12 Jan 2012, NeilBrown wrote:
On Wed, 11 Jan 2012 06:43:04 -0700 (MST) Paul Walmsley p...@pwsan.com
wrote:
I spent some time exploring why cpuidle never drops below state 0 and found
out that the code explicitly disables
Tomi Valkeinen tomi.valkei...@ti.com writes:
On Thu, 2012-01-12 at 14:40 -0800, Kevin Hilman wrote:
Tomi Valkeinen tomi.valkei...@ti.com writes:
On Mon, 2012-01-09 at 12:46 +, Joe Woodward wrote:
I'm running on a Gumstix Overo (OMAP3530) with an 24-bit LCD panel
connected via the
Hi Olof,
On Monday 09 January 2012 11:12 AM, Olof Johansson wrote:
Hi,
On Sun, Jan 8, 2012 at 9:23 AM, Aneesh Vane...@ti.com wrote:
Hi,
On Tuesday 20 December 2011 03:08 PM, Aneesh V wrote:
Hi Benoit
On Tuesday 20 December 2011 06:10 PM, Cousson, Benoit wrote:
Hi Aneesh,
snip
In
From: Rob Clark r...@ti.com
Register OMAP DRM/KMS platform device, and reserve a CMA region for
the device to use for buffer allocation.
Signed-off-by: Rob Clark r...@ti.com
---
arch/arm/plat-omap/Makefile |2 +-
arch/arm/plat-omap/common.c |2 +
arch/arm/plat-omap/drm.c| 88
On Fri, Jan 13, 2012 at 1:41 PM, Rob Clark rob.cl...@linaro.org wrote:
From: Rob Clark r...@ti.com
Register OMAP DRM/KMS platform device, and reserve a CMA region for
the device to use for buffer allocation.
Signed-off-by: Rob Clark r...@ti.com
---
arch/arm/plat-omap/Makefile | 2 +-
On Fri, Jan 13, 2012 at 9:46 PM, Rob Clark r...@ti.com wrote:
On Fri, Jan 13, 2012 at 1:41 PM, Rob Clark rob.cl...@linaro.org wrote:
+/* files from staging that contain platform data structure definitions */
+#include ../../../drivers/staging/omapdrm/omap_priv.h
+#include
Hi Rob,
Minor nitpicks.
On Fri, Jan 13, 2012 at 1:41 PM, Rob Clark rob.cl...@linaro.org wrote:
From: Rob Clark r...@ti.com
Register OMAP DRM/KMS platform device, and reserve a CMA region for
the device to use for buffer allocation.
Signed-off-by: Rob Clark r...@ti.com
---
On Fri, Jan 13, 2012 at 1:49 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, Jan 13, 2012 at 9:46 PM, Rob Clark r...@ti.com wrote:
On Fri, Jan 13, 2012 at 1:41 PM, Rob Clark rob.cl...@linaro.org wrote:
+/* files from staging that contain platform data structure definitions */
On Fri, Jan 13, 2012 at 1:51 PM, Aguirre, Sergio saagui...@ti.com wrote:
+ *
+ * DRM/KMS device registration for TI OMAP platforms
+ *
+ * Copyright (C) 2011 Texas Instruments
Happy new year! (2012?) :)
well, the patch did start life last year.. I can update these ;-)
BR,
-R
--
To
Hi,
On Friday 13 January 2012 05:16 PM, Tomi Valkeinen wrote:
Move fifo threshold calculation into dispc.c, as the thresholds are
really dispc internal thing.
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
snip
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
On Fri, Jan 13, 2012 at 9:53 PM, Rob Clark r...@ti.com wrote:
On Fri, Jan 13, 2012 at 1:49 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, Jan 13, 2012 at 9:46 PM, Rob Clark r...@ti.com wrote:
On Fri, Jan 13, 2012 at 1:41 PM, Rob Clark rob.cl...@linaro.org wrote:
+/* files from
On Fri, Jan 13, 2012 at 2:23 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, Jan 13, 2012 at 9:53 PM, Rob Clark r...@ti.com wrote:
On Fri, Jan 13, 2012 at 1:49 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, Jan 13, 2012 at 9:46 PM, Rob Clark r...@ti.com wrote:
On Fri, Jan 13, 2012 at 9:41 PM, Rob Clark rob.cl...@linaro.org wrote:
+void omapdrm_reserve_vram(void)
+{
+#ifdef CONFIG_CMA
+ /* Create private 32MiB contiguous memory area for omapdrm.0 device
+ * TODO revisit size.. if uc/wc buffers are allocated from CMA pages
+ *
From: Rob Clark r...@ti.com
Register OMAP DRM/KMS platform device, and reserve a CMA region for
the device to use for buffer allocation.
v1: initial patch
v2: move platform data structs into plat-omap to avoid having to
#include headers from drivers/staging and cleanups
Signed-off-by: Rob
From: Rob Clark r...@ti.com
Platform data structs populated when the platform device is registered
need to be #include'able under arch/arm/..., but having to #include
headers from drivers/staging is messy. Instead these structs are
moved to arch/arm/plat-omap/include/plat.
Signed-off-by: Rob
On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark rob.cl...@linaro.org wrote:
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 9a58461..b86e6cb 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -4,7 +4,7 @@
# Common support
obj-y :=
On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark rob.cl...@linaro.org wrote:
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 9a58461..b86e6cb 100644
--- a/arch/arm/plat-omap/Makefile
Hi Ming,
sorry for the late response. It's all looking better now, however there
is still a few things that could be improved.
On 12/14/2011 03:00 PM, Ming Lei wrote:
This patch introduces two new IOCTLs and related data
structure which will be used by the coming video device
with object
On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark rob.cl...@linaro.org wrote:
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 9a58461..b86e6cb 100644
--- a/arch/arm/plat-omap/Makefile
Kevin Hilman khil...@ti.com writes:
[...]
From: Paul Walmsley p...@pwsan.com
Date: Fri, 13 Jan 2012 02:10:30 -0700
Subject: [PATCH] ARM: OMAP3: PM: allow MPU to enter low-power states even
when the UART is active
For some reason, both the existing OMAP3 PM code and the OMAP3 CPUIdle
On Fri, 13 Jan 2012, Kevin Hilman wrote:
Kevin Hilman khil...@ti.com writes:
[...]
From: Paul Walmsley p...@pwsan.com
Date: Fri, 13 Jan 2012 02:10:30 -0700
Subject: [PATCH] ARM: OMAP3: PM: allow MPU to enter low-power states even
when the UART is active
For some reason, both
On Fri, 13 Jan 2012 04:31:37 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
On Fri, 13 Jan 2012, NeilBrown wrote:
Also, the HDQ access to the battery 'fuel gauge' is working fine, so
presumably that gets disturbed by one of the lower power states (3,4,5).
I guess it is 4,5,6 when CORE
Hi
just to follow up on this, I think there are some other bugs in this
formula... maybe someone might want to tackle them.
On Fri, 13 Jan 2012, Paul Walmsley wrote:
up-calc_latency = (100 * up-port.fifosize) /
(baud / 8);
One problem is that
On Sat, 14 Jan 2012, NeilBrown wrote:
On Fri, 13 Jan 2012 04:31:37 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
I'm not seeing garbling at all on the OMAP3 BeagleBoard here, running v3.2
with omap2plus_defconfig. The first character from the console gets lost,
which again is
On Fri, 13 Jan 2012, Paul Walmsley wrote:
Let's work out this formula for 115.2kbps:
(100 * 16) / (1000 * 115200 / 8)
= 1600 / 1440
= 1.11... (presumably the unit here is milliseconds)
= 1 (since up-calc_latency is a u32)
Then up-calc_latency is passed to
On Fri, 13 Jan 2012 16:34:06 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
So ideally this formula should change the 8 depending on the number of
data bits, whether there is a parity bit, and on the number of stop bits.
The real formula to determine the number of bits per byte should
On Sat, 14 Jan 2012, NeilBrown wrote:
On Fri, 13 Jan 2012 16:34:06 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
So ideally this formula should change the 8 depending on the number of
data bits, whether there is a parity bit, and on the number of stop bits.
The real formula to
On 12/17/2011 03:04 AM, Russell King - ARM Linux wrote:
On Fri, Dec 16, 2011 at 04:45:48PM -0800, Turquette, Mike wrote:
On Wed, Dec 14, 2011 at 5:18 AM, Thomas Gleixnert...@linutronix.de wrote:
On Tue, 13 Dec 2011, Mike Turquette wrote:
+void __clk_unprepare(struct clk *clk)
+{
+ if
On Fri, Jan 13, 2012 at 8:18 PM, Saravana Kannan skan...@codeaurora.org wrote:
On 12/17/2011 03:04 AM, Russell King - ARM Linux wrote:
On Fri, Dec 16, 2011 at 04:45:48PM -0800, Turquette, Mike wrote:
On Wed, Dec 14, 2011 at 5:18 AM, Thomas Gleixnert...@linutronix.de
wrote:
On Tue, 13 Dec
On 01/13/2012 08:39 PM, Turquette, Mike wrote:
On Fri, Jan 13, 2012 at 8:18 PM, Saravana Kannanskan...@codeaurora.org wrote:
On 12/17/2011 03:04 AM, Russell King - ARM Linux wrote:
On Fri, Dec 16, 2011 at 04:45:48PM -0800, Turquette, Mike wrote:
On Wed, Dec 14, 2011 at 5:18 AM, Thomas
75 matches
Mail list logo
