* Tomi Valkeinen [110419 17:13]:
> Hi Tony and Russell,
>
> On Mon, 2011-04-18 at 11:17 +0300, Tony Lindgren wrote:
> > * Tomi Valkeinen [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 p
Hi Tony and Russell,
On Mon, 2011-04-18 at 11:17 +0300, Tony Lindgren wrote:
> * Tomi Valkeinen [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 Russell's tree along wi
2011/4/15 Russell King - ARM Linux :
> 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.
Grea
* Tomi Valkeinen [110418 09:57]:
> On Mon, 2011-04-18 at 09:48 +0300, Tony Lindgren wrote:
> > * Russell King - ARM Linux [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
> > > > >
> > > > > Thi
On Mon, 2011-04-18 at 09:48 +0300, Tony Lindgren wrote:
> * Russell King - ARM Linux [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 Davinc
* Russell King - ARM Linux [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 the physical
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 stuff
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
> 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
On Fri, Apr 15, 2011 at 9:06 PM, 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-implementi
Hi Russell,
[CC Paul Mundt]
On Sat, Apr 16, 2011 at 12:41 AM, 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
>>
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
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 funct
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 into the SRAM.
I havn't checked the details, but maybe the code in
arch
el.org; linux-arm-ker...@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]
&g
in Hilman; davinci-linux-open-sou...@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 05:20:45PM +0100, Russell King - ARM Linux wr
el.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, that's
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 thi
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 ph
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
> > >t
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 expe
nci-linux-open-sou...@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
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
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 S
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 agree
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 9:26 AM, Russell King - ARM Linux
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.
>> > >
>> > > We
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,
> > >
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
> > --- a/arch/arm/p
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 mo
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 IR
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 unsi
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.
32 matches
Mail list logo
