From: Brian Norris <computersforpeace@gmail.com>
To: Simon Falsig <simon@newtec.dk>
Cc: linux-mtd@lists.infradead.org, Vignesh R <vigneshr@ti.com>
Subject: Re: mmap support for m25p80 device
Date: Tue, 17 Nov 2015 18:15:03 -0800 [thread overview]
Message-ID: <20151118021503.GA140057@google.com> (raw)
In-Reply-To: <9d83b70759c3d2507200432b4ff162be@mail.gmail.com>
+ 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/
next prev parent reply other threads:[~2015-11-18 2:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-20 14:31 mmap support for m25p80 device Simon Falsig
2015-11-18 2:15 ` Brian Norris [this message]
2015-11-19 21:31 ` Brian Norris
2015-11-20 8:41 ` Philippe De Muyter
2015-11-21 0:12 ` Brian Norris
2015-11-20 4:08 ` Vignesh R
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151118021503.GA140057@google.com \
--to=computersforpeace@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=simon@newtec.dk \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.