mmap support for m25p80 device

mmap support for m25p80 device

[Simon Falsig]

Hi,

I'm currently working on a new custom board (with a TI AM3356 ARM-Cortex
A8
CPU), with a 32 kB Everspin MR25H256 MRAM chip, attached over SPI. It
works
fine using the m25p80 driver, but I was wondering how complex it would be
to
add the possibility of memory-mapping the device in userspace? - mainly to
make the interface consistent with the board that it is replacing, which
uses
a different, mmap-able, RAM chip.

I'm not very experienced in the deeper aspects of the kernel, but I've
been
poking around a bit in the mtd subsystem, and it seems as if the main
thing
that is missing, is a valid get_unmapped_area() function for the m25p80
driver, and then to change the mtdchar_mmap() function (in mtdchar.c) to
actually allow mmap'ing on MMU systems.

But - does it even make sense to create such a function for m25p80? - and
how would I start?

Any pointers and/or comments are appreciated!
Thanks and best regards,
Simon Falsig
simon@newtec.dk

Re: mmap support for m25p80 device

[Brian Norris]

+ Vignesh

Vignesh is working on supporting mmap'd flash reads in the SPI core,
particularly for the TI QSPI driver. I don't believe he's planning on
exposing this to userspace, though, and I believe that might be pretty
difficult to do now.

Perhaps Vignesh can comment.

On Tue, Oct 20, 2015 at 04:31:20PM +0200, Simon Falsig wrote:
> Hi,
> 
> I'm currently working on a new custom board (with a TI AM3356 ARM-Cortex
> A8
> CPU), with a 32 kB Everspin MR25H256 MRAM chip, attached over SPI. It
> works
> fine using the m25p80 driver, but I was wondering how complex it would be
> to
> add the possibility of memory-mapping the device in userspace? - mainly to
> make the interface consistent with the board that it is replacing, which
> uses
> a different, mmap-able, RAM chip.
> 
> I'm not very experienced in the deeper aspects of the kernel, but I've
> been
> poking around a bit in the mtd subsystem, and it seems as if the main
> thing
> that is missing, is a valid get_unmapped_area() function for the m25p80
> driver, and then to change the mtdchar_mmap() function (in mtdchar.c) to
> actually allow mmap'ing on MMU systems.

It's not quite so simple. Read the comments in mtdchar, and you'll see
that there's some layering bugs that caused us to disable MMU mmap
entirely. Apparently no one cared so far. Read the comments here:

commit f5cf8f07423b2677cebebcebc863af77223a4972
Author: David Woodhouse <David.Woodhouse@intel.com>
Date:   Tue Oct 9 15:08:10 2012 +0100

    mtd: Disable mtdchar mmap on MMU systems

But feel free to fix it.

> But - does it even make sense to create such a function for m25p80? - and
> how would I start?

SPI drivers don't really expose a mmap-able interface, so this isn't
possible at the moment. Even once it can be done, it would be restricted
only to those controllers that can do memory map for you. AIUI, your SoC
might (?).

But even if it supports it, I expect you'll have difficulty coordinating
this properly, since the SPI bus technically can be shared with multiple
devices, whereas mmap would kind of assume that user-space can access
the flash at any time. So I guess m25p80 would have to grab exclusive
access of the entire SPI bus? If your system design can handle that,
then I guess it CAN be done...

...but why do you want to do this, again?

Brian

> Any pointers and/or comments are appreciated!
> Thanks and best regards,
> Simon Falsig
> simon@newtec.dk
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: mmap support for m25p80 device

[Brian Norris]

+ Philippe

On Tue, Nov 17, 2015 at 06:15:03PM -0800, Brian Norris wrote:
> + Vignesh
> 
> Vignesh is working on supporting mmap'd flash reads in the SPI core,
> particularly for the TI QSPI driver. I don't believe he's planning on
> exposing this to userspace, though, and I believe that might be pretty
> difficult to do now.
> 
> Perhaps Vignesh can comment.
> 
> On Tue, Oct 20, 2015 at 04:31:20PM +0200, Simon Falsig wrote:
> > Hi,
> > 
> > I'm currently working on a new custom board (with a TI AM3356 ARM-Cortex
> > A8
> > CPU), with a 32 kB Everspin MR25H256 MRAM chip, attached over SPI. It
> > works
> > fine using the m25p80 driver, but I was wondering how complex it would be
> > to
> > add the possibility of memory-mapping the device in userspace? - mainly to
> > make the interface consistent with the board that it is replacing, which
> > uses
> > a different, mmap-able, RAM chip.
> > 
> > I'm not very experienced in the deeper aspects of the kernel, but I've
> > been
> > poking around a bit in the mtd subsystem, and it seems as if the main
> > thing
> > that is missing, is a valid get_unmapped_area() function for the m25p80
> > driver, and then to change the mtdchar_mmap() function (in mtdchar.c) to
> > actually allow mmap'ing on MMU systems.
> 
> It's not quite so simple. Read the comments in mtdchar, and you'll see
> that there's some layering bugs that caused us to disable MMU mmap
> entirely. Apparently no one cared so far. Read the comments here:
> 
> commit f5cf8f07423b2677cebebcebc863af77223a4972
> Author: David Woodhouse <David.Woodhouse@intel.com>
> Date:   Tue Oct 9 15:08:10 2012 +0100
> 
>     mtd: Disable mtdchar mmap on MMU systems
> 
> But feel free to fix it.

