headers
Maxim Levitsky | 1 Nov 2010 02:44
Picon

RE: commit mmc: sdhci: add MMC_CAP_8_BIT_DATA in the host

On Sat, 2010-10-30 at 16:01 +0200, Maxim Levitsky wrote:
> On Sat, 2010-10-30 at 05:47 -0700, Philip Rakity wrote:
> > eMMC unlike SD does not have a field to inside the card data to say the bit width of the card.  
> > In addition some mmc cards (from Transcend) only support 1 bit mode.  The physical pins to support 4 bit
data are not there as well as no card specific data saying the bus width of the card.
> > 
> > The only solution is to probe the bus by sending a CMD19 and CMD14 (BUSTEST_W/BUSTEST_R).  
> > This procedure is defined in the JEDEC Standard No. 84-A441 spec -- Annex A.8.3 and this has been working
in our linux 2.6.28/2.6.29 for quite a while.   I can submit a patch if this makes sense.
> > However, it may not work all the time; some controllers do not send out the CMD19 sequence.  The 
(BUSTEST_W/BUSTEST_R) procedure is used in BSD. Also, in SD v3.0 CMD19 is defined for tuning and its
definition is slightly different then in the JEDEC standard.
> > 
> > One option for the problem you are seeing would be for my patch 
> > http://permalink.gmane.org/gmane.linux.kernel.mmc/3966
> > or something like it to be accepted.   As well as adding the bustest procedure. 
> > 
> > At least the board specific data can then say 8 bit data lines are supported on the physical slot.  The
controller can say 8 bit works but normally does not have knowledge of the lower level board design.
> 
> I see two solutions to this problem which you proposed above:
> 
> 1. Allow the controller to tell host that it doesn't support 8-bit.
> However, what about generic sdhci controllers? These that don't have
> quirks in sdhci.c. Are there any desktop sdhci controllers that support
> 8-bit. Note that SDHCI controllers are primary for SD/SDHCI cards not
> MMC. I don't know if extra pins have same locations on SD and MMC cards.
> 
> 2. Test the card for being readable.
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Philip Rakity | 1 Nov 2010 02:52
Favicon

Re: commit mmc: sdhci: add MMC_CAP_8_BIT_DATA in the host


On Oct 31, 2010, at 6:44 PM, Maxim Levitsky wrote:

> On Sat, 2010-10-30 at 16:01 +0200, Maxim Levitsky wrote:
>> On Sat, 2010-10-30 at 05:47 -0700, Philip Rakity wrote:
>>> eMMC unlike SD does not have a field to inside the card data to say the bit width of the card.  
>>> In addition some mmc cards (from Transcend) only support 1 bit mode.  The physical pins to support 4 bit
data are not there as well as no card specific data saying the bus width of the card.
>>> 
>>> The only solution is to probe the bus by sending a CMD19 and CMD14 (BUSTEST_W/BUSTEST_R).  
>>> This procedure is defined in the JEDEC Standard No. 84-A441 spec -- Annex A.8.3 and this has been working
in our linux 2.6.28/2.6.29 for quite a while.   I can submit a patch if this makes sense.
>>> However, it may not work all the time; some controllers do not send out the CMD19 sequence.  The 
(BUSTEST_W/BUSTEST_R) procedure is used in BSD. Also, in SD v3.0 CMD19 is defined for tuning and its
definition is slightly different then in the JEDEC standard.
>>> 
>>> One option for the problem you are seeing would be for my patch 
>>> http://permalink.gmane.org/gmane.linux.kernel.mmc/3966
>>> or something like it to be accepted.   As well as adding the bustest procedure. 
>>> 
>>> At least the board specific data can then say 8 bit data lines are supported on the physical slot.  The
controller can say 8 bit works but normally does not have knowledge of the lower level board design.
>> 
>> I see two solutions to this problem which you proposed above:
>> 
>> 1. Allow the controller to tell host that it doesn't support 8-bit.
>> However, what about generic sdhci controllers? These that don't have
>> quirks in sdhci.c. Are there any desktop sdhci controllers that support
>> 8-bit. Note that SDHCI controllers are primary for SD/SDHCI cards not
>> MMC. I don't know if extra pins have same locations on SD and MMC cards.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ohad Ben-Cohen | 1 Nov 2010 05:50

Re: regression: b43-sdio: probe of mmc0:0001:1 failed with error -16

On Sun, Oct 31, 2010 at 11:51 PM, Arnd Hannemann <arnd <at> arndnet.de> wrote:
>> In Daniel's scenario, mmc_sdio_init_card() fails because
>> mmc_send_relative_addr() returns -110.
>>
>> Can you please check out if that's the same thing you have too ?
>
> No, it seems to be the pm_runtime_get_sync in sdio_bus.c::sdio_bus_probe().

