On Sat, Sep 7, 2013 at 9:21 AM, Ard Biesheuvel
wrote:
> On 6 September 2013 21:32, Russ Dill wrote:
>> On Fri, Sep 6, 2013 at 4:12 AM, Russell King - ARM Linux
>> wrote:
>>> On Tue, Sep 03, 2013 at 09:44:21AM -0700, Russ Dill wrote:
SRAM handling code is in the process of being moved from a
On 6 September 2013 21:32, Russ Dill wrote:
> On Fri, Sep 6, 2013 at 4:12 AM, Russell King - ARM Linux
> wrote:
>> On Tue, Sep 03, 2013 at 09:44:21AM -0700, Russ Dill wrote:
>>> SRAM handling code is in the process of being moved from arch directories
>>> into drivers/misc/sram.c using device tre
On Fri, Sep 06, 2013 at 05:40:59PM +0100, Dave Martin wrote:
> I actually wonder whether fncpy() contains a buglet, whereby
> flush_icache_range() is used instead of coherent_kern_range().
> The SRAM is probably not mapped cached, but at least a DSB would be
> needed before flushing the relevant li
On Fri, Sep 6, 2013 at 9:19 AM, Dave Martin wrote:
> On Fri, Sep 06, 2013 at 12:12:21PM +0100, Russell King - ARM Linux wrote:
>> On Tue, Sep 03, 2013 at 09:44:21AM -0700, Russ Dill wrote:
>> > SRAM handling code is in the process of being moved from arch directories
>> > into drivers/misc/sram.c
On Fri, Sep 6, 2013 at 4:12 AM, Russell King - ARM Linux
wrote:
> On Tue, Sep 03, 2013 at 09:44:21AM -0700, Russ Dill wrote:
>> SRAM handling code is in the process of being moved from arch directories
>> into drivers/misc/sram.c using device tree and genalloc [1] [2]. This RFC
>> patchset builds
On Fri, Sep 6, 2013 at 9:40 AM, Dave Martin wrote:
> On Fri, Sep 06, 2013 at 12:14:08PM +0100, Russell King - ARM Linux wrote:
>> On Wed, Sep 04, 2013 at 02:47:51PM -0700, Russ Dill wrote:
>> > I think this is already taken care of by the way sram.c is using
>> > genalloc. The allocation returned
On Fri, Sep 6, 2013 at 4:14 AM, Russell King - ARM Linux
wrote:
> On Wed, Sep 04, 2013 at 02:47:51PM -0700, Russ Dill wrote:
>> I think this is already taken care of by the way sram.c is using
>> genalloc. The allocation returned should be aligned to 32 bytes. The
>> thumb bit shouldn't be an issu
On Fri, Sep 06, 2013 at 12:12:21PM +0100, Russell King - ARM Linux wrote:
> On Tue, Sep 03, 2013 at 09:44:21AM -0700, Russ Dill wrote:
> > SRAM handling code is in the process of being moved from arch directories
> > into drivers/misc/sram.c using device tree and genalloc [1] [2]. This RFC
> > patc
On Fri, Sep 06, 2013 at 12:14:08PM +0100, Russell King - ARM Linux wrote:
> On Wed, Sep 04, 2013 at 02:47:51PM -0700, Russ Dill wrote:
> > I think this is already taken care of by the way sram.c is using
> > genalloc. The allocation returned should be aligned to 32 bytes. The
> > thumb bit shouldn'
On Wed, Sep 04, 2013 at 02:47:51PM -0700, Russ Dill wrote:
> I think this is already taken care of by the way sram.c is using
> genalloc. The allocation returned should be aligned to 32 bytes. The
> thumb bit shouldn't be an issue as code is copied based on the start
> and end makers made by the li
On Tue, Sep 03, 2013 at 09:44:21AM -0700, Russ Dill wrote:
> SRAM handling code is in the process of being moved from arch directories
> into drivers/misc/sram.c using device tree and genalloc [1] [2]. This RFC
> patchset builds on that, including the limitation that the SRAM address is
> not known
On Thursday 05 September 2013 03:17 AM, Russ Dill wrote:
> On Wed, Sep 4, 2013 at 12:52 PM, Emilio López wrote:
>> I'm interested in this, as I'll need something like it for suspend/resume on
>> sunxi. Unfortunately, I only got the cover letter on my email, and the web
>> lakml archives don't see
On Wed, Sep 4, 2013 at 12:52 PM, Emilio López wrote:
> Hi,
>
> El 03/09/13 13:44, Russ Dill escribió:
>
>> This RFC patchset explores an idea for loading C code into SRAM.
>> Currently, all the code I'm aware of that needs to run from SRAM is
>> written
>> in assembler. The most common reason for
Hi,
El 03/09/13 13:44, Russ Dill escribió:
This RFC patchset explores an idea for loading C code into SRAM.
Currently, all the code I'm aware of that needs to run from SRAM is written
in assembler. The most common reason for code needing to run from SRAM is
that the memory controller is being di
This RFC patchset explores an idea for loading C code into SRAM.
Currently, all the code I'm aware of that needs to run from SRAM is written
in assembler. The most common reason for code needing to run from SRAM is
that the memory controller is being disabled/ enabled or is already
disabled. arch/a
15 matches
Mail list logo