I see there's an old patch that never got reviewed/tested, for doing
this:

http://patchwork.ozlabs.org/patch/327981/

You could check that out.

Brian

> > But - does it even make sense to create such a function for m25p80? - and
> > how would I start?
> 
> SPI drivers don't really expose a mmap-able interface, so this isn't
> possible at the moment. Even once it can be done, it would be restricted
> only to those controllers that can do memory map for you. AIUI, your SoC
> might (?).
> 
> But even if it supports it, I expect you'll have difficulty coordinating
> this properly, since the SPI bus technically can be shared with multiple
> devices, whereas mmap would kind of assume that user-space can access
> the flash at any time. So I guess m25p80 would have to grab exclusive
> access of the entire SPI bus? If your system design can handle that,
> then I guess it CAN be done...
> 
> ...but why do you want to do this, again?
> 
> Brian
> 
> > Any pointers and/or comments are appreciated!
> > Thanks and best regards,
> > Simon Falsig
> > simon@newtec.dk
> > 
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: mmap support for m25p80 device

[Vignesh R]

On 11/18/2015 07:45 AM, Brian Norris wrote:
> + Vignesh
> 
> Vignesh is working on supporting mmap'd flash reads in the SPI core,
> particularly for the TI QSPI driver. I don't believe he's planning on
> exposing this to userspace, though, and I believe that might be pretty
> difficult to do now.
> 
> Perhaps Vignesh can comment.

I have no plans of exposing this to userspace anytime sooner. Supporting
DMA and all types of opcode/address/data combinations are the first steps.

> 
> On Tue, Oct 20, 2015 at 04:31:20PM +0200, Simon Falsig wrote:
>> Hi,
>>
>> I'm currently working on a new custom board (with a TI AM3356 ARM-Cortex
>> A8
>> CPU), with a 32 kB Everspin MR25H256 MRAM chip, attached over SPI. It
>> works
>> fine using the m25p80 driver, but I was wondering how complex it would be
>> to
>> add the possibility of memory-mapping the device in userspace? - mainly to
>> make the interface consistent with the board that it is replacing, which
>> uses
>> a different, mmap-able, RAM chip.
>>
>> I'm not very experienced in the deeper aspects of the kernel, but I've
>> been
>> poking around a bit in the mtd subsystem, and it seems as if the main
>> thing
>> that is missing, is a valid get_unmapped_area() function for the m25p80
>> driver, and then to change the mtdchar_mmap() function (in mtdchar.c) to
>> actually allow mmap'ing on MMU systems.
> 
> It's not quite so simple. Read the comments in mtdchar, and you'll see
> that there's some layering bugs that caused us to disable MMU mmap
> entirely. Apparently no one cared so far. Read the comments here:
> 
> commit f5cf8f07423b2677cebebcebc863af77223a4972
> Author: David Woodhouse <David.Woodhouse@intel.com>
> Date:   Tue Oct 9 15:08:10 2012 +0100
> 
>     mtd: Disable mtdchar mmap on MMU systems
> 
> But feel free to fix it.
> 
>> But - does it even make sense to create such a function for m25p80? - and
>> how would I start?
> 
> SPI drivers don't really expose a mmap-able interface, so this isn't
> possible at the moment. Even once it can be done, it would be restricted
> only to those controllers that can do memory map for you. AIUI, your SoC
> might (?).
> 
> But even if it supports it, I expect you'll have difficulty coordinating
> this properly, since the SPI bus technically can be shared with multiple
> devices, whereas mmap would kind of assume that user-space can access
> the flash at any time. So I guess m25p80 would have to grab exclusive
> access of the entire SPI bus? If your system design can handle that,
> then I guess it CAN be done...
> 
> ...but why do you want to do this, again?
> 
> Brian
> 
>> Any pointers and/or comments are appreciated!
>> Thanks and best regards,
>> Simon Falsig
>> simon@newtec.dk
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/

-- 
Regards
Vignesh

Re: mmap support for m25p80 device

[Philippe De Muyter]