Yeah, this is just the symptom though - pm_runtime_get_sync tries to
power up the card, and eventually mmc_sdio_init_card() is called (by
mmc_sdio_resume which is invoked by mmc_resume_host).

On the XO-1.5 mmc_sdio_init_card() seems to fail due to
mmc_send_relative_addr() returning -110; this may suggest that
although mmc_power_off() and mmc_power_on() were called, we still
didn't have a full power reset, and the card/controller are left at a
weird state.

Can you please check out if that's the same failure in your case too ?

Thanks!
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 4 comments |
headers
Arnd Hannemann | 1 Nov 2010 09:05
Picon

Re: regression: b43-sdio: probe of mmc0:0001:1 failed with error -16

Am 01.11.2010 05:50, schrieb Ohad Ben-Cohen:
> On Sun, Oct 31, 2010 at 11:51 PM, Arnd Hannemann <arnd <at> arndnet.de> wrote:
>>> In Daniel's scenario, mmc_sdio_init_card() fails because
>>> mmc_send_relative_addr() returns -110.
>>>
>>> Can you please check out if that's the same thing you have too ?
>>
>> No, it seems to be the pm_runtime_get_sync in sdio_bus.c::sdio_bus_probe().
> 
> Yeah, this is just the symptom though - pm_runtime_get_sync tries to
> power up the card, and eventually mmc_sdio_init_card() is called (by
> mmc_sdio_resume which is invoked by mmc_resume_host).

No, actually mmc_sdio_init_card() is called _before_ sdio_bus_probe and
the failing pm_runtime_get_sync in my case.
Also mmd_sdio_resume is not called at all.

> On the XO-1.5 mmc_sdio_init_card() seems to fail due to
> mmc_send_relative_addr() returning -110; this may suggest that
> although mmc_power_off() and mmc_power_on() were called, we still
> didn't have a full power reset, and the card/controller are left at a
> weird state.
> 
> Can you please check out if that's the same failure in your case too ?

No mmc_send_relative_addr() does _not_ return -110, actually it
is not called at all.

I inserted a WARN_ON() in sdio_bus_probe, and here is the backtrace I get:
[   32.351562] [<c0034754>] (warn_slowpath_null+0x0/0x2c) from [<c017ef48>] (sdio_bus_probe+0x5c/0xe8)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ohad Ben-Cohen | 1 Nov 2010 09:27

Re: MMC runtime PM patches break libertas probe

Hi Daniel,

On Sun, Oct 31, 2010 at 9:06 PM, Ohad Ben-Cohen <ohad <at> wizery.com> wrote:
...
> we need to support boards with controllers/cards
> which we can't power off in runtime.
>
> On such boards, the right thing to do would be to disable runtime PM altogether.

The patch below (/attached) should trivially fix the problem - can you
please check it out ?

It's very simple: it just requires hosts to explicitly indicate they
support runtime powering off/on their cards (by means of
MMC_CAP_RUNTIME_PM).

There is no way around this I'm afraid: it is legitimate for a
board/host/card configuration not to support powering off the card
after boot, and we must allow it.

In addition having an explicit MMC_CAP_RUNTIME_PM will also allow us
smoother transition to runtime PM behavior. Developers will have to
explicitly turn it on, and will not be surprised if things won't
immediately work.

Please note that this cap is not interchangeable, and can't be replace
with CONFIG_PM_RUNTIME.

Having said that, I still think we need to understand why CMD3 timed
out on the XO-1.5.
(Continue reading)

Permalink | Reply | 17 comments |
headers
Ohad Ben-Cohen | 1 Nov 2010 10:02

Re: regression: b43-sdio: probe of mmc0:0001:1 failed with error -16

On Mon, Nov 1, 2010 at 10:05 AM, Arnd Hannemann <arnd <at> arndnet.de> wrote:
> No, actually mmc_sdio_init_card() is called _before_ sdio_bus_probe

Yes, it is called once at boot while the card is mmc_rescan()ed.

But that's not interesting, because the card is then powered down, and
will only be powered on again when it is probed with a driver.

> Also mmd_sdio_resume is not called at all.

Sorry, I meant mmc_sdio_restore_host.

You should see something like this:

sdio_bus_probe - >
    ... (runtime PM function calls) ... ->
           mmc_power_restore_host ->
                 mmc_sdio_power_restore ->
                        mmc_sdio_init_card -> ...

We have 1 report where the latter mmc_sdio_init_card fails at this
point, and I'm interested to know whether it fails for you, too (and
if yes, where). If it is not even called, I'd appreciate if you can
check out where does this flow break in your case.

> No mmc_send_relative_addr() does _not_ return -110, actually it
> is not called at all.

OK.
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Vrabel | 1 Nov 2010 12:27
Favicon

Re: [PATCH] MMC Agressive clocking framework v6

