Currently the fifo depth is set to zero for OMAP4 which disables
the FIFO usage. This patch enables the FIFO usage for I2C transactions
on OMAP4 also.
Reported-By:Nishanth Menon n...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |9 -
1
Hi Randy,
Thanks for your comments !
On Wed, Jun 29, 2011 at 2:44 AM, Randy Dunlap rdun...@xenotime.net wrote:
+hardware accelerators, and therefore are often used to offload cpu-intensive
prefer: CPU-
throughout.
Isn't that changing
* Grazvydas Ignotas nota...@gmail.com [110603 15:01]:
On Sat, Jun 4, 2011 at 12:14 AM, Vimal Singh vimal.neww...@gmail.com wrote:
On Sat, Jun 4, 2011 at 1:26 AM, Grazvydas Ignotas nota...@gmail.com wrote:
-static int omap2_nand_gpmc_retime(void)
+static int omap2_nand_gpmc_retime(struct
* Peter Ujfalusi peter.ujfal...@ti.com [110628 03:12]:
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hello Tony,
While rebasing my series on top of your devel-cleanup branch,
I found this compillation error.
You can pick it right away, or I can queue this within my series.
But
Sorry for the delay, I had still some problems with the OMAP3 wakeup handling
with this set from suspend, but now this one works again. This set has been
tested on OMAP3 beagleboard, with suspend and cpuidle, with and without
off-mode. Appears to be working in all cases.
Main differences between
PRCM interrupt handler will now parse registered pads to see whether there
is an active wakeup event. If there is a pending wakeup event, the registered
ISR will be called.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/prcm.c | 94
This is no longer needed as it will be handled within serial driver itself.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 19 ---
1 files changed, 0 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
This patch is just a temporary hack to allow serial to work properly with
the PRCM chain handler. Should be replaced with a proper implementation.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/serial.c | 28 +---
drivers/tty/serial/omap-serial.c
Introduce a chained interrupt handler mechanism for the PRCM
interrupt, so that individual PRCM event can cleanly be handled by
handlers in separate drivers. We do this by introducing PRCM event
names, which are then matched to the particular PRCM interrupt bit
depending on the specific OMAP SoC
This should be replaced with a proper implementation.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/serial.c | 66 -
1 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c
Prevents a hang when omap_device would want to print something for
serial console device while enabling / disabling its clocks.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/plat-omap/omap_device.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git
PRCM chain interrupt registration is done now as part of
omap_hwmod_enable_wakeup() and omap_hwmod_disable_wakeup() calls. This
allows module ISR:s to be called when the module is idle but an IO_PAD
event is detected on the module input pads.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
These are no longer needed as omap_hwmod takes care of multiplexing of pads.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/serial.c | 25 +
1 files changed, 1 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c
This prevents system hang while attempting to access suspended console.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index
On Wed, Jun 29, 2011 at 5:02 AM, Kevin Hilman khil...@ti.com wrote:
+Rajendra
Balaji T K balaj...@ti.com writes:
add runtime pm support to HSMMC host controller
Use runtime pm API to enable/disable HSMMC clock
Use runtime autosuspend APIs to enable auto suspend delay
Based on OMAP HSMMC
* Péter Ujfalusi peter.ujfal...@ti.com [110614 05:34]:
On Tuesday 14 June 2011 13:23:51 Jarkko Nikula wrote:
We haven't seen any use for the SPI API in McBSP driver over the years. More
over, Peter Ujfalusi peter.ujfal...@ti.com noticed that SPI mode is not
even supported since OMAP2430 so
* Felipe Balbi ba...@ti.com [110616 04:22]:
it's a much more sensible location for that
sort of thing.
Applying all four to cbus branch.
Tony
--
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
now with Sparse IRQ numbering, we don't need
to add a bunch of defines in plat/irqs.h
Compile tested with omap2plus_defconfig (+cbus)
and omap1_defconfig (+cbus).
Felipe Balbi (2):
cbus: retu: use sparse IRQ numbering
cbus: retu: stop polluting plat/irqs.h
there's no need to pass a bunch of IRQ
bases down to drivers, we can use
irq_alloc_descs() for that and put the
sparse IRQ numbering scheme to work for
us.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/cbus/retu.c | 25 -
1 files changed, 16 insertions(+), 9
now that we're using sparse IRQs, we don't
need to polute plat/irqs.h anymore with
the dumb IRQ_BASE/IRQ_END definitions.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap1/board-nokia770.c |2 --
arch/arm/mach-omap2/board-n8x0.c |2 --
* Tony Lindgren t...@atomide.com [110627 12:17]:
* Kevin Hilman khil...@ti.com [110627 09:45]:
Tony Lindgren t...@atomide.com writes:
* Kevin Hilman khil...@ti.com [110623 17:32]:
Tony,
Please pull the following misc. OMAP PM updates targetted for v3.1.
This branch is
On Wednesday 29 June 2011, Ohad Ben-Cohen wrote:
On Wed, Jun 29, 2011 at 2:44 AM, Randy Dunlap rdun...@xenotime.net wrote:
+hardware accelerators, and therefore are often used to offload
cpu-intensive
prefer: CPU-
throughout.
On Wed, Jun 29, 2011 at 2:59 PM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 29 June 2011, Ohad Ben-Cohen wrote:
On Wed, Jun 29, 2011 at 2:44 AM, Randy Dunlap rdun...@xenotime.net wrote:
+hardware accelerators, and therefore are often used to offload
cpu-intensive
prefer:
Hi Jean-Christophe,
On Thu, May 26, 2011 at 06:32:57, Jean-Christophe PLAGNIOL-VILLARD wrote:
From: Russell King - ARM Linux li...@arm.linux.org.uk
We have two SoCs using SRAM, both with their own allocation systems,
and both with their own ways of copying functions into the SRAM.
Let's
Hi Tomi,
On Mon, Jun 27, 2011 at 6:28 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2011-06-27 at 11:21 +0530, K, Mythri P wrote:
Hi Tomi,
On Thu, Jun 23, 2011 at 6:01 PM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Thu, 2011-06-23 at 17:35 +0530, K, Mythri P wrote:
Hi
On Tue, Jun 28, 2011 at 04:59:57PM -0700, Colin Cross wrote:
On Tue, Jun 28, 2011 at 4:46 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Jun 28, 2011 at 04:37:08PM -0700, Colin Cross wrote:
I don't think it affects bogomips - loops_per_jiffy can still be
calibrated and
On Wed, Jun 29, 2011 at 12:11 AM, Paul Walmsley p...@pwsan.com wrote:
On Tue, 28 Jun 2011, T Krishnamoorthy, Balaji wrote:
On Tue, Jun 28, 2011 at 10:52 PM, Paul Walmsley p...@pwsan.com wrote:
On Wed, 22 Jun 2011, Balaji T K wrote:
Use runtime autosuspend APIs to enable auto suspend
On Wed, Jun 29, 2011 at 2:00 AM, Kevin Hilman khil...@ti.com wrote:
T Krishnamoorthy, Balaji balaj...@ti.com writes:
On Tue, Jun 28, 2011 at 10:52 PM, Paul Walmsley p...@pwsan.com wrote:
(cc'ing Adrian also)
Hi Balaji
On Wed, 22 Jun 2011, Balaji T K wrote:
Use runtime autosuspend APIs to
On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote:
On Wed, Jun 29, 2011 at 12:11 AM, Paul Walmsley p...@pwsan.com wrote:
On Tue, 28 Jun 2011, T Krishnamoorthy, Balaji wrote:
On Tue, Jun 28, 2011 at 10:52 PM, Paul Walmsley p...@pwsan.com wrote:
On Wed, 22 Jun 2011, Balaji T K wrote:
On Tue, Jun 28, 2011 at 12:00 AM, Grant Likely
grant.lik...@secretlab.ca wrote:
Very little for me to comment on here. However, something I just
noticed. Why is it necessary to pass in THIS_MODULE to the
rproc_register function? Having a reference to the pdev gives you the
pointer to the
On Thu, Jun 2, 2011 at 5:36 AM, Kevin Hilman khil...@ti.com wrote:
Keshava Munegowda keshava_mgo...@ti.com writes:
From: Keshava Munegowda keshava_mgo...@ti.com
The global suspend and resume functions for usbhs core driver
are implemented.These routine are called when the global suspend
and
On Wed, Jun 29, 2011 at 9:04 AM, Ohad Ben-Cohen o...@wizery.com wrote:
On Tue, Jun 28, 2011 at 12:00 AM, Grant Likely
grant.lik...@secretlab.ca wrote:
Very little for me to comment on here. However, something I just
noticed. Why is it necessary to pass in THIS_MODULE to the
rproc_register
On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote:
There have been some experiments on our customer programs to reduce this
value to a few ms and infrequent crashes were observed (stress testing
for several hours) while trying to access the controller registers.
By the way, could you send
On Tue, Jun 28, 2011 at 5:00 PM, Ohad Ben-Cohen o...@wizery.com wrote:
On Wed, Jun 29, 2011 at 1:51 AM, Grant Likely grant.lik...@secretlab.ca
wrote:
It's not the device_for_each_child() that you're 'putting' back from
here. Its the original kref initialization when the device was
created.
On Wed, Jun 29, 2011 at 8:12 PM, Paul Walmsley p...@pwsan.com wrote:
On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote:
On Wed, Jun 29, 2011 at 12:11 AM, Paul Walmsley p...@pwsan.com wrote:
On Tue, 28 Jun 2011, T Krishnamoorthy, Balaji wrote:
On Tue, Jun 28, 2011 at 10:52 PM, Paul
Hi,
On Wed, 2011-06-29 at 19:08 +0530, K, Mythri P wrote:
Hi Tomi,
As the HDMI PLL , PHY and video blocks are logical blocks it would
make sense to have the API's for all and the DSS HDMI (interface
driver - user driver) would make a call to configure this in a
particular sequence to enable
On Wed, Jun 29, 2011 at 9:08 PM, Paul Walmsley p...@pwsan.com wrote:
On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote:
There have been some experiments on our customer programs to reduce this
value to a few ms and infrequent crashes were observed (stress testing
for several hours) while
On Wed, Jun 29, 2011 at 8:52 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Thu, Jun 2, 2011 at 5:36 AM, Kevin Hilman khil...@ti.com wrote:
Keshava Munegowda keshava_mgo...@ti.com writes:
From: Keshava Munegowda keshava_mgo...@ti.com
The global suspend and resume functions for usbhs
From: Jean Pihet j-pi...@ti.com
Most of the ASM sleep code (in arch/arm/mach-omap2/sleep34xx.S)
is copied to internal SRAM at boot and after wake-up from CORE OFF mode.
However only a small part of the code really needs to run from internal SRAM.
This fix lets most of the ASM idle code run from
Hi,
On Wed, Jun 29, 2011 at 12:04:55PM +0300, Tero Kristo wrote:
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 96a7624..89cf027 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -880,20 +824,35 @@ static int __init
On Wed, Jun 29, 2011 at 07:53:19PM +0300, Felipe Balbi wrote:
On Wed, Jun 29, 2011 at 12:04:55PM +0300, Tero Kristo wrote:
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 96a7624..89cf027 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++
On Wed, Jun 29, 2011 at 7:00 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Jun 28, 2011 at 04:59:57PM -0700, Colin Cross wrote:
On Tue, Jun 28, 2011 at 4:46 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Jun 28, 2011 at 04:37:08PM -0700, Colin Cross
Hi,
On Tuesday 28 June 2011 09:58 PM, Valkeinen, Tomi wrote:
On Tue, 2011-06-28 at 09:19 -0700, Archit Taneja wrote:
Hi,
On Monday 27 June 2011 10:31 AM, Dima Zavin wrote:
There's no guarantee that the error handler worker thread
will run while the dispc clocks are on. Explicitly
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
Most of the ASM sleep code (in arch/arm/mach-omap2/sleep34xx.S)
is copied to internal SRAM at boot and after wake-up from CORE OFF mode.
However only a small part of the code really needs to run from internal SRAM.
This fix
On Wed, 29 Jun 2011, Munegowda, Keshava wrote:
for usb host case , I am seeing that the pm_runtime_get_sync
static int rpm_resume(struct device *dev, int rpmflags)
{
..
if (dev-pwr_domain) {
callback = dev-pwr_domain-ops.runtime_resume;
T Krishnamoorthy, Balaji balaj...@ti.com writes:
On Wed, Jun 29, 2011 at 2:00 AM, Kevin Hilman khil...@ti.com wrote:
T Krishnamoorthy, Balaji balaj...@ti.com writes:
On Tue, Jun 28, 2011 at 10:52 PM, Paul Walmsley p...@pwsan.com wrote:
(cc'ing Adrian also)
Hi Balaji
On Wed, 22 Jun 2011,
On Wed, Jun 29, 2011 at 7:29 PM, Kevin Hilman khil...@ti.com wrote:
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
Most of the ASM sleep code (in arch/arm/mach-omap2/sleep34xx.S)
is copied to internal SRAM at boot and after wake-up from CORE OFF mode.
However only a small
T Krishnamoorthy, Balaji balaj...@ti.com writes:
On Wed, Jun 29, 2011 at 5:02 AM, Kevin Hilman khil...@ti.com wrote:
+Rajendra
Balaji T K balaj...@ti.com writes:
add runtime pm support to HSMMC host controller
Use runtime pm API to enable/disable HSMMC clock
Use runtime autosuspend APIs
On Wed, Jun 29, 2011 at 10:29:49AM -0700, Kevin Hilman wrote:
Russell, if you're OK with it, can you add it to your suspend branch for
the upcoming merge window?
Yes - though I think we can go a little bit further - this patch is on
top of my code so far, and is untested. There isn't a need
-Original Message-
From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Wednesday, June 29, 2011 11:03 PM
To: Munegowda, Keshava
Cc: Kevin Hilman; linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
linux-ker...@vger.kernel.org; ba...@ti.com; gadi...@ti.com;
sa...@linux.intel.com;
On 06/28/2011 04:17 PM, Russell King - ARM Linux wrote:
That's why people have proposed hardware-timer based delay loops -
these screw up the bogomips value (it no longer refers to the CPU
but to the timer used for the delays) and the code proposed thus far
probably has a severe negative
If an ARM system has multiple cpus in the same socket and the
kernel is booted with maxcpus=1, secondary cpus are possible but
not present due to how platform_smp_prepare_cpus() is called.
Fix this by always calling platform_smp_prepare_cpus() as long as
max_cpus is non-zero (0 means no SMP) to
On Wed, Jun 29, 2011 at 11:29:29AM -0700, Stephen Boyd wrote:
On 06/28/2011 04:17 PM, Russell King - ARM Linux wrote:
That's why people have proposed hardware-timer based delay loops -
these screw up the bogomips value (it no longer refers to the CPU
but to the timer used for the delays)
On Wed, 29 Jun 2011, Partha Basak wrote:
-Original Message-
From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Wednesday, June 29, 2011 11:03 PM
To: Munegowda, Keshava
Cc: Kevin Hilman; linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
linux-ker...@vger.kernel.org;
+ Venkat
Hi Balaji, Venkat,
On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote:
OOPS pointed to omap_hsmmc_prepare_data / set_data_timeout
Use case was MMC + SDIO +GPS activity, on kernel 2.6.35 though.
Unhandled fault: imprecise external abort (0x1406) at 0x4073102c
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Wed, Jun 29, 2011 at 10:29:49AM -0700, Kevin Hilman wrote:
Russell, if you're OK with it, can you add it to your suspend branch for
the upcoming merge window?
Yes - though I think we can go a little bit further - this patch is on
Munegowda, Keshava keshava_mgo...@ti.com writes:
On Wed, Jun 29, 2011 at 8:52 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Thu, Jun 2, 2011 at 5:36 AM, Kevin Hilman khil...@ti.com wrote:
Keshava Munegowda keshava_mgo...@ti.com writes:
From: Keshava Munegowda keshava_mgo...@ti.com
cc'ing lakml
Hi Venkat, Balaji,
On Wed, 29 Jun 2011, S, Venkatraman wrote:
On Wed, Jun 29, 2011 at 9:08 PM, Paul Walmsley p...@pwsan.com wrote:
On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote:
There have been some experiments on our customer programs to reduce this
value to a few
On Wed, 29 Jun 2011 14:46:49 +0300, Felipe Balbi wrote:
now with Sparse IRQ numbering, we don't need
to add a bunch of defines in plat/irqs.h
Compile tested with omap2plus_defconfig (+cbus)
and omap1_defconfig (+cbus).
Felipe Balbi (2):
cbus: retu: use sparse IRQ numbering
cbus: retu: stop
On Wed, Jun 29, 2011 at 06:40:23PM +0200, jean.pi...@newoldbits.com wrote:
@@ -309,7 +308,7 @@ static irqreturn_t prcm_interrupt_handler (int irq, void
*dev_id)
static void omap34xx_do_sram_idle(unsigned long save_state)
{
- _omap_sram_idle(omap3_arm_context, save_state);
+
On Wed, Jun 29, 2011 at 12:06:07PM -0700, Kevin Hilman wrote:
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Wed, Jun 29, 2011 at 10:29:49AM -0700, Kevin Hilman wrote:
Russell, if you're OK with it, can you add it to your suspend branch for
the upcoming merge window?
Yes -
Shubhrajyoti D shubhrajy...@ti.com writes:
Currently the fifo depth is set to zero for OMAP4 which disables
the FIFO usage. This patch enables the FIFO usage for I2C transactions
on OMAP4 also.
Do you know the history of why the FIFO depth was set to zero? A
summary of that history would
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Wed, Jun 29, 2011 at 12:06:07PM -0700, Kevin Hilman wrote:
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Wed, Jun 29, 2011 at 10:29:49AM -0700, Kevin Hilman wrote:
Russell, if you're OK with it, can you add it to your
OMAP3630 supports an Adaptive Body-Bias ldo as well as some MPU interrupts
related to voltage control that are not present on OMAP34XX. This patch
adds the offsets, register addresses, bitfield shifts and masks to support
this feature.
Signed-off-by: Mike Turquette mturque...@ti.com
---
From: Nishanth Menon n...@ti.com
OMAP3 and more recent platforms support a PRM interrupt to the MPU for
Adapative Body-Bias ldo transitions.
Add helpers to the OMAP3 OMAP4 PRM code to check the status of the
interrupt and also to clear it. These will be called from the ABB code
as part of the
Due to voltage domain trimming and silicon characterstics some silicon
may experience instability when operating at a high voltage. To
compensate for this an Adaptive Body-Bias ldo exists. First featured in
OMAP3630, the purpose of this ldo is to provide a voltage boost to PMOS
backgates when a
The operating mode of the Adaptive Body-Bias ldo maps directly to the
voltage of its voltage domain. The two modes supported are bypass and
Forward Body-Bias (FBB).
This patch models this relationship by adding an opp_sel paramter to
struct omap_volt_data and populates this type in the 3630 and
The Adaptive Body-Bias ldo can be set to bypass or Forward Body-Bias
after voltage scaling is performed.
This patch implements the Adaptive Body-Bias ldo initialization routine
and the transition sequence which is needed after a vc_bypass or
vp_forceupdate sequence completes.
Signed-off-by: Mike
This patchset adds Adaptive Body-Bias ldo handling to the OMAP voltage
code with support for 36xx and 44xx chips. ABB handling is a mandatory
part of the voltage scaling process when operating at high OPPs.
A longer explanation is that due to voltage domain trimming and silicon
characterstics
Adaptive Body-Bias ldo state should be transitioned (if necessary) after
a voltage scaling sequence completes via vc_bypass or vp_forceupdate
methods.
This patch initializes the ABB ldo's as a part of the greater voltage
initialization function and adds the ABB transition routine to both the
From: Nishanth Menon n...@ti.com
We have multiple interrupt status hidden in the PRM interrupt status
reg. Make this handling generic to allow us to pull out LDO status such
as those for ABB from it using the same data structure and indexing. We
hence rename accordingly.
We also fix a trivial
Starting with OMAP36xx, some voltage domains have an ABB ldo meant to
insure stability when that voltage domain is operating at a high OPP.
This patch adds struct omap_abb_instance to struct voltagedomain and
populates the data for those voltage domains that have an ABB ldo on
both 36xx and 44xx
+ Venkat
Hi Balaji
On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote:
On Wed, Jun 29, 2011 at 2:00 AM, Kevin Hilman khil...@ti.com wrote:
T Krishnamoorthy, Balaji balaj...@ti.com writes:
I have seen some instabilities if delay is very less, on some
production boards. The previous
Change-Id: I18168c887e1384c07dc033a1ffc57abdacb26073
Signed-off-by: Arve Hjønnevåg a...@android.com
---
drivers/video/omap2/dss/dsi.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index c16b933..6975645
On Wed, Jun 29, 2011 at 11:26 PM, Kevin Hilman khil...@ti.com wrote:
T Krishnamoorthy, Balaji balaj...@ti.com writes:
On Wed, Jun 29, 2011 at 5:02 AM, Kevin Hilman khil...@ti.com wrote:
+Rajendra
Balaji T K balaj...@ti.com writes:
add runtime pm support to HSMMC host controller
Use
On Thu, Jun 30, 2011 at 1:37 AM, Paul Walmsley p...@pwsan.com wrote:
cc'ing lakml
Hi Venkat, Balaji,
On Wed, 29 Jun 2011, S, Venkatraman wrote:
On Wed, Jun 29, 2011 at 9:08 PM, Paul Walmsley p...@pwsan.com wrote:
On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote:
There have been
On Sat, Jun 25, 2011 at 03:00:01PM +0900, Kim HeungJun wrote:
Hi everyone,
Hi HeungJun,
Does anybody knows about n810 integration status on Kernel? I have one
n810, and I try to update the newest kernel and filesystem image freely.
And, if anyone know about , please let me know.
Are you
On Thu, Jun 30, 2011 at 6:10 AM, Paul Walmsley p...@pwsan.com wrote:
+ Venkat
Hi Balaji
On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote:
On Wed, Jun 29, 2011 at 2:00 AM, Kevin Hilman khil...@ti.com wrote:
T Krishnamoorthy, Balaji balaj...@ti.com writes:
I have seen some
On Wed, Jun 29, 2011 at 11:31:39AM -0700, Stephen Boyd wrote:
If an ARM system has multiple cpus in the same socket and the
kernel is booted with maxcpus=1, secondary cpus are possible but
not present due to how platform_smp_prepare_cpus() is called.
Fix this by always calling
On Wed, 2011-06-29 at 18:53 +0200, Balbi, Felipe wrote:
Hi,
On Wed, Jun 29, 2011 at 12:04:55PM +0300, Tero Kristo wrote:
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 96a7624..89cf027 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++
80 matches
Mail list logo
