Hi Ulf
Thank you for your feedback
> > If you can't accept it, we will consider it again.
> > But is it possilbe to keep consistency if host side exchange block size
> > without using framework ??
>
> Nope, we need adaptations to the framework and I have no objections to that.
Thank you.
Basically, I agree with your opinion (= it locals to host driver side, not on framework)
but, I couldn't find good method for it
(the size is decided on framework, and it seems host side driver can't do something to it)
And, we noticed similar flag.
But, hmm... if we can have callback function on framework...
/*
* this can replace MMC_CAP2_NO_MULTI_READ ?
*/
void no_multi_read_fixup(struct mmc_blk_request *brq,
struct request *req)
{
if (rq_data_dir(req) == READ)
brq->data.blocks = 1;
}
/*
* we can use this instead of MMC_CAP2_2BLKS_LIMIT ?
*/
void two_block_limit_read_fixup(struct mmc_blk_request *brq,
struct request *req)
{
if ((rq_data_dir(req) == READ) &&
(brq->data.blocks == 2))
brq->data.blocks = 1;
}
static void mmc_blk_rw_rq_prep(xxxx)
{
...
if (brq->data.blocks > 1) {
...
if (card->host->host_data_fixup)
card->host->host_data_fixup(brq, req)
}
...
}
> > Because this method will check caps2 flag twice for
> > MMC_CAP2_2BLKS_LIMIT and MMC_CAP2_NO_MULTI_READ in such case.
> > But, these are similar flag, and is no effect for almost all drivers.
> > We avoided such checks.
>
> I see, but I don't think such "optimization" is worth much. To me it
> just adds a bit of confusion. I would prefer to have them separate.
OK, I see.
I already posted v3 patch-set which doesn't have this patch.
I will post v3 of this patch if above v3 patch-set were accepted.
Best regards
---
Kuninori Morimoto
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
