Hi Shawn..
Shawn Guo wrote:
> Hi Jaehoon,
>
> On Thu, Apr 07, 2011 at 05:04:52PM +0900, Jaehoon Chung wrote:
> [...]
>> +static unsigned int dw_mci_pre_dma_transfer(struct dw_mci *host,
>> + struct mmc_data *data, struct dw_mci_next *next)
>> +{
>> + unsigned int sg_len;
>> +
>> + BUG_ON(next && data->host_cookie);
>> + BUG_ON(!next && data->host_cookie &&
>> + data->host_cookie != host->next_data.cookie);
>> +
>> + if (!next && data->host_cookie &&
>> + data->host_cookie != host->next_data.cookie) {
>> + data->host_cookie = 0;
>> + }
>> +
> I'm unsure if the 'if' statement makes any sense here, since the
> exactly same conditions have been caught by the BUG_ON just above
> it.
>
You're right..i'll modify this..
>> + if (next ||
>> + (!next && data->host_cookie != host->next_data.cookie)) {
>> + sg_len = dma_map_sg(&host->pdev->dev, data->sg,
>> + data->sg_len, ((data->flags & MMC_DATA_WRITE)
>> + ? DMA_TO_DEVICE : DMA_FROM_DEVICE));
>> + } else {
>> + sg_len = host->next_data.sg_len;
>> + host->next_data.sg_len = 0;
>> + }
>> +
>> + if (sg_len == 0)
>> + return -EINVAL;
>> +
>> + if (next) {
>> + next->sg_len = sg_len;
>> + data->host_cookie = ++next->cookie < 0 ? 1 : next->cookie;
>> + } else
>> + data->sg_len = sg_len;
>> +
>> + return sg_len;
>> +}
>> +
> Function dw_mci_pre_dma_transfer() returns non-zero value anyway,
> either -EINVAL or sg_len ...
>
Sorry,, i didn't understand this your comments..
> [...]
>> +static void dw_mci_pre_request(struct mmc_host *mmc, struct mmc_request
>> *mrq,
>> + bool is_first_req)
>> +{
>> + struct dw_mci_slot *slot = mmc_priv(mmc);
>> + struct mmc_data *data = mrq->data;
>> +
>> + if (!data)
>> + return;
>> +
>> + BUG_ON(mrq->data->host_cookie);
>> +
>> + if (slot->host->use_dma) {
>> + if (dw_mci_pre_dma_transfer(slot->host, mrq->data,
>> + &slot->host->next_data))
>> + mrq->data->host_cookie = 0;
> ... while it steps back to old blocking way by setting
> data->host_cookie 0 when dw_mci_pre_dma_transfer returns non-zero.
>
> Per my understanding, it means the non-blocking optimization will
> always get bypassed anyway, so I doubt the patch can really gain
> performance improvement. Did you get the chance to measure?
>
Actually, i didn't get performance improvement, but didn't fully affect by
CPU_FREQ.
Somebody get performance improvement?
Regards,
Jaehoon Chung
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html