mmc: imx: 8-bit bus timeout (4.10-rc1)

mmc: imx: 8-bit bus timeout (4.10-rc1)

[Gary Bisson]

Hi Fabio, Shawn,

While I was testing some pinctrl modifications based on kernel 4.10-rc1,
I've encountered some errors with the sdhci driver:
[   13.919613] mmc2: Timeout waiting for hardware cmd interrupt.
[   13.925400] sdhci: =========== REGISTER DUMP (mmc2)===========
[   13.931260] sdhci: Sys addr: 0x3d733000 | Version:  0x00000002
[   13.937113] sdhci: Blk size: 0x00000200 | Blk cnt:  0x00000001
[   13.942965] sdhci: Argument: 0x00010000 | Trn mode: 0x00000013
[   13.948817] sdhci: Present:  0x01fd8009 | Host ctl: 0x00000031
[   13.954668] sdhci: Power:    0x00000002 | Blk gap:  0x00000080
[   13.960518] sdhci: Wake-up:  0x00000008 | Clock:    0x0000001f
[   13.966369] sdhci: Timeout:  0x0000008f | Int stat: 0x00000000
[   13.972221] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   13.978071] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000003
[   13.983922] sdhci: Caps:     0x07eb0000 | Caps_1:   0x0000a007
[   13.989773] sdhci: Cmd:      0x00000d1a | Max curr: 0x00ffffff
[   13.995623] sdhci: Host ctl2: 0x00000000
[   13.999563] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0xefc7d208
[   14.005406] sdhci: ===========================================
...

This goes on until it finally says:
[  169.532125] mmc2: switch to bus width 8 ddr failed
[  169.536970] mmc2: error -110 whilst initialising MMC card

This issue was seen on a Nitrogen6_MAX and only affects the eMMC (8-bit
bus) whereas the regular SD card slot works fine.

Have you seen such behavior? Is the eMMC on the SABRE platform working
fine?

Regards,
Gary

Re: mmc: imx: 8-bit bus timeout (4.10-rc1)

[Fabio Estevam]

Hi Gary,

On Mon, Jan 2, 2017 at 5:15 PM, Gary Bisson
<gary.bisson@boundarydevices.com> wrote:

> Have you seen such behavior? Is the eMMC on the SABRE platform working
> fine?

Yes, just noticed the same on a mx6qsabresd.

I haven't had a chance to debug this yet.

If you could run a 'git bisect' that would be great. Thanks

Re: mmc: imx: 8-bit bus timeout (4.10-rc1)

[Gary Bisson]

Hi Fabio,

On Mon, Jan 02, 2017 at 07:40:43PM -0200, Fabio Estevam wrote:
> Hi Gary,
> 
> On Mon, Jan 2, 2017 at 5:15 PM, Gary Bisson
> <gary.bisson@boundarydevices.com> wrote:
> 
> > Have you seen such behavior? Is the eMMC on the SABRE platform working
> > fine?
> 
> Yes, just noticed the same on a mx6qsabresd.
> 
> I haven't had a chance to debug this yet.
> 
> If you could run a 'git bisect' that would be great. Thanks

Doing a 'git bisect' shows that the culprit is [1]:
e173f891 mmc: core: Update CMD13 polling policy when switch to HS DDR
mode

Unfortunately I don't know the JEDEC specification enough to know what's
wrong but the patch broke 8-bit eMMC (HS DDR) on i.MX platforms. Which
platform has it beend tested on?

Ulf and Linus have been added to the loop since they know the details.

Also, I confirm that reverting that patch on v4.10-rc1 fixes the issue.

Regards,
Gary

[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/mmc/core/mmc.c?id=e173f891

Re: mmc: imx: 8-bit bus timeout (4.10-rc1)

[Fabio Estevam]

Hi Gary,

On Tue, Jan 3, 2017 at 7:57 AM, Gary Bisson
<gary.bisson@boundarydevices.com> wrote:

> Doing a 'git bisect' shows that the culprit is [1]:
> e173f891 mmc: core: Update CMD13 polling policy when switch to HS DDR
> mode
>
> Unfortunately I don't know the JEDEC specification enough to know what's
> wrong but the patch broke 8-bit eMMC (HS DDR) on i.MX platforms. Which
> platform has it beend tested on?
>
> Ulf and Linus have been added to the loop since they know the details.
>
> Also, I confirm that reverting that patch on v4.10-rc1 fixes the issue.

Thanks for doing the bisect.

I can also confirm that reverting e173f891 ("mmc: core: Update CMD13
polling policy when switch to HS DDR mode") makes the MMC card on
mx6qsabresd to be correctly detected:

mmc2: new DDR MMC card at address 0001

Thanks

Re: mmc: imx: 8-bit bus timeout (4.10-rc1)

[Gary Bisson]

Hi all,

On Tue, Jan 03, 2017 at 09:27:23AM -0200, Fabio Estevam wrote:
> Hi Gary,
> 
> On Tue, Jan 3, 2017 at 7:57 AM, Gary Bisson
> <gary.bisson@boundarydevices.com> wrote:
> 
> > Doing a 'git bisect' shows that the culprit is [1]:
> > e173f891 mmc: core: Update CMD13 polling policy when switch to HS DDR
> > mode
> >
> > Unfortunately I don't know the JEDEC specification enough to know what's
> > wrong but the patch broke 8-bit eMMC (HS DDR) on i.MX platforms. Which
> > platform has it beend tested on?
> >
> > Ulf and Linus have been added to the loop since they know the details.
> >
> > Also, I confirm that reverting that patch on v4.10-rc1 fixes the issue.
> 
> Thanks for doing the bisect.
> 
> I can also confirm that reverting e173f891 ("mmc: core: Update CMD13
> polling policy when switch to HS DDR mode") makes the MMC card on
> mx6qsabresd to be correctly detected:
> 
> mmc2: new DDR MMC card at address 0001

Gentle ping. Should we send a revert patch for next rc cycle?

Regards,
Gary

Re: mmc: imx: 8-bit bus timeout (4.10-rc1)

[Ulf Hansson]

On 12 January 2017 at 11:39, Gary Bisson
<gary.bisson@boundarydevices.com> wrote:
> Hi all,
>
> On Tue, Jan 03, 2017 at 09:27:23AM -0200, Fabio Estevam wrote:
>> Hi Gary,
>>
>> On Tue, Jan 3, 2017 at 7:57 AM, Gary Bisson
>> <gary.bisson@boundarydevices.com> wrote:
>>
>> > Doing a 'git bisect' shows that the culprit is [1]:
>> > e173f891 mmc: core: Update CMD13 polling policy when switch to HS DDR
>> > mode
>> >
>> > Unfortunately I don't know the JEDEC specification enough to know what's
>> > wrong but the patch broke 8-bit eMMC (HS DDR) on i.MX platforms. Which
>> > platform has it beend tested on?
>> >
>> > Ulf and Linus have been added to the loop since they know the details.
>> >
>> > Also, I confirm that reverting that patch on v4.10-rc1 fixes the issue.
>>
>> Thanks for doing the bisect.
>>
>> I can also confirm that reverting e173f891 ("mmc: core: Update CMD13
>> polling policy when switch to HS DDR mode") makes the MMC card on
>> mx6qsabresd to be correctly detected:
>>
>> mmc2: new DDR MMC card at address 0001
>
> Gentle ping. Should we send a revert patch for next rc cycle?

Sorry, I have been busy catching up.

Allow me to have look within the next days or so.

Kind regards
Uffe