On 29/10/2010 21:18, Linus Walleij wrote:
> This patch modifies the MMC core code to optionally call the
> set_ios() operation on the driver with the clock frequency set
> to 0 (gate) after a grace period of at least 8 MCLK cycles, then
> restore it (ungate) before any new request. This gives
> the driver the option to shut down the MCI clock to the MMC/SD
> card when the clock frequency is 0, i.e. the core has stated
> that the MCI clock does not need to be generated.

With SDIO cards, 1 bit mode needs to be set on the controller otherwise
many controllers cannot detect card interrupts.

Also some v2.00 SDIO cards in 4-bit mode will not generate card
interrupts unless they are clocked (the spec v2.00 doesn't require them
to be able to but v3.00 does).  I would suggest a white list of v2.00
cards that can generate interrupts asynchronousy.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
zhangfei gao | 1 Nov 2010 15:21
Picon

[Patch 1/1]sdhci: verify ddr50 mode

Based on the work from Adrian and Hanumath, here is the patch to
verify ddr50 for sdhci.c on sdhci-pxa with HYNIX and toshiba eMMC.
Only support emmc DDR50 mode now.
Would you help review, thanks

From 59072fa8fea50634f01009e51c4b5e16308ab466 Mon Sep 17 00:00:00 2001
From: Zhangfei Gao <zhangfei.gao <at> marvell.com>
Date: Mon, 1 Nov 2010 07:43:57 -0400
Subject: [PATCH] sdhci: support DDR50 mode

	Verified DDR50 mode on sdhci-pxa and HYNIX and toshiba eMMC

Signed-off-by: Zhangfei Gao <zhangfei.gao <at> marvell.com>
---
 drivers/mmc/host/sdhci.c |   48 +++++++++++++++++++++++++++++++++++++++++++++-
 drivers/mmc/host/sdhci.h |   15 ++++++++++++-
 2 files changed, 60 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 782c0ee..d9e4ab8 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
 <at>  <at>  -982,6 +982,44  <at>  <at>  static void sdhci_finish_command(struct sdhci_host *host)
 	host->cmd = NULL;
 }

+static void sdhci_set_ddr(struct sdhci_host *host, unsigned int ddr)
+{
+	u16 con;
+	unsigned long timeout;
(Continue reading)

Permalink | Reply | 5 comments |
headers
Arnd Hannemann | 1 Nov 2010 15:22
Picon

Re: regression: b43-sdio: probe of mmc0:0001:1 failed with error -16

Am 01.11.2010 10:02, schrieb Ohad Ben-Cohen:
> On Mon, Nov 1, 2010 at 10:05 AM, Arnd Hannemann <arnd <at> arndnet.de> wrote:
>> No, actually mmc_sdio_init_card() is called _before_ sdio_bus_probe
> 
> Yes, it is called once at boot while the card is mmc_rescan()ed.
> 
> But that's not interesting, because the card is then powered down, and
> will only be powered on again when it is probed with a driver.
> 
>> Also mmd_sdio_resume is not called at all.
> 
> Sorry, I meant mmc_sdio_restore_host.
> 
> You should see something like this:
> 
> sdio_bus_probe - >
>     ... (runtime PM function calls) ... ->
>            mmc_power_restore_host ->
>                  mmc_sdio_power_restore ->
>                         mmc_sdio_init_card -> ...
> 
> We have 1 report where the latter mmc_sdio_init_card fails at this
> point, and I'm interested to know whether it fails for you, too (and
> if yes, where). If it is not even called, I'd appreciate if you can
> check out where does this flow break in your case.

It looks like this:

root <at> ap4evb:~# modprobe b43
[   36.023437] cfg80211: Calling CRDA to update world regulatory domain
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ohad Ben-Cohen | 1 Nov 2010 15:33

Re: regression: b43-sdio: probe of mmc0:0001:1 failed with error -16

On Mon, Nov 1, 2010 at 4:22 PM, Arnd Hannemann <arnd <at> arndnet.de> wrote:
> It looks like this:
>
> root <at> ap4evb:~# modprobe b43
> [   36.023437] cfg80211: Calling CRDA to update world regulatory domain
> [   36.460937] sdio_bus_probe()
> [   36.468750] sdio_bus_probe() calling pm_runtime_get_sync()
> [   36.468750] mmc_power_restore_host() begin
> [   36.570312] mmc_sdio_power_restore() begin
> [   36.570312] mmc_sdio_init_card()
> [   36.578125] mmc_sdio_init_card() mmc_send_io_op_cond ret=-110

OK, thanks. CMD5 time outs. I suspect it's similar to what we have
with the XO-1.5: despite software calling mmc_power_off/on, the
hardware does not go through full power off/on cycle.

>> The interesting part is actually what happens after sdio_bus_probe(),
>> not before it.
>
> Actually nothing special happens after sdio_bus_probe()

The actual failure happens after it (in mmc_sdio_init_card).

> With your patch the problem goes away, thanks.

Thank you for testing this,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 0 comments |

Gmane