From: merez@codeaurora.org
To: Seungwon Jeon <tgih.jun@samsung.com>
Cc: merez@codeaurora.org, "'S, Venkatraman'" <svenkatr@ti.com>,
linux-mmc@vger.kernel.org, 'Chris Ball' <cjb@laptop.org>,
linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
kgene.kim@samsung.com, dh.han@samsung.com
Subject: RE: [PATCH 2/2] mmc: core: Support packed command for eMMC4.5 device
Date: Tue, 15 Nov 2011 04:48:02 -0800 (PST) [thread overview]
Message-ID: <faba552e7bd19ee5399c73c2b478a34d.squirrel@www.codeaurora.org> (raw)
In-Reply-To: <001e01cca2b2$3b449310$b1cdb930$%jun@samsung.com>
>> >>> >> >> > + 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.
WARNING: multiple messages have this Message-ID (diff)
From: merez@codeaurora.org
To: "Seungwon Jeon" <tgih.jun@samsung.com>
Cc: merez@codeaurora.org, "'S, Venkatraman'" <svenkatr@ti.com>,
linux-mmc@vger.kernel.org, "'Chris Ball'" <cjb@laptop.org>,
linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
kgene.kim@samsung.com, dh.han@samsung.com
Subject: RE: [PATCH 2/2] mmc: core: Support packed command for eMMC4.5 device
Date: Tue, 15 Nov 2011 04:48:02 -0800 (PST) [thread overview]
Message-ID: <faba552e7bd19ee5399c73c2b478a34d.squirrel@www.codeaurora.org> (raw)
In-Reply-To: <001e01cca2b2$3b449310$b1cdb930$%jun@samsung.com>
>> >>> >> >> > + 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.
next prev parent reply other threads:[~2011-11-15 12:48 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-10 13:41 [PATCH 2/2] mmc: core: Support packed command for eMMC4.5 device merez
2011-11-11 7:26 ` Seungwon Jeon
2011-11-11 9:38 ` S, Venkatraman
2011-11-11 19:01 ` merez
2011-11-11 19:01 ` merez
2011-11-13 13:04 ` merez
2011-11-14 9:46 ` Seungwon Jeon
2011-11-15 12:48 ` merez [this message]
2011-11-15 12:48 ` merez
2011-11-17 2:02 ` Seungwon Jeon
2011-11-17 9:16 ` mmc: sdio: runtime PM and 8686 problems Joe Woodward
2011-11-14 9:44 ` [PATCH 2/2] mmc: core: Support packed command for eMMC4.5 device Seungwon Jeon
2011-11-15 13:27 ` merez
2011-11-15 13:27 ` merez
2011-11-17 2:21 ` Seungwon Jeon
2011-11-17 13:45 ` merez
2011-11-17 13:45 ` merez
-- strict thread matches above, loose matches on Subject: below --
2011-11-27 19:41 merez
2011-11-28 8:52 ` Seungwon Jeon
2011-12-01 13:51 ` merez
2011-12-01 13:51 ` merez
2011-12-02 9:06 ` Seungwon Jeon
2011-11-02 8:03 Seungwon Jeon
2011-11-02 10:59 ` Girish K S
2011-11-02 11:35 ` S, Venkatraman
2011-11-03 1:53 ` Seungwon Jeon
2011-11-04 14:46 ` S, Venkatraman
2011-11-07 3:45 ` Seungwon Jeon
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=faba552e7bd19ee5399c73c2b478a34d.squirrel@www.codeaurora.org \
--to=merez@codeaurora.org \
--cc=cjb@laptop.org \
--cc=dh.han@samsung.com \
--cc=kgene.kim@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=svenkatr@ti.com \
--cc=tgih.jun@samsung.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.