Hi,
On 15 April 2011 12:34, David Vrabel david.vra...@csr.com wrote:
On 06/04/11 20:07, Per Forlin wrote:
Previously there has only been one function mmc_wait_for_req
to start and wait for a request. This patch adds
* mmc_start_req - starts a request wihtout waiting
* mmc_wait_for_req_done
On 17 April 2011 09:09, Lin Tony-B19295 b19...@freescale.com wrote:
Hi Per
Just have a glance of your patch, good thinking. But I have a question
about this patch. You modified mmc_test to test your driver. Does it mean
your driver's performance enhancement depends on application?
I
On 17 April 2011 17:46, Shawn Guo shawn@freescale.com wrote:
On Wed, Apr 06, 2011 at 09:07:04PM +0200, Per Forlin wrote:
[...]
+static int mmc_test_rw_multiple(struct mmc_test_card *test,
+ struct mmc_test_multiple_rw *tdata,
+
On 17 April 2011 18:33, Shawn Guo shawn@linaro.org wrote:
pre_req() runs dma_map_sg() post_req() runs dma_unmap_sg.
If not calling pre_req() before mxs_mmc_request(), request()
will prepare the cache just like it did it before.
It is optional to use pre_req() and post_req().
On 17 April 2011 18:48, Shawn Guo shawn@freescale.com wrote:
On Mon, Apr 18, 2011 at 12:33:30AM +0800, Shawn Guo wrote:
pre_req() runs dma_map_sg() post_req() runs dma_unmap_sg.
If not calling pre_req() before mxs_mmc_request(), request()
will prepare the cache just like it did it before.
On Wed, Apr 20, 2011 at 09:58:48AM +0200, Per Forlin wrote:
static struct dma_async_tx_descriptor *mxs_mmc_prep_dma(
struct mxs_mmc_host *host, unsigned int append)
{
@@ -312,8 +342,8 @@ static struct dma_async_tx_descriptor *mxs_mmc_prep_dma(
if (data) {
On 16 April 2011 17:48, Shawn Guo shawn@freescale.com wrote:
Hi Per,
On Wed, Apr 06, 2011 at 09:07:01PM +0200, Per Forlin wrote:
[...]
Per Forlin (12):
mmc: add none blocking mmc request function
mmc: mmc_test: add debugfs file to list all tests
mmc: mmc_test: add test for none
V3
[01/11]: Set bit 24 and bit 28 of OCR within mmc_sd_get_cid(),
and only retry sending ACMD41 with bit 24 reset in case
signal voltage switch procedure fails.
[01/11]: Change (*rocr 0x4100) to ((*rocr 0x4100) ==
0x4100) to check for both CCS and S18A
SD cards which conform to Physical Layer Spec v3.01 can support
additional Bus Speed Modes, Driver Strength, and Current Limit
other than the default values. We use CMD6 mode 0 to read these
additional card functions. The values read here will be used
during UHS-I initialization steps.
This patch adds support for setting driver strength during UHS-I
initialization prcedure. Since UHS-I cards set S18A (bit 24) in
response to ACMD41, we use this as a base for UHS-I initialization.
We modify the parameter list of mmc_sd_get_cid() so that we can
save the ROCR from ACMD41 to check
As per Host Controller spec v3.00, we reset SDCLK before setting
High Speed Enable, and then set it back to avoid generating clock
gliches. Before enabling SDCLK again, we make sure the clock is
stable, so we use sdhci_set_clock().
Signed-off-by: Arindam Nath arindam.n...@amd.com
---
This patch adds support for setting UHS-I bus speed mode during UHS-I
initialization procedure. Since both the host and card can support
more than one bus speed, we select the highest speed based on both of
their capabilities. First we set the bus speed mode for the card using
CMD6 mode 1, and
We decide on the current limit to be set for the card based on the
Capability of Host Controller to provide current at 1.8V signalling,
and the maximum current limit of the card as indicated by CMD6
mode 0. We then set the current limit for the card using CMD6 mode 1.
As per the Physical Layer
Since only UHS-I cards respond with S18A set in response to ACMD41,
we set the card as ultra-high-speed after successfull initialization.
We need to decide whether a card is SDXC based on the C_SIZE field
of CSDv2.0 register. According to Physical Layer spec v3.01, the
minimum value of C_SIZE for
Host Controller needs tuning during initialization to operate SDR50
and SDR104 UHS-I cards. Whether SDR50 mode actually needs tuning is
indicated by bit 45 of the Host Controller Capabilities register.
A new command CMD19 has been defined in the Physical Layer spec
v3.01 to request the card to
According to the Host Controller spec v3.00, setting Preset Value Enable
in the Host Control2 register lets SDCLK Frequency Select, Clock Generator
Select and Driver Strength Select to be set automatically by the Host
Controller based on the UHS-I mode set. This patch enables this feature.
We also
Host Controller v3.00 supports programmable clock mode as an optional
feature. The support for this mode is indicated by non-zero value in
bits 48-55 of the Capabilities register. If supported, the actual
value of Clock Multiplier is one more than the value provided in the
bit fields. We only set
On 6 April 2011 21:07, Per Forlin per.for...@linaro.org wrote:
Change mmc_blk_issue_rw_rq() to become asynchronous.
The execution flow looks like this:
The mmc-queue calls issue_rw_rq(), which sends the request
to the host and returns back to the mmc-queue. The mmc-queue calls
isuue_rw_rq()
pre_req() runs dma_map_sg() post_req() runs dma_unmap_sg.
If not calling pre_req() before mxs_mmc_request(), request()
will prepare the cache just like it did it before.
It is optional to use pre_req() and post_req().
Signed-off-by: Shawn Guo shawn@linaro.org
---
Changes since v1:
* Get
On Wed, Apr 20, 2011 at 10:01:22AM +0200, Per Forlin wrote:
On 17 April 2011 18:48, Shawn Guo shawn@freescale.com wrote:
On Mon, Apr 18, 2011 at 12:33:30AM +0800, Shawn Guo wrote:
pre_req() runs dma_map_sg() post_req() runs dma_unmap_sg.
If not calling pre_req() before
On Wed, 20 Apr 2011, Guennadi Liakhovetski wrote:
As I said above - I did mean probe() and remove(). Now, I have now traced
down the cause of my problem. In dd.c::driver_probe_device():
pm_runtime_get_noresume(dev);
pm_runtime_barrier(dev);
ret = really_probe(dev, drv);
On 20 April 2011 16:01, Shawn Guo shawn@freescale.com wrote:
On Wed, Apr 20, 2011 at 10:01:22AM +0200, Per Forlin wrote:
On 17 April 2011 18:48, Shawn Guo shawn@freescale.com wrote:
On Mon, Apr 18, 2011 at 12:33:30AM +0800, Shawn Guo wrote:
pre_req() runs dma_map_sg() post_req() runs
On 20 April 2011 16:01, Shawn Guo shawn@freescale.com wrote:
On Wed, Apr 20, 2011 at 10:01:22AM +0200, Per Forlin wrote:
On 17 April 2011 18:48, Shawn Guo shawn@freescale.com wrote:
On Mon, Apr 18, 2011 at 12:33:30AM +0800, Shawn Guo wrote:
pre_req() runs dma_map_sg() post_req() runs
Chris,
Have you had the chance to look at v6 of this patch? If so, what do you
think?
John
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi John,
On Wed, Apr 20 2011, John Calixto wrote:
Have you had the chance to look at v6 of this patch? If so, what do you
think?
Looks good to me. Since Arnd's been reviewing, it'd be nice to get a
Reviewed-by: tag from him and acknowledgement that his concerns are all
addressed, and then
2011/4/14 John Calixto john.cali...@modsystems.com:
[...]
+ /* DAT buffer */
+ __u32 data_ptr_size; /* size of the *pointer* */
+ __u64 data_ptr;
So... again... What's the problem with anonymous union of pointer and u64?
Example implementation:
struct mmc_ioc_cmd {
...
Hi Michal,
On Wed, 20 Apr 2011, Michał Mirosław wrote:
So... again... What's the problem with anonymous union of pointer and u64?
As Arnd pointed out, this would not work for big endian machines.
John
W dniu 20 kwietnia 2011 19:38 użytkownik John Calixto
john.cali...@modsystems.com napisał:
Hi Michal,
On Wed, 20 Apr 2011, Michał Mirosław wrote:
So... again... What's the problem with anonymous union of pointer and u64?
As Arnd pointed out, this would not work for big endian machines.
W dniu 20 kwietnia 2011 19:31 użytkownik Michał Mirosław
mir...@gmail.com napisał:
2011/4/14 John Calixto john.cali...@modsystems.com:
[...]
+ /* DAT buffer */
+ __u32 data_ptr_size; /* size of the *pointer* */
+ __u64 data_ptr;
So... again... What's the problem with
Fix tmio MMC_POWER_UP invocation which had been broken in linux-2.6.39-rc1. In
tmio_mmc_set_ios() an affirmative test for ios-clock == 0 executes the
MMC_POWER_OFF block regardless of ios-power_mode. Because mmc_power_up()
invokes MMC_POWER_UP before setting ios-clock, tmio_mmc_set_ios() turns
Hi Michał,
On Wed, 20 Apr 2011, Michał Mirosław wrote:
Hmm. This might be even better:
static int mmc_blk_ioctl(struct block_device *bdev, fmode_t mode,
unsigned int cmd, unsigned long arg)
{
struct mmc_ioc_cmd blk;
if (cmd != MMC_IOC_CMD)
return -EINVAL;
On Wednesday 20 April 2011 21:06:49 John Calixto wrote:
On Wed, 20 Apr 2011, Michał Mirosław wrote:
Hmm. This might be even better:
static int mmc_blk_ioctl(struct block_device *bdev, fmode_t mode,
unsigned int cmd, unsigned long arg)
{
struct mmc_ioc_cmd blk;
if (cmd !=
Hi Arnd,
On Wed, 20 Apr 2011, Arnd Bergmann wrote:
No need for a union or a ptr_size member in the struct. Just use
a single __u64 and let the user cast the pointer to that. This
will work on all architectures.
However, I still think it should be implemented in compat_ioctl()
because
On Wednesday 20 April 2011 21:34:20 John Calixto wrote:
On Wed, 20 Apr 2011, Arnd Bergmann wrote:
No need for a union or a ptr_size member in the struct. Just use
a single __u64 and let the user cast the pointer to that. This
will work on all architectures.
However, I still think
2011/4/20 Arnd Bergmann a...@arndb.de:
On Wednesday 20 April 2011 21:06:49 John Calixto wrote:
On Wed, 20 Apr 2011, Michał Mirosław wrote:
Hmm. This might be even better:
static int mmc_blk_ioctl(struct block_device *bdev, fmode_t mode,
unsigned int cmd, unsigned long arg)
{
struct
[Added linux-pm to the CC list.]
On Wednesday, April 20, 2011, Alan Stern wrote:
On Wed, 20 Apr 2011, Guennadi Liakhovetski wrote:
...
Ah, now I see the problem. It looks like we did not give sufficient
thought to the case where a device starts off (and therefore should
finish up) in a
On Wed, 20 Apr 2011, Michał Mirosław wrote:
I'm okay with the anon union + ``compat_ptr(*(u32 *))`` part of your
solution. If everyone else thinks it is reasonable, I'll submit a v7
with it.
No need for a union or a ptr_size member in the struct. Just use
a single __u64 and let the user
On Wednesday, April 20, 2011, Alan Stern wrote:
On Wed, 20 Apr 2011, Rafael J. Wysocki wrote:
On Wednesday, April 20, 2011, Alan Stern wrote:
On Wed, 20 Apr 2011, Guennadi Liakhovetski wrote:
...
Ah, now I see the problem. It looks like we did not give sufficient
thought to the
Hi John,
On Wed, Apr 20 2011, John Calixto wrote:
Do you have a preference here? I do not have a preference. On the one
hand, not having the union makes for a cleaner-to-read struct. On the
other hand, not having to cast the pointer in 32-bit userspace is nice
especially since I foresee
Hi Andrei,
On Mon, Apr 11 2011, Andrei Warkentin wrote:
Allows device MMC boot partitions to be accessed. MMC partitions
are treated effectively as separate block devices on the same
MMC card.
Booted this with a Sandisk SEM04G eMMC:
[2.469921] mmcblk0boot0: mmc2:0001 SEM04G partition 1
Hi,
On Wed, Apr 20 2011, Chris Ball wrote:
On Mon, Apr 11 2011, Andrei Warkentin wrote:
Allows device MMC boot partitions to be accessed. MMC partitions
are treated effectively as separate block devices on the same
MMC card.
Booted this with a Sandisk SEM04G eMMC:
[2.469921]
Hi,
On Sat, Apr 16 2011, Andrei Warkentin wrote:
This is the third version of the CMD23 plumbing and host driver support
patch set.
Changes:
1) CMD23 support (used for features such as reliable writes) is decoupled
from general multiblock trans through use of a quirk for affected cards.
Hi Chris.
Chris Ball wrote:
Hi Andrei,
On Mon, Apr 11 2011, Andrei Warkentin wrote:
Allows device MMC boot partitions to be accessed. MMC partitions
are treated effectively as separate block devices on the same
MMC card.
Booted this with a Sandisk SEM04G eMMC:
[2.469921]
Chris,
I have also seen this on mmc-next.
[2.489403] mmcblk0boot1: unknown partition table
[2.495921] mmcblk0boot0: unknown partition table
Aren't these the hidden partitions ? Only available at boot time?
I need to apply my patch to reset the boot partition -- or is that now
On Wednesday 20 April 2011 21:46:04 Michał Mirosław wrote:
2011/4/20 Arnd Bergmann a...@arndb.de:
No, please don't try to invent random new ways of doing this.
Your example relies on the assumption that the task is calling
the entry point for its native word size. Some architectures
Hi,
On Thu, Apr 21 2011, Philip Rakity wrote:
Aren't these the hidden partitions ? Only available at boot time?
Yes, it's the previously-hidden boot partitions -- Andrei's patch
exposes them to Linux.
I need to apply my patch to reset the boot partition -- or is that now
in mmc-next
Your
On Thu, Apr 21, 2011 at 12:22 AM, Chris Ball c...@laptop.org wrote:
Hi,
On Thu, Apr 21 2011, Philip Rakity wrote:
Aren't these the hidden partitions ? Only available at boot time?
Yes, it's the previously-hidden boot partitions -- Andrei's patch
exposes them to Linux.
I need to apply my
47 matches
Mail list logo
