| Message ID | 1351584769-16662-2-git-send-email-r66093@freescale.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 30 October 2012 13:42, <r66093@freescale.com> wrote: > From: Jerry Huang <Chang-Ming.Huang@freescale.com> > > In order to check whether the card has been removed, the function > mmc_send_status() will send command CMD13 to card and ask the card > to send its status register to sdhc driver, which will generate > many interrupts repeatedly and make the system performance bad. > > Therefore, add callback function get_cd() to check whether > the card has been removed when the driver has this callback function. > > If the card is present, 1 will return, if the card is absent, 0 will return. > If the controller will not support this feature, -ENOSYS will return. > > Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com> > CC: Anton Vorontsov <cbouatmailru@gmail.com> > CC: Chris Ball <cjb@laptop.org> > --- > changes for v2: > - when controller don't support get_cd, return -ENOSYS > - add the CC > changes for v3: > - enalbe the controller clock in platform, instead of core > changes for v4: > - move the detect code to core.c according to the new structure > > drivers/mmc/core/core.c | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c > index 9c162cd..6412355 100644 > --- a/drivers/mmc/core/core.c > +++ b/drivers/mmc/core/core.c > @@ -2073,7 +2073,7 @@ static int mmc_rescan_try_freq(struct mmc_host *host, unsigned freq) > > int _mmc_detect_card_removed(struct mmc_host *host) > { > - int ret; > + int ret = -ENOSYS; > > if ((host->caps & MMC_CAP_NONREMOVABLE) || !host->bus_ops->alive) > return 0; > @@ -2081,7 +2081,13 @@ int _mmc_detect_card_removed(struct mmc_host *host) > if (!host->card || mmc_card_removed(host->card)) > return 1; > > - ret = host->bus_ops->alive(host); > + if (host->ops->get_cd) { > + ret = host->ops->get_cd(host); > + if (ret >= 0) > + ret = !ret; > + } > + if (ret < 0) > + ret = host->bus_ops->alive(host); why should we check for negative here? can move this code into else path of if (host->ops->get_cd). > if (ret) { > mmc_card_set_removed(host->card); > pr_debug("%s: card remove detected\n", mmc_hostname(host)); > -- > 1.7.9.5 > > > -- > 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 -- 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
Best Regards Jerry Huang > -----Original Message----- > From: linux-mmc-owner@vger.kernel.org [mailto:linux-mmc- > owner@vger.kernel.org] On Behalf Of Girish K S > Sent: Tuesday, October 30, 2012 7:35 PM > To: Huang Changming-R66093 > Cc: linux-mmc@vger.kernel.org; Huang Changming-R66093; Anton Vorontsov; > Chris Ball > Subject: Re: [PATCH 2/4 v4] MMC/SD: Add callback function to detect card > > On 30 October 2012 13:42, <r66093@freescale.com> wrote: > > From: Jerry Huang <Chang-Ming.Huang@freescale.com> > > > > In order to check whether the card has been removed, the function > > mmc_send_status() will send command CMD13 to card and ask the card > > to send its status register to sdhc driver, which will generate > > many interrupts repeatedly and make the system performance bad. > > > > Therefore, add callback function get_cd() to check whether > > the card has been removed when the driver has this callback function. > > > > If the card is present, 1 will return, if the card is absent, 0 will > return. > > If the controller will not support this feature, -ENOSYS will return. > > > > Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com> > > CC: Anton Vorontsov <cbouatmailru@gmail.com> > > CC: Chris Ball <cjb@laptop.org> > > --- > > changes for v2: > > - when controller don't support get_cd, return -ENOSYS > > - add the CC > > changes for v3: > > - enalbe the controller clock in platform, instead of core > > changes for v4: > > - move the detect code to core.c according to the new structure > > > > drivers/mmc/core/core.c | 10 ++++++++-- > > 1 file changed, 8 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c > > index 9c162cd..6412355 100644 > > --- a/drivers/mmc/core/core.c > > +++ b/drivers/mmc/core/core.c > > @@ -2073,7 +2073,7 @@ static int mmc_rescan_try_freq(struct mmc_host > *host, unsigned freq) > > > > int _mmc_detect_card_removed(struct mmc_host *host) > > { > > - int ret; > > + int ret = -ENOSYS; > > > > if ((host->caps & MMC_CAP_NONREMOVABLE) || !host->bus_ops- > >alive) > > return 0; > > @@ -2081,7 +2081,13 @@ int _mmc_detect_card_removed(struct mmc_host > *host) > > if (!host->card || mmc_card_removed(host->card)) > > return 1; > > > > - ret = host->bus_ops->alive(host); > > + if (host->ops->get_cd) { > > + ret = host->ops->get_cd(host); > > + if (ret >= 0) > > + ret = !ret; > > + } > > + if (ret < 0) > > + ret = host->bus_ops->alive(host); > why should we check for negative here? can move this code into else > path of if (host->ops->get_cd). > > if (ret) { I did this comment: If the card is present, 1 will return, if the card is absent, 0 will return. If the controller will not support this feature, -ENOSYS will return. Can't move to other address, because these codes check the card present state. -- 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
Hi, >> *host) >>> if (!host->card || mmc_card_removed(host->card)) >>> return 1; >>> >>> - ret = host->bus_ops->alive(host); >>> + if (host->ops->get_cd) { >>> + ret = host->ops->get_cd(host); >>> + if (ret >= 0) >>> + ret = !ret; >>> + } >>> + if (ret < 0) >>> + ret = host->bus_ops->alive(host); >> why should we check for negative here? can move this code into else >> path of if (host->ops->get_cd). >>> if (ret) { > > I did this comment: > If the card is present, 1 will return, if the card is absent, 0 will return. > If the controller will not support this feature, -ENOSYS will return. If checked whether card is absent or not with get_cd(), need to check the host->bus_ops->alive? > > Can't move to other address, because these codes check the card present state. > > > -- > 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 > -- 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
Best Regards Jerry Huang > -----Original Message----- > From: Jaehoon Chung [mailto:jh80.chung@samsung.com] > Sent: Wednesday, October 31, 2012 12:29 PM > To: Huang Changming-R66093 > Cc: Girish K S; linux-mmc@vger.kernel.org; Anton Vorontsov; Chris Ball > Subject: Re: [PATCH 2/4 v4] MMC/SD: Add callback function to detect card > > Hi, > > >> *host) > >>> if (!host->card || mmc_card_removed(host->card)) > >>> return 1; > >>> > >>> - ret = host->bus_ops->alive(host); > >>> + if (host->ops->get_cd) { > >>> + ret = host->ops->get_cd(host); > >>> + if (ret >= 0) > >>> + ret = !ret; > >>> + } > >>> + if (ret < 0) > >>> + ret = host->bus_ops->alive(host); > >> why should we check for negative here? can move this code into else > >> path of if (host->ops->get_cd). > >>> if (ret) { > > > > I did this comment: > > If the card is present, 1 will return, if the card is absent, 0 will > return. > > If the controller will not support this feature, -ENOSYS will return. > If checked whether card is absent or not with get_cd(), need to check the > host->bus_ops->alive? When get_cd is not supported, need to check it. -- 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
Hi Jerry, 2012/10/30 <r66093@freescale.com>: > From: Jerry Huang <Chang-Ming.Huang@freescale.com> > > In order to check whether the card has been removed, the function > mmc_send_status() will send command CMD13 to card and ask the card > to send its status register to sdhc driver, which will generate > many interrupts repeatedly and make the system performance bad. > > Therefore, add callback function get_cd() to check whether > the card has been removed when the driver has this callback function. > > If the card is present, 1 will return, if the card is absent, 0 will return. > If the controller will not support this feature, -ENOSYS will return. In what cases is the performance affected by this? I believe this function is called only on some errors and on detect? Also, we've seen cases where the card detect GPIO cannot be trusted to tell wether the card is present or not, for instance in the corner case when an SD-card is removed very slowly... Kind regards, Johan -- 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
Hi, Johan, When quicks SDHCI_QUIRK_BROKEN_CARD_DETECTION is set, the driver will poll the card status with the command CMD13 periodically, then many interrupts will be generated, which affect the performance. Yes, some cases to detect GPIO can't be trusted, so I only just implement this callback in eSDHC-of driver. that is to say, just when the platform support it, this callback can be implement, if not, continue to send the command CMD13. > Hi Jerry, > > 2012/10/30 <r66093@freescale.com>: > > From: Jerry Huang <Chang-Ming.Huang@freescale.com> > > > > In order to check whether the card has been removed, the function > > mmc_send_status() will send command CMD13 to card and ask the card to > > send its status register to sdhc driver, which will generate many > > interrupts repeatedly and make the system performance bad. > > > > Therefore, add callback function get_cd() to check whether the card > > has been removed when the driver has this callback function. > > > > If the card is present, 1 will return, if the card is absent, 0 will > return. > > If the controller will not support this feature, -ENOSYS will return. > > In what cases is the performance affected by this? I believe this > function is called only on some errors and on detect? > > Also, we've seen cases where the card detect GPIO cannot be trusted to > tell wether the card is present or not, for instance in the corner case > when an SD-card is removed very slowly... > > Kind regards, Johan -- 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
Hi Jerry, 2012/11/2 Huang Changming-R66093 <r66093@freescale.com>: > Hi, Johan, > When quicks SDHCI_QUIRK_BROKEN_CARD_DETECTION is set, the driver will poll the card status with the command CMD13 periodically, then many interrupts will be generated, which affect the performance. Ok, just to see if I understand the scenario correctly: SDHCI_QUIRK_BROKEN_CARD_DETECTION causes the MMC_CAP_NEEDS_POLL cap to be set, which will cause mmc_rescan to be run at a one second interval. mmc_rescan calls bus_ops->detect (mmc_sd_detect) and this in turn calls _mmc_detect_card_removed, which will do the bus_ops->alive and send CMD13. So in this case, one CMD13 is sent per second, right? Is this the cause of the performance issue? A thought: if the host hardware does have a GPIO card detect pin hooked up, would it not be possible to make this pin generate an IRQ whenever a card is inserted or removed? This is what we do in the MMCI driver, for instance (mmci_cd_irq). > Yes, some cases to detect GPIO can't be trusted, so I only just implement this callback in eSDHC-of driver. that is to say, just when the platform support it, this callback can be implement, if not, continue to send the command CMD13. I'm just wondering how this will affect our system, where we use the cd GPIO to generate detect jobs on card insert/remove, but where the cd pin is not 100% synchronized with the electrical connection of the power and cmd line of the SD-card. So if I remember correctly, the cd pin may report that the card has been removed, but there is still an electric connection and the card is alive... Kind regards, Johan -- 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
> > 2012/11/2 Huang Changming-R66093 <r66093@freescale.com>: > > Hi, Johan, > > When quicks SDHCI_QUIRK_BROKEN_CARD_DETECTION is set, the driver will > poll the card status with the command CMD13 periodically, then many > interrupts will be generated, which affect the performance. > > Ok, just to see if I understand the scenario correctly: > SDHCI_QUIRK_BROKEN_CARD_DETECTION causes the MMC_CAP_NEEDS_POLL cap to be > set, which will cause mmc_rescan to be run at a one second interval. > mmc_rescan calls bus_ops->detect (mmc_sd_detect) and this in turn calls > _mmc_detect_card_removed, which will do the bus_ops->alive and send CMD13. > So in this case, one CMD13 is sent per second, right? > Is this the cause of the performance issue? Yes, You are right. > > A thought: if the host hardware does have a GPIO card detect pin hooked > up, would it not be possible to make this pin generate an IRQ whenever a > card is inserted or removed? This is what we do in the MMCI driver, for > instance (mmci_cd_irq). Our silicones has this pin to do card detect, but some boards don't generate the interrupt when card is inserted or removed. So I have to use the poll mode. > > Yes, some cases to detect GPIO can't be trusted, so I only just > implement this callback in eSDHC-of driver. that is to say, just when the > platform support it, this callback can be implement, if not, continue to > send the command CMD13. > > I'm just wondering how this will affect our system, where we use the cd > GPIO to generate detect jobs on card insert/remove, but where the cd pin > is not 100% synchronized with the electrical connection of the power and > cmd line of the SD-card. So if I remember correctly, the cd pin may > report that the card has been removed, but there is still an electric > connection and the card is alive... > I don't see this on our board, when card is inserted or removed, the register field can reflect this state correctly. -- 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
Hi, 2012/11/5 Huang Changming-R66093 <r66093@freescale.com>: >> >> 2012/11/2 Huang Changming-R66093 <r66093@freescale.com>: >> > Hi, Johan, >> > When quicks SDHCI_QUIRK_BROKEN_CARD_DETECTION is set, the driver will >> poll the card status with the command CMD13 periodically, then many >> interrupts will be generated, which affect the performance. >> >> Ok, just to see if I understand the scenario correctly: >> SDHCI_QUIRK_BROKEN_CARD_DETECTION causes the MMC_CAP_NEEDS_POLL cap to be >> set, which will cause mmc_rescan to be run at a one second interval. >> mmc_rescan calls bus_ops->detect (mmc_sd_detect) and this in turn calls >> _mmc_detect_card_removed, which will do the bus_ops->alive and send CMD13. >> So in this case, one CMD13 is sent per second, right? >> Is this the cause of the performance issue? > > Yes, You are right. Ok, it's a bit hard to understand how this can lead to a noticeable performance impact, but OK. :) >> A thought: if the host hardware does have a GPIO card detect pin hooked >> up, would it not be possible to make this pin generate an IRQ whenever a >> card is inserted or removed? This is what we do in the MMCI driver, for >> instance (mmci_cd_irq). > > Our silicones has this pin to do card detect, but some boards don't generate the interrupt when card is inserted or removed. So I have to use the poll mode. > >> > Yes, some cases to detect GPIO can't be trusted, so I only just >> implement this callback in eSDHC-of driver. that is to say, just when the >> platform support it, this callback can be implement, if not, continue to >> send the command CMD13. >> >> I'm just wondering how this will affect our system, where we use the cd >> GPIO to generate detect jobs on card insert/remove, but where the cd pin >> is not 100% synchronized with the electrical connection of the power and >> cmd line of the SD-card. So if I remember correctly, the cd pin may >> report that the card has been removed, but there is still an electric >> connection and the card is alive... >> > I don't see this on our board, when card is inserted or removed, the register field can reflect this state correctly. We see a difference on our boards with this patch, but no functional change (actually a removed card is detected earlier now), so from my perspective: Reviewed-By: Johan Rudholm <johan.rudholm@stericsson.com> //Johan -- 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
Thanks a lot, Johan. Best Regards Jerry Huang > -----Original Message----- > From: Johan Rudholm [mailto:jrudholm@gmail.com] > Sent: Monday, November 05, 2012 10:08 PM > To: Huang Changming-R66093 > Cc: linux-mmc@vger.kernel.org; Anton Vorontsov; Chris Ball > Subject: Re: [PATCH 2/4 v4] MMC/SD: Add callback function to detect card > > Hi, > > 2012/11/5 Huang Changming-R66093 <r66093@freescale.com>: > >> > >> 2012/11/2 Huang Changming-R66093 <r66093@freescale.com>: > >> > Hi, Johan, > >> > When quicks SDHCI_QUIRK_BROKEN_CARD_DETECTION is set, the driver > will > >> poll the card status with the command CMD13 periodically, then many > >> interrupts will be generated, which affect the performance. > >> > >> Ok, just to see if I understand the scenario correctly: > >> SDHCI_QUIRK_BROKEN_CARD_DETECTION causes the MMC_CAP_NEEDS_POLL cap to > be > >> set, which will cause mmc_rescan to be run at a one second interval. > >> mmc_rescan calls bus_ops->detect (mmc_sd_detect) and this in turn > calls > >> _mmc_detect_card_removed, which will do the bus_ops->alive and send > CMD13. > >> So in this case, one CMD13 is sent per second, right? > >> Is this the cause of the performance issue? > > > > Yes, You are right. > > Ok, it's a bit hard to understand how this can lead to a noticeable > performance impact, but OK. :) > > >> A thought: if the host hardware does have a GPIO card detect pin > hooked > >> up, would it not be possible to make this pin generate an IRQ whenever > a > >> card is inserted or removed? This is what we do in the MMCI driver, > for > >> instance (mmci_cd_irq). > > > > Our silicones has this pin to do card detect, but some boards don't > generate the interrupt when card is inserted or removed. So I have to use > the poll mode. > > > >> > Yes, some cases to detect GPIO can't be trusted, so I only just > >> implement this callback in eSDHC-of driver. that is to say, just when > the > >> platform support it, this callback can be implement, if not, continue > to > >> send the command CMD13. > >> > >> I'm just wondering how this will affect our system, where we use the > cd > >> GPIO to generate detect jobs on card insert/remove, but where the cd > pin > >> is not 100% synchronized with the electrical connection of the power > and > >> cmd line of the SD-card. So if I remember correctly, the cd pin may > >> report that the card has been removed, but there is still an electric > >> connection and the card is alive... > >> > > I don't see this on our board, when card is inserted or removed, the > register field can reflect this state correctly. > > We see a difference on our boards with this patch, but no functional > change (actually a removed card is detected earlier now), so from my > perspective: > > Reviewed-By: Johan Rudholm <johan.rudholm@stericsson.com> > > //Johan -- 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
Hi, Anton and Chris Have you any comment about the serial patch [patch 2/3/4, please ignore patch1]? Reviewed-By: Johan Rudholm <johan.rudholm@stericsson.com> Best Regards Jerry Huang > -----Original Message----- > From: Johan Rudholm [mailto:jrudholm@gmail.com] > Sent: Monday, November 05, 2012 10:08 PM > To: Huang Changming-R66093 > Cc: linux-mmc@vger.kernel.org; Anton Vorontsov; Chris Ball > Subject: Re: [PATCH 2/4 v4] MMC/SD: Add callback function to detect card > > Hi, > > 2012/11/5 Huang Changming-R66093 <r66093@freescale.com>: > >> > >> 2012/11/2 Huang Changming-R66093 <r66093@freescale.com>: > >> > Hi, Johan, > >> > When quicks SDHCI_QUIRK_BROKEN_CARD_DETECTION is set, the driver > will > >> poll the card status with the command CMD13 periodically, then many > >> interrupts will be generated, which affect the performance. > >> > >> Ok, just to see if I understand the scenario correctly: > >> SDHCI_QUIRK_BROKEN_CARD_DETECTION causes the MMC_CAP_NEEDS_POLL cap to > be > >> set, which will cause mmc_rescan to be run at a one second interval. > >> mmc_rescan calls bus_ops->detect (mmc_sd_detect) and this in turn > calls > >> _mmc_detect_card_removed, which will do the bus_ops->alive and send > CMD13. > >> So in this case, one CMD13 is sent per second, right? > >> Is this the cause of the performance issue? > > > > Yes, You are right. > > Ok, it's a bit hard to understand how this can lead to a noticeable > performance impact, but OK. :) > > >> A thought: if the host hardware does have a GPIO card detect pin > hooked > >> up, would it not be possible to make this pin generate an IRQ whenever > a > >> card is inserted or removed? This is what we do in the MMCI driver, > for > >> instance (mmci_cd_irq). > > > > Our silicones has this pin to do card detect, but some boards don't > generate the interrupt when card is inserted or removed. So I have to use > the poll mode. > > > >> > Yes, some cases to detect GPIO can't be trusted, so I only just > >> implement this callback in eSDHC-of driver. that is to say, just when > the > >> platform support it, this callback can be implement, if not, continue > to > >> send the command CMD13. > >> > >> I'm just wondering how this will affect our system, where we use the > cd > >> GPIO to generate detect jobs on card insert/remove, but where the cd > pin > >> is not 100% synchronized with the electrical connection of the power > and > >> cmd line of the SD-card. So if I remember correctly, the cd pin may > >> report that the card has been removed, but there is still an electric > >> connection and the card is alive... > >> > > I don't see this on our board, when card is inserted or removed, the > register field can reflect this state correctly. > > We see a difference on our boards with this patch, but no functional > change (actually a removed card is detected earlier now), so from my > perspective: > > Reviewed-By: Johan Rudholm <johan.rudholm@stericsson.com> > > //Johan -- 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
Hi, Anton and Chris Have you any comment about this serial patches[patch 2/3/4, except 1]? Best Regards Jerry Huang > -----Original Message----- > From: linux-mmc-owner@vger.kernel.org [mailto:linux-mmc- > owner@vger.kernel.org] On Behalf Of Huang Changming-R66093 > Sent: Tuesday, November 06, 2012 9:56 AM > To: Anton Vorontsov; Chris Ball > Cc: linux-mmc@vger.kernel.org; Johan Rudholm > Subject: RE: [PATCH 2/4 v4] MMC/SD: Add callback function to detect card > > Hi, Anton and Chris > Have you any comment about the serial patch [patch 2/3/4, please ignore > patch1]? > Reviewed-By: Johan Rudholm <johan.rudholm@stericsson.com> > > Best Regards > Jerry Huang > > > > -----Original Message----- > > From: Johan Rudholm [mailto:jrudholm@gmail.com] > > Sent: Monday, November 05, 2012 10:08 PM > > To: Huang Changming-R66093 > > Cc: linux-mmc@vger.kernel.org; Anton Vorontsov; Chris Ball > > Subject: Re: [PATCH 2/4 v4] MMC/SD: Add callback function to detect > > card > > > > Hi, > > > > 2012/11/5 Huang Changming-R66093 <r66093@freescale.com>: > > >> > > >> 2012/11/2 Huang Changming-R66093 <r66093@freescale.com>: > > >> > Hi, Johan, > > >> > When quicks SDHCI_QUIRK_BROKEN_CARD_DETECTION is set, the driver > > will > > >> poll the card status with the command CMD13 periodically, then many > > >> interrupts will be generated, which affect the performance. > > >> > > >> Ok, just to see if I understand the scenario correctly: > > >> SDHCI_QUIRK_BROKEN_CARD_DETECTION causes the MMC_CAP_NEEDS_POLL cap > > >> to > > be > > >> set, which will cause mmc_rescan to be run at a one second interval. > > >> mmc_rescan calls bus_ops->detect (mmc_sd_detect) and this in turn > > calls > > >> _mmc_detect_card_removed, which will do the bus_ops->alive and send > > CMD13. > > >> So in this case, one CMD13 is sent per second, right? > > >> Is this the cause of the performance issue? > > > > > > Yes, You are right. > > > > Ok, it's a bit hard to understand how this can lead to a noticeable > > performance impact, but OK. :) > > > > >> A thought: if the host hardware does have a GPIO card detect pin > > hooked > > >> up, would it not be possible to make this pin generate an IRQ > > >> whenever > > a > > >> card is inserted or removed? This is what we do in the MMCI driver, > > for > > >> instance (mmci_cd_irq). > > > > > > Our silicones has this pin to do card detect, but some boards don't > > generate the interrupt when card is inserted or removed. So I have to > > use the poll mode. > > > > > >> > Yes, some cases to detect GPIO can't be trusted, so I only just > > >> implement this callback in eSDHC-of driver. that is to say, just > > >> when > > the > > >> platform support it, this callback can be implement, if not, > > >> continue > > to > > >> send the command CMD13. > > >> > > >> I'm just wondering how this will affect our system, where we use > > >> the > > cd > > >> GPIO to generate detect jobs on card insert/remove, but where the > > >> cd > > pin > > >> is not 100% synchronized with the electrical connection of the > > >> power > > and > > >> cmd line of the SD-card. So if I remember correctly, the cd pin may > > >> report that the card has been removed, but there is still an > > >> electric connection and the card is alive... > > >> > > > I don't see this on our board, when card is inserted or removed, the > > register field can reflect this state correctly. > > > > We see a difference on our boards with this patch, but no functional > > change (actually a removed card is detected earlier now), so from my > > perspective: > > > > Reviewed-By: Johan Rudholm <johan.rudholm@stericsson.com> > > > > //Johan > > > -- > 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 -- 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
Hi, Anton and Chris This patch has been Reviewed-By: Johan Rudholm <johan.rudholm@stericsson.com> on Nov 05. Could you give some comment about it? Best Regards Jerry Huang > -----Original Message----- > From: Johan Rudholm [mailto:jrudholm@gmail.com] > Sent: Monday, November 05, 2012 10:08 PM > To: Huang Changming-R66093 > Cc: linux-mmc@vger.kernel.org; Anton Vorontsov; Chris Ball > Subject: Re: [PATCH 2/4 v4] MMC/SD: Add callback function to detect card > > Hi, > > 2012/11/5 Huang Changming-R66093 <r66093@freescale.com>: > >> > >> 2012/11/2 Huang Changming-R66093 <r66093@freescale.com>: > >> > Hi, Johan, > >> > When quicks SDHCI_QUIRK_BROKEN_CARD_DETECTION is set, the driver > will > >> poll the card status with the command CMD13 periodically, then many > >> interrupts will be generated, which affect the performance. > >> > >> Ok, just to see if I understand the scenario correctly: > >> SDHCI_QUIRK_BROKEN_CARD_DETECTION causes the MMC_CAP_NEEDS_POLL cap to > be > >> set, which will cause mmc_rescan to be run at a one second interval. > >> mmc_rescan calls bus_ops->detect (mmc_sd_detect) and this in turn > calls > >> _mmc_detect_card_removed, which will do the bus_ops->alive and send > CMD13. > >> So in this case, one CMD13 is sent per second, right? > >> Is this the cause of the performance issue? > > > > Yes, You are right. > > Ok, it's a bit hard to understand how this can lead to a noticeable > performance impact, but OK. :) > > >> A thought: if the host hardware does have a GPIO card detect pin > hooked > >> up, would it not be possible to make this pin generate an IRQ whenever > a > >> card is inserted or removed? This is what we do in the MMCI driver, > for > >> instance (mmci_cd_irq). > > > > Our silicones has this pin to do card detect, but some boards don't > generate the interrupt when card is inserted or removed. So I have to use > the poll mode. > > > >> > Yes, some cases to detect GPIO can't be trusted, so I only just > >> implement this callback in eSDHC-of driver. that is to say, just when > the > >> platform support it, this callback can be implement, if not, continue > to > >> send the command CMD13. > >> > >> I'm just wondering how this will affect our system, where we use the > cd > >> GPIO to generate detect jobs on card insert/remove, but where the cd > pin > >> is not 100% synchronized with the electrical connection of the power > and > >> cmd line of the SD-card. So if I remember correctly, the cd pin may > >> report that the card has been removed, but there is still an electric > >> connection and the card is alive... > >> > > I don't see this on our board, when card is inserted or removed, the > register field can reflect this state correctly. > > We see a difference on our boards with this patch, but no functional > change (actually a removed card is detected earlier now), so from my > perspective: > > Reviewed-By: Johan Rudholm <johan.rudholm@stericsson.com> > > //Johan -- 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
On Tue, Oct 30, 2012 at 04:12:47PM +0800, r66093@freescale.com wrote: [..] > If the card is present, 1 will return, if the card is absent, 0 will return. > If the controller will not support this feature, -ENOSYS will return. > > Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com> > CC: Anton Vorontsov <cbouatmailru@gmail.com> > CC: Chris Ball <cjb@laptop.org> > --- [...] > int _mmc_detect_card_removed(struct mmc_host *host) > { > - int ret; > + int ret = -ENOSYS; > > if ((host->caps & MMC_CAP_NONREMOVABLE) || !host->bus_ops->alive) > return 0; > @@ -2081,7 +2081,13 @@ int _mmc_detect_card_removed(struct mmc_host *host) > if (!host->card || mmc_card_removed(host->card)) > return 1; > > - ret = host->bus_ops->alive(host); > + if (host->ops->get_cd) { > + ret = host->ops->get_cd(host); > + if (ret >= 0) > + ret = !ret; o_O Oh, I see... Reviewed-by: Anton Vorontsov <cbouatmailru@gmail.com> (But I must confess I didn't follow the whole discussion about get_cd()-via-gpio being unreliable. I'm assuming you fixed this?) > + } > + if (ret < 0) > + ret = host->bus_ops->alive(host); > if (ret) { > mmc_card_set_removed(host->card); > pr_debug("%s: card remove detected\n", mmc_hostname(host)); > -- > 1.7.9.5 -- 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
> -----Original Message----- > From: Anton Vorontsov [mailto:cbouatmailru@gmail.com] > Sent: Monday, November 19, 2012 11:06 AM > To: Huang Changming-R66093 > Cc: linux-mmc@vger.kernel.org; Huang Changming-R66093; Chris Ball > Subject: Re: [PATCH 2/4 v4] MMC/SD: Add callback function to detect card > > On Tue, Oct 30, 2012 at 04:12:47PM +0800, r66093@freescale.com wrote: > [..] > > If the card is present, 1 will return, if the card is absent, 0 will > return. > > If the controller will not support this feature, -ENOSYS will return. > > > > Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com> > > CC: Anton Vorontsov <cbouatmailru@gmail.com> > > CC: Chris Ball <cjb@laptop.org> > > --- > [...] > > int _mmc_detect_card_removed(struct mmc_host *host) > > { > > - int ret; > > + int ret = -ENOSYS; > > > > if ((host->caps & MMC_CAP_NONREMOVABLE) || !host->bus_ops->alive) > > return 0; > > @@ -2081,7 +2081,13 @@ int _mmc_detect_card_removed(struct mmc_host > *host) > > if (!host->card || mmc_card_removed(host->card)) > > return 1; > > > > - ret = host->bus_ops->alive(host); > > + if (host->ops->get_cd) { > > + ret = host->ops->get_cd(host); > > + if (ret >= 0) > > + ret = !ret; > > o_O > > Oh, I see... > > Reviewed-by: Anton Vorontsov <cbouatmailru@gmail.com> > > (But I must confess I didn't follow the whole discussion about > get_cd()-via-gpio being unreliable. I'm assuming you fixed this?) > If the GPIO is unreliable, the related driver may not implement the callback function get_cd. For eSDHC, the GPIO is reliable, so I do it.
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index 9c162cd..6412355 100644 --- a/drivers/mmc/core/core.c +++ b/drivers/mmc/core/core.c @@ -2073,7 +2073,7 @@ static int mmc_rescan_try_freq(struct mmc_host *host, unsigned freq) int _mmc_detect_card_removed(struct mmc_host *host) { - int ret; + int ret = -ENOSYS; if ((host->caps & MMC_CAP_NONREMOVABLE) || !host->bus_ops->alive) return 0; @@ -2081,7 +2081,13 @@ int _mmc_detect_card_removed(struct mmc_host *host) if (!host->card || mmc_card_removed(host->card)) return 1; - ret = host->bus_ops->alive(host); + if (host->ops->get_cd) { + ret = host->ops->get_cd(host); + if (ret >= 0) + ret = !ret; + } + if (ret < 0) + ret = host->bus_ops->alive(host); if (ret) { mmc_card_set_removed(host->card); pr_debug("%s: card remove detected\n", mmc_hostname(host));