Hi Tony and Russell,
On Mon, 2011-04-18 at 11:17 +0300, Tony Lindgren wrote:
* Tomi Valkeinen tomi.valkei...@ti.com [110418 09:57]:
So, I can make a patch that removes the SRAM support from omapfb, and
queue it up for the next merge window.
OK. That patch should probably go into
* Tomi Valkeinen tomi.valkei...@ti.com [110419 17:13]:
Hi Tony and Russell,
On Mon, 2011-04-18 at 11:17 +0300, Tony Lindgren wrote:
* Tomi Valkeinen tomi.valkei...@ti.com [110418 09:57]:
So, I can make a patch that removes the SRAM support from omapfb, and
queue it up for the next
* Russell King - ARM Linux li...@arm.linux.org.uk [110416 16:06]:
On Sat, Apr 16, 2011 at 09:01:26PM +0800, Haojian Zhuang wrote:
On Fri, Apr 15, 2011 at 9:06 PM, Russell King - ARM Linux
This uses the physical address, and unlike Davinci's dma address usage,
it always wants to have
On Mon, 2011-04-18 at 09:48 +0300, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [110416 16:06]:
On Sat, Apr 16, 2011 at 09:01:26PM +0800, Haojian Zhuang wrote:
On Fri, Apr 15, 2011 at 9:06 PM, Russell King - ARM Linux
This uses the physical address, and
* Tomi Valkeinen tomi.valkei...@ti.com [110418 09:57]:
On Mon, 2011-04-18 at 09:48 +0300, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [110416 16:06]:
On Sat, Apr 16, 2011 at 09:01:26PM +0800, Haojian Zhuang wrote:
On Fri, Apr 15, 2011 at 9:06 PM, Russell King -
2011/4/15 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 unify this before we have additional SoCs re-implementing this
obviously common functionality
On Friday 15 April 2011, Russell King - ARM Linux wrote:
On Fri, Apr 15, 2011 at 09:32:01AM -0600, Grant Likely wrote:
Yes, once the infrastructure is in place, powerpc can do its own
migration to the new code. I vote for putting it in lib at the
outset.
I don't agree with stuffing
On Fri, Apr 15, 2011 at 9:06 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
This is work in progress.
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 unify this before we have additional
On Sat, Apr 16, 2011 at 09:01:26PM +0800, Haojian Zhuang wrote:
On Fri, Apr 15, 2011 at 9:06 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
This is work in progress.
We have two SoCs using SRAM, both with their own allocation systems,
and both with their own ways of copying
This is work in progress.
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 unify this before we have additional SoCs re-implementing this
obviously common functionality themselves.
Unfortunately, we end
Russell,
On 04/15/2011 08:06 AM, Russell King - ARM Linux wrote:
This is work in progress.
We have two SoCs using SRAM, both with their own allocation systems,
and both with their own ways of copying functions into the SRAM.
It's more than that. Several i.MX chips use plat-mxc/iram_alloc.c.
Hi Russel,
Just small comment,
On Fri, Apr 15, 2011 at 08:06:07AM -0500, Russell King wrote:
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..3588749 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -75,7 +75,6 @@
static unsigned
On Fri, 2011-04-15 at 08:39 -0500, Rob Herring wrote:
lpc32xx and pnx4008 also use iram, but do not have an allocator (only
1 user). Both are doing a copy the suspend code to IRAM and run it
which may also be a good thing to have generic code for. Several i.MX
chips also need to run from IRAM
On Friday 15 April 2011 15:39:55 Rob Herring wrote:
On 04/15/2011 08:06 AM, Russell King - ARM Linux wrote:
This is work in progress.
We have two SoCs using SRAM, both with their own allocation systems,
and both with their own ways of copying functions into the SRAM.
It's more than
On Fri, Apr 15, 2011 at 04:52:38PM +0300, Eduardo Valentin wrote:
Hi Russel,
Just small comment,
On Fri, Apr 15, 2011 at 08:06:07AM -0500, Russell King wrote:
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..3588749 100644
---
On Fri, Apr 15, 2011 at 04:40:00PM +0200, Arnd Bergmann wrote:
On Friday 15 April 2011 15:39:55 Rob Herring wrote:
On 04/15/2011 08:06 AM, Russell King - ARM Linux wrote:
This is work in progress.
We have two SoCs using SRAM, both with their own allocation systems,
and both with
On Fri, Apr 15, 2011 at 9:26 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Apr 15, 2011 at 04:40:00PM +0200, Arnd Bergmann wrote:
On Friday 15 April 2011 15:39:55 Rob Herring wrote:
On 04/15/2011 08:06 AM, Russell King - ARM Linux wrote:
This is work in progress.
On Fri, Apr 15, 2011 at 04:50:49PM +0200, Detlef Vollmann wrote:
I'd love to have the mapping inside the create pool, but that might
not be possible in general.
No, think about it. What if you need to map the RAM area with some
special attributes - eg, where ioremap() doesn't work. Eg, OMAP
On Fri, Apr 15, 2011 at 09:32:01AM -0600, Grant Likely wrote:
Yes, once the infrastructure is in place, powerpc can do its own
migration to the new code. I vote for putting it in lib at the
outset.
I don't agree with stuffing non-arch directories with code which people
haven't already agreed
On Fri, Apr 15, 2011 at 08:39:55AM -0500, Rob Herring wrote:
Russell,
On 04/15/2011 08:06 AM, Russell King - ARM Linux wrote:
This is work in progress.
We have two SoCs using SRAM, both with their own allocation systems,
and both with their own ways of copying functions into the SRAM.
Le 15/04/2011 16:50, Detlef Vollmann :
On 04/15/11 15:06, Russell King - ARM Linux wrote:
This is work in progress.
Thanks, very useful.
[..]
Another question is whether we should allow multiple SRAM pools or not -
this code does allow multiple pools, but so far we only have one pool
per
...@linux.davincidsp.com; Tony
Lindgren; Sekhar Nori; linux-
o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [RFC PATCH] Consolidate SRAM support
On Fri, Apr 15, 2011 at 08:39:55AM -0500, Rob Herring wrote:
Russell,
On 04/15/2011 08:06 AM, Russell King - ARM Linux wrote:
This is work
On Fri, Apr 15, 2011 at 04:18:23PM +, Nguyen Dinh-R00091 wrote:
Hmm, that's nice - except for one issue. According to my grep of
arch/arm/ and drivers/, nothing uses iram_alloc(). So, does anything in
the MX stuff use iram_alloc.c, or is it dead code left over from a
previous experiment?
On Fri, Apr 15, 2011 at 05:20:45PM +0100, Russell King - ARM Linux wrote:
On Fri, Apr 15, 2011 at 04:18:23PM +, Nguyen Dinh-R00091 wrote:
Hmm, that's nice - except for one issue. According to my grep of
arch/arm/ and drivers/, nothing uses iram_alloc(). So, does anything in
the MX
On Fri, Apr 15, 2011 at 08:12:07PM +0200, Detlef Vollmann wrote:
Second point is that you'll notice that the code converts to a phys
address using this: phys = phys_base + (virt - virt_base). As soon as
we start allowing multiple regions of SRAM, it becomes impossible to
provide the phys
On 14:06 Fri 15 Apr , Russell King - ARM Linux wrote:
This is work in progress.
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 unify this before we have additional SoCs re-implementing this
...@lists.infradead.org
Subject: Re: [RFC PATCH] Consolidate SRAM support
On Fri, Apr 15, 2011 at 05:20:45PM +0100, Russell King - ARM Linux wrote:
On Fri, Apr 15, 2011 at 04:18:23PM +, Nguyen Dinh-R00091 wrote:
Hmm, that's nice - except for one issue. According to my grep of
arch/arm/ and drivers
Lindgren; Sekhar Nori; linux-
o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [RFC PATCH] Consolidate SRAM support
On Fri, Apr 15, 2011 at 05:20:45PM +0100, Russell King - ARM Linux wrote:
On Fri, Apr 15, 2011 at 04:18:23PM +, Nguyen Dinh-R00091 wrote:
Hmm
...@lists.infradead.org
Subject: Re: [RFC PATCH] Consolidate SRAM support
On Fri, Apr 15, 2011 at 07:20:12PM +, Nguyen Dinh-R00091 wrote:
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Friday, April 15, 2011 11:59 AM
To: Nguyen Dinh-R00091
Cc: Kevin
On Fri, Apr 15, 2011 at 10:11:07PM +0200, Uwe Kleine-König wrote:
On Fri, Apr 15, 2011 at 02:06:07PM +0100, Russell King - ARM Linux wrote:
This is work in progress.
We have two SoCs using SRAM, both with their own allocation systems,
and both with their own ways of copying functions
On Fri, Apr 15, 2011 at 09:19:25PM +0100, Russell King - ARM Linux wrote:
On Fri, Apr 15, 2011 at 10:11:07PM +0200, Uwe Kleine-König wrote:
On Fri, Apr 15, 2011 at 02:06:07PM +0100, Russell King - ARM Linux wrote:
This is work in progress.
We have two SoCs using SRAM, both with their
Hi Russell,
[CC Paul Mundt]
On Sat, Apr 16, 2011 at 12:41 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Apr 15, 2011 at 09:32:01AM -0600, Grant Likely wrote:
Yes, once the infrastructure is in place, powerpc can do its own
migration to the new code. I vote for putting it
32 matches
Mail list logo
