On 01/13/2012 08:39 PM, Turquette, Mike wrote:
On Fri, Jan 13, 2012 at 8:18 PM, Saravana Kannan 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 Gleixner
wrote:
On Tue,
On Fri, Jan 13, 2012 at 8:18 PM, Saravana Kannan 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 Gleixner
>>> wrote:
On Tue, 13 Dec 2011, Mike Turquett
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 Gleixner wrote:
On Tue, 13 Dec 2011, Mike Turquette wrote:
+void __clk_unprepare(struct clk *clk)
+{
+ if (!clk)
+ r
On Sat, 14 Jan 2012, NeilBrown wrote:
> On Fri, 13 Jan 2012 16:34:06 -0700 (MST) Paul Walmsley 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 de
On Fri, 13 Jan 2012 16:34:06 -0700 (MST) Paul Walmsley 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 be
> some
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 Sat, 14 Jan 2012, NeilBrown wrote:
> On Fri, 13 Jan 2012 04:31:37 -0700 (MST) Paul Walmsley 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 expected when
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 U
On Fri, 13 Jan 2012 04:31:37 -0700 (MST) Paul Walmsley 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 goes to
On Fri, 13 Jan 2012, Kevin Hilman wrote:
> Kevin Hilman writes:
>
> [...]
>
> >> From: Paul Walmsley
> >> 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 exist
Kevin Hilman writes:
[...]
>> From: Paul Walmsley
>> 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
>> driver prevent the
On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
wrote:
> On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark 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
>> @@
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 de
On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
wrote:
> On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark 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
>> @@
On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark 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 := common.o sram.o cl
From: Rob Clark
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 Clark
---
d
From: Rob Clark
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 Clark
---
No
On Fri, Jan 13, 2012 at 9:41 PM, Rob Clark 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
> + * then the amount o
On Fri, Jan 13, 2012 at 2:23 PM, Felipe Contreras
wrote:
> On Fri, Jan 13, 2012 at 9:53 PM, Rob Clark wrote:
>> On Fri, Jan 13, 2012 at 1:49 PM, Felipe Contreras
>> wrote:
>>> On Fri, Jan 13, 2012 at 9:46 PM, Rob Clark wrote:
On Fri, Jan 13, 2012 at 1:41 PM, Rob Clark wrote:
> +/* fil
On Fri, Jan 13, 2012 at 9:53 PM, Rob Clark wrote:
> On Fri, Jan 13, 2012 at 1:49 PM, Felipe Contreras
> wrote:
>> On Fri, Jan 13, 2012 at 9:46 PM, Rob Clark wrote:
>>> On Fri, Jan 13, 2012 at 1:41 PM, Rob Clark wrote:
+/* files from staging that contain platform data structure definitions
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 Valkeinen
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 511ae2a..1cbb7a5 100
On Fri, Jan 13, 2012 at 1:51 PM, Aguirre, Sergio 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 unsubscribe fro
On Fri, Jan 13, 2012 at 1:49 PM, Felipe Contreras
wrote:
> On Fri, Jan 13, 2012 at 9:46 PM, Rob Clark wrote:
>> On Fri, Jan 13, 2012 at 1:41 PM, Rob Clark wrote:
>>> +/* files from staging that contain platform data structure definitions */
>>> +#include "../../../drivers/staging/omapdrm/omap_pr
Hi Rob,
Minor nitpicks.
On Fri, Jan 13, 2012 at 1:41 PM, Rob Clark wrote:
> From: Rob Clark
>
> Register OMAP DRM/KMS platform device, and reserve a CMA region for
> the device to use for buffer allocation.
>
> Signed-off-by: Rob Clark
> ---
> arch/arm/plat-omap/Makefile | 2 +-
> arch/arm
On Fri, Jan 13, 2012 at 9:46 PM, Rob Clark wrote:
> On Fri, Jan 13, 2012 at 1:41 PM, Rob Clark wrote:
>> +/* files from staging that contain platform data structure definitions */
>> +#include "../../../drivers/staging/omapdrm/omap_priv.h"
>> +#include "../../../drivers/staging/omapdrm/omap_dmm_t
On Fri, Jan 13, 2012 at 1:41 PM, Rob Clark wrote:
> From: Rob Clark
>
> Register OMAP DRM/KMS platform device, and reserve a CMA region for
> the device to use for buffer allocation.
>
> Signed-off-by: Rob Clark
> ---
> arch/arm/plat-omap/Makefile | 2 +-
> arch/arm/plat-omap/common.c | 2
From: Rob Clark
Register OMAP DRM/KMS platform device, and reserve a CMA region for
the device to use for buffer allocation.
Signed-off-by: Rob Clark
---
arch/arm/plat-omap/Makefile |2 +-
arch/arm/plat-omap/common.c |2 +
arch/arm/plat-omap/drm.c| 88
Hi Olof,
On Monday 09 January 2012 11:12 AM, Olof Johansson wrote:
Hi,
On Sun, Jan 8, 2012 at 9:23 AM, Aneesh V 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,
In general, is it rea
Tomi Valkeinen writes:
> On Thu, 2012-01-12 at 14:40 -0800, Kevin Hilman wrote:
>> Tomi Valkeinen 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 DPI interface (using the gen
Paul Walmsley writes:
> cc Tero, Govindraj
>
> On Thu, 12 Jan 2012, NeilBrown wrote:
>
>> On Wed, 11 Jan 2012 06:43:04 -0700 (MST) Paul Walmsley
>> wrote:
>>
>> I spent some time exploring why cpuidle never drops below state 0 and found
>> out that the code explicitly disables other states whe
* Ohad Ben-Cohen [120113 08:16]:
> On Fri, Jan 13, 2012 at 6:46 PM, Joerg Roedel 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
--
To unsubscribe from this list: send the line "unsub
On Fri, Jan 13, 2012 at 4:05 PM, Russell King - ARM Linux
wrote:
> +phys_addr_t arm_memblock_steal(phys_addr_t size, phys_addr_t align)
> +{
> + phys_addr_t phys;
> +
> + if (!arm_memblock_steal_permitted)
> + panic("arm_memblock_steal used in an unsafe manner\n");
> +
>
* Shilimkar, Santosh [120113 06:08]:
> On Fri, Jan 13, 2012 at 2:42 PM, Hiremath, Vaibhav 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
> >> > present.
> >> >
> >>
On Fri, Jan 13, 2012 at 6:46 PM, Joerg Roedel 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 http://vger.kernel.org/
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 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 as much as possi
* Russell King - ARM Linux [120113 06:31]:
> On Fri, Jan 13, 2012 at 02:05:20PM +, Russell King - ARM Linux wrote:
> > From: Russell King
> > ARM: Add arm_memblock_steal() to allocate memory away from the kernel
> >
> > Several platforms are now using the memblock_alloc+memblock_free+
> > me
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 th
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 will
On Fri, Jan 13, 2012 at 1:07 PM, Joerg Roedel 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: send the line "unsubsc
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-s
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 generat
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
+++ b/arch/arm/mach
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
#ifd
On Fri, Jan 13, 2012 at 02:05:20PM +, Russell King - ARM Linux wrote:
> From: Russell King
> 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 memory which won't be mapp
On Fri, Jan 13, 2012 at 20:11:04, Shilimkar, Santosh wrote:
> On Fri, Jan 13, 2012 at 2:42 PM, Hiremath, Vaibhav wrote:
> > On Fri, Jan 13, 2012 at 18:19:24, Shilimkar, Santosh wrote:
> >> On Fri, Jan 13, 2012 at 1:21 PM, Hiremath, Vaibhav wrote:
> >> > Hi,
> >> >
> >> > In case of AM33xx family
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 2:42 PM, Hiremath, Vaibhav wrote:
> On Fri, Jan 13, 2012 at 18:19:24, Shilimkar, Santosh wrote:
>> On Fri, Jan 13, 2012 at 1:21 PM, Hiremath, Vaibhav wrote:
>> > Hi,
>> >
>> > In case of AM33xx family of devices, we do not have 32K Sync timer
>> > (32K Counter) available;
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 wr
On Thu, Jan 12, 2012 at 11:59:51AM -0800, Tony Lindgren wrote:
> * Nicolas Pitre [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 yo
On Fri, Jan 13, 2012 at 18:19:24, Shilimkar, Santosh wrote:
> On Fri, Jan 13, 2012 at 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
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 wo
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 next_valid_
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, Jan 13, 2012 at 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/ma
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;
> >>
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 oma
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 la
Move fifo threshold calculation into dispc.c, as the thresholds are
really dispc internal thing.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/apply.c | 34 ++
drivers/video/omap2/dss/dispc.c | 22 --
drivers/video/omap2/dss
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
---
drivers/video/omap2/dss/dispc.c |8
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 certa
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 f
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
---
drivers/video/omap2/dss/dispc.c|5
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 use
On Fri, Jan 13, 2012 at 3:35 PM, Paul Walmsley wrote:
> cc Tero, Govindraj
>
> On Thu, 12 Jan 2012, NeilBrown wrote:
>
>> On Wed, 11 Jan 2012 06:43:04 -0700 (MST) Paul Walmsley
>> wrote:
>>
>> I spent some time exploring why cpuidle never drops below state 0 and found
>> out that the code explic
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 UAR
On Fri, 13 Jan 2012 03:05:03 -0700 (MST) Paul Walmsley wrote:
> cc Tero, Govindraj
>
> On Thu, 12 Jan 2012, NeilBrown wrote:
>
> > On Wed, 11 Jan 2012 06:43:04 -0700 (MST) Paul Walmsley
> > wrote:
> >
> > I spent some time exploring why cpuidle never drops below state 0 and found
> > out tha
On Thu, 12 Jan 2012, NeilBrown wrote:
> On Wed, 11 Jan 2012 06:43:04 -0700 (MST) Paul Walmsley 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
that shoul
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:
>
> arch/arm/plat-omap/inclu
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 Thu, Jan 12, 2012 at 10:00 PM, Russell King - ARM Linux
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 rather complex wa
cc Tero, Govindraj
On Thu, 12 Jan 2012, NeilBrown wrote:
> On Wed, 11 Jan 2012 06:43:04 -0700 (MST) Paul Walmsley 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 fairly broa
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 Interface(st
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
Cc: Keshava Munegowda
Signed-off-by: Shubhrajyoti D
---
drivers/mmc/host/omap_hsmmc.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers
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
---
driv
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
---
drivers/mmc/host/omap_hsmmc.c |9 ++
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 p
76 matches
Mail list logo
