I had exactly the same problem. It looks like the struct omap_mcbsp array was
intended to be accessible
From include/plat/mcbsp.h
extern struct omap_mcbsp **mcbsp_ptr;
I couldn't get access to mcbsp_ptr in an out of tree module. So I added this
arch/arm/plat-omap/include/plat/mcbsp.h
+struct
Hi,
On Fri, 26 Nov 2010 21:36:56 +0400, Elvis Dowson elvis.dow...@mac.com
wrote:
Hi,
Is the Inventra Highspeed Dual Role Controller silicon IP
available
on the TI OMAP 3503?
yes it is there.
The kernel config help documentation mentions only TI OMAP 353x and I'm
not sure if
Hi Mark,
On Thursday 25 November 2010 22:47:09 Mark Brown wrote:
On Thu, Nov 25, 2010 at 07:49:05PM +0200, Sakari Ailus wrote:
Currently when two media entities are connected they will be powered up
for the duration of the link setup, just in case the drivers would need
to access hardware
Hi Mark,
On Friday 26 November 2010 15:14:42 Mark Brown wrote:
On Fri, Nov 26, 2010 at 03:13:36PM +0100, Laurent Pinchart wrote:
On Thursday 25 November 2010 16:49:52 Mark Brown wrote:
On Thu, Nov 25, 2010 at 04:40:41PM +0100, Laurent Pinchart wrote:
It's supposed to reflect whether the
On Sunday, November 28, 2010 13:34:45 Laurent Pinchart wrote:
Hi Mark,
On Friday 26 November 2010 15:14:42 Mark Brown wrote:
On Fri, Nov 26, 2010 at 03:13:36PM +0100, Laurent Pinchart wrote:
On Thursday 25 November 2010 16:49:52 Mark Brown wrote:
On Thu, Nov 25, 2010 at 04:40:41PM
On 28 Nov 2010, at 12:33, Laurent Pinchart wrote:
Throwing an idea here, what about making power management modular ? The MC
core would then call back to drivers to handle use count changes. The
media_entity_use_change() function would be exported (and renamed), so that
drivers could use
On Fri, 26 Nov 2010, Datta, Shubhrajyoti wrote:
We were wondering how to test McSPI on N800.
Is there any peripheral connected to McSPI?
These devices are configured in the board file for the
device, which is arch/arm/mach-omap2/board-n8x0.c
- Paul
--
To unsubscribe from this list: send the
Hello Rajendra,
some comments:
On Tue, 16 Nov 2010, Rajendra Nayak wrote:
This is in preparation of splitting the powerdomain framework into
platform-independent part (for all omaps) and platform-specific
parts.
The platform-independent code would reside in plat-omap/powerdomain.c
and the
One minor comment here:
On Tue, 16 Nov 2010, Rajendra Nayak wrote:
Put infrastructure in place, so arch specific func pointers
can be hooked up to the platform-independent part of the
framework.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit
Some comments below:
On Tue, 16 Nov 2010, Rajendra Nayak wrote:
Define the following architecture specific funtions for omap2/3/4
.pwrdm_set_next_pwrst
.pwrdm_read_next_pwrst
.pwrdm_read_pwrst
.pwrdm_read_prev_pwrst
Convert the platform-independent framework to call these functions.
Some comments:
On Tue, 16 Nov 2010, Rajendra Nayak wrote:
Define the following architecture specific funtions for omap2/3/4
.pwrdm_set_logic_retst
.pwrdm_read_logic_pwrst
.pwrdm_read_prev_logic_pwrst
.pwrdm_read_logic_retst
Convert the platform-independent framework to call these
Hi Rajendra,
On Tue, 16 Nov 2010, Rajendra Nayak wrote:
Define the following architecture specific funtions for omap2/3/4
.pwrdm_set_mem_onst
.pwrdm_set_mem_retst
.pwrdm_read_mem_pwrst
.pwrdm_read_prev_mem_pwrst
.pwrdm_read_mem_retst
.pwrdm_clear_all_prev_pwrst
.pwrdm_enable_hdwr_sar
Hi
On Tue, 16 Nov 2010, Rajendra Nayak wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
OMAP4430 ES2 has additional bitfields in PWRSTST register which help
identify the previous power state entered by the powerdomain.
Add pwrdm_clear_all_prev_pwrst api to support this.
OMAP3 has
Hi Rajendra,
As you've seen, I just did another review pass on these. All of the
review comments are pretty minor, although some of them will require
moving some of the functions to different files, mostly due to OMAP3
functions being present in an OMAP2xxx file.
Once those changes are
14 matches
Mail list logo