On Thu, Nov 19, 2015 at 01:31:19PM -0800, Brian Norris wrote:
> + Philippe
> 
> On Tue, Nov 17, 2015 at 06:15:03PM -0800, Brian Norris wrote:
> > + Vignesh
> > 
> > Vignesh is working on supporting mmap'd flash reads in the SPI core,
> > particularly for the TI QSPI driver. I don't believe he's planning on
> > exposing this to userspace, though, and I believe that might be pretty
> > difficult to do now.
> > 
> > Perhaps Vignesh can comment.
> > 
> > On Tue, Oct 20, 2015 at 04:31:20PM +0200, Simon Falsig wrote:
> > > Hi,
> > > 
> > > I'm currently working on a new custom board (with a TI AM3356 ARM-Cortex
> > > A8
> > > CPU), with a 32 kB Everspin MR25H256 MRAM chip, attached over SPI. It
> > > works
> > > fine using the m25p80 driver, but I was wondering how complex it would be
> > > to
> > > add the possibility of memory-mapping the device in userspace? - mainly to
> > > make the interface consistent with the board that it is replacing, which
> > > uses
> > > a different, mmap-able, RAM chip.
> > > 
> > > I'm not very experienced in the deeper aspects of the kernel, but I've
> > > been
> > > poking around a bit in the mtd subsystem, and it seems as if the main
> > > thing
> > > that is missing, is a valid get_unmapped_area() function for the m25p80
> > > driver, and then to change the mtdchar_mmap() function (in mtdchar.c) to
> > > actually allow mmap'ing on MMU systems.
> > 
> > It's not quite so simple. Read the comments in mtdchar, and you'll see
> > that there's some layering bugs that caused us to disable MMU mmap
> > entirely. Apparently no one cared so far. Read the comments here:
> > 
> > commit f5cf8f07423b2677cebebcebc863af77223a4972
> > Author: David Woodhouse <David.Woodhouse@intel.com>
> > Date:   Tue Oct 9 15:08:10 2012 +0100
> > 
> >     mtd: Disable mtdchar mmap on MMU systems
> > 
> > But feel free to fix it.
> 
> I see there's an old patch that never got reviewed/tested, for doing
> this:
> 
> http://patchwork.ozlabs.org/patch/327981/

I use that patch to access a battery-back-up'ed SRAM connected to the
WEIM bus of a Freescale i.MX6q ARM processor, and it works perfectly for
that.  On that processor, the WEIM bus maps the connected peripherals in
the physical memory addresses range, so it is really easy to make that
user-accessible through mmap.  Only the above patch was needed.

Philippe

> 
> You could check that out.
> 
> Brian
> 
> > > But - does it even make sense to create such a function for m25p80? - and
> > > how would I start?
> > 
> > SPI drivers don't really expose a mmap-able interface, so this isn't
> > possible at the moment. Even once it can be done, it would be restricted
> > only to those controllers that can do memory map for you. AIUI, your SoC
> > might (?).
> > 
> > But even if it supports it, I expect you'll have difficulty coordinating
> > this properly, since the SPI bus technically can be shared with multiple
> > devices, whereas mmap would kind of assume that user-space can access
> > the flash at any time. So I guess m25p80 would have to grab exclusive
> > access of the entire SPI bus? If your system design can handle that,
> > then I guess it CAN be done...
> > 
> > ...but why do you want to do this, again?
> > 
> > Brian
> > 
> > > Any pointers and/or comments are appreciated!
> > > Thanks and best regards,
> > > Simon Falsig
> > > simon@newtec.dk
> > > 
> > > ______________________________________________________
> > > Linux MTD discussion mailing list
> > > http://lists.infradead.org/mailman/listinfo/linux-mtd/

-- 
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles

Re: mmap support for m25p80 device

[Brian Norris]

On Fri, Nov 20, 2015 at 09:41:52AM +0100, Philippe De Muyter wrote:
> On Thu, Nov 19, 2015 at 01:31:19PM -0800, Brian Norris wrote:
> > On Tue, Nov 17, 2015 at 06:15:03PM -0800, Brian Norris wrote:
> > > It's not quite so simple. Read the comments in mtdchar, and you'll see
> > > that there's some layering bugs that caused us to disable MMU mmap
> > > entirely. Apparently no one cared so far. Read the comments here:
> > > 
> > > commit f5cf8f07423b2677cebebcebc863af77223a4972
> > > Author: David Woodhouse <David.Woodhouse@intel.com>
> > > Date:   Tue Oct 9 15:08:10 2012 +0100
> > > 
> > >     mtd: Disable mtdchar mmap on MMU systems
> > > 
> > > But feel free to fix it.
> > 
> > I see there's an old patch that never got reviewed/tested, for doing
> > this:
> > 
> > http://patchwork.ozlabs.org/patch/327981/
> 
> I use that patch to access a battery-back-up'ed SRAM connected to the
> WEIM bus of a Freescale i.MX6q ARM processor, and it works perfectly for
> that.  On that processor, the WEIM bus maps the connected peripherals in
> the physical memory addresses range, so it is really easy to make that
> user-accessible through mmap.  Only the above patch was needed.

OK, would you mind resending it, so it can get fresh eyes?

Brian