All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaehoon Chung <jh80.chung@samsung.com>
To: Huang Changming-R66093 <r66093@freescale.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>,
	Philip Rakity <prakity@marvell.com>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	Chris Ball <cjb@laptop.org>
Subject: Re: [PATCH 3/4 v5] SDHCI: add sdhci_get_cd callback to detect the card
Date: Fri, 16 Dec 2011 13:05:33 +0900	[thread overview]
Message-ID: <4EEAC38D.9070705@samsung.com> (raw)
In-Reply-To: <8A2FC72B45BB5A4C9F801431E06AE48F11651768@039-SN1MPN1-005.039d.mgd.msft.net>

On 12/16/2011 12:25 PM, Huang Changming-R66093 wrote:

>>> I am very confused, why do we read the present state register on every
>> request?
>>
>> How long time read the present state register?
> Even if one line code is performed, I think it need time to complete.
> 
>>> My codes are added to the function mmc_sd_detect in file core/sd.c
>>> Function mmc_rescan has detect the card present state repeatedly, so I
>> think we don't need to detect the card state on every request.
>>> So I think the codes to detect the card present state in sdhci_request
>> should be removed to improve the performance.
>>
>> How did you get the performance benefit?
> Do you know there are many tools to run the performance?
> IPForward/IPSEC for network, iozone for SATA/SDHC...
> 
> We have the performance result from our platform, the result will decrease 2%~5%!
> 
> If the driver has the option 'MMC_CAP_NEEDS_POLL' (many driver enable this option) and the card is always present, the driver will send the command "mmc_send_status" to ask the card state repeatedly.
> Do you know what it means? Many interrupts will be generated even if the system is reading from/writing to the SD/MMC card.
> 
>> And mmc_rescan is repeatedly for SD-card?
>> If mmc_rescan is repeatedly, that reason is the below code. (just my
>> thinking)
>>
>> if (host->caps & MMC_CAP_NEEDS_POLL)
>> 	mmc_schedule_delayed_work(&host->detect, HZ);
>>
>> what is your point related with mmc_rescan?
>> I didn't understand yours..
> 
> There are some controllers don't support the card detect, the SDHCI_CARD_PRESENT is forever one. And some controller must enable the MMC_CAP_NEEDS_POLL option (about this, you can search the folder mmc/host/), that means mmc_rescan will be run repeatedly.
> In these cases, if we detect the card state though command mmc_send_status, a lot of interrupts will be generated.

I know that...Some controller didn't support the card detect...But I think you can control this problem with SDHCI_QUIRK_BROKEN_CARD_DETECTION and some flags.
If controller is always polling for card status, that's inefficient.
I use the SDHCI_QUIRK_BROKEN_CARD_DETECTION, but didn't generate the interrupt at every time(didn't polling)
I think you can solve this problem in sdhci-xxx.c, not in sdhci.c

> 
> For the transaction from/to SD card, we don't need to check the card present state, it should be done in other area.
> So I don't think it is correct to detect card state in function sdhci_request. 

> 

> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



  reply	other threads:[~2011-12-16  4:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-14  2:18 [PATCH 3/4 v5] SDHCI: add sdhci_get_cd callback to detect the card r66093
2011-12-14  4:51 ` Philip Rakity
2011-12-15  2:32   ` Huang Changming-R66093
2011-12-15  6:41     ` Philip Rakity
2011-12-15  6:56       ` Huang Changming-R66093
2011-12-15 10:04         ` Jaehoon Chung
2011-12-16  3:25           ` Huang Changming-R66093
2011-12-16  4:05             ` Jaehoon Chung [this message]
2011-12-16  4:33               ` Huang Changming-R66093
2012-01-13  2:25 ` Huang Changming-R66093
2012-01-13  3:26   ` Aaron Lu
2012-01-13  4:50     ` Huang Changming-R66093
2012-01-13  6:20       ` Aaron Lu
2012-01-13  6:44         ` Huang Changming-R66093
  -- strict thread matches above, loose matches on Subject: below --
2012-10-30  8:12 [PATCH 1/4 v3] MMC/core: Add f_min to mmc_power_on() r66093
2012-10-30  8:12 ` [PATCH 2/4 v4] MMC/SD: Add callback function to detect card r66093
2012-10-30  8:12   ` [PATCH 3/4 v5] SDHCI: add sdhci_get_cd callback to detect the card r66093
2012-11-19  2:50     ` Huang Changming-R66093
2012-11-19  2:58       ` Anton Vorontsov
2012-11-19  3:15         ` Huang Changming-R66093
2012-11-19  3:31           ` Anton Vorontsov
2012-11-19  3:38             ` Huang Changming-R66093

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=4EEAC38D.9070705@samsung.com \
    --to=jh80.chung@samsung.com \
    --cc=cjb@laptop.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=prakity@marvell.com \
    --cc=r66093@freescale.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.