Hi Russell,
From: ext Russell King - ARM Linux li...@arm.linux.org.uk
Subject: Re: [PATCH 4/6] omap iommu: simple virtual address space management
Date: Sat, 16 May 2009 11:22:48 +0200
On Tue, May 05, 2009 at 03:47:06PM +0300, Hiroshi DOYU wrote:
+int ioremap_page(unsigned long virt, unsigned
Hi there,
See title. I think one of the hardest work to do is figuring out how to
route digital audio from GSM modem to Omap processor via McBsp3. Could
anyone give me some points?
Thanks,
Wang, Husheng
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
- Original Message -
From: Kevin Hilman khil...@deeprootsystems.com
Subject: Re: [PATCH][RFC] McSPI Slave and DMA,FIFO support
Hemanth V heman...@ti.com writes:
This patch adds support for McSPI slave and FIFO. DMA and FIFO
could be enabled together for better throughput. Platform
- Original Message -
From: Gadiyar, Anand gadi...@ti.com
To: V, Hemanth heman...@ti.com; Kevin Hilman
khil...@deeprootsystems.com
Index: linux-omap-2.6/arch/arm/mach-omap2/devices.c
===
---
On Mon, May 18, 2009 at 8:16 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
From: ext Felipe Contreras felipe.contre...@gmail.com
Subject: Re: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration
Date: Sat, 16 May 2009 20:32:10 +0200
On Sat, May 16, 2009 at 7:36 PM, Russell King -
On Mon, May 18, 2009 at 8:33 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
From: Hiroshi DOYU hiroshi.d...@nokia.com
Subject: Re: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration
Date: Mon, 18 May 2009 08:16:27 +0300 (EEST)
From: ext Felipe Contreras felipe.contre...@gmail.com
On Sat, May 16, 2009 at 01:05:48PM +0300, Felipe Contreras wrote:
+struct iommu_device {
+ resource_size_t base;
+ resource_size_t irq;
+ struct iommu_platform_data pdata;
+ struct resource res[2];
};
The data which is needed per device is:
- base address
- IRQ (no need
Russell,
+static const char *omap4_dm_source_names[] __initdata = {
+ sys_ck,
+ omap_32k_fck,
+ NULL
+};
+static struct clk **omap4_dm_source_clocks[2];
Umm. struct clk **[2].
+static const int dm_timer_count = ARRAY_SIZE(omap4_dm_timers);
+
#else
#error OMAP
On Mon, May 18, 2009 at 05:37:24PM +0530, Shilimkar, Santosh wrote:
As for the pointer to the array of names, why can't this be declared
const and therefore that cast be removed?
I am sorry but didn't get this point.
dm_source_names = (char **)omap4_dm_source_names;
In this
-Original Message-
From: Mark Brown [mailto:broo...@sirena.org.uk]
Sent: Saturday, May 09, 2009 1:45 AM
To: Aggarwal, Anuj
Cc: linux-omap@vger.kernel.org; l...@slimlogic.co.uk
Subject: Re: [PATCH 3/3] Regulator: Added board-dependent code for
TPS65023
On Fri, May 08, 2009 at
On Mon, May 18, 2009 at 3:11 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Sat, May 16, 2009 at 01:05:50PM +0300, Felipe Contreras wrote:
This allows devices to be registered only when they are used. The
current dsp-bridge driver for example is not using iommu so registering
On Mon, May 18, 2009 at 3:07 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Sat, May 16, 2009 at 01:05:48PM +0300, Felipe Contreras wrote:
+struct iommu_device {
+ resource_size_t base;
+ resource_size_t irq;
+ struct iommu_platform_data pdata;
+ struct
On Mon, May 18, 2009 at 03:46:07PM +0300, Felipe Contreras wrote:
On Mon, May 18, 2009 at 3:11 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
The real problem here seems to be the TI DSP bridge code, and if that's
the case why can't we just avoid registering IVA2 if the TI DSP
On Mon, May 18, 2009 at 05:50:31PM +0530, Aggarwal, Anuj wrote:
The kernel already provides facilities for detecting the presence of
devices. In cases where it is possible to do a generic check for a
[Aggarwal, Anuj] In my opinion, it would not be a good idea to probe
for several PMICs,
On Mon, May 18, 2009 at 09:31:26AM +0300, Hiroshi DOYU wrote:
Right. In this change for better performance, I have to expose struct
mem_type and get_mem_type() a bit more as below. Is this change
acceptable, or do you have a better idea?
You don't need to expose struct mem_type at all. You
On Fri, May 15, 2009 at 11:40:41AM -0700, Kevin Hilman wrote:
This patch is to sync the core linux-omap PM code with mainline. This
code has evolved and been used for a while the linux-omap tree, but
the attempt here is to finally get this into mainline.
Following this will be a series of
From: ext Russell King - ARM Linux li...@arm.linux.org.uk
Subject: Re: [RFC/PATCH 3/3] omap3-iommu: remote registration
Date: Mon, 18 May 2009 14:11:13 +0200
On Sat, May 16, 2009 at 01:05:50PM +0300, Felipe Contreras wrote:
This allows devices to be registered only when they are used. The
On Tue, May 05, 2009 at 03:47:11PM +0300, Hiroshi DOYU wrote:
+config OMAP_IOMMU
+ tristate IOMMU support
+ depends on ARCH_OMAP
+ default n
default n is the default whatever. There's no need for the depends line
either - the whole file is protected by an if ARCH_OMAP..endif
On Mon, May 18, 2009 at 04:21:19PM +0300, Felipe Contreras wrote:
On Mon, May 18, 2009 at 4:02 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, May 18, 2009 at 03:46:07PM +0300, Felipe Contreras wrote:
On Mon, May 18, 2009 at 3:11 PM, Russell King - ARM Linux
From: ext Felipe Contreras felipe.contre...@gmail.com
Subject: Re: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration
Date: Mon, 18 May 2009 13:48:09 +0200
On Mon, May 18, 2009 at 8:16 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
From: ext Felipe Contreras
On Mon, May 18, 2009 at 4:35 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
From: ext Russell King - ARM Linux li...@arm.linux.org.uk
Subject: Re: [RFC/PATCH 3/3] omap3-iommu: remote registration
Date: Mon, 18 May 2009 14:11:13 +0200
On Sat, May 16, 2009 at 01:05:50PM +0300, Felipe Contreras
From: Hiroshi DOYU hiroshi.d...@nokia.com
Subject: Re: [RFC/PATCH 3/3] omap3-iommu: remote registration
Date: Mon, 18 May 2009 16:35:33 +0300 (EEST)
From: ext Russell King - ARM Linux li...@arm.linux.org.uk
Subject: Re: [RFC/PATCH 3/3] omap3-iommu: remote registration
Date: Mon, 18 May 2009
From: ext Felipe Contreras felipe.contre...@gmail.com
Subject: Re: [RFC/PATCH 3/3] omap3-iommu: remote registration
Date: Mon, 18 May 2009 15:52:59 +0200
On Mon, May 18, 2009 at 4:35 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
From: ext Russell King - ARM Linux li...@arm.linux.org.uk
On Mon, May 18, 2009 at 4:40 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, May 18, 2009 at 04:21:19PM +0300, Felipe Contreras wrote:
On Mon, May 18, 2009 at 4:02 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, May 18, 2009 at 03:46:07PM +0300, Felipe
From: ext Russell King - ARM Linux li...@arm.linux.org.uk
Subject: Re: [PATCH 3/6] omap iommu: omap3 iommu device registration
Date: Sat, 16 May 2009 11:55:14 +0200
On Sat, May 16, 2009 at 10:20:36AM +0100, Russell King - ARM Linux wrote:
This looks all very convoluted. Why not do something
Omap3 MUSB AUTOIDLE functionality configured through OTG_SYSCONFIG
register prevents the device from going into retention.
This is a workaround (by Richard Woodruff/TI), as his comment :
A new MUSB bug which is a match to data below was identified very
recently (on hardware and in simulation).
* Shilimkar, Santosh santosh.shilim...@ti.com [090516 13:04]:
Thanks Russell for scanning all the patches minutely !!
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Saturday, May 16, 2009 3:24 PM
To: Shilimkar, Santosh
Cc:
is a static function. The only user of omap4_globals is
__omap4_set_globals.
It looks to me like the only purpose of omap4_globals is to pass a
structure to __omap4_set_globals. Why not use a function
argument instead?
Indeed. Actually I just more or less followed what is
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Fri, May 08, 2009 at 07:47:09PM +0300, Kalle Valo wrote:
stanley.miao stanley.m...@windriver.com writes:
Looks like you used the CodeSourcery 2007q3 toolchain. This had been
reported earlier. Switching to 2008q3 works.
Yeah,
On Mon, May 18, 2009 at 06:54:56PM +0300, Kalle Valo wrote:
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Fri, May 08, 2009 at 07:47:09PM +0300, Kalle Valo wrote:
stanley.miao stanley.m...@windriver.com writes:
Looks like you used the CodeSourcery 2007q3 toolchain. This
No functional changes.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
How about this?
arch/arm/mach-omap2/omap3-iommu.c | 53 ++---
1 files changed, 26 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-omap2/omap3-iommu.c
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Fri, May 15, 2009 at 11:40:41AM -0700, Kevin Hilman wrote:
This patch is to sync the core linux-omap PM code with mainline. This
code has evolved and been used for a while the linux-omap tree, but
the attempt here is to finally get
On Mon, May 18, 2009 at 10:00:44AM -0700, Kevin Hilman wrote:
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Fri, May 15, 2009 at 11:40:41AM -0700, Kevin Hilman wrote:
This patch is to sync the core linux-omap PM code with mainline. This
code has evolved and been used for a
[ adding Richard W. to To: since he can probably shed some light here ]
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Fri, May 15, 2009 at 11:40:41AM -0700, Kevin Hilman wrote:
This patch is to sync the core linux-omap PM code with mainline. This
code has evolved and been used
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Mon, May 18, 2009 at 06:54:56PM +0300, Kalle Valo wrote:
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Fri, May 08, 2009 at 07:47:09PM +0300, Kalle Valo wrote:
stanley.miao stanley.m...@windriver.com writes:
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Mon, May 18, 2009 at 10:00:44AM -0700, Kevin Hilman wrote:
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Fri, May 15, 2009 at 11:40:41AM -0700, Kevin Hilman wrote:
This patch is to sync the core linux-omap PM code
On Mon, May 18, 2009 at 10:08:36AM -0700, Kevin Hilman wrote:
[ adding Richard W. to To: since he can probably shed some light here ]
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Fri, May 15, 2009 at 11:40:41AM -0700, Kevin Hilman wrote:
This patch is to sync the core
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Niilo Minkkinen
Sent: Monday, May 18, 2009 9:54 AM
Omap3 MUSB AUTOIDLE functionality configured through OTG_SYSCONFIG
register prevents the device from going into retention.
This is a workaround
Hi Kevin,
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/gpio.c | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index
On Mon, May 18, 2009 at 02:04:19PM -0500, Woodruff, Richard wrote:
cpu_init() is not yet accessible at the point this code is running.
Not at that _exact_ point, but there's no need what so ever for it
to be at that exact point. There's nothing stopping a call to
cpu_init() happening later.
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Monday, May 18, 2009 3:25 PM
The call to the enter method essentially calls the core specific suspend
function (eg, pxa25x_cpu_suspend()), which is an assembly function which
ultimately ends up powering down the core
On Mon, May 18, 2009 at 03:47:31PM -0500, Woodruff, Richard wrote:
The code flow is:
- Wakeup event
- ARM reboots and uses SOC mask ROM context restore helper
- Mask ROM code jump to restore pointers with MMU OFF.
- Restore code resets ARM CortexA8 state
Hi,
Few comments below.
* Mikkel Christensen m...@ti.com [090515 14:17]:
This patch creates the minimal OMAP3 Zoom2 board support.
Signed-off-by: Mikkel Christensen m...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
arch/arm/mach-omap2/board-zoom2-debugboard.c | 161
Tony
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Hi,
Few comments below.
* Mikkel Christensen m...@ti.com [090515 14:17]:
This patch creates the minimal OMAP3 Zoom2 board support.
Signed-off-by: Mikkel Christensen m...@ti.com
Signed-off-by: Vikram Pandita
* Shilimkar, Santosh santosh.shilim...@ti.com [090513 07:53]:
Tony,
Any comments on this patch.
http://patchwork.kernel.org/patch/19161/
We should just set the interrupts etc dynamically using the
cpu_is_omap() functions.
Regards,
Tony
--
To unsubscribe from this list: send the line
Hi everyone,
We have been looking into the Slab Corruption error and we have found the
problem occurs after an application has been terminated abnormally, e.g. Using
CTL-C or Segmentation Fault or kill.
The issue is observed not only for DMM test cases but for others test cases
that don't
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Tuesday, May 19, 2009 3:16 AM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP: Remove IRQ hardcoding from serial.c
* Shilimkar, Santosh santosh.shilim...@ti.com [090513 07:53]:
Hi,
I have a problem with my TI OMAP 3503 platform, where the
microSD card that I have, gets corrupted during a suspend/resume
operation. Do the existing power management drivers, cleanly unmount/
mount the mmc card during a suspend/resume operation?
I am using the TI OMAP linux
Hi Nate,
I have 1 input regarding your question:
From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org] On
Behalf Of Dongsoo, Nathaniel Kim [dongsoo@gmail.com]
Sent: Tuesday, May 19, 2009 7:53 AM
To: Shah, Hardik
Cc: linux-me...@vger.kernel.org;
Hi Sergio,
Thank you for your explanation . I learned much from that.
Cheers,
Nate
On Tue, May 19, 2009 at 2:22 PM, Aguirre Rodriguez, Sergio Alberto
saagui...@ti.com wrote:
Hi Nate,
I have 1 input regarding your question:
From: linux-media-ow...@vger.kernel.org
Hi Nate,
-Original Message-
From: Aguirre Rodriguez, Sergio Alberto
Sent: Tuesday, May 19, 2009 10:52 AM
To: Dongsoo, Nathaniel Kim; Shah, Hardik
Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh R;
Hiremath, Vaibhav
Subject: RE: [PATCH 3/3] OMAP2/3 V4L2
Hi Hardik,
According to earlier mail from Sergio, I could be noticed that it is
totally ok to restrict number of buffers by driver. As matter of fact,
I was always considering about the H/W restriction and could find the
answer from his mail.
By the way, thank you for your answer.
Cheers,
Nate
Kevin Hilman wrote:
The problem here is that such an interface is extremely fragile. Consider
what happens if a program disables HLT, and then gets killed off for some
reason. How does this reference get balanced again?
I think a better solution would be a char device driver which has to be
53 matches
Mail list logo
