Re: [PATCH] ARM: mmci: add capabilities2 for MMC_CAP2

[Linus Walleij]

On Mon, Nov 14, 2011 at 12:02 PM, Per Forlin  wrote:

Some more verbose blurb on the patch here maybe?

> Signed-off-by: Per Forlin 
> ---
> This patch depends on patches adding CAP2 available on mmc-next.
> Chris, would you mind merging this through your tree when it
> has been accepted.

Seems like the right way to pass caps from the platform.
Acked-by: Linus Walleij 

Yours,
Linus Walleij
--
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

Re: [PATCH] mmc: block: release host in case of error

[Linus Walleij]

On Mon, Nov 14, 2011 at 12:12 PM, Per Forlin  wrote:

> Host is claimed as long as there are requests in the block queue
> and all request are completed successfully. If an error occur release
> the host in case someone else needs to claim it, for instance if the card
> is removed during a transfer.
>
> Signed-off-by: Per Forlin 

Acked-by: Linus Walleij 

Thanks,
Linus Walleij
--
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

RE: [PATCH RESEND V4] mmc: core: HS200 mode support for eMMC 4.5

[Subhash Jadavani]

Hi Girish,

> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Sahitya Tummala
> Sent: Tuesday, November 08, 2011 2:10 PM
> To: Girish K S
> Cc: linux-mmc@vger.kernel.org; c...@laptop.org; patc...@linaro.org;
> linux-samsung-...@vger.kernel.org
> Subject: Re: [PATCH RESEND V4] mmc: core: HS200 mode support for eMMC
> 4.5
> 
> Hi Girish,
> 
> On 10/26/2011 10:29 AM, Girish K S wrote:
> > This patch adds the support of the HS200 bus speed for eMMC 4.5
> devices.
> > The eMMC 4.5 devices have support for 200MHz bus speed.The mmc core
> and
> > host modules have been touched to add support for this module.
> >
> > It is necessary to know the card type in the sdhci.c file to add
> support
> > for eMMC tuning function. So card.h file is included to import the
> card
> > data structure.
> >
> > cc: Chris Ball
> > Signed-off-by: Girish K S
> > ---
> > Changes in v4:
> > Rebased onto chris-mmc/mmc-next branch. This patch is
> successfully
> > applied on commit with id
> de022ed3fdc14808299b2fa66dbb1ed5ab921912.
> > Changes in v3:
> > In the previous commits of chris-mmc/mmc-next branch, the patch
> with
> > commit id (c0f22a2c92e357e7cb3988b0b13034d70b7461f9) defines
> caps2 for
> > more capabilities. This patch version deletes the member
> ext_caps(created
> > in my earlier patch) from struct mmc_host and reuses already
> accepted
> > caps2 member.
> > Changes in v2:
> > Rebased to latest chris-mmc/mmc-next branch. Resolved indentation
> > problems identified in review. This patch has to be applied
> before
> > the patch released for modifying the printk messages.
> > Changes in v1:
> > Case statements in switch that produce same result have
> > been combined to reduce repeated assignments.
> > patch recreated after rebase to chris balls mmc-next branch.
> >
> >   drivers/mmc/core/bus.c|3 +-
> >   drivers/mmc/core/mmc.c|   92
> 
> >   drivers/mmc/host/sdhci.c  |   36 +++---
> >   include/linux/mmc/card.h  |3 +
> >   include/linux/mmc/host.h  |6 +++
> >   include/linux/mmc/mmc.h   |8 +++-
> >   include/linux/mmc/sdhci.h |1 +
> >   7 files changed, 132 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
> > index 46b6e84..2f82f6b 100644
> > --- a/drivers/mmc/core/bus.c
> > +++ b/drivers/mmc/core/bus.c
> > @@ -301,10 +301,11 @@ int mmc_add_card(struct mmc_card *card)
> > mmc_card_ddr_mode(card) ? "DDR " : "",
> > type);
> > } else {
> > -   printk(KERN_INFO "%s: new %s%s%s card at address %04x\n",
> > +   pr_info("%s: new %s%s%s%s card at address %04x\n",
> > mmc_hostname(card->host),
> > mmc_sd_card_uhs(card) ? "ultra high speed " :
> > (mmc_card_highspeed(card) ? "high speed " : ""),
> > +   (mmc_card_hs200(card) ? "HS200 " : ""),
> > mmc_card_ddr_mode(card) ? "DDR " : "",
> > type, card->rca);
> > }
> > diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> > index 3627044..4db248c 100644
> > --- a/drivers/mmc/core/mmc.c
> > +++ b/drivers/mmc/core/mmc.c
> > @@ -285,6 +285,39 @@ static int mmc_read_ext_csd(struct mmc_card
> *card, u8 *ext_csd)
> > }
> > card->ext_csd.raw_card_type = ext_csd[EXT_CSD_CARD_TYPE];
> > switch (ext_csd[EXT_CSD_CARD_TYPE]&  EXT_CSD_CARD_TYPE_MASK) {
> > +   case EXT_CSD_CARD_TYPE_SDR_200 |
> > +EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
> > +   case EXT_CSD_CARD_TYPE_SDR_200 | EXT_CSD_CARD_TYPE_DDR_1_8V |
> > +EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
> > +   case EXT_CSD_CARD_TYPE_SDR_200 | EXT_CSD_CARD_TYPE_DDR_1_2V |
> > +EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
> > +   case EXT_CSD_CARD_TYPE_SDR_200 | EXT_CSD_CARD_TYPE_DDR_52 |
> > +EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
> > +   card->ext_csd.hs_max_dtr = 2;
> > +   card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_200;
> > +   break;
> > +   case EXT_CSD_CARD_TYPE_SDR_1_2V |
> > +EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
> > +   case EXT_CSD_CARD_TYPE_SDR_1_2V | EXT_CSD_CARD_TYPE_DDR_1_8V |
> > +EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
> > +   case EXT_CSD_CARD_TYPE_SDR_1_2V | EXT_CSD_CARD_TYPE_DDR_1_2V |
> > +EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
> > +   case EXT_CSD_CARD_TYPE_SDR_1_2V | EXT_CSD_CARD_TYPE_DDR_52 |
> > +EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
> > +   card->ext_csd.hs_max_dtr = 2;
> > +   card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_1_2V;
> > +   break;
> > +   case EXT_CSD_CARD_TYPE_SDR_1_8V |
> > +EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
> > +   case EXT_CSD_CARD_TYPE_SDR_1_8V | EXT_CSD_CARD_TY

Re: [PATCH] mmc: core: Fix typo at mmc_card_sleep

[Chris Ball]

Hi,

On Wed, Nov 16 2011, Kyungmin Park wrote:
> From: Kyungmin Park 
>
> Fix wrong bus_ops->sleep check.
>
> Signed-off-by: Kyungmin Park 
> ---
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 5278ffb..193e449 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -2196,7 +2196,7 @@ int mmc_card_sleep(struct mmc_host *host)
>  
>   mmc_bus_get(host);
>  
> - if (host->bus_ops && !host->bus_dead && host->bus_ops->awake)
> + if (host->bus_ops && !host->bus_dead && host->bus_ops->sleep)
>   err = host->bus_ops->sleep(host);
>  
>   mmc_bus_put(host);
>

Thanks, applied to mmc-next for 3.2.

(My understanding is that this isn't going to have any real-world
consequences, since the only bus that defines awake or sleep is
core/mmc.c, and it defines both of them.)

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
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

[PATCH] mmc: core: Fix typo at mmc_card_sleep

[Kyungmin Park]

From: Kyungmin Park 

Fix wrong bus_ops->sleep check.

Signed-off-by: Kyungmin Park 
---
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 5278ffb..193e449 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2196,7 +2196,7 @@ int mmc_card_sleep(struct mmc_host *host)
 
mmc_bus_get(host);
 
-   if (host->bus_ops && !host->bus_dead && host->bus_ops->awake)
+   if (host->bus_ops && !host->bus_dead && host->bus_ops->sleep)
err = host->bus_ops->sleep(host);
 
mmc_bus_put(host);
--
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

Re: [PATCH] mmc: block: release host in case of error

[Sujit Reddy Thumma]

On 11/14/2011 4:42 PM, Per Forlin wrote:

Host is claimed as long as there are requests in the block queue
and all request are completed successfully. If an error occur release
the host in case someone else needs to claim it, for instance if the card
is removed during a transfer.

Signed-off-by: Per Forlin
---
  drivers/mmc/card/block.c |   37 +
  1 files changed, 29 insertions(+), 8 deletions(-)


Tested-by: Sujit Reddy Thumma 


Thanks
Sujit

--
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

Re: [PATCH] mmc: mmc_test: align max_seg_size

[Sujit Reddy Thumma]

On 11/14/2011 4:34 PM, Per Forlin wrote:

If max_seg_size is unaligned, mmc_test_map_sg() may create sg element
sizes that are not aligned with 512 byte. Fix, align max_seg_size at
mmc_test_area_init().

Signed-off-by: Per Forlin
---
  drivers/mmc/card/mmc_test.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c
index b038c4a..5848998 100644
--- a/drivers/mmc/card/mmc_test.c
+++ b/drivers/mmc/card/mmc_test.c
@@ -1581,6 +1581,7 @@ static int mmc_test_area_init(struct mmc_test_card *test, 
int erase, int fill)

t->max_segs = test->card->host->max_segs;
t->max_seg_sz = test->card->host->max_seg_size;
+   t->max_seg_sz -= t->max_seg_sz % 512;


Shouldn't we align this to host->max_blk_size supported by controller? I 
guess there are some extended capacity cards which claim to support 
4096bytes as block size. I am not sure if any card/controller supports 
this mode yet.




t->max_tfr = t->max_sz;
if (t->max_tfr>>  9>  test->card->host->max_blk_count)



--
Thanks,
Sujit
--
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

RE: [PATCH] mmc: core: Add packed command for eMMC4.5 device

[Seungwon Jeon]

Maya Erez wrote:
> 
> > +   if (reqs >= 2) {
> > +   mmc_blk_packed_hdr_wrq_prep(mq->mqrq_cur, card, 
> > mq, reqs);
> > +   if (rq_data_dir(rqc) == READ) {
> > +   areq = &mq->mqrq_cur->mmc_active;
> > +   mmc_wait_for_req(card->host, areq->mrq);
> Packing read requests requires preparation of two requests. After sending
> the header we wait for its completion before sending the next request
> (mmc_wait_for_req is used). Therefore, if we try to pack 2 read requests
> we might end up with worse performance in comparison to sending each
> request by itself (which allows the preparation of one request while the
> other is sent).
> I suggest to check the size of the packed commands list and in case it is
> less than 3 send the requests one by one. If you move mmc_blk_chk_packable
> to queue.c after the first fetch this change should be very easy and can
> be done by removing the requests from the packed_list and calling issue_fn
> for each one of them.

Sending header for packed read which doesn't require nand program
unlike normal data, so it may not spend long time.
Which point you think is the overhead of packed two-requests
in comparison to individual request?
> 
> Thanks,
> Maya Erez
> Consultant for Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
> 
> 
> 
> 
> 
> 
> --
> 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

--
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

RE: [PATCH 2/2] mmc: core: Support packed command for eMMC4.5 device

[Seungwon Jeon]

Maya Erez wrote:
> >> >> >> >> > +               phys_segments +=  next->nr_phys_segments;
> >> >> >> >> > +               if (phys_segments > max_phys_segs) {
> >> >> >> >> > +                       blk_requeue_request(q, next);
> >> >> >> >> > +                       break;
> >> >> >> >> > +               }
> >> >> >> >> I mentioned this before - if the next request is not packable
> >> and
> >> >> >> requeued,
> >> >> >> >> blk_fetch_request will retrieve it again and this while loop
> >> will
> >> >> never terminate.
> >> >> >> >>
> >> >> >> > If next request is not packable, it is requeued and 'break'
> >> >> terminates
> >> >> >> this loop.
> >> >> >> > So it not infinite.
> >> >> >> Right !! But that doesn't help finding the commands that are
> >> packable.
> >> >> Ideally, you'd need to pack all neighbouring requests into one packed
> >> >> command.
> >> >> >> The way CFQ works, it is not necessary that the fetch would return
> >> all
> >> >> outstanding
> >> >> >> requests that are packable (unless you invoke a forced dispatch)
> >> It
> >> >> would be good to see some numbers on the number of pack hits /
> >> >> misses
> >> >> >> that
> >> >> >> you would encounter with this logic, on a typical usecase.
> >> >> > Is it considered only for CFQ scheduler? How about other I/O
> >> scheduler?
> >> >> If all requests are drained from scheduler queue forcedly,
> >> >> > the number of candidate to be packed can be increased.
> >> >> > However we may lose the unique CFQ's strength and MMC D/D may take
> >> the
> >> >> CFQ's duty.
> >> >> > Basically, this patch accommodates the origin order requests from
> >> I/O
> >> >> scheduler.
> >> >> >
> >> >>
> >> >> In order to better utilize the packed commands feature and achieve
> >> the
> >> >> best performance improvements I think that the command packing should
> >> be
> >> >> done in the block layer, according to the scheduler policy.
> >> >> That is, the scheduler should be aware of the capability of the
> >> device to
> >> >> receive a request list and its constrains (such as maximum number of
> >> >> requests, max number of sectors etc) and use this information as a
> >>  factor
> >> >> to its algorithm.
> >> >> This way you keep the decision making in the hands of the scheduler
> >> while
> >> >> the MMC layer will only have to send this list as a packed command.
> >> >>
> >> > Yes, it would be another interesting approach.
> >> > Command packing you mentioned means gathering request among same
> >> direction(read/write)?
> >> > Currently I/O scheduler may know device constrains which MMC driver
> >> informs
> >> > with the exception of order information for packed command.
> >> > But I think the dependency of I/O scheduler may be able to come up.
> >> > How can MMC layer treat packed command with I/O scheduler which
> >> doesn't support this?
> >>
> >> The very act of packing presumes some sorting and re-ordering at the
> >> I/O scheduler level.
> >> When no such sorting is done (ex. noop), MMC should resort to
> >> non-packed execution, respecting the system configuration choice.
> >>
> >> Looking deeper into this, I think a better approach would be to set
> >> the prep_rq_fn of the request_queue, with a custom mmc function that
> >> decides if the requests are packable or not, and return a
> >> BLKPREP_DEFER for those that can't be packed.
> >
> > MMC layer anticipates the favorable requests for packing from I/O
> > scheduler.
> > Obviously request order from I/O scheduler might be poor for packing and
> > requests can't be packed.
> > But that doesn't mean mmc layer need to wait a better pack-case.
> > BLKPREP_DEFER may give rise to I/O latency. Top of request will be
> > deferred next time.
> > If request can't be packed, it'd rather be sent at once than delayed
> > by returning a BLKPREP_DEFER for better responsiveness.
> >
> > Thanks.
> > Seungwon Jeon.
> The decision whether a request is packable or not should not be made per
> request, therefore I don't see the need for using req_prep_fn. The MMC
> layer can peek each request and decide if to pack it or not when preparing
> the packed list (as suggested in this patch). The scheduler changes will
> improve the probability of getting a list that can be packed.
> My suggestion for the scheduler change is:
> The block layer will be notified of the packing limits via new queue
> limits (in blk-settings). We can make it generic to allow all kinds of
> requests lists. Example for the new queue limits can be:
> Is_reqs_list_supported
> Max_num_of_read_reqs_in_list
> Max_num_of_write_reqs_in_list
> max_blk_cnt_in_list
> Is_list_interleaved (optional - to support read and write requests to be
> linked together, not the case for eMMC4.5)
> The scheduler, that will have all the required info in the queue limits,
> will be able to decide which requests can be in the same list and move all
> of them to the dispatch queue (in one elevator_dispatch_fn call).

If probability of packing gets higher, it would be

RE: [PATCH 2/2] mmc: core: Support packed command for eMMC4.5 device

[Seungwon Jeon]

Maya Erez wrote:
> >> >>> >> >> > +       if (rqc)
> >> >>> >> >> > +               reqs = mmc_blk_chk_packable(mq, rqc);
> >> >>>
> >> >>> It would be best to keep all the calls to blk_fetch_request in the
> >> same
> >> >>> location. Therefore, I suggest to move the call to
> >> mmc_blk_chk_packable
> >> >>> to
> >> >>> mmc/card/queue.c after the first request is fetched.
> >> >>
> >> >> At the first time, I considered that way.
> >> >> I'll do more, if possible.
> > I considered more.
> > I think that mmc_blk_chk_packable would rather be called only for r/w type
> > than all request type(e.g. discard, flush).
> >
> mmc_blk_chk_packable can check the cmd_flags of the request to verify it's
> not a flush/disacrad etc. In such cases will not pack.
Yes. It must be checked, but omitted.
I already have added this check. It will be applied next.

Thanks,
Seungwon Jeon.
> 
> --
> 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

--
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

Re: [PATCH V4 00/14] add clk_prepare/clk_unprepare to imx drivers

[Richard Zhao]

Hi Sascha,

Would you merge this patch series?

Thanks
Richard 

--
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

[PATCH v3] mmc: support BKOPS feature for eMMC

[Jaehoon Chung]

Enable eMMC background operations (BKOPS) feature.

If URGENT_BKOPS is set after a response, note that BKOPS
are required. After all I/O requests are finished, run
BKOPS if required. Should read/write operations be requested
during BKOPS, first issue HPI to interrupt the ongoing BKOPS
and then service the request.

If you want to enable this feature, set MMC_CAP2_BKOPS.

Future considerations
 * Check BKOPS_LEVEL=1 and start BKOPS in a preventive manner.
 * Interrupt ongoing BKOPS before powering off the card.

Signed-off-by: Jaehoon Chung 
Signed-off-by: Kyungmin Park 
CC: Hanumath Prasad 
---
Changelog V3:
- move the bkops setting's location in mmc_blk_issue_rw_rq
- modify condition checking
- bkops_en is assigned ext_csd[EXT_CSD_BKOPS_EN] instead of "1"
- remove the unused code
- change pr_debug instead of pr_warn in mmc_send_hpi_cmd
- Add the Future consideration suggested by Per

Changelog V2:
- Use EXCEPTION_STATUS instead of URGENT_BKOPS
- Add function to check Exception_status(for eMMC4.5)
- remove unnecessary code.

 drivers/mmc/card/block.c   |   10 +
 drivers/mmc/card/queue.c   |4 ++
 drivers/mmc/core/core.c|   87 
 drivers/mmc/core/mmc.c |8 
 drivers/mmc/core/mmc_ops.c |6 +++-
 include/linux/mmc/card.h   |   12 ++
 include/linux/mmc/core.h   |3 ++
 include/linux/mmc/host.h   |1 +
 include/linux/mmc/mmc.h|   14 +++
 9 files changed, 144 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c80bb6d..9d19ebb 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1188,6 +1188,16 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, 
struct request *rqc)
type = rq_data_dir(req) == READ ? MMC_BLK_READ : MMC_BLK_WRITE;
mmc_queue_bounce_post(mq_rq);
 
+   /*
+* Check BKOPS urgency from each R1 response
+*/
+   if (mmc_card_mmc(card) &&
+   (brq->cmd.resp[0] & R1_EXCEPTION_EVENT)) {
+   if (mmc_is_exception_event(card,
+   EXT_CSD_URGENT_BKOPS))
+   mmc_card_set_need_bkops(card);
+   }
+
switch (status) {
case MMC_BLK_SUCCESS:
case MMC_BLK_PARTIAL:
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index dcad59c..20bb4a5 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -61,6 +61,9 @@ static int mmc_queue_thread(void *d)
spin_unlock_irq(q->queue_lock);
 
if (req || mq->mqrq_prev->req) {
+   if (mmc_card_doing_bkops(mq->card))
+   mmc_interrupt_bkops(mq->card);
+
set_current_state(TASK_RUNNING);
mq->issue_fn(mq, req);
} else {
@@ -68,6 +71,7 @@ static int mmc_queue_thread(void *d)
set_current_state(TASK_RUNNING);
break;
}
+   mmc_start_bkops(mq->card);
up(&mq->thread_sem);
schedule();
down(&mq->thread_sem);
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 7ee2e07..2d2f1d5 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -238,6 +238,50 @@ mmc_start_request(struct mmc_host *host, struct 
mmc_request *mrq)
host->ops->request(host, mrq);
 }
 
+/**
+ * mmc_start_bkops - start BKOPS for supported cards
+ * @card: MMC card to start BKOPS
+ *
+ * Start background operations whenever requested.
+ * when the urgent BKOPS bit is set in a R1 command response
+ * then background operations should be started immediately.
+*/
+void mmc_start_bkops(struct mmc_card *card)
+{
+   int err;
+   unsigned long flags;
+
+   BUG_ON(!card);
+   if ((!card->ext_csd.bkops_en) ||
+   !(card->host->caps2 & MMC_CAP2_BKOPS))
+   return;
+
+   /*
+* If card is already doing bkops or need for
+* bkops flag is not set, then do nothing just
+* return
+*/
+   if (mmc_card_doing_bkops(card)
+   || !mmc_card_need_bkops(card))
+   return;
+
+   mmc_claim_host(card->host);
+   err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+   EXT_CSD_BKOPS_START, 1, 0);
+   if (err) {
+   pr_warning("error %d starting bkops\n", err);
+   mmc_card_clr_need_bkops(card);
+   goto out;
+   }
+   spin_lock_irqsave(&card->host->lock, flags);
+   mmc_card_clr_need_bkops(card);
+   mmc_card_set_doing_bkops(card);
+   spin_unlock_irqrestore(&card->host->lock, f

Re: [PATCH 3/4] mmc: Logging neatening

[Mike Frysinger]

On Tuesday 15 November 2011 20:48:05 NamJae Jeon wrote:
> 2011/11/16 Joe Perches :
> >mci_writel(host, CTRL, SDMMC_CTRL_INT_ENABLE); /* Enable mci
> > interrupt */
> > 
> > -   dev_info(&pdev->dev, "DW MMC controller at irq %d, "
> > -"%d bit host data width, "
> > -"%u deep fifo\n",
> > +   dev_info(&pdev->dev,
> > +   "DW MMC controller at irq %d, %d bit host data width, %u deep
> > fifo\n", irq, width, fifo_size);
> 
> I think that tab is needed this "DW MMC controller at irq " ?

looks to me like this was the only part you replied to.  could you please snip 
the unrelated context in the future ?  no reason to include ~1700 lines of 
context when you only replying to like ~10 lines.
-mike


signature.asc
Description: This is a digitally signed message part.

RE: Plans to add SD4.0 (UHS-II) support

[Subhash Jadavani]

> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Sachin Nikam
> Sent: Wednesday, November 16, 2011 6:29 PM
> To: linux-mmc@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Plans to add SD4.0 (UHS-II) support
> 
> Hi Folks,
> What are the plans to add SD4.0 (UHS-II) support in mmc driver?

Are there any SD4.0 spec available? I can't find simplified version of the
same from sdcard.org.

> 
> Best Regards,
> Sachin Nikam.
> Sr. Software Engineer.
> NVIDIA, Pune.
> --
> 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

--
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

Plans to add SD4.0 (UHS-II) support

[Sachin Nikam]

Hi Folks,
What are the plans to add SD4.0 (UHS-II) support in mmc driver?

Best Regards,
Sachin Nikam.
Sr. Software Engineer.
NVIDIA, Pune.
--
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

Re: [PATCH] mmc: core: Add packed command for eMMC4.5 device

[merez]

> + if (reqs >= 2) {
> + mmc_blk_packed_hdr_wrq_prep(mq->mqrq_cur, card, 
> mq, reqs);
> + if (rq_data_dir(rqc) == READ) {
> + areq = &mq->mqrq_cur->mmc_active;
> + mmc_wait_for_req(card->host, areq->mrq);
Packing read requests requires preparation of two requests. After sending
the header we wait for its completion before sending the next request
(mmc_wait_for_req is used). Therefore, if we try to pack 2 read requests
we might end up with worse performance in comparison to sending each
request by itself (which allows the preparation of one request while the
other is sent).
I suggest to check the size of the packed commands list and in case it is
less than 3 send the requests one by one. If you move mmc_blk_chk_packable
to queue.c after the first fetch this change should be very easy and can
be done by removing the requests from the packed_list and calling issue_fn
for each one of them.

Thanks,
Maya Erez
Consultant for Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum






--
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

Re: [PATCH] mmc: core: Add packed command for eMMC4.5 device

[Sahitya Tummala]

Hi,

On 10/27/2011 4:24 PM, Seungwon Jeon wrote:


+static int mmc_blk_packed_err_check(struct mmc_card *card,
+struct mmc_async_req *areq)
+{
+   struct mmc_queue_req *mq_mrq = container_of(areq, struct mmc_queue_req,
+   mmc_active);
+   int err, check, status;
+   u8 ext_csd[512];
+
+   check = mmc_blk_err_check(card, areq);
+
+   if (check == MMC_BLK_SUCCESS)
+   return check;
+
+   if (check == MMC_BLK_PARTIAL) {
+   err = get_card_status(card,&status, 0);
+   if (err)
+   return MMC_BLK_ABORT;
+
+   if (status&  R1_EXP_EVENT) {
+   err = mmc_send_ext_csd(card, ext_csd);
+   if (err)
+   return MMC_BLK_ABORT;
+
+   if ((ext_csd[EXT_CSD_EXP_EVENTS_STATUS + 0]&
+   EXT_CSD_PACKED_FAILURE)&&
+   (ext_csd[EXT_CSD_PACKED_CMD_STATUS]&
+EXT_CSD_PACKED_GENERIC_ERROR)) {
+   if (ext_csd[EXT_CSD_PACKED_CMD_STATUS]&
+   EXT_CSD_PACKED_INDEXED_ERROR) {
+   /* Make be 0-based */
+   mq_mrq->packed_fail_idx =
+   
ext_csd[EXT_CSD_PACKED_FAILURE_INDEX] - 1;
+   return MMC_BLK_PARTIAL;
+   } else {
+   return MMC_BLK_RETRY;
+   }
+   }
+   } else {
+   return MMC_BLK_RETRY;
+   }
+   }
+
+   if (check != MMC_BLK_ABORT)
+   return MMC_BLK_RETRY;
+   else
+   return MMC_BLK_ABORT;


The current code does not return other errors (MMC_BLK_CMD_ERR, 
MMC_BLK_ECC_ERR and MMC_BLK_DATA_ERR) returned by mmc_blk_err_check().  
Why not return check here?



+}
+
  static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
   struct mmc_card *card,
   int disable_multi,
@@ -1126,6 +1187,207 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req 
*mqrq,
mmc_queue_bounce_pre(mqrq);
  }

+static u8 mmc_blk_chk_packable(struct mmc_queue *mq, struct request *req)
+{
+   struct request_queue *q = mq->queue;
+   struct mmc_card *card = mq->card;
+   struct request *cur = req, *next = NULL;
+   struct mmc_blk_data *md = mq->data;
+   bool en_rel_wr = card->ext_csd.rel_param&  EXT_CSD_WR_REL_PARAM_EN;
+   unsigned int req_sectors = 0, phys_segments = 0;
+   unsigned int max_blk_count, max_phys_segs;
+   u8 max_packed_rw = 0;
+   u8 reqs = 0;
+
+   if (!(md->flags&  MMC_BLK_CMD23)&&
+   !card->ext_csd.packed_event_en)
+   goto no_packed;
+
+   if (rq_data_dir(cur) == READ)
+   max_packed_rw = card->ext_csd.max_packed_reads;
+   else
+   max_packed_rw = card->ext_csd.max_packed_writes;
+
+   if (max_packed_rw == 0)
+   goto no_packed;
+
+   if (mmc_req_rel_wr(cur)&&
+   (md->flags&  MMC_BLK_REL_WR)&&
+   !en_rel_wr) {
+   goto no_packed;
+   }
+
+   max_blk_count = min(card->host->max_blk_count,
+   card->host->max_req_size>>  9);
+   max_phys_segs = queue_max_segments(q);
+   req_sectors += blk_rq_sectors(cur);
+   phys_segments += req->nr_phys_segments;
+
+   if (rq_data_dir(cur) == WRITE) {
+   req_sectors++;
+   phys_segments++;
+   }
+
+   while (reqs<  max_packed_rw - 1) {


What if the number of requests exceeds the packed header size defined?


+   next = blk_fetch_request(q);
+   if (!next)
+   break;
+
+   if (rq_data_dir(cur) != rq_data_dir(next)) {
+   blk_requeue_request(q, next);
+   break;
+   }
+
+   if (mmc_req_rel_wr(next)&&
+   (md->flags&  MMC_BLK_REL_WR)&&
+   !en_rel_wr) {
+   blk_requeue_request(q, next);
+   break;
+   }
+
+   req_sectors += blk_rq_sectors(next);
+   if (req_sectors>  max_blk_count) {
+   blk_requeue_request(q, next);
+   break;
+   }
+
+   phys_segments +=  next->nr_phys_segments;
+   if (phys_segments>  max_phys_segs) {
+   blk_requeue_request(q, next);
+   break;
+   }
+
+   list_add_tail(&next->queuelist,&mq->mqrq_cur->packe

[PATCH 1/1] mmc:Extension of MMC Block IOCTL Command support for testing of non read/write Commands

[Shashidhar Hiremath]

The patch provides An infrastructure to test commands other than Read/Write 
commands using the IOCTL interface.The Patch can be useful incase of validating 
the device to verify whether device support a given command or not. The result 
of the sent command will be written to the  result element of the mmc_ioc_cmd 
structure passed through IOCTL interface.

Signed-off-by: Shashidhar Hiremath 
---
 drivers/mmc/card/Makefile|2 +-
 drivers/mmc/card/block.c |   28 ++
 drivers/mmc/card/test_cmds.c |  743 ++
 drivers/mmc/card/test_cmds.h |   53 +++
 drivers/mmc/core/core.c  |4 +
 drivers/mmc/core/mmc.c   |4 +
 drivers/mmc/core/mmc_ops.c   |1 +
 drivers/mmc/core/sd.c|2 +
 include/linux/mmc/ioctl.h|1 +
 9 files changed, 837 insertions(+), 1 deletions(-)
 create mode 100644 drivers/mmc/card/test_cmds.c
 create mode 100644 drivers/mmc/card/test_cmds.h

diff --git a/drivers/mmc/card/Makefile b/drivers/mmc/card/Makefile
index c73b406..ea52ee1 100644
--- a/drivers/mmc/card/Makefile
+++ b/drivers/mmc/card/Makefile
@@ -3,7 +3,7 @@
 #
 
 obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
-mmc_block-objs := block.o queue.o
+mmc_block-objs := block.o queue.o test_cmds.o
 obj-$(CONFIG_MMC_TEST) += mmc_test.o
 
 obj-$(CONFIG_SDIO_UART)+= sdio_uart.o
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c80bb6d..c55d564 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -58,6 +58,7 @@ MODULE_ALIAS("mmc:block");
 #define INAND_CMD38_ARG_SECERASE 0x80
 #define INAND_CMD38_ARG_SECTRIM1 0x81
 #define INAND_CMD38_ARG_SECTRIM2 0x88
+#define NON_DATA_CMD 2
 
 static DEFINE_MUTEX(block_mutex);
 
@@ -77,6 +78,11 @@ static int max_devices;
 static DECLARE_BITMAP(dev_use, 256);
 static DECLARE_BITMAP(name_use, 256);
 
+/* prototype of function called for testing
+ * non-read-write commands
+ */
+void test_command(struct mmc_card *card, struct mmc_ioc_cmd *cmd);
+
 /*
  * There is one mmc_blk_data per slot.
  */
@@ -345,6 +351,28 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev,
 
mmc_claim_host(card->host);
 
+   /* Calling API for testing the non-read/write commands */
+   if (idata->ic.write_flag == NON_DATA_CMD) {
+   test_command(card, &(idata->ic));
+   err = 0;
+   if (copy_to_user(&(ic_ptr->response), cmd.resp
+, sizeof(cmd.resp))) {
+   err = -EFAULT;
+   goto cmd_rel_host;
+   }
+   /* The result of the state of the tested command is returned
+* to user space RESULT OK - 0, RESULT_FAIL - 1
+* RESUL_UNSUP_CMD - 2, RESULT_UNSUP_CARD - 3
+* Other Failures - any other integer.
+*/
+   if (copy_to_user(&(ic_ptr->result), &(idata->ic.result)
+, sizeof(idata->ic.result))) {
+   err = -EFAULT;
+   goto cmd_rel_host;
+   }
+   goto cmd_rel_host;
+   }
+
if (idata->ic.is_acmd) {
err = mmc_app_cmd(card->host, card);
if (err)
diff --git a/drivers/mmc/card/test_cmds.c b/drivers/mmc/card/test_cmds.c
new file mode 100644
index 000..dd9671f
--- /dev/null
+++ b/drivers/mmc/card/test_cmds.c
@@ -0,0 +1,743 @@
+/*
+ *  linux/drivers/mmc/card/test_cmds.c
+ *
+ *  This File implements functions for testing non-data commands 
+ *  through IOCTL interface.
+ *
+ *  Copyright (C) 2011 Vayavya Labs Pvt. Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../core/sd_ops.h"
+#include "../core/mmc_ops.h"
+#include "../core/sdio_ops.h"
+#include "test_cmds.h"
+
+static int mmc_test_CMD0(struct mmc_card *card)
+{
+   int ret;
+   struct mmc_host *host = card->host;
+
+   mmc_power_off(host);
+   mmc_power_up(host);
+
+   ret = mmc_go_idle(card->host);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+static int mmc_test_CMD1(struct mmc_card *card)
+{
+   int err = 0;
+   struct mmc_host *host = card->host;
+   u32 ocr;
+
+   if (card->type == MMC_TYPE_MMC) {
+   mmc_test_CMD0(card);
+
+   err = mmc_send_op_cond(card->host, 0, &ocr);
+   if (err)
+   return err;
+
+   /*
+* Sanity check the voltages that the card claims to
+* support.
+*/
+   if (ocr & 0x7F) {
+   printk(KERN_WARNING
+  "%s: card claims to support voltages

[PATCH] mmc: tmio: fix clock gating on platforms, implementing a .set_pwr() method

[Guennadi Liakhovetski]

Do not power down the card in .set_ios(), unless MMC_POWER_OFF is 
requested. This fixes the SDHI functionality on ecovec.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/mmc/host/tmio_mmc_pio.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 1f16357..8d3d2b2 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -762,7 +762,7 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc, struct 
mmc_ios *ios)
/* start bus clock */
tmio_mmc_clk_start(host);
} else if (ios->power_mode != MMC_POWER_UP) {
-   if (host->set_pwr)
+   if (host->set_pwr && ios->power_mode == MMC_POWER_OFF)
host->set_pwr(host->pdev, 0);
if ((pdata->flags & TMIO_MMC_HAS_COLD_CD) &&
pdata->power) {
-- 
1.7.2.5

--
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

[PATCH] mmc: sh_mmcif: fix clock gating on platforms, implementing a .down_pwr() method

[Guennadi Liakhovetski]

Do not power down the card in .set_ios(), unless MMC_POWER_OFF is 
requested. This fixes the MMCIF interface functionality on ecovec boards.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/mmc/host/sh_mmcif.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 557886b..c021482 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -895,7 +895,7 @@ static void sh_mmcif_set_ios(struct mmc_host *mmc, struct 
mmc_ios *ios)
if (host->power) {
pm_runtime_put(&host->pd->dev);
host->power = false;
-   if (p->down_pwr)
+   if (p->down_pwr && ios->power_mode == MMC_POWER_OFF)
p->down_pwr(host->pd);
}
host->state = STATE_IDLE;
-- 
1.7.2.5

--
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

Re: [PATCH v2] mmc: support BKOPS feature for eMMC

[Jaehoon Chung]

Hi Chuanxiao,

On 11/11/2011 03:51 PM, Dong, Chuanxiao wrote:

> Hi Jaehoon,
> 
>> -Original Message-
>> From: Jaehoon Chung [mailto:jh80.ch...@samsung.com]
>> Sent: Wednesday, November 02, 2011 6:29 PM
>> To: linux-mmc
>> Cc: Chris Ball; Kyungmin Park; Hanumath Prasad; Sebastian Rasmussen; Per 
>> Forlin;
>> svenk...@ti.com; Dong, Chuanxiao
>> Subject: [PATCH v2] mmc: support BKOPS feature for eMMC
>>
>> Enable eMMC background operations (BKOPS) feature.
>>
>> If URGENT_BKOPS is set after a response, note that BKOPS
>> are required. After all I/O requests are finished, run
>> BKOPS if required. Should read/write operations be requested
>> during BKOPS, first issue HPI to interrupt the ongoing BKOPS
>> and then service the request.
>>
>> If you want to enable this feature, set MMC_CAP2_BKOPS.
>>
>> Signed-off-by: Jaehoon Chung 
>> Signed-off-by: Kyungmin Park 
>> CC: Hanumath Prasad 
>>
>> ---
>> Changelog V2:
>>  - Use EXCEPTION_STATUS instead of URGENT_BKOPS
>>  - Add function to check Exception_status(for eMMC4.5)
>>  - remove unnecessary code.
>>
>>  drivers/mmc/card/block.c   |9 +
>>  drivers/mmc/card/queue.c   |4 ++
>>  drivers/mmc/core/core.c|   87
>> 
>>  drivers/mmc/core/mmc.c |9 -
>>  drivers/mmc/core/mmc_ops.c |4 ++
>>  include/linux/mmc/card.h   |   12 ++
>>  include/linux/mmc/core.h   |3 ++
>>  include/linux/mmc/host.h   |1 +
>>  include/linux/mmc/mmc.h|   14 +++
>>  9 files changed, 142 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
>> index a1cb21f..fbfb405 100644
>> --- a/drivers/mmc/card/block.c
>> +++ b/drivers/mmc/card/block.c
>> @@ -1192,6 +1192,15 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue
>> *mq, struct request *rqc)
>>  case MMC_BLK_SUCCESS:
>>  case MMC_BLK_PARTIAL:
>>  /*
>> + * Check BKOPS urgency from each R1 response
>> + */
>> +if (mmc_card_mmc(card) &&
>> +(brq->cmd.resp[0] & R1_EXCEPTION_EVENT)) {
>> +if (mmc_is_exception_event(card,
>> +EXT_CSD_URGENT_BKOPS))
>> +mmc_card_set_need_bkops(card);
>> +}
>> +/*

> Have you thought about moving this into mmc_wait_for_req_done()? We can check 
> if the command is a R1 or R1B or not, and set BKOPS bit in there if needed. I 
> was just thinking if we put such code here, we may only cover the successful 
> scenario but not for the failed cases. Putting in mmc_wait_for_req_done can 
> cover all cases.


Thanks for comment..I will move this into mmc_wait_for_req_done..and i will 
test.
Then i will modify and resend the patch with your opinion

Best Regards,
Jaehoon Chung

> 
> Thanks
> Chuanxiao
> 


--
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