Folks - I'm wondering what this list thinks of making a change to the mmc
driver to make use the the High Priority Interrupt (HPI) feature that was added
in the eMMC 4.41 spec to give priority to reads over writes. Part of this
could be writing a custom i/o scheduler that just resorts the reque
At the back of the document is a change list for each revision. On the 84-A44
spec I have it is Annex B, on page 209.
Charles Johnson
Ultra-Mobility Group
UPSG Architecture
Intel Corporation
charles.f.john...@intel.com
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:
Looking at the sdcard.org site, it appears that they have not published an
updated "Simplified" spec. Does anyone know, will that be required in order to
make the Linux MMC/SD drivers to support SD 3.0 cards ??
Charles Johnson
Intel Corporation
charles.f.john...@intel.com
--
To unsubscribe fr
Given that JEDEC is spec'ing UFS which appears to be the follow-on to eMMC,
does anyone know if any driver work has started on this ??
With SCSI over Unipro - I would expect a Unipro transport driver to be added to
the SCSI subsystem ? Any thoughts?
Charles Johnson
Ultra-Mobility Group
UPSG Arch
o:spy...@gmail.com] On Behalf Of Ian Molton
Sent: Tuesday, October 13, 2009 2:29 PM
To: Johnson, Charles F
Subject: Re: RFC: Shared eMMC Controller
I cant see that being a problem. I wonder how fine grained the access
would be though - having mounted filesystems would mean that the other
systtem
I'm working on a system where we have a need to share the eMMC host controller
with both the main CPU and a micro-controller. So to coodinate access we need
to define a mutex mechanism between the two. This is possible since there is
some shared non-cachable static ram that both have access to
I'd like to get some feedback from the eMMC/MMC/SD driver community. We are
considering a design where we need to share the eMMC controller between the
main host CPU and a secondary microcontroller. A hardware mutex would be added
to coordinate access.
My question here is, if we added this thr
