All of lore.kernel.org
 help / color / mirror / Atom feed
* slram on mapped ram areas
@ 2014-10-09 16:17 dwalker
  2014-10-21  0:05 ` Brian Norris
  0 siblings, 1 reply; 3+ messages in thread
From: dwalker @ 2014-10-09 16:17 UTC (permalink / raw)
  To: Jochen Schaeuble; +Cc: linux-mtd, Joern Engel

Hi,

It seems that slram was made for access parts of memory not used by the system,
or not mapped (right terminology?). I wanted to use it on memory which is mapped
or memory that can be used by the system. The problem I have is that the system I
work on places a filesystem image in memory someplace, and send the physical address
and size of the area as boot parameters. The memory where the images ends up is not
special memory.

I made the following changes to your driver (somewhat condensed),

1) Added memblock_reserve() on the memory region
2) Added an insert_resource() call to the memory
3) Altered the driver to not use ioremap, instead use __va() conditionally.

This worked. I was able to access the memory via the typical mtd
userspace interface.

So is this something acceptable to add to the slram driver?

Should it go someplace else?

Does the functionality to do this exists someplace already ?

I just wanted to send out feelers before I send any patches..

Daniel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: slram on mapped ram areas
  2014-10-09 16:17 slram on mapped ram areas dwalker
@ 2014-10-21  0:05 ` Brian Norris
  2014-10-22 15:32   ` dwalker
  0 siblings, 1 reply; 3+ messages in thread
From: Brian Norris @ 2014-10-21  0:05 UTC (permalink / raw)
  To: dwalker; +Cc: Joern Engel, linux-mtd, Jochen Schaeuble

On Thu, Oct 9, 2014 at 9:17 AM,  <dwalker@fifo99.com> wrote:
> Hi,
>
> It seems that slram was made for access parts of memory not used by the system,
> or not mapped (right terminology?). I wanted to use it on memory which is mapped
> or memory that can be used by the system. The problem I have is that the system I
> work on places a filesystem image in memory someplace, and send the physical address
> and size of the area as boot parameters. The memory where the images ends up is not
> special memory.

I honestly don't know much about the slram.c driver. I doubt it has
many serious users these days.

It also seems like you're really trying to use this driver in a way it
was not designed. Do you really need to access specific kernel memory?
Or do you just want a RAM-backed MTD? There are other drivers for this
already (mtdram?).

> I made the following changes to your driver (somewhat condensed),
>
> 1) Added memblock_reserve() on the memory region
> 2) Added an insert_resource() call to the memory
> 3) Altered the driver to not use ioremap, instead use __va() conditionally.

I see this comment next to the __va() definition for ARM:

/*
 * Drivers should NOT use these either.
 */

> This worked. I was able to access the memory via the typical mtd
> userspace interface.
>
> So is this something acceptable to add to the slram driver?
>
> Should it go someplace else?
>
> Does the functionality to do this exists someplace already ?
>
> I just wanted to send out feelers before I send any patches..

Brian

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: slram on mapped ram areas
  2014-10-21  0:05 ` Brian Norris
@ 2014-10-22 15:32   ` dwalker
  0 siblings, 0 replies; 3+ messages in thread
From: dwalker @ 2014-10-22 15:32 UTC (permalink / raw)
  To: Brian Norris; +Cc: linux-mtd

On Mon, Oct 20, 2014 at 05:05:56PM -0700, Brian Norris wrote:
> On Thu, Oct 9, 2014 at 9:17 AM,  <dwalker@fifo99.com> wrote:
> > Hi,
> >
> > It seems that slram was made for access parts of memory not used by the system,
> > or not mapped (right terminology?). I wanted to use it on memory which is mapped
> > or memory that can be used by the system. The problem I have is that the system I
> > work on places a filesystem image in memory someplace, and send the physical address
> > and size of the area as boot parameters. The memory where the images ends up is not
> > special memory.
> 
> I honestly don't know much about the slram.c driver. I doubt it has
> many serious users these days.

Seems that way since both people I emailed have dead addresses.
 
> It also seems like you're really trying to use this driver in a way it
> was not designed. Do you really need to access specific kernel memory?
> Or do you just want a RAM-backed MTD? There are other drivers for this
> already (mtdram?).

It's not very different from how it's currently used. The only difference is the memory I want to use
could be used by the kernel at the time I want to use it.

I need to access a specific memory area, no random area will do. I looked at drivers/block/brd.c for example
it doesn't allow a specific area to be used.

> > I made the following changes to your driver (somewhat condensed),
> >
> > 1) Added memblock_reserve() on the memory region
> > 2) Added an insert_resource() call to the memory
> > 3) Altered the driver to not use ioremap, instead use __va() conditionally.
> 
> I see this comment next to the __va() definition for ARM:
> 
> /*
>  * Drivers should NOT use these either.
>  */

That's interesting, there must be an alternative.. I just need a way to convert the address from
physical to virtual.

Daniel

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2014-10-22 15:33 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-09 16:17 slram on mapped ram areas dwalker
2014-10-21  0:05 ` Brian Norris
2014-10-22 15:32   ` dwalker

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.