device name usbhs clocks are changed from
usbhs-omap.0 to usbhs_omap; this is because
in the hwmod registration the device name is set
as usbhs_omap
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c | 28 ++--
Current checks for cpu type were too restrictive leading
to failures for other silicons in same family.
The problem was found while testing audio playback on
AM37x and AM35x processors. But should exist on OMAP36xx
as well.
Signed-off-by: Sanjeev Premi pr...@ti.com
cc: Mark Brown
Hi,
On Tue, May 10, 2011 at 7:12 PM, Avinash.H.M. avinas...@ti.com wrote:
On Tue, May 10, 2011 at 04:25:19PM +0530, Gulati, Shweta wrote:
Hi,
On Sat, May 7, 2011 at 3:19 AM, Paul Walmsley p...@pwsan.com wrote:
On Thu, 21 Apr 2011, Gulati, Shweta wrote:
Yes, but in current code
From: Keshava Munegowda keshava_mgo...@ti.com
The disableing of clocks and freeing GPIO are changed
to fix the occurence of the crash of rmmod of ehci and ohci
drivers. The GPIOs should be freed after the spin locks are
unlocked.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
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 resume occurs. Before calling these functions, the
bus suspend and resume of ehci and ohci drivers are called
from
When reading/writing a subpage (When HW ECC is not available/enabled)
for number of bytes not aligned to 4, the mis-aligned bytes are handled
first (by cpu copy method) before enabling the Prefetch engine to/from
'p'(start of buffer 'buf'). Then it reads/writes rest of the bytes with
the help of
On Wednesday 11 May 2011 16:55:35 Premi, Sanjeev wrote:
Current checks for cpu type were too restrictive leading
to failures for other silicons in same family.
The problem was found while testing audio playback on
AM37x and AM35x processors. But should exist on OMAP36xx
as well.
On Wed, 11 May 2011 19:25:35 +0530
Sanjeev Premi pr...@ti.com wrote:
Current checks for cpu type were too restrictive leading
to failures for other silicons in same family.
The problem was found while testing audio playback on
AM37x and AM35x processors. But should exist on OMAP36xx
as
When reading/writing a subpage (When HW ECC is not available/enabled)
for number of bytes not aligned to 4, the mis-aligned bytes are handled
first (by cpu copy method) before enabling the Prefetch engine to/from
'p'(start of buffer 'buf'). Then it reads/writes rest of the bytes with
the help of
Following 2 hwmod strcuture are added:
UHH hwmod of usbhs with uhh base address and
EHCI , OHCI irq and base addresses.
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 184
From: Keshava Munegowda keshava_mgo...@ti.com
The Hwmod structures and Runtime PM features are implemented
For EHCI and OHCI drivers of OMAP3 and OMAP4.
The global suspend/resume of EHCI and OHCI
is validated on OMAP3430 sdp board with these patches.
Keshava Munegowda (5):
arm: omap: usb:
From: Keshava Munegowda keshava_mgo...@ti.com
The usbhs core driver does not enable/disable the intefrace and
fucntional clocks; These clocks are handled by hwmod and runtime pm,
hence insted of the clock enable/disable, the runtime pm APIS are
used. however,the port clocks and tll clocks are
On Wed, May 11, 2011 at 8:24 PM, Greg KH g...@kroah.com wrote:
On Wed, May 11, 2011 at 07:54:57PM +0530, Kishore Kadiyala wrote:
When reading/writing a subpage (When HW ECC is not available/enabled)
for number of bytes not aligned to 4, the mis-aligned bytes are handled
first (by cpu copy
The hwmod structure of uhh and tll are retrived
and registered with omap device
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/usb-host.c | 99 ++--
1 files changed, 35 insertions(+), 64 deletions(-)
diff --git
currently that's used by another module
(am35x) which, granted, it shouldn't be
using that, but in order to avoid compile
errors, let's export that symbol temporarily
until re-factoring work is done on that
driver.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/musb/musb_core.c |2
Hi all,
with the following three patches I could successfully
compile musb with omap2plus and am35x glue layers with
no problems.
Currently we still can't have all glue layers plus
DMA support, but we are getting there. Please give
this a round of test on your setup to avoid us
introducing any
On Wed, May 11, 2011 at 07:25:35PM +0530, Sanjeev Premi wrote:
Current checks for cpu type were too restrictive leading
to failures for other silicons in same family.
The problem was found while testing audio playback on
AM37x and AM35x processors. But should exist on OMAP36xx
as well.
On 5/11/2011 6:11 AM, Menon, Nishanth wrote:
On Mon, Mar 14, 2011 at 06:38, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On OMAP SMP configuartion, both processors share the voltage
and clock. So both CPUs needs to be scaled together and hence
needs software co-ordination.
Signed-off-by:
On Wed, May 11, 2011 at 07:54:57PM +0530, Kishore Kadiyala wrote:
When reading/writing a subpage (When HW ECC is not available/enabled)
for number of bytes not aligned to 4, the mis-aligned bytes are handled
first (by cpu copy method) before enabling the Prefetch engine to/from
'p'(start of
On 05/10/2011 12:59 PM, Russell King - ARM Linux wrote:
Add a generic mmio clocksource, covering both 32-bit and 16-bit register
access sizes, for up or down counters. This can be used to easily
create clocksources for simple counter-based implementations.
Cc: Alessandro Rubini
Oops forgot to CC sta...@kernel.org, posting again without any changes.
Regards,
Kishore
On Mon, May 9, 2011 at 7:51 PM, Kishore Kadiyala
kishore.kadiy...@ti.com wrote:
When reading/writing a subpage (When HW ECC is not available/enabled)
for number of bytes not aligned to 4, the mis-aligned
On Wed, May 11, 2011 at 12:23:45PM +0300, Tomi Valkeinen wrote:
So how should the regulator be set up?
You need to create a new regulator of some kind and then provide a way
for machines to set the supply_regulator in the init_data.
I should setup a fixed regulator, which is supplied from
On Tue, 2011-05-10 at 15:47 +0200, Mark Brown wrote:
On Tue, May 10, 2011 at 03:30:52PM +0300, Tomi Valkeinen wrote:
This sounds just the thing we need here. Do you think there's a chance
the code could get merged in the next window? And I'm also happy to test
the code with omapdss,
Add a generic mmio clocksource, covering both 32-bit and 16-bit register
access sizes, for up or down counters. This can be used to easily
create clocksources for simple counter-based implementations.
Cc: Alessandro Rubini rub...@unipv.it
Cc: Colin Cross ccr...@android.com
Cc: Eric Miao
On Wed, May 11, 2011 at 04:12, Shweta Gulati shweta.gul...@ti.com wrote:
To set sr ntarget values for all volt_domain,
volt_table is retrieved by doing a look_up of 'vdd_name'
field from omap_hwmod but voltage domain pointer does not
belong to omap_hwmod and is not used anywhere else.
As a
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Valkeinen, Tomi
Sent: Monday, May 09, 2011 1:06 PM
To: t...@atomide.com
Cc: linux-omap@vger.kernel.org; Valkeinen, Tomi; Stanley Miao
Subject: [PATCH 4/6] OMAP: LDP:
To set sr ntarget values for all volt_domain,
volt_table is retrieved by doing a look_up of 'vdd_name'
field from omap_hwmod but voltage domain pointer does not
belong to omap_hwmod and is not used anywhere else.
As a part of voltage layer and SR Layer clean up volt
pointer is removed from
OMAP Display Subsystem driver header files are currently located in
arch/arm/plat-omap/include/plat/ which is not a good place for driver headers.
This patch set moves the headers to a more suitable location at include/video/
and renaming the files as follows:
display.h - omapdss.h
arch/arm/plat-omap/include/plat/display.h is an include for the OMAP DSS
driver. A more logical place for it is in include/video.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c|2 +-
arch/arm/mach-omap2/board-4430sdp.c
arch/arm/plat-omap/include/plat/nokia-dsi-panel.h is an include for the
OMAP DSS panel driver for Nokia's DSI displays. A more logical place for
it is in include/video.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays/panel-taal.c |2 +-
* Tomi Valkeinen tomi.valkei...@ti.com [110510 17:00]:
On Tue, 2011-05-10 at 16:35 +0300, Tony Lindgren wrote:
* Tomi Valkeinen tomi.valkei...@ti.com [110509 19:58]:
Do the dss platform data code coalescing patches affect these?
Do you mean the recent discussions about DSS regulator
Hi,
On Mon, May 09, 2011 at 03:58:53PM +0530, Munegowda, Keshava wrote:
I you see only the patch ; its looks like variable halt is not needed;
If the code; it will be set only when the clocks are disabled;
Then after restoring irq, you will free the gpio based on this value.
that code is
This in part reverts commit 7a180e70cfc56e131bfe4796773df2acfc7d4180.
(usb: musb: temporarily make it bool) and while
at that we also allow glue layers to be compiled
as modules.
There are still some other changes needed
until we can have a fully functional build
with this setup, but we're
arch/arm/plat-omap/include/plat/panel-generic-dpi.h is an include for
the OMAP DSS panel driver for generic DPI displays. A more logical place
for it is in include/video.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c|2 +-
Hi,
On Mon, May 02, 2011 at 12:46:57PM +0300, Felipe Balbi wrote:
am35x_musb_set_mode() was redefined. Fix it.
Reported-by: Sebastian Andrzej Siewior bige...@linutronix.de
Signed-off-by: Felipe Balbi ba...@ti.com
---
Tony, it would be nice to get this in before merge window.
Can you send
Please, ignore this,
I have another idea which I will send in the near future.
Sorry for the noise...
On 05/11/11 10:43, Igor Grinberg wrote:
Each board defining mtd partitions also defined NAND_BLOCK_SIZE as
SZ_128K. Move the define to common-board-devices.h
Signed-off-by: Igor Grinberg
Tony,
You can fold this one to the original patch from Mike as well,
or do you want it into the rc1?
On 05/04/11 20:22, Thomas Weber wrote:
Am 04.05.2011 17:04, schrieb Igor Grinberg:
introduced by: 96974a24
(omap: consolidate touch screen initialization among different boards)
ads7846
Each board defining mtd partitions also defined NAND_BLOCK_SIZE as
SZ_128K. Move the define to common-board-devices.h
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t35.c |2 --
arch/arm/mach-omap2/board-cm-t3517.c |2 --
ping x2
Can this one get into .39?
On 05/03/11 18:30, Igor Grinberg wrote:
ping!
Just to make sure you haven't missed this one liner ;)
On 04/26/11 23:41, Igor Grinberg wrote:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x11014): Section mismatch
in reference from the function
On Wed, 2011-05-11 at 09:15 +0530, Janorkar, Mayuresh wrote:
-Original Message-
From: linux-fbdev-ow...@vger.kernel.org [mailto:linux-fbdev-
ow...@vger.kernel.org] On Behalf Of Valkeinen, Tomi
Sent: Tuesday, May 10, 2011 9:54 PM
To: linux-omap@vger.kernel.org;
On Tue, 2011-05-10 at 19:08 +, aaro.koski...@nokia.com wrote:
Hi,
Tomi Valkeinen [tomi.valkei...@ti.com]:
omapfb_mode_to_timings() had struct fb_info, struct fb_var and struct
fb_ops allocated from stack. This caused the stack usage grow quite
high.
Use kzalloc to allocate the
On Wed, 2011-05-11 at 10:28 +0530, Janorkar, Mayuresh wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Valkeinen, Tomi
Sent: Monday, May 09, 2011 1:06 PM
To: t...@atomide.com
Cc:
On 05/11/11 06:55, Sanjeev Premi wrote:
Current checks for cpu type were too restrictive leading
to failures for other silicons in same family.
The problem was found while testing audio playback on
AM37x and AM35x processors. But should exist on OMAP36xx
as well.
Signed-off-by: Sanjeev
[Another try with a different email client, sorry for any dups.]
...
diff --git a/arch/arm/mach-omap2/sr_device.c
b/arch/arm/mach-omap2/sr_device.c
index 2782d3f..65b2aae 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -82,6 +82,7 @@ static int
From: Steve Calfee [stevecal...@gmail.com]
Sent: Wednesday, May 11, 2011 11:46 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org; Girdwood, Liam
Subject: Re: [alsa-devel] [PATCH] ASoC: omap-mcbsp: Remove restrictive checks
for cpu type
[snip]...[snip]
Hi,
I removed all but the
Hi,
On Wed, May 11, 2011 at 10:06 PM, Todd Poynor toddpoy...@google.com wrote:
On Wed, May 11, 2011 at 2:12 AM, Shweta Gulati shweta.gul...@ti.com wrote:
...
diff --git a/arch/arm/mach-omap2/sr_device.c
b/arch/arm/mach-omap2/sr_device.c
index 2782d3f..65b2aae 100644
---
46 matches
Mail list logo
