sdhci timeout on imx8mq

sdhci timeout on imx8mq

[Fabio Estevam]

Hi,

I observe the following timeout on a imx8mq-evk running linux-next 20200203:

# [   11.747858] mmc0: Timeout waiting for hardware interrupt.
[   11.753264] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[   11.759705] mmc0: sdhci: Sys addr:  0x00000800 | Version:  0x00000002
[   11.766145] mmc0: sdhci: Blk size:  0x00000200 | Blk cnt:  0x00000001
[   11.772584] mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000013
[   11.779024] mmc0: sdhci: Present:   0x01f88a0a | Host ctl: 0x00000011
[   11.785463] mmc0: sdhci: Power:     0x00000002 | Blk gap:  0x00000080
[   11.791902] mmc0: sdhci: Wake-up:   0x00000008 | Clock:    0x000020ff
[   11.798342] mmc0: sdhci: Timeout:   0x0000008f | Int stat: 0x00000000
[   11.804781] mmc0: sdhci: Int enab:  0x117f100b | Sig enab: 0x117f100b
[   11.811220] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00008402
[   11.817660] mmc0: sdhci: Caps:      0x07eb0000 | Caps_1:   0x8000b407
[   11.824100] mmc0: sdhci: Cmd:       0x0000083a | Max curr: 0x00ffffff
[   11.830539] mmc0: sdhci: Resp[0]:   0x00000900 | Resp[1]:  0xffffffff
[   11.836978] mmc0: sdhci: Resp[2]:   0x320f5913 | Resp[3]:  0x00d04f01
[   11.843416] mmc0: sdhci: Host ctl2: 0x00000008
[   11.847860] mmc0: sdhci: ADMA Err:  0x00000001 | ADMA Ptr: 0xf97d2200
[   11.854297] mmc0: sdhci: ============================================
[   11.860908] mmc0: error -110 whilst initialising MMC card
[   12.027806] mmc0: new HS400 MMC card at address 0001
[   12.033283] mmcblk0: mmc0:0001 R1J56L 13.8 GiB
[   12.038007] mmcblk0boot0: mmc0:0001 R1J56L partition 1 4.00 MiB
[   12.044112] mmcblk0boot1: mmc0:0001 R1J56L partition 2 4.00 MiB
[   12.050172] mmcblk0rpmb: mmc0:0001 R1J56L partition 3 128 KiB,
chardev (235:0)
[   12.058210]  mmcblk0: p1 p2

Haven't had a chance to debug this yet, but just reporting in case
anyone has any ideas.

Thanks

sdhci timeout on imx8mq

[Fabio Estevam]

Hi,

I observe the following timeout on a imx8mq-evk running linux-next 20200203:

# [   11.747858] mmc0: Timeout waiting for hardware interrupt.
[   11.753264] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[   11.759705] mmc0: sdhci: Sys addr:  0x00000800 | Version:  0x00000002
[   11.766145] mmc0: sdhci: Blk size:  0x00000200 | Blk cnt:  0x00000001
[   11.772584] mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000013
[   11.779024] mmc0: sdhci: Present:   0x01f88a0a | Host ctl: 0x00000011
[   11.785463] mmc0: sdhci: Power:     0x00000002 | Blk gap:  0x00000080
[   11.791902] mmc0: sdhci: Wake-up:   0x00000008 | Clock:    0x000020ff
[   11.798342] mmc0: sdhci: Timeout:   0x0000008f | Int stat: 0x00000000
[   11.804781] mmc0: sdhci: Int enab:  0x117f100b | Sig enab: 0x117f100b
[   11.811220] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00008402
[   11.817660] mmc0: sdhci: Caps:      0x07eb0000 | Caps_1:   0x8000b407
[   11.824100] mmc0: sdhci: Cmd:       0x0000083a | Max curr: 0x00ffffff
[   11.830539] mmc0: sdhci: Resp[0]:   0x00000900 | Resp[1]:  0xffffffff
[   11.836978] mmc0: sdhci: Resp[2]:   0x320f5913 | Resp[3]:  0x00d04f01
[   11.843416] mmc0: sdhci: Host ctl2: 0x00000008
[   11.847860] mmc0: sdhci: ADMA Err:  0x00000001 | ADMA Ptr: 0xf97d2200
[   11.854297] mmc0: sdhci: ============================================
[   11.860908] mmc0: error -110 whilst initialising MMC card
[   12.027806] mmc0: new HS400 MMC card at address 0001
[   12.033283] mmcblk0: mmc0:0001 R1J56L 13.8 GiB
[   12.038007] mmcblk0boot0: mmc0:0001 R1J56L partition 1 4.00 MiB
[   12.044112] mmcblk0boot1: mmc0:0001 R1J56L partition 2 4.00 MiB
[   12.050172] mmcblk0rpmb: mmc0:0001 R1J56L partition 3 128 KiB,
chardev (235:0)
[   12.058210]  mmcblk0: p1 p2

Haven't had a chance to debug this yet, but just reporting in case
anyone has any ideas.

Thanks

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: sdhci timeout on imx8mq

[Guido Günther]

Hi Fabio,
On Mon, Feb 03, 2020 at 04:19:50PM -0300, Fabio Estevam wrote:
> Hi,
> 
> I observe the following timeout on a imx8mq-evk running linux-next 20200203:
> 
> # [   11.747858] mmc0: Timeout waiting for hardware interrupt.
> [   11.753264] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> [   11.759705] mmc0: sdhci: Sys addr:  0x00000800 | Version:  0x00000002
> [   11.766145] mmc0: sdhci: Blk size:  0x00000200 | Blk cnt:  0x00000001
> [   11.772584] mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000013
> [   11.779024] mmc0: sdhci: Present:   0x01f88a0a | Host ctl: 0x00000011
> [   11.785463] mmc0: sdhci: Power:     0x00000002 | Blk gap:  0x00000080
> [   11.791902] mmc0: sdhci: Wake-up:   0x00000008 | Clock:    0x000020ff
> [   11.798342] mmc0: sdhci: Timeout:   0x0000008f | Int stat: 0x00000000
> [   11.804781] mmc0: sdhci: Int enab:  0x117f100b | Sig enab: 0x117f100b
> [   11.811220] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00008402
> [   11.817660] mmc0: sdhci: Caps:      0x07eb0000 | Caps_1:   0x8000b407
> [   11.824100] mmc0: sdhci: Cmd:       0x0000083a | Max curr: 0x00ffffff
> [   11.830539] mmc0: sdhci: Resp[0]:   0x00000900 | Resp[1]:  0xffffffff
> [   11.836978] mmc0: sdhci: Resp[2]:   0x320f5913 | Resp[3]:  0x00d04f01
> [   11.843416] mmc0: sdhci: Host ctl2: 0x00000008
> [   11.847860] mmc0: sdhci: ADMA Err:  0x00000001 | ADMA Ptr: 0xf97d2200
> [   11.854297] mmc0: sdhci: ============================================
> [   11.860908] mmc0: error -110 whilst initialising MMC card
> [   12.027806] mmc0: new HS400 MMC card at address 0001
> [   12.033283] mmcblk0: mmc0:0001 R1J56L 13.8 GiB
> [   12.038007] mmcblk0boot0: mmc0:0001 R1J56L partition 1 4.00 MiB
> [   12.044112] mmcblk0boot1: mmc0:0001 R1J56L partition 2 4.00 MiB
> [   12.050172] mmcblk0rpmb: mmc0:0001 R1J56L partition 3 128 KiB,
> chardev (235:0)
> [   12.058210]  mmcblk0: p1 p2
> 
> Haven't had a chance to debug this yet, but just reporting in case
> anyone has any ideas.

I've seen the same occasionally on the librem 5 with older linux-next as
well. Do you have a good reproducer?
Cheers,
 -- Guido

> 
> Thanks
> 

Re: sdhci timeout on imx8mq

[Guido Günther]

Hi Fabio,
On Mon, Feb 03, 2020 at 04:19:50PM -0300, Fabio Estevam wrote:
> Hi,
> 
> I observe the following timeout on a imx8mq-evk running linux-next 20200203:
> 
> # [   11.747858] mmc0: Timeout waiting for hardware interrupt.
> [   11.753264] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> [   11.759705] mmc0: sdhci: Sys addr:  0x00000800 | Version:  0x00000002
> [   11.766145] mmc0: sdhci: Blk size:  0x00000200 | Blk cnt:  0x00000001
> [   11.772584] mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000013
> [   11.779024] mmc0: sdhci: Present:   0x01f88a0a | Host ctl: 0x00000011
> [   11.785463] mmc0: sdhci: Power:     0x00000002 | Blk gap:  0x00000080
> [   11.791902] mmc0: sdhci: Wake-up:   0x00000008 | Clock:    0x000020ff
> [   11.798342] mmc0: sdhci: Timeout:   0x0000008f | Int stat: 0x00000000
> [   11.804781] mmc0: sdhci: Int enab:  0x117f100b | Sig enab: 0x117f100b
> [   11.811220] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00008402
> [   11.817660] mmc0: sdhci: Caps:      0x07eb0000 | Caps_1:   0x8000b407
> [   11.824100] mmc0: sdhci: Cmd:       0x0000083a | Max curr: 0x00ffffff
> [   11.830539] mmc0: sdhci: Resp[0]:   0x00000900 | Resp[1]:  0xffffffff
> [   11.836978] mmc0: sdhci: Resp[2]:   0x320f5913 | Resp[3]:  0x00d04f01
> [   11.843416] mmc0: sdhci: Host ctl2: 0x00000008
> [   11.847860] mmc0: sdhci: ADMA Err:  0x00000001 | ADMA Ptr: 0xf97d2200
> [   11.854297] mmc0: sdhci: ============================================
> [   11.860908] mmc0: error -110 whilst initialising MMC card
> [   12.027806] mmc0: new HS400 MMC card at address 0001
> [   12.033283] mmcblk0: mmc0:0001 R1J56L 13.8 GiB
> [   12.038007] mmcblk0boot0: mmc0:0001 R1J56L partition 1 4.00 MiB
> [   12.044112] mmcblk0boot1: mmc0:0001 R1J56L partition 2 4.00 MiB
> [   12.050172] mmcblk0rpmb: mmc0:0001 R1J56L partition 3 128 KiB,
> chardev (235:0)
> [   12.058210]  mmcblk0: p1 p2
> 
> Haven't had a chance to debug this yet, but just reporting in case
> anyone has any ideas.

I've seen the same occasionally on the librem 5 with older linux-next as
well. Do you have a good reproducer?
Cheers,
 -- Guido

> 
> Thanks
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: sdhci timeout on imx8mq

[Fabio Estevam]

Hi Guido,

On Wed, Feb 5, 2020 at 6:26 AM Guido Günther <agx@sigxcpu.org> wrote:

> I've seen the same occasionally on the librem 5 with older linux-next as
> well. Do you have a good reproducer?

Yes, with linux-next I always get this timeout by just booting the
kernel and waiting 1 or 2 minutes without any activity.

Regards,

Fabio Estevam

Re: sdhci timeout on imx8mq

[Fabio Estevam]

Hi Guido,

On Wed, Feb 5, 2020 at 6:26 AM Guido Günther <agx@sigxcpu.org> wrote:

> I've seen the same occasionally on the librem 5 with older linux-next as
> well. Do you have a good reproducer?

Yes, with linux-next I always get this timeout by just booting the
kernel and waiting 1 or 2 minutes without any activity.

Regards,

Fabio Estevam

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: sdhci timeout on imx8mq

[BOUGH CHEN]

> -----Original Message-----
> From: Fabio Estevam <festevam@gmail.com>
> Sent: 2020年2月5日 21:18
> To: Guido Günther <agx@sigxcpu.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>; Adrian Hunter
> <adrian.hunter@intel.com>; linux-mmc <linux-mmc@vger.kernel.org>;
> dl-linux-imx <linux-imx@nxp.com>; Sascha Hauer <kernel@pengutronix.de>;
> moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
> <linux-arm-kernel@lists.infradead.org>
> Subject: Re: sdhci timeout on imx8mq
> 
> Hi Guido,
> 
> On Wed, Feb 5, 2020 at 6:26 AM Guido Günther <agx@sigxcpu.org> wrote:
> 
> > I've seen the same occasionally on the librem 5 with older linux-next
> > as well. Do you have a good reproducer?
> 
> Yes, with linux-next I always get this timeout by just booting the kernel and
> waiting 1 or 2 minutes without any activity.

I will reserve some time next week to check this issue.

Bough Chen
> 
> Regards,
> 
> Fabio Estevam

RE: sdhci timeout on imx8mq

[BOUGH CHEN]

> -----Original Message-----
> From: Fabio Estevam <festevam@gmail.com>
> Sent: 2020年2月5日 21:18
> To: Guido Günther <agx@sigxcpu.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>; Adrian Hunter
> <adrian.hunter@intel.com>; linux-mmc <linux-mmc@vger.kernel.org>;
> dl-linux-imx <linux-imx@nxp.com>; Sascha Hauer <kernel@pengutronix.de>;
> moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
> <linux-arm-kernel@lists.infradead.org>
> Subject: Re: sdhci timeout on imx8mq
> 
> Hi Guido,
> 
> On Wed, Feb 5, 2020 at 6:26 AM Guido Günther <agx@sigxcpu.org> wrote:
> 
> > I've seen the same occasionally on the librem 5 with older linux-next
> > as well. Do you have a good reproducer?
> 
> Yes, with linux-next I always get this timeout by just booting the kernel and
> waiting 1 or 2 minutes without any activity.

I will reserve some time next week to check this issue.

Bough Chen
> 
> Regards,
> 
> Fabio Estevam
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: sdhci timeout on imx8mq

[Fabio Estevam]

Hi Bough,

On Wed, Feb 12, 2020 at 11:33 PM BOUGH CHEN <haibo.chen@nxp.com> wrote:

> The board I use is SCH-29615 REV B4.  This board use Sandisk eMMC chip. Maybe your board use Micron eMMC.

Mine is REV B3 with the Micron eMMC.

> I attach the bootloader I use. Please try this bootloader on your side.

I hope we don't have a bootloader dependency here.

Thanks

Re: sdhci timeout on imx8mq

[Fabio Estevam]

Hi Bough,

On Wed, Feb 12, 2020 at 11:33 PM BOUGH CHEN <haibo.chen@nxp.com> wrote:

> The board I use is SCH-29615 REV B4.  This board use Sandisk eMMC chip. Maybe your board use Micron eMMC.

Mine is REV B3 with the Micron eMMC.

> I attach the bootloader I use. Please try this bootloader on your side.

I hope we don't have a bootloader dependency here.

Thanks

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: sdhci timeout on imx8mq

[Angus Ainslie]

Hi Fabio, Bough

On 2020-02-13 02:53, Fabio Estevam wrote:
> Hi Bough,
> 
> On Wed, Feb 12, 2020 at 11:33 PM BOUGH CHEN <haibo.chen@nxp.com> wrote:
> 
>> The board I use is SCH-29615 REV B4.  This board use Sandisk eMMC 
>> chip. Maybe your board use Micron eMMC.
> 
> Mine is REV B3 with the Micron eMMC.
> 
>> I attach the bootloader I use. Please try this bootloader on your 
>> side.
> 
> I hope we don't have a bootloader dependency here.
> 

Has there been any progress with this. I'm getting this on about 50% of 
boots with 5.7.5 in some configurations. I'm working on the USB 
subsystem so nothing that should directly influence the sdhci code.

Our device tree setup for the usdhc is the same as the imx8mq-evk

https://source.puri.sm/Librem5/linux-next/-/blob/imx8-current-librem5/arch/arm64/boot/dts/freescale/imx8mq-librem5.dts#L836

Thanks
Angus

> Thanks
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: sdhci timeout on imx8mq

[Angus Ainslie]

Hi Fabio, Bough

On 2020-02-13 02:53, Fabio Estevam wrote:
> Hi Bough,
> 
> On Wed, Feb 12, 2020 at 11:33 PM BOUGH CHEN <haibo.chen@nxp.com> wrote:
> 
>> The board I use is SCH-29615 REV B4.  This board use Sandisk eMMC 
>> chip. Maybe your board use Micron eMMC.
> 
> Mine is REV B3 with the Micron eMMC.
> 
>> I attach the bootloader I use. Please try this bootloader on your 
>> side.
> 
> I hope we don't have a bootloader dependency here.
> 

Has there been any progress with this. I'm getting this on about 50% of 
boots with 5.7.5 in some configurations. I'm working on the USB 
subsystem so nothing that should directly influence the sdhci code.

Our device tree setup for the usdhc is the same as the imx8mq-evk

https://source.puri.sm/Librem5/linux-next/-/blob/imx8-current-librem5/arch/arm64/boot/dts/freescale/imx8mq-librem5.dts#L836

Thanks
Angus

> Thanks
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: sdhci timeout on imx8mq

[Fabio Estevam]

Hi Angus,

On Tue, Jun 30, 2020 at 4:39 PM Angus Ainslie <angus@akkea.ca> wrote:

> Has there been any progress with this. I'm getting this on about 50% of

Not from my side, sorry.

Bough,

Do you know why this problem affects the imx8mq-evk versions that are
populated with the Micron eMMC and not the ones with Sandisk eMMC?

Thanks

Re: sdhci timeout on imx8mq

[Fabio Estevam]

Hi Angus,

On Tue, Jun 30, 2020 at 4:39 PM Angus Ainslie <angus@akkea.ca> wrote:

> Has there been any progress with this. I'm getting this on about 50% of

Not from my side, sorry.

Bough,

Do you know why this problem affects the imx8mq-evk versions that are
populated with the Micron eMMC and not the ones with Sandisk eMMC?

Thanks

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: sdhci timeout on imx8mq

[BOUGH CHEN]

> -----Original Message-----
> From: Fabio Estevam [mailto:festevam@gmail.com]
> Sent: 2020年7月7日 20:45
> To: Angus Ainslie <angus@akkea.ca>
> Cc: BOUGH CHEN <haibo.chen@nxp.com>; Ulf Hansson
> <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>; linux-mmc
> <linux-mmc@vger.kernel.org>; Adrian Hunter <adrian.hunter@intel.com>;
> dl-linux-imx <linux-imx@nxp.com>; Sascha Hauer <kernel@pengutronix.de>;
> moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
> <linux-arm-kernel@lists.infradead.org>
> Subject: Re: sdhci timeout on imx8mq
> 
> Hi Angus,
> 
> On Tue, Jun 30, 2020 at 4:39 PM Angus Ainslie <angus@akkea.ca> wrote:
> 
> > Has there been any progress with this. I'm getting this on about 50%
> > of
> 
> Not from my side, sorry.
> 
> Bough,
> 
> Do you know why this problem affects the imx8mq-evk versions that are
> populated with the Micron eMMC and not the ones with Sandisk eMMC?

Hi Angus,

Can you show me the full fail log? I do not meet this issue on my side, besides, which kind of uboot do you use?

Best Regards
Haibo Chen
> 
> Thanks

RE: sdhci timeout on imx8mq

[BOUGH CHEN]

> -----Original Message-----
> From: Fabio Estevam [mailto:festevam@gmail.com]
> Sent: 2020年7月7日 20:45
> To: Angus Ainslie <angus@akkea.ca>
> Cc: BOUGH CHEN <haibo.chen@nxp.com>; Ulf Hansson
> <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>; linux-mmc
> <linux-mmc@vger.kernel.org>; Adrian Hunter <adrian.hunter@intel.com>;
> dl-linux-imx <linux-imx@nxp.com>; Sascha Hauer <kernel@pengutronix.de>;
> moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
> <linux-arm-kernel@lists.infradead.org>
> Subject: Re: sdhci timeout on imx8mq
> 
> Hi Angus,
> 
> On Tue, Jun 30, 2020 at 4:39 PM Angus Ainslie <angus@akkea.ca> wrote:
> 
> > Has there been any progress with this. I'm getting this on about 50%
> > of
> 
> Not from my side, sorry.
> 
> Bough,
> 
> Do you know why this problem affects the imx8mq-evk versions that are
> populated with the Micron eMMC and not the ones with Sandisk eMMC?

Hi Angus,

Can you show me the full fail log? I do not meet this issue on my side, besides, which kind of uboot do you use?

Best Regards
Haibo Chen
> 
> Thanks
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: sdhci timeout on imx8mq

[Lucas Stach]

Hi all,

Am Mittwoch, dem 08.07.2020 um 01:32 +0000 schrieb BOUGH CHEN:
> -----Original Message-----
> From: Fabio Estevam [mailto:festevam@gmail.com]
> Sent: 2020年7月7日 20:45
> To: Angus Ainslie <angus@akkea.ca>
> Cc: BOUGH CHEN <haibo.chen@nxp.com>; Ulf Hansson
> <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>; linux-mmc
> <linux-mmc@vger.kernel.org>; Adrian Hunter <adrian.hunter@intel.com>;
> dl-linux-imx <linux-imx@nxp.com>; Sascha Hauer
> <kernel@pengutronix.de>;
> moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
> <linux-arm-kernel@lists.infradead.org>
> Subject: Re: sdhci timeout on imx8mq
> 
> Hi Angus,
> 
> On Tue, Jun 30, 2020 at 4:39 PM Angus Ainslie <angus@akkea.ca> wrote:
> 
> > Has there been any progress with this. I'm getting this on about
> > 50%
> > of
> 
> Not from my side, sorry.
> 
> Bough,
> 
> Do you know why this problem affects the imx8mq-evk versions that are
> populated with the Micron eMMC and not the ones with Sandisk eMMC?

Hi Angus,

Can you show me the full fail log? I do not meet this issue on my side,
besides, which kind of uboot do you use?

Has there been any progress on this issue? I'm now hitting this on a
system that just upgraded from 5.4 to 5.10. Has anyone tried bisecting
this issue, yet?

Regards,
Lucas

Re: sdhci timeout on imx8mq

[Lucas Stach]

Hi all,

Am Mittwoch, dem 08.07.2020 um 01:32 +0000 schrieb BOUGH CHEN:
> -----Original Message-----
> From: Fabio Estevam [mailto:festevam@gmail.com]
> Sent: 2020年7月7日 20:45
> To: Angus Ainslie <angus@akkea.ca>
> Cc: BOUGH CHEN <haibo.chen@nxp.com>; Ulf Hansson
> <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>; linux-mmc
> <linux-mmc@vger.kernel.org>; Adrian Hunter <adrian.hunter@intel.com>;
> dl-linux-imx <linux-imx@nxp.com>; Sascha Hauer
> <kernel@pengutronix.de>;
> moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
> <linux-arm-kernel@lists.infradead.org>
> Subject: Re: sdhci timeout on imx8mq
> 
> Hi Angus,
> 
> On Tue, Jun 30, 2020 at 4:39 PM Angus Ainslie <angus@akkea.ca> wrote:
> 
> > Has there been any progress with this. I'm getting this on about
> > 50%
> > of
> 
> Not from my side, sorry.
> 
> Bough,
> 
> Do you know why this problem affects the imx8mq-evk versions that are
> populated with the Micron eMMC and not the ones with Sandisk eMMC?

Hi Angus,

Can you show me the full fail log? I do not meet this issue on my side,
besides, which kind of uboot do you use?

Has there been any progress on this issue? I'm now hitting this on a
system that just upgraded from 5.4 to 5.10. Has anyone tried bisecting
this issue, yet?

Regards,
Lucas


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: sdhci timeout on imx8mq

[Angus Ainslie]

Hi Lucas,

Thanks for the ping, I've been meaning to get back to this.

On 2020-12-18 12:07, Lucas Stach wrote:
> Hi all,
> 
> Am Mittwoch, dem 08.07.2020 um 01:32 +0000 schrieb BOUGH CHEN:
>> -----Original Message-----
>> From: Fabio Estevam [mailto:festevam@gmail.com]
>> Sent: 2020年7月7日 20:45
>> To: Angus Ainslie <angus@akkea.ca>
>> Cc: BOUGH CHEN <haibo.chen@nxp.com>; Ulf Hansson
>> <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>; linux-mmc
>> <linux-mmc@vger.kernel.org>; Adrian Hunter <adrian.hunter@intel.com>;
>> dl-linux-imx <linux-imx@nxp.com>; Sascha Hauer
>> <kernel@pengutronix.de>;
>> moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
>> <linux-arm-kernel@lists.infradead.org>
>> Subject: Re: sdhci timeout on imx8mq
>> 
>> Hi Angus,
>> 
>> On Tue, Jun 30, 2020 at 4:39 PM Angus Ainslie <angus@akkea.ca> wrote:
>> 
>> > Has there been any progress with this. I'm getting this on about
>> > 50%
>> > of
>> 
>> Not from my side, sorry.
>> 
>> Bough,
>> 
>> Do you know why this problem affects the imx8mq-evk versions that are
>> populated with the Micron eMMC and not the ones with Sandisk eMMC?
> 
> Hi Angus,
> 
> Can you show me the full fail log? I do not meet this issue on my side,
> besides, which kind of uboot do you use?

I have not seen this on any of my devices running 5.9.x but I think 
there have been reports of this still failing so I'll try and find out 
whether it's with the 5.9.x kernel or newer.

We're using a modified imx u-boot

https://source.puri.sm/Librem5/uboot-imx/

> 
> Has there been any progress on this issue? I'm now hitting this on a
> system that just upgraded from 5.4 to 5.10. Has anyone tried bisecting
> this issue, yet?

We have other issues with 5.10 right now so it hasn't had much testing.

Angus

> 
> Regards,
> Lucas

Re: sdhci timeout on imx8mq

[Angus Ainslie]

Hi Lucas,

Thanks for the ping, I've been meaning to get back to this.

On 2020-12-18 12:07, Lucas Stach wrote:
> Hi all,
> 
> Am Mittwoch, dem 08.07.2020 um 01:32 +0000 schrieb BOUGH CHEN:
>> -----Original Message-----
>> From: Fabio Estevam [mailto:festevam@gmail.com]
>> Sent: 2020年7月7日 20:45
>> To: Angus Ainslie <angus@akkea.ca>
>> Cc: BOUGH CHEN <haibo.chen@nxp.com>; Ulf Hansson
>> <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>; linux-mmc
>> <linux-mmc@vger.kernel.org>; Adrian Hunter <adrian.hunter@intel.com>;
>> dl-linux-imx <linux-imx@nxp.com>; Sascha Hauer
>> <kernel@pengutronix.de>;
>> moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
>> <linux-arm-kernel@lists.infradead.org>
>> Subject: Re: sdhci timeout on imx8mq
>> 
>> Hi Angus,
>> 
>> On Tue, Jun 30, 2020 at 4:39 PM Angus Ainslie <angus@akkea.ca> wrote:
>> 
>> > Has there been any progress with this. I'm getting this on about
>> > 50%
>> > of
>> 
>> Not from my side, sorry.
>> 
>> Bough,
>> 
>> Do you know why this problem affects the imx8mq-evk versions that are
>> populated with the Micron eMMC and not the ones with Sandisk eMMC?
> 
> Hi Angus,
> 
> Can you show me the full fail log? I do not meet this issue on my side,
> besides, which kind of uboot do you use?

I have not seen this on any of my devices running 5.9.x but I think 
there have been reports of this still failing so I'll try and find out 
whether it's with the 5.9.x kernel or newer.

We're using a modified imx u-boot

https://source.puri.sm/Librem5/uboot-imx/

> 
> Has there been any progress on this issue? I'm now hitting this on a
> system that just upgraded from 5.4 to 5.10. Has anyone tried bisecting
> this issue, yet?

We have other issues with 5.10 right now so it hasn't had much testing.

Angus

> 
> Regards,
> Lucas

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: sdhci timeout on imx8mq

[Angus Ainslie]

Hi Lucas,

On 2020-12-18 12:07, Lucas Stach wrote:
> 
> Can you show me the full fail log? I do not meet this issue on my side,
> besides, which kind of uboot do you use?
> 

I've got the dmesg output and it's 33K. Should I send it to the list or 
do you want to see it out of band ?

The 2 relevant sections are

[   13.281867] mmc0: Timeout waiting for hardware interrupt.
[   13.287310] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[   13.293810] mmc0: sdhci: Sys addr:  0x00000800 | Version:  0x00000002
[   13.300290] mmc0: sdhci: Blk size:  0x00000200 | Blk cnt:  0x00000001
[   13.306774] mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000013
[   13.313258] mmc0: sdhci: Present:   0x01f88a0a | Host ctl: 0x00000011
[   13.319738] mmc0: sdhci: Power:     0x00000002 | Blk gap:  0x00000080
[   13.326218] mmc0: sdhci: Wake-up:   0x00000008 | Clock:    0x000020ff
[   13.332699] mmc0: sdhci: Timeout:   0x0000008f | Int stat: 0x00000000
[   13.339178] mmc0: sdhci: Int enab:  0x107f100b | Sig enab: 0x107f100b
[   13.345658] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00008402
[   13.352141] mmc0: sdhci: Caps:      0x07eb0000 | Caps_1:   0x8000b407
[   13.358622] mmc0: sdhci: Cmd:       0x0000083a | Max curr: 0x00ffffff
[   13.365106] mmc0: sdhci: Resp[0]:   0x00000900 | Resp[1]:  0xffffffff
[   13.371589] mmc0: sdhci: Resp[2]:   0x328f5903 | Resp[3]:  0x00d02700
[   13.378068] mmc0: sdhci: Host ctl2: 0x00000000
[   13.382554] mmc0: sdhci: ADMA Err:  0x00000001 | ADMA Ptr: 0xe5b90200
[   13.389042] mmc0: sdhci-esdhc-imx: ========= ESDHC IMX DEBUG STATUS 
DUMP =========
[   13.396661] mmc0: sdhci-esdhc-imx: cmd debug status:  0x2100
[   13.402361] mmc0: sdhci-esdhc-imx: data debug status:  0x2200
[   13.408119] mmc0: sdhci-esdhc-imx: trans debug status:  0x2300
[   13.413991] mmc0: sdhci-esdhc-imx: dma debug status:  0x2402
[   13.419718] mmc0: sdhci-esdhc-imx: adma debug status:  0x2501
[   13.425478] mmc0: sdhci-esdhc-imx: fifo debug status:  0x2610
[   13.431294] mmc0: sdhci-esdhc-imx: async fifo debug status:  0x2751
[   13.437600] mmc0: sdhci: ============================================
[   13.453076] mmc0: error -110 whilst initialising MMC card
[   13.662288] mmc0: new HS400 MMC card at address 0001
[   13.676191] mmcblk0: mmc0:0001 032G32 29.1 GiB
[   13.684755] mmcblk0boot0: mmc0:0001 032G32 partition 1 4.00 MiB
[   13.694405] mmcblk0boot1: mmc0:0001 032G32 partition 2 4.00 MiB
[   13.702264] mmcblk0rpmb: mmc0:0001 032G32 partition 3 4.00 MiB, 
chardev (245:0)
[   13.715966]  mmcblk0: p1 p2

[   29.665891] mmc1: Timeout waiting for hardware interrupt.
[   29.671310] mmc1: sdhci: ============ SDHCI REGISTER DUMP ===========
[   29.677758] mmc1: sdhci: Sys addr:  0x00000800 | Version:  0x00000002
[   29.684201] mmc1: sdhci: Blk size:  0x00000004 | Blk cnt:  0x00000001
[   29.690642] mmc1: sdhci: Argument:  0x12008004 | Trn mode: 0x00000013
[   29.697086] mmc1: sdhci: Present:   0x01f88a0a | Host ctl: 0x00000013
[   29.703529] mmc1: sdhci: Power:     0x00000002 | Blk gap:  0x00000080
[   29.709980] mmc1: sdhci: Wake-up:   0x00000008 | Clock:    0x0000003f
[   29.716426] mmc1: sdhci: Timeout:   0x0000008f | Int stat: 0x00000000
[   29.722868] mmc1: sdhci: Int enab:  0x107f110b | Sig enab: 0x107f110b
[   29.729310] mmc1: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00008402
[   29.735754] mmc1: sdhci: Caps:      0x07eb0000 | Caps_1:   0x8000b407
[   29.742212] mmc1: sdhci: Cmd:       0x0000353a | Max curr: 0x00ffffff
[   29.748658] mmc1: sdhci: Resp[0]:   0x00002000 | Resp[1]:  0x00000000
[   29.755099] mmc1: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000000
[   29.761540] mmc1: sdhci: Host ctl2: 0x00000000
[   29.765989] mmc1: sdhci: ADMA Err:  0x00000001 | ADMA Ptr: 0xe6605200
[   29.772439] mmc1: sdhci-esdhc-imx: ========= ESDHC IMX DEBUG STATUS 
DUMP =========
[   29.780026] mmc1: sdhci-esdhc-imx: cmd debug status:  0x2100
[   29.785692] mmc1: sdhci-esdhc-imx: data debug status:  0x2200
[   29.791448] mmc1: sdhci-esdhc-imx: trans debug status:  0x2300
[   29.797284] mmc1: sdhci-esdhc-imx: dma debug status:  0x2402
[   29.802943] mmc1: sdhci-esdhc-imx: adma debug status:  0x2501
[   29.808690] mmc1: sdhci-esdhc-imx: fifo debug status:  0x2690
[   29.814437] mmc1: sdhci-esdhc-imx: async fifo debug status:  0x2751
[   29.820701] mmc1: sdhci: ============================================

Thanks
Angus

Re: sdhci timeout on imx8mq

[Angus Ainslie]

Hi Lucas,

On 2020-12-18 12:07, Lucas Stach wrote:
> 
> Can you show me the full fail log? I do not meet this issue on my side,
> besides, which kind of uboot do you use?
> 

I've got the dmesg output and it's 33K. Should I send it to the list or 
do you want to see it out of band ?

The 2 relevant sections are

[   13.281867] mmc0: Timeout waiting for hardware interrupt.
[   13.287310] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[   13.293810] mmc0: sdhci: Sys addr:  0x00000800 | Version:  0x00000002
[   13.300290] mmc0: sdhci: Blk size:  0x00000200 | Blk cnt:  0x00000001
[   13.306774] mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000013
[   13.313258] mmc0: sdhci: Present:   0x01f88a0a | Host ctl: 0x00000011
[   13.319738] mmc0: sdhci: Power:     0x00000002 | Blk gap:  0x00000080
[   13.326218] mmc0: sdhci: Wake-up:   0x00000008 | Clock:    0x000020ff
[   13.332699] mmc0: sdhci: Timeout:   0x0000008f | Int stat: 0x00000000
[   13.339178] mmc0: sdhci: Int enab:  0x107f100b | Sig enab: 0x107f100b
[   13.345658] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00008402
[   13.352141] mmc0: sdhci: Caps:      0x07eb0000 | Caps_1:   0x8000b407
[   13.358622] mmc0: sdhci: Cmd:       0x0000083a | Max curr: 0x00ffffff
[   13.365106] mmc0: sdhci: Resp[0]:   0x00000900 | Resp[1]:  0xffffffff
[   13.371589] mmc0: sdhci: Resp[2]:   0x328f5903 | Resp[3]:  0x00d02700
[   13.378068] mmc0: sdhci: Host ctl2: 0x00000000
[   13.382554] mmc0: sdhci: ADMA Err:  0x00000001 | ADMA Ptr: 0xe5b90200
[   13.389042] mmc0: sdhci-esdhc-imx: ========= ESDHC IMX DEBUG STATUS 
DUMP =========
[   13.396661] mmc0: sdhci-esdhc-imx: cmd debug status:  0x2100
[   13.402361] mmc0: sdhci-esdhc-imx: data debug status:  0x2200
[   13.408119] mmc0: sdhci-esdhc-imx: trans debug status:  0x2300
[   13.413991] mmc0: sdhci-esdhc-imx: dma debug status:  0x2402
[   13.419718] mmc0: sdhci-esdhc-imx: adma debug status:  0x2501
[   13.425478] mmc0: sdhci-esdhc-imx: fifo debug status:  0x2610
[   13.431294] mmc0: sdhci-esdhc-imx: async fifo debug status:  0x2751
[   13.437600] mmc0: sdhci: ============================================
[   13.453076] mmc0: error -110 whilst initialising MMC card
[   13.662288] mmc0: new HS400 MMC card at address 0001
[   13.676191] mmcblk0: mmc0:0001 032G32 29.1 GiB
[   13.684755] mmcblk0boot0: mmc0:0001 032G32 partition 1 4.00 MiB
[   13.694405] mmcblk0boot1: mmc0:0001 032G32 partition 2 4.00 MiB
[   13.702264] mmcblk0rpmb: mmc0:0001 032G32 partition 3 4.00 MiB, 
chardev (245:0)
[   13.715966]  mmcblk0: p1 p2

[   29.665891] mmc1: Timeout waiting for hardware interrupt.
[   29.671310] mmc1: sdhci: ============ SDHCI REGISTER DUMP ===========
[   29.677758] mmc1: sdhci: Sys addr:  0x00000800 | Version:  0x00000002
[   29.684201] mmc1: sdhci: Blk size:  0x00000004 | Blk cnt:  0x00000001
[   29.690642] mmc1: sdhci: Argument:  0x12008004 | Trn mode: 0x00000013
[   29.697086] mmc1: sdhci: Present:   0x01f88a0a | Host ctl: 0x00000013
[   29.703529] mmc1: sdhci: Power:     0x00000002 | Blk gap:  0x00000080
[   29.709980] mmc1: sdhci: Wake-up:   0x00000008 | Clock:    0x0000003f
[   29.716426] mmc1: sdhci: Timeout:   0x0000008f | Int stat: 0x00000000
[   29.722868] mmc1: sdhci: Int enab:  0x107f110b | Sig enab: 0x107f110b
[   29.729310] mmc1: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00008402
[   29.735754] mmc1: sdhci: Caps:      0x07eb0000 | Caps_1:   0x8000b407
[   29.742212] mmc1: sdhci: Cmd:       0x0000353a | Max curr: 0x00ffffff
[   29.748658] mmc1: sdhci: Resp[0]:   0x00002000 | Resp[1]:  0x00000000
[   29.755099] mmc1: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000000
[   29.761540] mmc1: sdhci: Host ctl2: 0x00000000
[   29.765989] mmc1: sdhci: ADMA Err:  0x00000001 | ADMA Ptr: 0xe6605200
[   29.772439] mmc1: sdhci-esdhc-imx: ========= ESDHC IMX DEBUG STATUS 
DUMP =========
[   29.780026] mmc1: sdhci-esdhc-imx: cmd debug status:  0x2100
[   29.785692] mmc1: sdhci-esdhc-imx: data debug status:  0x2200
[   29.791448] mmc1: sdhci-esdhc-imx: trans debug status:  0x2300
[   29.797284] mmc1: sdhci-esdhc-imx: dma debug status:  0x2402
[   29.802943] mmc1: sdhci-esdhc-imx: adma debug status:  0x2501
[   29.808690] mmc1: sdhci-esdhc-imx: fifo debug status:  0x2690
[   29.814437] mmc1: sdhci-esdhc-imx: async fifo debug status:  0x2751
[   29.820701] mmc1: sdhci: ============================================

Thanks
Angus

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: sdhci timeout on imx8mq

[Lucas Stach]

Hi all,

Am Mittwoch, dem 08.07.2020 um 01:32 +0000 schrieb BOUGH CHEN:
> > -----Original Message-----
> > From: Fabio Estevam [mailto:festevam@gmail.com]
> > Sent: 2020年7月7日 20:45
> > To: Angus Ainslie <angus@akkea.ca>
> > Cc: BOUGH CHEN <haibo.chen@nxp.com>; Ulf Hansson
> > <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>; linux-
> > mmc
> > <linux-mmc@vger.kernel.org>; Adrian Hunter
> > <adrian.hunter@intel.com>;
> > dl-linux-imx <linux-imx@nxp.com>; Sascha Hauer <
> > kernel@pengutronix.de>;
> > moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
> > <linux-arm-kernel@lists.infradead.org>
> > Subject: Re: sdhci timeout on imx8mq
> > 
> > Hi Angus,
> > 
> > On Tue, Jun 30, 2020 at 4:39 PM Angus Ainslie <angus@akkea.ca>
> > wrote:
> > 
> > > Has there been any progress with this. I'm getting this on about
> > > 50%
> > > of
> > 
> > Not from my side, sorry.
> > 
> > Bough,
> > 
> > Do you know why this problem affects the imx8mq-evk versions that
> > are
> > populated with the Micron eMMC and not the ones with Sandisk eMMC?
> 
> Hi Angus,
> 
> Can you show me the full fail log? I do not meet this issue on my
> side, besides, which kind of uboot do you use?

I was finally able to bisect this issue, which wasn't that much fun due
to the issue not being reproducible 100%. :/ Turns out that the issue
is even more interesting than I thought and likely doesn't have
anything to do with SDHCI or used bootloader versions. Here's my
current debugging state:

I've bisected the issue down to b04383b6a558 (clk: imx8mq: Define gates
for pll1/2 fixed dividers). The change itself looks fine to me, still
CC'ed Leonard for good measure.

In my testing the following partial revert fixes the issue:

--- a/drivers/clk/imx/clk-imx8mq.c
+++ b/drivers/clk/imx/clk-imx8mq.c
@@ -365,7 +365,7 @@ static int imx8mq_clocks_probe(struct platform_device *pdev)
        hws[IMX8MQ_SYS1_PLL_133M_CG] = imx_clk_hw_gate("sys1_pll_133m_cg", "sys1_pll_out", base + 0x30, 15);
        hws[IMX8MQ_SYS1_PLL_160M_CG] = imx_clk_hw_gate("sys1_pll_160m_cg", "sys1_pll_out", base + 0x30, 17);
        hws[IMX8MQ_SYS1_PLL_200M_CG] = imx_clk_hw_gate("sys1_pll_200m_cg", "sys1_pll_out", base + 0x30, 19);
-       hws[IMX8MQ_SYS1_PLL_266M_CG] = imx_clk_hw_gate("sys1_pll_266m_cg", "sys1_pll_out", base + 0x30, 21);
        hws[IMX8MQ_SYS1_PLL_400M_CG] = imx_clk_hw_gate("sys1_pll_400m_cg", "sys1_pll_out", base + 0x30, 23);
        hws[IMX8MQ_SYS1_PLL_800M_CG] = imx_clk_hw_gate("sys1_pll_800m_cg", "sys1_pll_out", base + 0x30, 25);
 
@@ -375,7 +375,7 @@ static int imx8mq_clocks_probe(struct platform_device *pdev)
        hws[IMX8MQ_SYS1_PLL_133M] = imx_clk_hw_fixed_factor("sys1_pll_133m", "sys1_pll_133m_cg", 1, 6);
        hws[IMX8MQ_SYS1_PLL_160M] = imx_clk_hw_fixed_factor("sys1_pll_160m", "sys1_pll_160m_cg", 1, 5);
        hws[IMX8MQ_SYS1_PLL_200M] = imx_clk_hw_fixed_factor("sys1_pll_200m", "sys1_pll_200m_cg", 1, 4);
-       hws[IMX8MQ_SYS1_PLL_266M] = imx_clk_hw_fixed_factor("sys1_pll_266m", "sys1_pll_266m_cg", 1, 3);
+       hws[IMX8MQ_SYS1_PLL_266M] = imx_clk_hw_fixed_factor("sys1_pll_266m", "sys1_pll_out", 1, 3);
        hws[IMX8MQ_SYS1_PLL_400M] = imx_clk_hw_fixed_factor("sys1_pll_400m", "sys1_pll_400m_cg", 1, 2);
        hws[IMX8MQ_SYS1_PLL_800M] = imx_clk_hw_fixed_factor("sys1_pll_800m", "sys1_pll_800m_cg", 1, 1);

The sys1_pll_266m is the parent of nand_usdhc_bus. I've validated that
the SDHCI driver properly enables this bus clock across the problematic
card access. So what I think is happening here is that both
nand_usdhc_bus and sys1_pll_266m are initially enabled. Sometime during
boot sys1_pll_266m gets disabled due to runtime PM on the enet_axi
clock, which is a direct child of sys1_pll_266m. At this point
nand_usdhc_bus is still enabled, but no consumer has claimed the clock
yet, so the parent clock gets disabled while this branch of the clock
tree is still active.

The reference manual states about this situation: "For any clock, its
source must be left on when it is kept on. Behavior is undefined if
this rule is violated."
And it seems this is exactly what's happening here: some kind of glitch
is introduced in the nand_usdhc_bus clock, which prevents the SDHCI
controller from working, even though the clock branch is properly
enabled later on. On my system the SDHCI timeout and following runtime
suspend/resume cycle on the nand_usdhc_bus clock seem to get it back
into a working state.

So I think we need some solution at the clock driver/framework level to
prevent shutting down parent clocks that have active branches, even if
those branches aren't claimed by a consumer (yet).

Regards,
Lucas

Re: sdhci timeout on imx8mq

[Lucas Stach]

Hi all,

Am Mittwoch, dem 08.07.2020 um 01:32 +0000 schrieb BOUGH CHEN:
> > -----Original Message-----
> > From: Fabio Estevam [mailto:festevam@gmail.com]
> > Sent: 2020年7月7日 20:45
> > To: Angus Ainslie <angus@akkea.ca>
> > Cc: BOUGH CHEN <haibo.chen@nxp.com>; Ulf Hansson
> > <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>; linux-
> > mmc
> > <linux-mmc@vger.kernel.org>; Adrian Hunter
> > <adrian.hunter@intel.com>;
> > dl-linux-imx <linux-imx@nxp.com>; Sascha Hauer <
> > kernel@pengutronix.de>;
> > moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
> > <linux-arm-kernel@lists.infradead.org>
> > Subject: Re: sdhci timeout on imx8mq
> > 
> > Hi Angus,
> > 
> > On Tue, Jun 30, 2020 at 4:39 PM Angus Ainslie <angus@akkea.ca>
> > wrote:
> > 
> > > Has there been any progress with this. I'm getting this on about
> > > 50%
> > > of
> > 
> > Not from my side, sorry.
> > 
> > Bough,
> > 
> > Do you know why this problem affects the imx8mq-evk versions that
> > are
> > populated with the Micron eMMC and not the ones with Sandisk eMMC?
> 
> Hi Angus,
> 
> Can you show me the full fail log? I do not meet this issue on my
> side, besides, which kind of uboot do you use?

I was finally able to bisect this issue, which wasn't that much fun due
to the issue not being reproducible 100%. :/ Turns out that the issue
is even more interesting than I thought and likely doesn't have
anything to do with SDHCI or used bootloader versions. Here's my
current debugging state:

I've bisected the issue down to b04383b6a558 (clk: imx8mq: Define gates
for pll1/2 fixed dividers). The change itself looks fine to me, still
CC'ed Leonard for good measure.

In my testing the following partial revert fixes the issue:

--- a/drivers/clk/imx/clk-imx8mq.c
+++ b/drivers/clk/imx/clk-imx8mq.c
@@ -365,7 +365,7 @@ static int imx8mq_clocks_probe(struct platform_device *pdev)
        hws[IMX8MQ_SYS1_PLL_133M_CG] = imx_clk_hw_gate("sys1_pll_133m_cg", "sys1_pll_out", base + 0x30, 15);
        hws[IMX8MQ_SYS1_PLL_160M_CG] = imx_clk_hw_gate("sys1_pll_160m_cg", "sys1_pll_out", base + 0x30, 17);
        hws[IMX8MQ_SYS1_PLL_200M_CG] = imx_clk_hw_gate("sys1_pll_200m_cg", "sys1_pll_out", base + 0x30, 19);
-       hws[IMX8MQ_SYS1_PLL_266M_CG] = imx_clk_hw_gate("sys1_pll_266m_cg", "sys1_pll_out", base + 0x30, 21);
        hws[IMX8MQ_SYS1_PLL_400M_CG] = imx_clk_hw_gate("sys1_pll_400m_cg", "sys1_pll_out", base + 0x30, 23);
        hws[IMX8MQ_SYS1_PLL_800M_CG] = imx_clk_hw_gate("sys1_pll_800m_cg", "sys1_pll_out", base + 0x30, 25);
 
@@ -375,7 +375,7 @@ static int imx8mq_clocks_probe(struct platform_device *pdev)
        hws[IMX8MQ_SYS1_PLL_133M] = imx_clk_hw_fixed_factor("sys1_pll_133m", "sys1_pll_133m_cg", 1, 6);
        hws[IMX8MQ_SYS1_PLL_160M] = imx_clk_hw_fixed_factor("sys1_pll_160m", "sys1_pll_160m_cg", 1, 5);
        hws[IMX8MQ_SYS1_PLL_200M] = imx_clk_hw_fixed_factor("sys1_pll_200m", "sys1_pll_200m_cg", 1, 4);
-       hws[IMX8MQ_SYS1_PLL_266M] = imx_clk_hw_fixed_factor("sys1_pll_266m", "sys1_pll_266m_cg", 1, 3);
+       hws[IMX8MQ_SYS1_PLL_266M] = imx_clk_hw_fixed_factor("sys1_pll_266m", "sys1_pll_out", 1, 3);
        hws[IMX8MQ_SYS1_PLL_400M] = imx_clk_hw_fixed_factor("sys1_pll_400m", "sys1_pll_400m_cg", 1, 2);
        hws[IMX8MQ_SYS1_PLL_800M] = imx_clk_hw_fixed_factor("sys1_pll_800m", "sys1_pll_800m_cg", 1, 1);

The sys1_pll_266m is the parent of nand_usdhc_bus. I've validated that
the SDHCI driver properly enables this bus clock across the problematic
card access. So what I think is happening here is that both
nand_usdhc_bus and sys1_pll_266m are initially enabled. Sometime during
boot sys1_pll_266m gets disabled due to runtime PM on the enet_axi
clock, which is a direct child of sys1_pll_266m. At this point
nand_usdhc_bus is still enabled, but no consumer has claimed the clock
yet, so the parent clock gets disabled while this branch of the clock
tree is still active.

The reference manual states about this situation: "For any clock, its
source must be left on when it is kept on. Behavior is undefined if
this rule is violated."
And it seems this is exactly what's happening here: some kind of glitch
is introduced in the nand_usdhc_bus clock, which prevents the SDHCI
controller from working, even though the clock branch is properly
enabled later on. On my system the SDHCI timeout and following runtime
suspend/resume cycle on the nand_usdhc_bus clock seem to get it back
into a working state.

So I think we need some solution at the clock driver/framework level to
prevent shutting down parent clocks that have active branches, even if
those branches aren't claimed by a consumer (yet).

Regards,
Lucas


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: sdhci timeout on imx8mq

[Bough Chen]

> -----Original Message-----
> From: Lucas Stach [mailto:l.stach@pengutronix.de]
> Sent: 2021年1月5日 23:07
> To: Bough Chen <haibo.chen@nxp.com>; Fabio Estevam
> <festevam@gmail.com>; Angus Ainslie <angus@akkea.ca>; Leonard Crestez
> <leonard.crestez@nxp.com>; Peng Fan <peng.fan@nxp.com>; Abel Vesa
> <abel.vesa@nxp.com>; Stephen Boyd <sboyd@kernel.org>; Michael Turquette
> <mturquette@baylibre.com>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>;
> linux-mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>; Sascha Hauer
> <kernel@pengutronix.de>; moderated list:ARM/FREESCALE IMX / MXC ARM
> ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> Subject: Re: sdhci timeout on imx8mq
> 
> Hi all,
> 
> Am Mittwoch, dem 08.07.2020 um 01:32 +0000 schrieb BOUGH CHEN:
> > > -----Original Message-----
> > > From: Fabio Estevam [mailto:festevam@gmail.com]
> > > Sent: 2020年7月7日 20:45
> > > To: Angus Ainslie <angus@akkea.ca>
> > > Cc: BOUGH CHEN <haibo.chen@nxp.com>; Ulf Hansson
> > > <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>; linux-
> > > mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> > > <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>; Sascha
> > > Hauer < kernel@pengutronix.de>; moderated list:ARM/FREESCALE IMX /
> > > MXC ARM ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> > > Subject: Re: sdhci timeout on imx8mq
> > >
> > > Hi Angus,
> > >
> > > On Tue, Jun 30, 2020 at 4:39 PM Angus Ainslie <angus@akkea.ca>
> > > wrote:
> > >
> > > > Has there been any progress with this. I'm getting this on about
> > > > 50% of
> > >
> > > Not from my side, sorry.
> > >
> > > Bough,
> > >
> > > Do you know why this problem affects the imx8mq-evk versions that
> > > are populated with the Micron eMMC and not the ones with Sandisk
> > > eMMC?
> >
> > Hi Angus,
> >
> > Can you show me the full fail log? I do not meet this issue on my
> > side, besides, which kind of uboot do you use?
> 
> I was finally able to bisect this issue, which wasn't that much fun due to the
> issue not being reproducible 100%. :/ Turns out that the issue is even more
> interesting than I thought and likely doesn't have anything to do with SDHCI or
> used bootloader versions. Here's my current debugging state:
> 
> I've bisected the issue down to b04383b6a558 (clk: imx8mq: Define gates for
> pll1/2 fixed dividers). The change itself looks fine to me, still CC'ed Leonard for
> good measure.
> 
> In my testing the following partial revert fixes the issue:
> 
> --- a/drivers/clk/imx/clk-imx8mq.c
> +++ b/drivers/clk/imx/clk-imx8mq.c
> @@ -365,7 +365,7 @@ static int imx8mq_clocks_probe(struct
> platform_device *pdev)
>         hws[IMX8MQ_SYS1_PLL_133M_CG] =
> imx_clk_hw_gate("sys1_pll_133m_cg", "sys1_pll_out", base + 0x30, 15);
>         hws[IMX8MQ_SYS1_PLL_160M_CG] =
> imx_clk_hw_gate("sys1_pll_160m_cg", "sys1_pll_out", base + 0x30, 17);
>         hws[IMX8MQ_SYS1_PLL_200M_CG] =
> imx_clk_hw_gate("sys1_pll_200m_cg", "sys1_pll_out", base + 0x30, 19);
> -       hws[IMX8MQ_SYS1_PLL_266M_CG] =
> imx_clk_hw_gate("sys1_pll_266m_cg", "sys1_pll_out", base + 0x30, 21);
>         hws[IMX8MQ_SYS1_PLL_400M_CG] =
> imx_clk_hw_gate("sys1_pll_400m_cg", "sys1_pll_out", base + 0x30, 23);
>         hws[IMX8MQ_SYS1_PLL_800M_CG] =
> imx_clk_hw_gate("sys1_pll_800m_cg", "sys1_pll_out", base + 0x30, 25);
> 
> @@ -375,7 +375,7 @@ static int imx8mq_clocks_probe(struct
> platform_device *pdev)
>         hws[IMX8MQ_SYS1_PLL_133M] =
> imx_clk_hw_fixed_factor("sys1_pll_133m", "sys1_pll_133m_cg", 1, 6);
>         hws[IMX8MQ_SYS1_PLL_160M] =
> imx_clk_hw_fixed_factor("sys1_pll_160m", "sys1_pll_160m_cg", 1, 5);
>         hws[IMX8MQ_SYS1_PLL_200M] =
> imx_clk_hw_fixed_factor("sys1_pll_200m", "sys1_pll_200m_cg", 1, 4);
> -       hws[IMX8MQ_SYS1_PLL_266M] =
> imx_clk_hw_fixed_factor("sys1_pll_266m", "sys1_pll_266m_cg", 1, 3);
> +       hws[IMX8MQ_SYS1_PLL_266M] =
> + imx_clk_hw_fixed_factor("sys1_pll_266m", "sys1_pll_out", 1, 3);
>         hws[IMX8MQ_SYS1_PLL_400M] =
> imx_clk_hw_fixed_factor("sys1_pll_400m", "sys1_pll_400m_cg", 1, 2);
>         hws[IMX8MQ_SYS1_PLL_800M] =
> imx_clk_hw_fixed_factor("sys1_pll_800m", "sys1_pll_800m_cg", 1, 1);
> 
> The sys1_pll_266m is the parent of nand_usdhc_bus. I've validated that the
> SDHCI driver properly enables this bus clock across the problematic card access.
> So what I think is happening here is that both nand_usdhc_bus and
> sys1_pll_266m are initially enabled. Sometime during boot sys1_pll_266m gets
> disabled due to runtime PM on the enet_axi clock, which is a direct child of
> sys1_pll_266m. At this point nand_usdhc_bus is still enabled, but no consumer
> has claimed the clock yet, so the parent clock gets disabled while this branch of
> the clock tree is still active.

Hi Lucas,

According to the clock tree, if nand_usdhc_bus is still enabled, then sys1_pll_266m has no chance to disable.

    sys1_pll_266m_cg                  1        1        0   800000000          0     0  50000         Y
       sys1_pll_266m                  1        1        0   266666666          0     0  50000         Y
          nand_usdhc_bus              0        0        0   266666666          0     0  50000         N
             nand_usdhc_rawnand_clk       0        0        0   266666666          0     0  50000         N
          enet_axi                    1        1        0   266666666          0     0  50000         Y
             enet1_root_clk           2        2        0   266666666          0     0  50000         Y


This issue seems related with the following errta:

e11232: USDHC: uSDHC setting requirement for IPG_CLK and AHB_BUS clocks
Description: uSDHC AHB_BUS and IPG_CLK clocks must be synchronized.
Due to current physical design implementation, AHB_BUS and IPG_CLK must come from
same clock source to maintain clock sync.
Workaround: Set AHB_BUS and IPG_CLK to clock source from PLL1.

After sys1_pll_266m gate off/on, seems need to sync the USDHC AHB bus and USDHC IPG_clk again. (Here usdhc AHB BUS source from nand_usdhc_bus.)
This sync is handle by hardware, and maybe need some time, during this sync period, usdhc operation may has issue.

I just double check our local v5.10 branch, already revert the commit b04383b6a558 (clk: imx8mq: Define gates for pll1/2 fixed dividers).
So to fix this issue, one method is revert this patch, another method is keep the 'nand_usdhc_bus' always on. Add change like this:

diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-imx8mq.c
index 779ea69e639c..939806b36916 100644
--- a/drivers/clk/imx/clk-imx8mq.c
+++ b/drivers/clk/imx/clk-imx8mq.c
@@ -433,7 +433,7 @@ static int imx8mq_clocks_probe(struct platform_device *pdev)
        /* BUS */
        hws[IMX8MQ_CLK_MAIN_AXI] = imx8m_clk_hw_composite_bus_critical("main_axi", imx8mq_main_axi_sels, base + 0x8800);
        hws[IMX8MQ_CLK_ENET_AXI] = imx8m_clk_hw_composite_bus("enet_axi", imx8mq_enet_axi_sels, base + 0x8880);
-       hws[IMX8MQ_CLK_NAND_USDHC_BUS] = imx8m_clk_hw_composite_bus("nand_usdhc_bus", imx8mq_nand_usdhc_sels, base + 0x8900);
+       hws[IMX8MQ_CLK_NAND_USDHC_BUS] = imx8m_clk_hw_composite_bus_critical("nand_usdhc_bus", imx8mq_nand_usdhc_sels, base + 0x8900);
        hws[IMX8MQ_CLK_VPU_BUS] = imx8m_clk_hw_composite_bus("vpu_bus", imx8mq_vpu_bus_sels, base + 0x8980);
        hws[IMX8MQ_CLK_DISP_AXI] = imx8m_clk_hw_composite_bus("disp_axi", imx8mq_disp_axi_sels, base + 0x8a00);
        hws[IMX8MQ_CLK_DISP_APB] = imx8m_clk_hw_composite_bus("disp_apb", imx8mq_disp_apb_sels, base + 0x8a80);


What you think? Or any other suggestion?

> 
> The reference manual states about this situation: "For any clock, its source
> must be left on when it is kept on. Behavior is undefined if this rule is violated."
> And it seems this is exactly what's happening here: some kind of glitch is
> introduced in the nand_usdhc_bus clock, which prevents the SDHCI controller
> from working, even though the clock branch is properly enabled later on. On my
> system the SDHCI timeout and following runtime suspend/resume cycle on the
> nand_usdhc_bus clock seem to get it back into a working state.
> 
> So I think we need some solution at the clock driver/framework level to prevent
> shutting down parent clocks that have active branches, even if those branches
> aren't claimed by a consumer (yet).
> 
> Regards,
> Lucas

RE: sdhci timeout on imx8mq

[Bough Chen]

> -----Original Message-----
> From: Lucas Stach [mailto:l.stach@pengutronix.de]
> Sent: 2021年1月5日 23:07
> To: Bough Chen <haibo.chen@nxp.com>; Fabio Estevam
> <festevam@gmail.com>; Angus Ainslie <angus@akkea.ca>; Leonard Crestez
> <leonard.crestez@nxp.com>; Peng Fan <peng.fan@nxp.com>; Abel Vesa
> <abel.vesa@nxp.com>; Stephen Boyd <sboyd@kernel.org>; Michael Turquette
> <mturquette@baylibre.com>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>;
> linux-mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>; Sascha Hauer
> <kernel@pengutronix.de>; moderated list:ARM/FREESCALE IMX / MXC ARM
> ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> Subject: Re: sdhci timeout on imx8mq
> 
> Hi all,
> 
> Am Mittwoch, dem 08.07.2020 um 01:32 +0000 schrieb BOUGH CHEN:
> > > -----Original Message-----
> > > From: Fabio Estevam [mailto:festevam@gmail.com]
> > > Sent: 2020年7月7日 20:45
> > > To: Angus Ainslie <angus@akkea.ca>
> > > Cc: BOUGH CHEN <haibo.chen@nxp.com>; Ulf Hansson
> > > <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>; linux-
> > > mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> > > <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>; Sascha
> > > Hauer < kernel@pengutronix.de>; moderated list:ARM/FREESCALE IMX /
> > > MXC ARM ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> > > Subject: Re: sdhci timeout on imx8mq
> > >
> > > Hi Angus,
> > >
> > > On Tue, Jun 30, 2020 at 4:39 PM Angus Ainslie <angus@akkea.ca>
> > > wrote:
> > >
> > > > Has there been any progress with this. I'm getting this on about
> > > > 50% of
> > >
> > > Not from my side, sorry.
> > >
> > > Bough,
> > >
> > > Do you know why this problem affects the imx8mq-evk versions that
> > > are populated with the Micron eMMC and not the ones with Sandisk
> > > eMMC?
> >
> > Hi Angus,
> >
> > Can you show me the full fail log? I do not meet this issue on my
> > side, besides, which kind of uboot do you use?
> 
> I was finally able to bisect this issue, which wasn't that much fun due to the
> issue not being reproducible 100%. :/ Turns out that the issue is even more
> interesting than I thought and likely doesn't have anything to do with SDHCI or
> used bootloader versions. Here's my current debugging state:
> 
> I've bisected the issue down to b04383b6a558 (clk: imx8mq: Define gates for
> pll1/2 fixed dividers). The change itself looks fine to me, still CC'ed Leonard for
> good measure.
> 
> In my testing the following partial revert fixes the issue:
> 
> --- a/drivers/clk/imx/clk-imx8mq.c
> +++ b/drivers/clk/imx/clk-imx8mq.c
> @@ -365,7 +365,7 @@ static int imx8mq_clocks_probe(struct
> platform_device *pdev)
>         hws[IMX8MQ_SYS1_PLL_133M_CG] =
> imx_clk_hw_gate("sys1_pll_133m_cg", "sys1_pll_out", base + 0x30, 15);
>         hws[IMX8MQ_SYS1_PLL_160M_CG] =
> imx_clk_hw_gate("sys1_pll_160m_cg", "sys1_pll_out", base + 0x30, 17);
>         hws[IMX8MQ_SYS1_PLL_200M_CG] =
> imx_clk_hw_gate("sys1_pll_200m_cg", "sys1_pll_out", base + 0x30, 19);
> -       hws[IMX8MQ_SYS1_PLL_266M_CG] =
> imx_clk_hw_gate("sys1_pll_266m_cg", "sys1_pll_out", base + 0x30, 21);
>         hws[IMX8MQ_SYS1_PLL_400M_CG] =
> imx_clk_hw_gate("sys1_pll_400m_cg", "sys1_pll_out", base + 0x30, 23);
>         hws[IMX8MQ_SYS1_PLL_800M_CG] =
> imx_clk_hw_gate("sys1_pll_800m_cg", "sys1_pll_out", base + 0x30, 25);
> 
> @@ -375,7 +375,7 @@ static int imx8mq_clocks_probe(struct
> platform_device *pdev)
>         hws[IMX8MQ_SYS1_PLL_133M] =
> imx_clk_hw_fixed_factor("sys1_pll_133m", "sys1_pll_133m_cg", 1, 6);
>         hws[IMX8MQ_SYS1_PLL_160M] =
> imx_clk_hw_fixed_factor("sys1_pll_160m", "sys1_pll_160m_cg", 1, 5);
>         hws[IMX8MQ_SYS1_PLL_200M] =
> imx_clk_hw_fixed_factor("sys1_pll_200m", "sys1_pll_200m_cg", 1, 4);
> -       hws[IMX8MQ_SYS1_PLL_266M] =
> imx_clk_hw_fixed_factor("sys1_pll_266m", "sys1_pll_266m_cg", 1, 3);
> +       hws[IMX8MQ_SYS1_PLL_266M] =
> + imx_clk_hw_fixed_factor("sys1_pll_266m", "sys1_pll_out", 1, 3);
>         hws[IMX8MQ_SYS1_PLL_400M] =
> imx_clk_hw_fixed_factor("sys1_pll_400m", "sys1_pll_400m_cg", 1, 2);
>         hws[IMX8MQ_SYS1_PLL_800M] =
> imx_clk_hw_fixed_factor("sys1_pll_800m", "sys1_pll_800m_cg", 1, 1);
> 
> The sys1_pll_266m is the parent of nand_usdhc_bus. I've validated that the
> SDHCI driver properly enables this bus clock across the problematic card access.
> So what I think is happening here is that both nand_usdhc_bus and
> sys1_pll_266m are initially enabled. Sometime during boot sys1_pll_266m gets
> disabled due to runtime PM on the enet_axi clock, which is a direct child of
> sys1_pll_266m. At this point nand_usdhc_bus is still enabled, but no consumer
> has claimed the clock yet, so the parent clock gets disabled while this branch of
> the clock tree is still active.

Hi Lucas,

According to the clock tree, if nand_usdhc_bus is still enabled, then sys1_pll_266m has no chance to disable.

    sys1_pll_266m_cg                  1        1        0   800000000          0     0  50000         Y
       sys1_pll_266m                  1        1        0   266666666          0     0  50000         Y
          nand_usdhc_bus              0        0        0   266666666          0     0  50000         N
             nand_usdhc_rawnand_clk       0        0        0   266666666          0     0  50000         N
          enet_axi                    1        1        0   266666666          0     0  50000         Y
             enet1_root_clk           2        2        0   266666666          0     0  50000         Y


This issue seems related with the following errta:

e11232: USDHC: uSDHC setting requirement for IPG_CLK and AHB_BUS clocks
Description: uSDHC AHB_BUS and IPG_CLK clocks must be synchronized.
Due to current physical design implementation, AHB_BUS and IPG_CLK must come from
same clock source to maintain clock sync.
Workaround: Set AHB_BUS and IPG_CLK to clock source from PLL1.

After sys1_pll_266m gate off/on, seems need to sync the USDHC AHB bus and USDHC IPG_clk again. (Here usdhc AHB BUS source from nand_usdhc_bus.)
This sync is handle by hardware, and maybe need some time, during this sync period, usdhc operation may has issue.

I just double check our local v5.10 branch, already revert the commit b04383b6a558 (clk: imx8mq: Define gates for pll1/2 fixed dividers).
So to fix this issue, one method is revert this patch, another method is keep the 'nand_usdhc_bus' always on. Add change like this:

diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-imx8mq.c
index 779ea69e639c..939806b36916 100644
--- a/drivers/clk/imx/clk-imx8mq.c
+++ b/drivers/clk/imx/clk-imx8mq.c
@@ -433,7 +433,7 @@ static int imx8mq_clocks_probe(struct platform_device *pdev)
        /* BUS */
        hws[IMX8MQ_CLK_MAIN_AXI] = imx8m_clk_hw_composite_bus_critical("main_axi", imx8mq_main_axi_sels, base + 0x8800);
        hws[IMX8MQ_CLK_ENET_AXI] = imx8m_clk_hw_composite_bus("enet_axi", imx8mq_enet_axi_sels, base + 0x8880);
-       hws[IMX8MQ_CLK_NAND_USDHC_BUS] = imx8m_clk_hw_composite_bus("nand_usdhc_bus", imx8mq_nand_usdhc_sels, base + 0x8900);
+       hws[IMX8MQ_CLK_NAND_USDHC_BUS] = imx8m_clk_hw_composite_bus_critical("nand_usdhc_bus", imx8mq_nand_usdhc_sels, base + 0x8900);
        hws[IMX8MQ_CLK_VPU_BUS] = imx8m_clk_hw_composite_bus("vpu_bus", imx8mq_vpu_bus_sels, base + 0x8980);
        hws[IMX8MQ_CLK_DISP_AXI] = imx8m_clk_hw_composite_bus("disp_axi", imx8mq_disp_axi_sels, base + 0x8a00);
        hws[IMX8MQ_CLK_DISP_APB] = imx8m_clk_hw_composite_bus("disp_apb", imx8mq_disp_apb_sels, base + 0x8a80);


What you think? Or any other suggestion?

> 
> The reference manual states about this situation: "For any clock, its source
> must be left on when it is kept on. Behavior is undefined if this rule is violated."
> And it seems this is exactly what's happening here: some kind of glitch is
> introduced in the nand_usdhc_bus clock, which prevents the SDHCI controller
> from working, even though the clock branch is properly enabled later on. On my
> system the SDHCI timeout and following runtime suspend/resume cycle on the
> nand_usdhc_bus clock seem to get it back into a working state.
> 
> So I think we need some solution at the clock driver/framework level to prevent
> shutting down parent clocks that have active branches, even if those branches
> aren't claimed by a consumer (yet).
> 
> Regards,
> Lucas

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: sdhci timeout on imx8mq

[Lucas Stach]

Hi Bough,

Am Mittwoch, dem 06.01.2021 um 09:29 +0000 schrieb Bough Chen:
> > -----Original Message-----
> > From: Lucas Stach [mailto:l.stach@pengutronix.de]
> > Sent: 2021年1月5日 23:07
> > To: Bough Chen <haibo.chen@nxp.com>; Fabio Estevam
> > <festevam@gmail.com>; Angus Ainslie <angus@akkea.ca>; Leonard
> > Crestez
> > <leonard.crestez@nxp.com>; Peng Fan <peng.fan@nxp.com>; Abel Vesa
> > <abel.vesa@nxp.com>; Stephen Boyd <sboyd@kernel.org>; Michael
> > Turquette
> > <mturquette@baylibre.com>
> > Cc: Ulf Hansson <ulf.hansson@linaro.org>; Guido Günther <
> > agx@sigxcpu.org>;
> > linux-mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> > <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>; Sascha
> > Hauer
> > <kernel@pengutronix.de>; moderated list:ARM/FREESCALE IMX / MXC ARM
> > ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> > Subject: Re: sdhci timeout on imx8mq
> > 
> > Hi all,
> > 
> > Am Mittwoch, dem 08.07.2020 um 01:32 +0000 schrieb BOUGH CHEN:
> > > > -----Original Message-----
> > > > From: Fabio Estevam [mailto:festevam@gmail.com]
> > > > Sent: 2020年7月7日 20:45
> > > > To: Angus Ainslie <angus@akkea.ca>
> > > > Cc: BOUGH CHEN <haibo.chen@nxp.com>; Ulf Hansson
> > > > <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>;
> > > > linux-
> > > > mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> > > > <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>;
> > > > Sascha
> > > > Hauer < kernel@pengutronix.de>; moderated list:ARM/FREESCALE
> > > > IMX /
> > > > MXC ARM ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> > > > Subject: Re: sdhci timeout on imx8mq
> > > > 
> > > > Hi Angus,
> > > > 
> > > > On Tue, Jun 30, 2020 at 4:39 PM Angus Ainslie <angus@akkea.ca>
> > > > wrote:
> > > > 
> > > > > Has there been any progress with this. I'm getting this on
> > > > > about
> > > > > 50% of
> > > > 
> > > > Not from my side, sorry.
> > > > 
> > > > Bough,
> > > > 
> > > > Do you know why this problem affects the imx8mq-evk versions
> > > > that
> > > > are populated with the Micron eMMC and not the ones with
> > > > Sandisk
> > > > eMMC?
> > > 
> > > Hi Angus,
> > > 
> > > Can you show me the full fail log? I do not meet this issue on my
> > > side, besides, which kind of uboot do you use?
> > 
> > I was finally able to bisect this issue, which wasn't that much fun
> > due to the
> > issue not being reproducible 100%. :/ Turns out that the issue is
> > even more
> > interesting than I thought and likely doesn't have anything to do
> > with SDHCI or
> > used bootloader versions. Here's my current debugging state:
> > 
> > I've bisected the issue down to b04383b6a558 (clk: imx8mq: Define
> > gates for
> > pll1/2 fixed dividers). The change itself looks fine to me, still
> > CC'ed Leonard for
> > good measure.
> > 
> > In my testing the following partial revert fixes the issue:
> > 
> > --- a/drivers/clk/imx/clk-imx8mq.c
> > +++ b/drivers/clk/imx/clk-imx8mq.c
> > @@ -365,7 +365,7 @@ static int imx8mq_clocks_probe(struct
> > platform_device *pdev)
> >         hws[IMX8MQ_SYS1_PLL_133M_CG] =
> > imx_clk_hw_gate("sys1_pll_133m_cg", "sys1_pll_out", base + 0x30, 15);
> >         hws[IMX8MQ_SYS1_PLL_160M_CG] =
> > imx_clk_hw_gate("sys1_pll_160m_cg", "sys1_pll_out", base + 0x30, 17);
> >         hws[IMX8MQ_SYS1_PLL_200M_CG] =
> > imx_clk_hw_gate("sys1_pll_200m_cg", "sys1_pll_out", base + 0x30, 19);
> > -       hws[IMX8MQ_SYS1_PLL_266M_CG] =
> > imx_clk_hw_gate("sys1_pll_266m_cg", "sys1_pll_out", base + 0x30, 21);
> >         hws[IMX8MQ_SYS1_PLL_400M_CG] =
> > imx_clk_hw_gate("sys1_pll_400m_cg", "sys1_pll_out", base + 0x30, 23);
> >         hws[IMX8MQ_SYS1_PLL_800M_CG] =
> > imx_clk_hw_gate("sys1_pll_800m_cg", "sys1_pll_out", base + 0x30, 25);
> > 
> > @@ -375,7 +375,7 @@ static int imx8mq_clocks_probe(struct
> > platform_device *pdev)
> >         hws[IMX8MQ_SYS1_PLL_133M] =
> > imx_clk_hw_fixed_factor("sys1_pll_133m", "sys1_pll_133m_cg", 1, 6);
> >         hws[IMX8MQ_SYS1_PLL_160M] =
> > imx_clk_hw_fixed_factor("sys1_pll_160m", "sys1_pll_160m_cg", 1, 5);
> >         hws[IMX8MQ_SYS1_PLL_200M] =
> > imx_clk_hw_fixed_factor("sys1_pll_200m", "sys1_pll_200m_cg", 1, 4);
> > -       hws[IMX8MQ_SYS1_PLL_266M] =
> > imx_clk_hw_fixed_factor("sys1_pll_266m", "sys1_pll_266m_cg", 1, 3);
> > +       hws[IMX8MQ_SYS1_PLL_266M] =
> > + imx_clk_hw_fixed_factor("sys1_pll_266m", "sys1_pll_out", 1, 3);
> >         hws[IMX8MQ_SYS1_PLL_400M] =
> > imx_clk_hw_fixed_factor("sys1_pll_400m", "sys1_pll_400m_cg", 1, 2);
> >         hws[IMX8MQ_SYS1_PLL_800M] =
> > imx_clk_hw_fixed_factor("sys1_pll_800m", "sys1_pll_800m_cg", 1, 1);
> > 
> > The sys1_pll_266m is the parent of nand_usdhc_bus. I've validated
> > that the
> > SDHCI driver properly enables this bus clock across the problematic
> > card access.
> > So what I think is happening here is that both nand_usdhc_bus and
> > sys1_pll_266m are initially enabled. Sometime during boot
> > sys1_pll_266m gets
> > disabled due to runtime PM on the enet_axi clock, which is a direct
> > child of
> > sys1_pll_266m. At this point nand_usdhc_bus is still enabled, but
> > no consumer
> > has claimed the clock yet, so the parent clock gets disabled while
> > this branch of
> > the clock tree is still active.
> 
> Hi Lucas,
> 
> According to the clock tree, if nand_usdhc_bus is still enabled, then
> sys1_pll_266m has no chance to disable.

This statement is only correct after the SDHCI driver is probed an has
enabled nand_usdhc_bus. Before the driver probes the refcounts on the
clocks are not synchronized, so sys1_pll_266m_cg can be disabled, while
nand_usdhc_bus is enabled (from software running before Linux), even
though no consumer is using nand_usdhc_bus, yet.

>     sys1_pll_266m_cg                  1        1        0   800000000          0     0  50000         Y
>        sys1_pll_266m                  1        1        0   266666666          0     0  50000         Y
>           nand_usdhc_bus              0        0        0   266666666          0     0  50000         N
>              nand_usdhc_rawnand_clk       0        0        0   266666666          0     0  50000         N
>           enet_axi                    1        1        0   266666666          0     0  50000         Y
>              enet1_root_clk           2        2        0   266666666          0     0  50000         Y
> 
> 
> This issue seems related with the following errta:
> 
> e11232: USDHC: uSDHC setting requirement for IPG_CLK and AHB_BUS
> clocks
> Description: uSDHC AHB_BUS and IPG_CLK clocks must be synchronized.
> Due to current physical design implementation, AHB_BUS and IPG_CLK
> must come from
> same clock source to maintain clock sync.
> Workaround: Set AHB_BUS and IPG_CLK to clock source from PLL1.
> 
> After sys1_pll_266m gate off/on, seems need to sync the USDHC AHB bus
> and USDHC IPG_clk again. (Here usdhc AHB BUS source from
> nand_usdhc_bus.)
> This sync is handle by hardware, and maybe need some time, during
> this sync period, usdhc operation may has issue.

Where in HW is this synchronization done? If it's at the uSDHC
controller side, I would expect this issue to show up even with the
commit reverted, as nand_usdhc_bus gets gated due to runtime PM from
the controller side. The only difference with the commit in question is
that now the clock branch can be gated _before_ nand_usdhc_bus. If the
synchronization is done somewhere in the clock tree than this might be
an issue.

> 
> I just double check our local v5.10 branch, already revert the commit
> b04383b6a558 (clk: imx8mq: Define gates for pll1/2 fixed dividers).
> So to fix this issue, one method is revert this patch, another method
> is keep the 'nand_usdhc_bus' always on. Add change like this:
> 
> diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-imx8mq.c
> index 779ea69e639c..939806b36916 100644
> --- a/drivers/clk/imx/clk-imx8mq.c
> +++ b/drivers/clk/imx/clk-imx8mq.c
> @@ -433,7 +433,7 @@ static int imx8mq_clocks_probe(struct platform_device *pdev)
>         /* BUS */
>         hws[IMX8MQ_CLK_MAIN_AXI] = imx8m_clk_hw_composite_bus_critical("main_axi", imx8mq_main_axi_sels, base + 0x8800);
>         hws[IMX8MQ_CLK_ENET_AXI] = imx8m_clk_hw_composite_bus("enet_axi", imx8mq_enet_axi_sels, base + 0x8880);
> -       hws[IMX8MQ_CLK_NAND_USDHC_BUS] = imx8m_clk_hw_composite_bus("nand_usdhc_bus", imx8mq_nand_usdhc_sels, base + 0x8900);
> +       hws[IMX8MQ_CLK_NAND_USDHC_BUS] = imx8m_clk_hw_composite_bus_critical("nand_usdhc_bus", imx8mq_nand_usdhc_sels, base + 0x8900);
>         hws[IMX8MQ_CLK_VPU_BUS] = imx8m_clk_hw_composite_bus("vpu_bus", imx8mq_vpu_bus_sels, base + 0x8980);
>         hws[IMX8MQ_CLK_DISP_AXI] = imx8m_clk_hw_composite_bus("disp_axi", imx8mq_disp_axi_sels, base + 0x8a00);
>         hws[IMX8MQ_CLK_DISP_APB] = imx8m_clk_hw_composite_bus("disp_apb", imx8mq_disp_apb_sels, base + 0x8a80);
> 
> 
> What you think? Or any other suggestion?

This is suboptimal, as it will not allow to gate the uSDHC controller
AHB clock in runtime suspend. Also my testing shows that it's the gate
_before_ the nand_usdhc_bus slice that's causing the issue. So my
minimal fix from the previous mail would still be better, as it allows
to gate the nand_usdhc_bus clock, while keeping sys1_pll_266m enabled.

Regards,
Lucas
> 

Re: sdhci timeout on imx8mq

[Lucas Stach]

Hi Bough,

Am Mittwoch, dem 06.01.2021 um 09:29 +0000 schrieb Bough Chen:
> > -----Original Message-----
> > From: Lucas Stach [mailto:l.stach@pengutronix.de]
> > Sent: 2021年1月5日 23:07
> > To: Bough Chen <haibo.chen@nxp.com>; Fabio Estevam
> > <festevam@gmail.com>; Angus Ainslie <angus@akkea.ca>; Leonard
> > Crestez
> > <leonard.crestez@nxp.com>; Peng Fan <peng.fan@nxp.com>; Abel Vesa
> > <abel.vesa@nxp.com>; Stephen Boyd <sboyd@kernel.org>; Michael
> > Turquette
> > <mturquette@baylibre.com>
> > Cc: Ulf Hansson <ulf.hansson@linaro.org>; Guido Günther <
> > agx@sigxcpu.org>;
> > linux-mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> > <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>; Sascha
> > Hauer
> > <kernel@pengutronix.de>; moderated list:ARM/FREESCALE IMX / MXC ARM
> > ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> > Subject: Re: sdhci timeout on imx8mq
> > 
> > Hi all,
> > 
> > Am Mittwoch, dem 08.07.2020 um 01:32 +0000 schrieb BOUGH CHEN:
> > > > -----Original Message-----
> > > > From: Fabio Estevam [mailto:festevam@gmail.com]
> > > > Sent: 2020年7月7日 20:45
> > > > To: Angus Ainslie <angus@akkea.ca>
> > > > Cc: BOUGH CHEN <haibo.chen@nxp.com>; Ulf Hansson
> > > > <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>;
> > > > linux-
> > > > mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> > > > <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>;
> > > > Sascha
> > > > Hauer < kernel@pengutronix.de>; moderated list:ARM/FREESCALE
> > > > IMX /
> > > > MXC ARM ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> > > > Subject: Re: sdhci timeout on imx8mq
> > > > 
> > > > Hi Angus,
> > > > 
> > > > On Tue, Jun 30, 2020 at 4:39 PM Angus Ainslie <angus@akkea.ca>
> > > > wrote:
> > > > 
> > > > > Has there been any progress with this. I'm getting this on
> > > > > about
> > > > > 50% of
> > > > 
> > > > Not from my side, sorry.
> > > > 
> > > > Bough,
> > > > 
> > > > Do you know why this problem affects the imx8mq-evk versions
> > > > that
> > > > are populated with the Micron eMMC and not the ones with
> > > > Sandisk
> > > > eMMC?
> > > 
> > > Hi Angus,
> > > 
> > > Can you show me the full fail log? I do not meet this issue on my
> > > side, besides, which kind of uboot do you use?
> > 
> > I was finally able to bisect this issue, which wasn't that much fun
> > due to the
> > issue not being reproducible 100%. :/ Turns out that the issue is
> > even more
> > interesting than I thought and likely doesn't have anything to do
> > with SDHCI or
> > used bootloader versions. Here's my current debugging state:
> > 
> > I've bisected the issue down to b04383b6a558 (clk: imx8mq: Define
> > gates for
> > pll1/2 fixed dividers). The change itself looks fine to me, still
> > CC'ed Leonard for
> > good measure.
> > 
> > In my testing the following partial revert fixes the issue:
> > 
> > --- a/drivers/clk/imx/clk-imx8mq.c
> > +++ b/drivers/clk/imx/clk-imx8mq.c
> > @@ -365,7 +365,7 @@ static int imx8mq_clocks_probe(struct
> > platform_device *pdev)
> >         hws[IMX8MQ_SYS1_PLL_133M_CG] =
> > imx_clk_hw_gate("sys1_pll_133m_cg", "sys1_pll_out", base + 0x30, 15);
> >         hws[IMX8MQ_SYS1_PLL_160M_CG] =
> > imx_clk_hw_gate("sys1_pll_160m_cg", "sys1_pll_out", base + 0x30, 17);
> >         hws[IMX8MQ_SYS1_PLL_200M_CG] =
> > imx_clk_hw_gate("sys1_pll_200m_cg", "sys1_pll_out", base + 0x30, 19);
> > -       hws[IMX8MQ_SYS1_PLL_266M_CG] =
> > imx_clk_hw_gate("sys1_pll_266m_cg", "sys1_pll_out", base + 0x30, 21);
> >         hws[IMX8MQ_SYS1_PLL_400M_CG] =
> > imx_clk_hw_gate("sys1_pll_400m_cg", "sys1_pll_out", base + 0x30, 23);
> >         hws[IMX8MQ_SYS1_PLL_800M_CG] =
> > imx_clk_hw_gate("sys1_pll_800m_cg", "sys1_pll_out", base + 0x30, 25);
> > 
> > @@ -375,7 +375,7 @@ static int imx8mq_clocks_probe(struct
> > platform_device *pdev)
> >         hws[IMX8MQ_SYS1_PLL_133M] =
> > imx_clk_hw_fixed_factor("sys1_pll_133m", "sys1_pll_133m_cg", 1, 6);
> >         hws[IMX8MQ_SYS1_PLL_160M] =
> > imx_clk_hw_fixed_factor("sys1_pll_160m", "sys1_pll_160m_cg", 1, 5);
> >         hws[IMX8MQ_SYS1_PLL_200M] =
> > imx_clk_hw_fixed_factor("sys1_pll_200m", "sys1_pll_200m_cg", 1, 4);
> > -       hws[IMX8MQ_SYS1_PLL_266M] =
> > imx_clk_hw_fixed_factor("sys1_pll_266m", "sys1_pll_266m_cg", 1, 3);
> > +       hws[IMX8MQ_SYS1_PLL_266M] =
> > + imx_clk_hw_fixed_factor("sys1_pll_266m", "sys1_pll_out", 1, 3);
> >         hws[IMX8MQ_SYS1_PLL_400M] =
> > imx_clk_hw_fixed_factor("sys1_pll_400m", "sys1_pll_400m_cg", 1, 2);
> >         hws[IMX8MQ_SYS1_PLL_800M] =
> > imx_clk_hw_fixed_factor("sys1_pll_800m", "sys1_pll_800m_cg", 1, 1);
> > 
> > The sys1_pll_266m is the parent of nand_usdhc_bus. I've validated
> > that the
> > SDHCI driver properly enables this bus clock across the problematic
> > card access.
> > So what I think is happening here is that both nand_usdhc_bus and
> > sys1_pll_266m are initially enabled. Sometime during boot
> > sys1_pll_266m gets
> > disabled due to runtime PM on the enet_axi clock, which is a direct
> > child of
> > sys1_pll_266m. At this point nand_usdhc_bus is still enabled, but
> > no consumer
> > has claimed the clock yet, so the parent clock gets disabled while
> > this branch of
> > the clock tree is still active.
> 
> Hi Lucas,
> 
> According to the clock tree, if nand_usdhc_bus is still enabled, then
> sys1_pll_266m has no chance to disable.

This statement is only correct after the SDHCI driver is probed an has
enabled nand_usdhc_bus. Before the driver probes the refcounts on the
clocks are not synchronized, so sys1_pll_266m_cg can be disabled, while
nand_usdhc_bus is enabled (from software running before Linux), even
though no consumer is using nand_usdhc_bus, yet.

>     sys1_pll_266m_cg                  1        1        0   800000000          0     0  50000         Y
>        sys1_pll_266m                  1        1        0   266666666          0     0  50000         Y
>           nand_usdhc_bus              0        0        0   266666666          0     0  50000         N
>              nand_usdhc_rawnand_clk       0        0        0   266666666          0     0  50000         N
>           enet_axi                    1        1        0   266666666          0     0  50000         Y
>              enet1_root_clk           2        2        0   266666666          0     0  50000         Y
> 
> 
> This issue seems related with the following errta:
> 
> e11232: USDHC: uSDHC setting requirement for IPG_CLK and AHB_BUS
> clocks
> Description: uSDHC AHB_BUS and IPG_CLK clocks must be synchronized.
> Due to current physical design implementation, AHB_BUS and IPG_CLK
> must come from
> same clock source to maintain clock sync.
> Workaround: Set AHB_BUS and IPG_CLK to clock source from PLL1.
> 
> After sys1_pll_266m gate off/on, seems need to sync the USDHC AHB bus
> and USDHC IPG_clk again. (Here usdhc AHB BUS source from
> nand_usdhc_bus.)
> This sync is handle by hardware, and maybe need some time, during
> this sync period, usdhc operation may has issue.

Where in HW is this synchronization done? If it's at the uSDHC
controller side, I would expect this issue to show up even with the
commit reverted, as nand_usdhc_bus gets gated due to runtime PM from
the controller side. The only difference with the commit in question is
that now the clock branch can be gated _before_ nand_usdhc_bus. If the
synchronization is done somewhere in the clock tree than this might be
an issue.

> 
> I just double check our local v5.10 branch, already revert the commit
> b04383b6a558 (clk: imx8mq: Define gates for pll1/2 fixed dividers).
> So to fix this issue, one method is revert this patch, another method
> is keep the 'nand_usdhc_bus' always on. Add change like this:
> 
> diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-imx8mq.c
> index 779ea69e639c..939806b36916 100644
> --- a/drivers/clk/imx/clk-imx8mq.c
> +++ b/drivers/clk/imx/clk-imx8mq.c
> @@ -433,7 +433,7 @@ static int imx8mq_clocks_probe(struct platform_device *pdev)
>         /* BUS */
>         hws[IMX8MQ_CLK_MAIN_AXI] = imx8m_clk_hw_composite_bus_critical("main_axi", imx8mq_main_axi_sels, base + 0x8800);
>         hws[IMX8MQ_CLK_ENET_AXI] = imx8m_clk_hw_composite_bus("enet_axi", imx8mq_enet_axi_sels, base + 0x8880);
> -       hws[IMX8MQ_CLK_NAND_USDHC_BUS] = imx8m_clk_hw_composite_bus("nand_usdhc_bus", imx8mq_nand_usdhc_sels, base + 0x8900);
> +       hws[IMX8MQ_CLK_NAND_USDHC_BUS] = imx8m_clk_hw_composite_bus_critical("nand_usdhc_bus", imx8mq_nand_usdhc_sels, base + 0x8900);
>         hws[IMX8MQ_CLK_VPU_BUS] = imx8m_clk_hw_composite_bus("vpu_bus", imx8mq_vpu_bus_sels, base + 0x8980);
>         hws[IMX8MQ_CLK_DISP_AXI] = imx8m_clk_hw_composite_bus("disp_axi", imx8mq_disp_axi_sels, base + 0x8a00);
>         hws[IMX8MQ_CLK_DISP_APB] = imx8m_clk_hw_composite_bus("disp_apb", imx8mq_disp_apb_sels, base + 0x8a80);
> 
> 
> What you think? Or any other suggestion?

This is suboptimal, as it will not allow to gate the uSDHC controller
AHB clock in runtime suspend. Also my testing shows that it's the gate
_before_ the nand_usdhc_bus slice that's causing the issue. So my
minimal fix from the previous mail would still be better, as it allows
to gate the nand_usdhc_bus clock, while keeping sys1_pll_266m enabled.

Regards,
Lucas
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: sdhci timeout on imx8mq

[Fabio Estevam]

Hi Lucas,

On Tue, Jan 5, 2021 at 12:06 PM Lucas Stach <l.stach@pengutronix.de> wrote:

> The reference manual states about this situation: "For any clock, its
> source must be left on when it is kept on. Behavior is undefined if
> this rule is violated."
> And it seems this is exactly what's happening here: some kind of glitch
> is introduced in the nand_usdhc_bus clock, which prevents the SDHCI
> controller from working, even though the clock branch is properly
> enabled later on. On my system the SDHCI timeout and following runtime
> suspend/resume cycle on the nand_usdhc_bus clock seem to get it back
> into a working state.

I think your analysis is correct and I recall helping a customer with
a similar issue:
https://community.nxp.com/t5/i-MX-Processors/External-clock-that-provide-root-clock-for-SAI3-and-SPDIF/m-p/1019834

Regards,

Fabio Estevam

Re: sdhci timeout on imx8mq

[Fabio Estevam]

Hi Lucas,

On Tue, Jan 5, 2021 at 12:06 PM Lucas Stach <l.stach@pengutronix.de> wrote:

> The reference manual states about this situation: "For any clock, its
> source must be left on when it is kept on. Behavior is undefined if
> this rule is violated."
> And it seems this is exactly what's happening here: some kind of glitch
> is introduced in the nand_usdhc_bus clock, which prevents the SDHCI
> controller from working, even though the clock branch is properly
> enabled later on. On my system the SDHCI timeout and following runtime
> suspend/resume cycle on the nand_usdhc_bus clock seem to get it back
> into a working state.

I think your analysis is correct and I recall helping a customer with
a similar issue:
https://community.nxp.com/t5/i-MX-Processors/External-clock-that-provide-root-clock-for-SAI3-and-SPDIF/m-p/1019834

Regards,

Fabio Estevam

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: sdhci timeout on imx8mq

[Jacky Bai]

> -----Original Message-----
> From: Fabio Estevam [mailto:festevam@gmail.com]
> Sent: Thursday, January 7, 2021 2:57 AM
> To: Lucas Stach <l.stach@pengutronix.de>
> Cc: Bough Chen <haibo.chen@nxp.com>; Angus Ainslie <angus@akkea.ca>;
> Leonard Crestez <leonard.crestez@nxp.com>; Peng Fan
> <peng.fan@nxp.com>; Abel Vesa <abel.vesa@nxp.com>; Stephen Boyd
> <sboyd@kernel.org>; Michael Turquette <mturquette@baylibre.com>; Ulf
> Hansson <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>;
> linux-mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>; Sascha
> Hauer <kernel@pengutronix.de>; moderated list:ARM/FREESCALE IMX / MXC
> ARM ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> Subject: Re: sdhci timeout on imx8mq
> 
> Hi Lucas,
> 
> On Tue, Jan 5, 2021 at 12:06 PM Lucas Stach <l.stach@pengutronix.de>
> wrote:
> 
> > The reference manual states about this situation: "For any clock, its
> > source must be left on when it is kept on. Behavior is undefined if
> > this rule is violated."
> > And it seems this is exactly what's happening here: some kind of
> > glitch is introduced in the nand_usdhc_bus clock, which prevents the
> > SDHCI controller from working, even though the clock branch is
> > properly enabled later on. On my system the SDHCI timeout and
> > following runtime suspend/resume cycle on the nand_usdhc_bus clock
> > seem to get it back into a working state.
> 
> I think your analysis is correct and I recall helping a customer with a similar
> issue:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcomm
> unity.nxp.com%2Ft5%2Fi-MX-Processors%2FExternal-clock-that-provide-root
> -clock-for-SAI3-and-SPDIF%2Fm-p%2F1019834&amp;data=04%7C01%7Cping
> .bai%40nxp.com%7C8d250a158cce469c378308d8b274d6d1%7C686ea1d3bc
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C637455562183497049%7CUnknow
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VkxuhmhDifzOxxfIgFz9PR5gKC1
> SyQhGeSHYysX1Co4%3D&amp;reserved=0
> 

For the customer case, it seem not the same issue. the customer issue is caused by clock source change while parent has no clock output.
This is inherit limitation for the CCM clock slice when using the smart interface to change the clock parent.

For current mmc timeout issue, I think we can have a try with nand_usdhc_bus clock gated at the beginning of kernel boot, directly modify the nand_usdhc_bus
Clock's HW register gate bit in clock-imx8mq.c.

BR
Jacky Bai
> Regards,
> 
> Fabio Estevam

RE: sdhci timeout on imx8mq

[Jacky Bai]

> -----Original Message-----
> From: Fabio Estevam [mailto:festevam@gmail.com]
> Sent: Thursday, January 7, 2021 2:57 AM
> To: Lucas Stach <l.stach@pengutronix.de>
> Cc: Bough Chen <haibo.chen@nxp.com>; Angus Ainslie <angus@akkea.ca>;
> Leonard Crestez <leonard.crestez@nxp.com>; Peng Fan
> <peng.fan@nxp.com>; Abel Vesa <abel.vesa@nxp.com>; Stephen Boyd
> <sboyd@kernel.org>; Michael Turquette <mturquette@baylibre.com>; Ulf
> Hansson <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>;
> linux-mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>; Sascha
> Hauer <kernel@pengutronix.de>; moderated list:ARM/FREESCALE IMX / MXC
> ARM ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> Subject: Re: sdhci timeout on imx8mq
> 
> Hi Lucas,
> 
> On Tue, Jan 5, 2021 at 12:06 PM Lucas Stach <l.stach@pengutronix.de>
> wrote:
> 
> > The reference manual states about this situation: "For any clock, its
> > source must be left on when it is kept on. Behavior is undefined if
> > this rule is violated."
> > And it seems this is exactly what's happening here: some kind of
> > glitch is introduced in the nand_usdhc_bus clock, which prevents the
> > SDHCI controller from working, even though the clock branch is
> > properly enabled later on. On my system the SDHCI timeout and
> > following runtime suspend/resume cycle on the nand_usdhc_bus clock
> > seem to get it back into a working state.
> 
> I think your analysis is correct and I recall helping a customer with a similar
> issue:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcomm
> unity.nxp.com%2Ft5%2Fi-MX-Processors%2FExternal-clock-that-provide-root
> -clock-for-SAI3-and-SPDIF%2Fm-p%2F1019834&amp;data=04%7C01%7Cping
> .bai%40nxp.com%7C8d250a158cce469c378308d8b274d6d1%7C686ea1d3bc
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C637455562183497049%7CUnknow
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VkxuhmhDifzOxxfIgFz9PR5gKC1
> SyQhGeSHYysX1Co4%3D&amp;reserved=0
> 

For the customer case, it seem not the same issue. the customer issue is caused by clock source change while parent has no clock output.
This is inherit limitation for the CCM clock slice when using the smart interface to change the clock parent.

For current mmc timeout issue, I think we can have a try with nand_usdhc_bus clock gated at the beginning of kernel boot, directly modify the nand_usdhc_bus
Clock's HW register gate bit in clock-imx8mq.c.

BR
Jacky Bai
> Regards,
> 
> Fabio Estevam
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: sdhci timeout on imx8mq

[Bough Chen]

> -----Original Message-----
> From: Lucas Stach [mailto:l.stach@pengutronix.de]
> Sent: 2021年1月6日 23:10
> To: Bough Chen <haibo.chen@nxp.com>; Fabio Estevam
> <festevam@gmail.com>; Angus Ainslie <angus@akkea.ca>; Peng Fan
> <peng.fan@nxp.com>; Abel Vesa <abel.vesa@nxp.com>; Stephen Boyd
> <sboyd@kernel.org>; Michael Turquette <mturquette@baylibre.com>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>;
> linux-mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>; Sascha Hauer
> <kernel@pengutronix.de>; moderated list:ARM/FREESCALE IMX / MXC ARM
> ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> Subject: Re: sdhci timeout on imx8mq
> 
> Hi Bough,
> 
> Am Mittwoch, dem 06.01.2021 um 09:29 +0000 schrieb Bough Chen:
> > > -----Original Message-----
> > > From: Lucas Stach [mailto:l.stach@pengutronix.de]
> > > Sent: 2021年1月5日 23:07
> > > To: Bough Chen <haibo.chen@nxp.com>; Fabio Estevam
> > > <festevam@gmail.com>; Angus Ainslie <angus@akkea.ca>; Leonard
> > > Crestez <leonard.crestez@nxp.com>; Peng Fan <peng.fan@nxp.com>; Abel
> > > Vesa <abel.vesa@nxp.com>; Stephen Boyd <sboyd@kernel.org>; Michael
> > > Turquette <mturquette@baylibre.com>
> > > Cc: Ulf Hansson <ulf.hansson@linaro.org>; Guido Günther <
> > > agx@sigxcpu.org>; linux-mmc <linux-mmc@vger.kernel.org>; Adrian
> > > Hunter <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>;
> > > Sascha Hauer <kernel@pengutronix.de>; moderated list:ARM/FREESCALE
> > > IMX / MXC ARM ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> > > Subject: Re: sdhci timeout on imx8mq
> > >
> > > Hi all,
> > >
> > > Am Mittwoch, dem 08.07.2020 um 01:32 +0000 schrieb BOUGH CHEN:
> > > > > -----Original Message-----
> > > > > From: Fabio Estevam [mailto:festevam@gmail.com]
> > > > > Sent: 2020年7月7日 20:45
> > > > > To: Angus Ainslie <angus@akkea.ca>
> > > > > Cc: BOUGH CHEN <haibo.chen@nxp.com>; Ulf Hansson
> > > > > <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>;
> > > > > linux-
> > > > > mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> > > > > <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>;
> > > > > Sascha Hauer < kernel@pengutronix.de>; moderated
> > > > > list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
> > > > > <linux-arm-kernel@lists.infradead.org>
> > > > > Subject: Re: sdhci timeout on imx8mq
> > > > >
> > > > > Hi Angus,
> > > > >
> > > > > On Tue, Jun 30, 2020 at 4:39 PM Angus Ainslie <angus@akkea.ca>
> > > > > wrote:
> > > > >
> > > > > > Has there been any progress with this. I'm getting this on
> > > > > > about 50% of
> > > > >
> > > > > Not from my side, sorry.
> > > > >
> > > > > Bough,
> > > > >
> > > > > Do you know why this problem affects the imx8mq-evk versions
> > > > > that are populated with the Micron eMMC and not the ones with
> > > > > Sandisk eMMC?
> > > >
> > > > Hi Angus,
> > > >
> > > > Can you show me the full fail log? I do not meet this issue on my
> > > > side, besides, which kind of uboot do you use?
> > >
> > > I was finally able to bisect this issue, which wasn't that much fun
> > > due to the issue not being reproducible 100%. :/ Turns out that the
> > > issue is even more interesting than I thought and likely doesn't
> > > have anything to do with SDHCI or used bootloader versions. Here's
> > > my current debugging state:
> > >
> > > I've bisected the issue down to b04383b6a558 (clk: imx8mq: Define
> > > gates for
> > > pll1/2 fixed dividers). The change itself looks fine to me, still
> > > CC'ed Leonard for good measure.
> > >
> > > In my testing the following partial revert fixes the issue:
> > >
> > > --- a/drivers/clk/imx/clk-imx8mq.c
> > > +++ b/drivers/clk/imx/clk-imx8mq.c
> > > @@ -365,7 +365,7 @@ static int imx8mq_clocks_probe(struct
> > > platform_device *pdev)
> > >         hws[IMX8MQ_SYS1_PLL_133M_CG] =
> > > imx_clk_hw_gate("sys1_pll_133m_cg", "sys1_pll_out", base + 0x30,
> > > 15);
> > >         hws[IMX8MQ_SYS1_PLL_160M_CG] =
> > > imx_clk_hw_gate("sys1_pll_160m_cg", "sys1_pll_out", base + 0x30,
> > > 17);
> > >         hws[IMX8MQ_SYS1_PLL_200M_CG] =
> > > imx_clk_hw_gate("sys1_pll_200m_cg", "sys1_pll_out", base + 0x30, 19);
> > > -       hws[IMX8MQ_SYS1_PLL_266M_CG] =
> > > imx_clk_hw_gate("sys1_pll_266m_cg", "sys1_pll_out", base + 0x30,
> > > 21);
> > >         hws[IMX8MQ_SYS1_PLL_400M_CG] =
> > > imx_clk_hw_gate("sys1_pll_400m_cg", "sys1_pll_out", base + 0x30,
> > > 23);
> > >         hws[IMX8MQ_SYS1_PLL_800M_CG] =
> > > imx_clk_hw_gate("sys1_pll_800m_cg", "sys1_pll_out", base + 0x30,
> > > 25);
> > >
> > > @@ -375,7 +375,7 @@ static int imx8mq_clocks_probe(struct
> > > platform_device *pdev)
> > >         hws[IMX8MQ_SYS1_PLL_133M] =
> > > imx_clk_hw_fixed_factor("sys1_pll_133m", "sys1_pll_133m_cg", 1, 6);
> > >         hws[IMX8MQ_SYS1_PLL_160M] =
> > > imx_clk_hw_fixed_factor("sys1_pll_160m", "sys1_pll_160m_cg", 1, 5);
> > >         hws[IMX8MQ_SYS1_PLL_200M] =
> > > imx_clk_hw_fixed_factor("sys1_pll_200m", "sys1_pll_200m_cg", 1, 4);
> > > -       hws[IMX8MQ_SYS1_PLL_266M] =
> > > imx_clk_hw_fixed_factor("sys1_pll_266m", "sys1_pll_266m_cg", 1, 3);
> > > +       hws[IMX8MQ_SYS1_PLL_266M] =
> > > + imx_clk_hw_fixed_factor("sys1_pll_266m", "sys1_pll_out", 1, 3);
> > >         hws[IMX8MQ_SYS1_PLL_400M] =
> > > imx_clk_hw_fixed_factor("sys1_pll_400m", "sys1_pll_400m_cg", 1, 2);
> > >         hws[IMX8MQ_SYS1_PLL_800M] =
> > > imx_clk_hw_fixed_factor("sys1_pll_800m", "sys1_pll_800m_cg", 1, 1);
> > >
> > > The sys1_pll_266m is the parent of nand_usdhc_bus. I've validated
> > > that the SDHCI driver properly enables this bus clock across the
> > > problematic card access.
> > > So what I think is happening here is that both nand_usdhc_bus and
> > > sys1_pll_266m are initially enabled. Sometime during boot
> > > sys1_pll_266m gets disabled due to runtime PM on the enet_axi clock,
> > > which is a direct child of sys1_pll_266m. At this point
> > > nand_usdhc_bus is still enabled, but no consumer has claimed the
> > > clock yet, so the parent clock gets disabled while this branch of
> > > the clock tree is still active.
> >
> > Hi Lucas,
> >
> > According to the clock tree, if nand_usdhc_bus is still enabled, then
> > sys1_pll_266m has no chance to disable.
> 
> This statement is only correct after the SDHCI driver is probed an has enabled
> nand_usdhc_bus. Before the driver probes the refcounts on the clocks are not
> synchronized, so sys1_pll_266m_cg can be disabled, while nand_usdhc_bus is
> enabled (from software running before Linux), even though no consumer is
> using nand_usdhc_bus, yet.

Yes, agree. For current case, uboot gate on the sys1_pll_266m, then boot the Linux.
In Linux, after clock driver probe, due the the support of sys1_pll_266m_cg, this sys1_pll_266m is gate off by clock driver due to no default consumer.

> 
> >     sys1_pll_266m_cg                  1        1        0
> 800000000          0     0  50000         Y
> >        sys1_pll_266m                  1        1        0
> 266666666          0     0  50000         Y
> >           nand_usdhc_bus              0        0        0
> 266666666          0     0  50000         N
> >              nand_usdhc_rawnand_clk       0        0        0
> 266666666          0     0  50000         N
> >           enet_axi                    1        1        0
> 266666666          0     0  50000         Y
> >              enet1_root_clk           2        2        0
> 266666666          0     0  50000         Y
> >
> >
> > This issue seems related with the following errta:
> >
> > e11232: USDHC: uSDHC setting requirement for IPG_CLK and AHB_BUS
> > clocks
> > Description: uSDHC AHB_BUS and IPG_CLK clocks must be synchronized.
> > Due to current physical design implementation, AHB_BUS and IPG_CLK
> > must come from same clock source to maintain clock sync.
> > Workaround: Set AHB_BUS and IPG_CLK to clock source from PLL1.
> >
> > After sys1_pll_266m gate off/on, seems need to sync the USDHC AHB bus
> > and USDHC IPG_clk again. (Here usdhc AHB BUS source from
> > nand_usdhc_bus.)
> > This sync is handle by hardware, and maybe need some time, during this
> > sync period, usdhc operation may has issue.
> 
> Where in HW is this synchronization done? If it's at the uSDHC controller side, I
> would expect this issue to show up even with the commit reverted, as
> nand_usdhc_bus gets gated due to runtime PM from the controller side. The
> only difference with the commit in question is that now the clock branch can be
> gated _before_ nand_usdhc_bus. If the synchronization is done somewhere in
> the clock tree than this might be an issue.
> 

Not in uSDHC side. This synchronization should be done somewhere in clock tree(hardware side). 

> >
> > I just double check our local v5.10 branch, already revert the commit
> > b04383b6a558 (clk: imx8mq: Define gates for pll1/2 fixed dividers).
> > So to fix this issue, one method is revert this patch, another method
> > is keep the 'nand_usdhc_bus' always on. Add change like this:
> >
> > diff --git a/drivers/clk/imx/clk-imx8mq.c
> > b/drivers/clk/imx/clk-imx8mq.c index 779ea69e639c..939806b36916 100644
> > --- a/drivers/clk/imx/clk-imx8mq.c
> > +++ b/drivers/clk/imx/clk-imx8mq.c
> > @@ -433,7 +433,7 @@ static int imx8mq_clocks_probe(struct
> > platform_device *pdev)
> >         /* BUS */
> >         hws[IMX8MQ_CLK_MAIN_AXI] =
> > imx8m_clk_hw_composite_bus_critical("main_axi", imx8mq_main_axi_sels,
> > base + 0x8800);
> >         hws[IMX8MQ_CLK_ENET_AXI] =
> imx8m_clk_hw_composite_bus("enet_axi", imx8mq_enet_axi_sels, base +
> 0x8880);
> > -       hws[IMX8MQ_CLK_NAND_USDHC_BUS] =
> imx8m_clk_hw_composite_bus("nand_usdhc_bus", imx8mq_nand_usdhc_sels,
> base + 0x8900);
> > +       hws[IMX8MQ_CLK_NAND_USDHC_BUS] =
> > + imx8m_clk_hw_composite_bus_critical("nand_usdhc_bus",
> > + imx8mq_nand_usdhc_sels, base + 0x8900);
> >         hws[IMX8MQ_CLK_VPU_BUS] =
> > imx8m_clk_hw_composite_bus("vpu_bus", imx8mq_vpu_bus_sels, base +
> > 0x8980);
> >         hws[IMX8MQ_CLK_DISP_AXI] =
> > imx8m_clk_hw_composite_bus("disp_axi", imx8mq_disp_axi_sels, base +
> > 0x8a00);
> >         hws[IMX8MQ_CLK_DISP_APB] =
> > imx8m_clk_hw_composite_bus("disp_apb", imx8mq_disp_apb_sels, base +
> > 0x8a80);
> >
> >
> > What you think? Or any other suggestion?
> 
> This is suboptimal, as it will not allow to gate the uSDHC controller AHB clock in
> runtime suspend. Also my testing shows that it's the gate _before_ the
> nand_usdhc_bus slice that's causing the issue. So my minimal fix from the
> previous mail would still be better, as it allows to gate the nand_usdhc_bus
> clock, while keeping sys1_pll_266m enabled.

Whether to choose your minimal fix or revert the commit, let's involve clock team member, Abel/Jacky, any comment?
Our local tree just revert this commit, I think there are some other reason, Jacky, could you help clarify that?

Best Regards
Haibo Chen
> 
> Regards,
> Lucas
> >

RE: sdhci timeout on imx8mq

[Bough Chen]

> -----Original Message-----
> From: Lucas Stach [mailto:l.stach@pengutronix.de]
> Sent: 2021年1月6日 23:10
> To: Bough Chen <haibo.chen@nxp.com>; Fabio Estevam
> <festevam@gmail.com>; Angus Ainslie <angus@akkea.ca>; Peng Fan
> <peng.fan@nxp.com>; Abel Vesa <abel.vesa@nxp.com>; Stephen Boyd
> <sboyd@kernel.org>; Michael Turquette <mturquette@baylibre.com>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>;
> linux-mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>; Sascha Hauer
> <kernel@pengutronix.de>; moderated list:ARM/FREESCALE IMX / MXC ARM
> ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> Subject: Re: sdhci timeout on imx8mq
> 
> Hi Bough,
> 
> Am Mittwoch, dem 06.01.2021 um 09:29 +0000 schrieb Bough Chen:
> > > -----Original Message-----
> > > From: Lucas Stach [mailto:l.stach@pengutronix.de]
> > > Sent: 2021年1月5日 23:07
> > > To: Bough Chen <haibo.chen@nxp.com>; Fabio Estevam
> > > <festevam@gmail.com>; Angus Ainslie <angus@akkea.ca>; Leonard
> > > Crestez <leonard.crestez@nxp.com>; Peng Fan <peng.fan@nxp.com>; Abel
> > > Vesa <abel.vesa@nxp.com>; Stephen Boyd <sboyd@kernel.org>; Michael
> > > Turquette <mturquette@baylibre.com>
> > > Cc: Ulf Hansson <ulf.hansson@linaro.org>; Guido Günther <
> > > agx@sigxcpu.org>; linux-mmc <linux-mmc@vger.kernel.org>; Adrian
> > > Hunter <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>;
> > > Sascha Hauer <kernel@pengutronix.de>; moderated list:ARM/FREESCALE
> > > IMX / MXC ARM ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> > > Subject: Re: sdhci timeout on imx8mq
> > >
> > > Hi all,
> > >
> > > Am Mittwoch, dem 08.07.2020 um 01:32 +0000 schrieb BOUGH CHEN:
> > > > > -----Original Message-----
> > > > > From: Fabio Estevam [mailto:festevam@gmail.com]
> > > > > Sent: 2020年7月7日 20:45
> > > > > To: Angus Ainslie <angus@akkea.ca>
> > > > > Cc: BOUGH CHEN <haibo.chen@nxp.com>; Ulf Hansson
> > > > > <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>;
> > > > > linux-
> > > > > mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> > > > > <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>;
> > > > > Sascha Hauer < kernel@pengutronix.de>; moderated
> > > > > list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
> > > > > <linux-arm-kernel@lists.infradead.org>
> > > > > Subject: Re: sdhci timeout on imx8mq
> > > > >
> > > > > Hi Angus,
> > > > >
> > > > > On Tue, Jun 30, 2020 at 4:39 PM Angus Ainslie <angus@akkea.ca>
> > > > > wrote:
> > > > >
> > > > > > Has there been any progress with this. I'm getting this on
> > > > > > about 50% of
> > > > >
> > > > > Not from my side, sorry.
> > > > >
> > > > > Bough,
> > > > >
> > > > > Do you know why this problem affects the imx8mq-evk versions
> > > > > that are populated with the Micron eMMC and not the ones with
> > > > > Sandisk eMMC?
> > > >
> > > > Hi Angus,
> > > >
> > > > Can you show me the full fail log? I do not meet this issue on my
> > > > side, besides, which kind of uboot do you use?
> > >
> > > I was finally able to bisect this issue, which wasn't that much fun
> > > due to the issue not being reproducible 100%. :/ Turns out that the
> > > issue is even more interesting than I thought and likely doesn't
> > > have anything to do with SDHCI or used bootloader versions. Here's
> > > my current debugging state:
> > >
> > > I've bisected the issue down to b04383b6a558 (clk: imx8mq: Define
> > > gates for
> > > pll1/2 fixed dividers). The change itself looks fine to me, still
> > > CC'ed Leonard for good measure.
> > >
> > > In my testing the following partial revert fixes the issue:
> > >
> > > --- a/drivers/clk/imx/clk-imx8mq.c
> > > +++ b/drivers/clk/imx/clk-imx8mq.c
> > > @@ -365,7 +365,7 @@ static int imx8mq_clocks_probe(struct
> > > platform_device *pdev)
> > >         hws[IMX8MQ_SYS1_PLL_133M_CG] =
> > > imx_clk_hw_gate("sys1_pll_133m_cg", "sys1_pll_out", base + 0x30,
> > > 15);
> > >         hws[IMX8MQ_SYS1_PLL_160M_CG] =
> > > imx_clk_hw_gate("sys1_pll_160m_cg", "sys1_pll_out", base + 0x30,
> > > 17);
> > >         hws[IMX8MQ_SYS1_PLL_200M_CG] =
> > > imx_clk_hw_gate("sys1_pll_200m_cg", "sys1_pll_out", base + 0x30, 19);
> > > -       hws[IMX8MQ_SYS1_PLL_266M_CG] =
> > > imx_clk_hw_gate("sys1_pll_266m_cg", "sys1_pll_out", base + 0x30,
> > > 21);
> > >         hws[IMX8MQ_SYS1_PLL_400M_CG] =
> > > imx_clk_hw_gate("sys1_pll_400m_cg", "sys1_pll_out", base + 0x30,
> > > 23);
> > >         hws[IMX8MQ_SYS1_PLL_800M_CG] =
> > > imx_clk_hw_gate("sys1_pll_800m_cg", "sys1_pll_out", base + 0x30,
> > > 25);
> > >
> > > @@ -375,7 +375,7 @@ static int imx8mq_clocks_probe(struct
> > > platform_device *pdev)
> > >         hws[IMX8MQ_SYS1_PLL_133M] =
> > > imx_clk_hw_fixed_factor("sys1_pll_133m", "sys1_pll_133m_cg", 1, 6);
> > >         hws[IMX8MQ_SYS1_PLL_160M] =
> > > imx_clk_hw_fixed_factor("sys1_pll_160m", "sys1_pll_160m_cg", 1, 5);
> > >         hws[IMX8MQ_SYS1_PLL_200M] =
> > > imx_clk_hw_fixed_factor("sys1_pll_200m", "sys1_pll_200m_cg", 1, 4);
> > > -       hws[IMX8MQ_SYS1_PLL_266M] =
> > > imx_clk_hw_fixed_factor("sys1_pll_266m", "sys1_pll_266m_cg", 1, 3);
> > > +       hws[IMX8MQ_SYS1_PLL_266M] =
> > > + imx_clk_hw_fixed_factor("sys1_pll_266m", "sys1_pll_out", 1, 3);
> > >         hws[IMX8MQ_SYS1_PLL_400M] =
> > > imx_clk_hw_fixed_factor("sys1_pll_400m", "sys1_pll_400m_cg", 1, 2);
> > >         hws[IMX8MQ_SYS1_PLL_800M] =
> > > imx_clk_hw_fixed_factor("sys1_pll_800m", "sys1_pll_800m_cg", 1, 1);
> > >
> > > The sys1_pll_266m is the parent of nand_usdhc_bus. I've validated
> > > that the SDHCI driver properly enables this bus clock across the
> > > problematic card access.
> > > So what I think is happening here is that both nand_usdhc_bus and
> > > sys1_pll_266m are initially enabled. Sometime during boot
> > > sys1_pll_266m gets disabled due to runtime PM on the enet_axi clock,
> > > which is a direct child of sys1_pll_266m. At this point
> > > nand_usdhc_bus is still enabled, but no consumer has claimed the
> > > clock yet, so the parent clock gets disabled while this branch of
> > > the clock tree is still active.
> >
> > Hi Lucas,
> >
> > According to the clock tree, if nand_usdhc_bus is still enabled, then
> > sys1_pll_266m has no chance to disable.
> 
> This statement is only correct after the SDHCI driver is probed an has enabled
> nand_usdhc_bus. Before the driver probes the refcounts on the clocks are not
> synchronized, so sys1_pll_266m_cg can be disabled, while nand_usdhc_bus is
> enabled (from software running before Linux), even though no consumer is
> using nand_usdhc_bus, yet.

Yes, agree. For current case, uboot gate on the sys1_pll_266m, then boot the Linux.
In Linux, after clock driver probe, due the the support of sys1_pll_266m_cg, this sys1_pll_266m is gate off by clock driver due to no default consumer.

> 
> >     sys1_pll_266m_cg                  1        1        0
> 800000000          0     0  50000         Y
> >        sys1_pll_266m                  1        1        0
> 266666666          0     0  50000         Y
> >           nand_usdhc_bus              0        0        0
> 266666666          0     0  50000         N
> >              nand_usdhc_rawnand_clk       0        0        0
> 266666666          0     0  50000         N
> >           enet_axi                    1        1        0
> 266666666          0     0  50000         Y
> >              enet1_root_clk           2        2        0
> 266666666          0     0  50000         Y
> >
> >
> > This issue seems related with the following errta:
> >
> > e11232: USDHC: uSDHC setting requirement for IPG_CLK and AHB_BUS
> > clocks
> > Description: uSDHC AHB_BUS and IPG_CLK clocks must be synchronized.
> > Due to current physical design implementation, AHB_BUS and IPG_CLK
> > must come from same clock source to maintain clock sync.
> > Workaround: Set AHB_BUS and IPG_CLK to clock source from PLL1.
> >
> > After sys1_pll_266m gate off/on, seems need to sync the USDHC AHB bus
> > and USDHC IPG_clk again. (Here usdhc AHB BUS source from
> > nand_usdhc_bus.)
> > This sync is handle by hardware, and maybe need some time, during this
> > sync period, usdhc operation may has issue.
> 
> Where in HW is this synchronization done? If it's at the uSDHC controller side, I
> would expect this issue to show up even with the commit reverted, as
> nand_usdhc_bus gets gated due to runtime PM from the controller side. The
> only difference with the commit in question is that now the clock branch can be
> gated _before_ nand_usdhc_bus. If the synchronization is done somewhere in
> the clock tree than this might be an issue.
> 

Not in uSDHC side. This synchronization should be done somewhere in clock tree(hardware side). 

> >
> > I just double check our local v5.10 branch, already revert the commit
> > b04383b6a558 (clk: imx8mq: Define gates for pll1/2 fixed dividers).
> > So to fix this issue, one method is revert this patch, another method
> > is keep the 'nand_usdhc_bus' always on. Add change like this:
> >
> > diff --git a/drivers/clk/imx/clk-imx8mq.c
> > b/drivers/clk/imx/clk-imx8mq.c index 779ea69e639c..939806b36916 100644
> > --- a/drivers/clk/imx/clk-imx8mq.c
> > +++ b/drivers/clk/imx/clk-imx8mq.c
> > @@ -433,7 +433,7 @@ static int imx8mq_clocks_probe(struct
> > platform_device *pdev)
> >         /* BUS */
> >         hws[IMX8MQ_CLK_MAIN_AXI] =
> > imx8m_clk_hw_composite_bus_critical("main_axi", imx8mq_main_axi_sels,
> > base + 0x8800);
> >         hws[IMX8MQ_CLK_ENET_AXI] =
> imx8m_clk_hw_composite_bus("enet_axi", imx8mq_enet_axi_sels, base +
> 0x8880);
> > -       hws[IMX8MQ_CLK_NAND_USDHC_BUS] =
> imx8m_clk_hw_composite_bus("nand_usdhc_bus", imx8mq_nand_usdhc_sels,
> base + 0x8900);
> > +       hws[IMX8MQ_CLK_NAND_USDHC_BUS] =
> > + imx8m_clk_hw_composite_bus_critical("nand_usdhc_bus",
> > + imx8mq_nand_usdhc_sels, base + 0x8900);
> >         hws[IMX8MQ_CLK_VPU_BUS] =
> > imx8m_clk_hw_composite_bus("vpu_bus", imx8mq_vpu_bus_sels, base +
> > 0x8980);
> >         hws[IMX8MQ_CLK_DISP_AXI] =
> > imx8m_clk_hw_composite_bus("disp_axi", imx8mq_disp_axi_sels, base +
> > 0x8a00);
> >         hws[IMX8MQ_CLK_DISP_APB] =
> > imx8m_clk_hw_composite_bus("disp_apb", imx8mq_disp_apb_sels, base +
> > 0x8a80);
> >
> >
> > What you think? Or any other suggestion?
> 
> This is suboptimal, as it will not allow to gate the uSDHC controller AHB clock in
> runtime suspend. Also my testing shows that it's the gate _before_ the
> nand_usdhc_bus slice that's causing the issue. So my minimal fix from the
> previous mail would still be better, as it allows to gate the nand_usdhc_bus
> clock, while keeping sys1_pll_266m enabled.

Whether to choose your minimal fix or revert the commit, let's involve clock team member, Abel/Jacky, any comment?
Our local tree just revert this commit, I think there are some other reason, Jacky, could you help clarify that?

Best Regards
Haibo Chen
> 
> Regards,
> Lucas
> >

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: sdhci timeout on imx8mq

[Lucas Stach]

Hi Jacky,

Am Donnerstag, dem 07.01.2021 um 01:30 +0000 schrieb Jacky Bai:
> > -----Original Message-----
> > From: Fabio Estevam [mailto:festevam@gmail.com]
> > Sent: Thursday, January 7, 2021 2:57 AM
> > To: Lucas Stach <l.stach@pengutronix.de>
> > Cc: Bough Chen <haibo.chen@nxp.com>; Angus Ainslie
> > <angus@akkea.ca>;
> > Leonard Crestez <leonard.crestez@nxp.com>; Peng Fan
> > <peng.fan@nxp.com>; Abel Vesa <abel.vesa@nxp.com>; Stephen Boyd
> > <sboyd@kernel.org>; Michael Turquette <mturquette@baylibre.com>;
> > Ulf
> > Hansson <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>;
> > linux-mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> > <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>; Sascha
> > Hauer <kernel@pengutronix.de>; moderated list:ARM/FREESCALE IMX /
> > MXC
> > ARM ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> > Subject: Re: sdhci timeout on imx8mq
> > 
> > Hi Lucas,
> > 
> > On Tue, Jan 5, 2021 at 12:06 PM Lucas Stach
> > <l.stach@pengutronix.de>
> > wrote:
> > 
> > > The reference manual states about this situation: "For any clock,
> > > its
> > > source must be left on when it is kept on. Behavior is undefined
> > > if
> > > this rule is violated."
> > > And it seems this is exactly what's happening here: some kind of
> > > glitch is introduced in the nand_usdhc_bus clock, which prevents
> > > the
> > > SDHCI controller from working, even though the clock branch is
> > > properly enabled later on. On my system the SDHCI timeout and
> > > following runtime suspend/resume cycle on the nand_usdhc_bus
> > > clock
> > > seem to get it back into a working state.
> > 
> > I think your analysis is correct and I recall helping a customer
> > with a similar
> > issue:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcomm
> > unity.nxp.com%2Ft5%2Fi-MX-Processors%2FExternal-clock-that-provide-
> > root
> > -clock-for-SAI3-and-SPDIF%2Fm-p%2F1019834&amp;data=04%7C01%7Cping
> > .bai%40nxp.com%7C8d250a158cce469c378308d8b274d6d1%7C686ea1d3bc
> > 2b4c6fa92cd99c5c301635%7C0%7C0%7C637455562183497049%7CUnknow
> > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > WwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VkxuhmhDifzOxxfIgFz9PR5gKC1
> > SyQhGeSHYysX1Co4%3D&amp;reserved=0
> > 
> 
> For the customer case, it seem not the same issue. the customer issue
> is caused by clock source change while parent has no clock output.
> This is inherit limitation for the CCM clock slice when using the
> smart interface to change the clock parent.
> 
> For current mmc timeout issue, I think we can have a try with
> nand_usdhc_bus clock gated at the beginning of kernel boot, directly
> modify the nand_usdhc_bus
> Clock's HW register gate bit in clock-imx8mq.c.

While this might be an option to fix this specific issue, I would hope
we can come up with something more generic, as the current clock
framework behavior allows to violate the system specification
constraint that parent clocks must not be disabled when any of the
children are active. This seems like a fundamental issue and might hurt
us also with other clocks than this specific nand_usdhc_bus clock.

Can you tell us if there were other issues found with the PLL1/2 gating
patch? The fact that, according to Bough, it's reverted in your tree
seems to suggest this.

Regards,
Lucas

Re: sdhci timeout on imx8mq

[Lucas Stach]

Hi Jacky,

Am Donnerstag, dem 07.01.2021 um 01:30 +0000 schrieb Jacky Bai:
> > -----Original Message-----
> > From: Fabio Estevam [mailto:festevam@gmail.com]
> > Sent: Thursday, January 7, 2021 2:57 AM
> > To: Lucas Stach <l.stach@pengutronix.de>
> > Cc: Bough Chen <haibo.chen@nxp.com>; Angus Ainslie
> > <angus@akkea.ca>;
> > Leonard Crestez <leonard.crestez@nxp.com>; Peng Fan
> > <peng.fan@nxp.com>; Abel Vesa <abel.vesa@nxp.com>; Stephen Boyd
> > <sboyd@kernel.org>; Michael Turquette <mturquette@baylibre.com>;
> > Ulf
> > Hansson <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>;
> > linux-mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> > <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>; Sascha
> > Hauer <kernel@pengutronix.de>; moderated list:ARM/FREESCALE IMX /
> > MXC
> > ARM ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> > Subject: Re: sdhci timeout on imx8mq
> > 
> > Hi Lucas,
> > 
> > On Tue, Jan 5, 2021 at 12:06 PM Lucas Stach
> > <l.stach@pengutronix.de>
> > wrote:
> > 
> > > The reference manual states about this situation: "For any clock,
> > > its
> > > source must be left on when it is kept on. Behavior is undefined
> > > if
> > > this rule is violated."
> > > And it seems this is exactly what's happening here: some kind of
> > > glitch is introduced in the nand_usdhc_bus clock, which prevents
> > > the
> > > SDHCI controller from working, even though the clock branch is
> > > properly enabled later on. On my system the SDHCI timeout and
> > > following runtime suspend/resume cycle on the nand_usdhc_bus
> > > clock
> > > seem to get it back into a working state.
> > 
> > I think your analysis is correct and I recall helping a customer
> > with a similar
> > issue:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcomm
> > unity.nxp.com%2Ft5%2Fi-MX-Processors%2FExternal-clock-that-provide-
> > root
> > -clock-for-SAI3-and-SPDIF%2Fm-p%2F1019834&amp;data=04%7C01%7Cping
> > .bai%40nxp.com%7C8d250a158cce469c378308d8b274d6d1%7C686ea1d3bc
> > 2b4c6fa92cd99c5c301635%7C0%7C0%7C637455562183497049%7CUnknow
> > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > WwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VkxuhmhDifzOxxfIgFz9PR5gKC1
> > SyQhGeSHYysX1Co4%3D&amp;reserved=0
> > 
> 
> For the customer case, it seem not the same issue. the customer issue
> is caused by clock source change while parent has no clock output.
> This is inherit limitation for the CCM clock slice when using the
> smart interface to change the clock parent.
> 
> For current mmc timeout issue, I think we can have a try with
> nand_usdhc_bus clock gated at the beginning of kernel boot, directly
> modify the nand_usdhc_bus
> Clock's HW register gate bit in clock-imx8mq.c.

While this might be an option to fix this specific issue, I would hope
we can come up with something more generic, as the current clock
framework behavior allows to violate the system specification
constraint that parent clocks must not be disabled when any of the
children are active. This seems like a fundamental issue and might hurt
us also with other clocks than this specific nand_usdhc_bus clock.

Can you tell us if there were other issues found with the PLL1/2 gating
patch? The fact that, according to Bough, it's reverted in your tree
seems to suggest this.

Regards,
Lucas


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: sdhci timeout on imx8mq

[Jacky Bai]

> Subject: Re: sdhci timeout on imx8mq
> 
> Hi Jacky,
> 
> Am Donnerstag, dem 07.01.2021 um 01:30 +0000 schrieb Jacky Bai:
> > > -----Original Message-----
> > > From: Fabio Estevam [mailto:festevam@gmail.com]
> > > Sent: Thursday, January 7, 2021 2:57 AM
> > > To: Lucas Stach <l.stach@pengutronix.de>
> > > Cc: Bough Chen <haibo.chen@nxp.com>; Angus Ainslie
> <angus@akkea.ca>;
> > > Leonard Crestez <leonard.crestez@nxp.com>; Peng Fan
> > > <peng.fan@nxp.com>; Abel Vesa <abel.vesa@nxp.com>; Stephen Boyd
> > > <sboyd@kernel.org>; Michael Turquette <mturquette@baylibre.com>; Ulf
> > > Hansson <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>;
> > > linux-mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> > > <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>; Sascha
> > > Hauer <kernel@pengutronix.de>; moderated list:ARM/FREESCALE IMX /
> > > MXC ARM ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> > > Subject: Re: sdhci timeout on imx8mq
> > >
> > > Hi Lucas,
> > >
> > > On Tue, Jan 5, 2021 at 12:06 PM Lucas Stach <l.stach@pengutronix.de>
> > > wrote:
> > >
> > > > The reference manual states about this situation: "For any clock,
> > > > its source must be left on when it is kept on. Behavior is
> > > > undefined if this rule is violated."
> > > > And it seems this is exactly what's happening here: some kind of
> > > > glitch is introduced in the nand_usdhc_bus clock, which prevents
> > > > the SDHCI controller from working, even though the clock branch is
> > > > properly enabled later on. On my system the SDHCI timeout and
> > > > following runtime suspend/resume cycle on the nand_usdhc_bus clock
> > > > seem to get it back into a working state.
> > >
> > > I think your analysis is correct and I recall helping a customer
> > > with a similar
> > > issue:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fco
> > > mm
> > > unity.nxp.com%2Ft5%2Fi-MX-Processors%2FExternal-clock-that-provide-
> > > root
> > >
> -clock-for-SAI3-and-SPDIF%2Fm-p%2F1019834&amp;data=04%7C01%7Cping
> > > .bai%40nxp.com%7C8d250a158cce469c378308d8b274d6d1%7C686ea1d
> 3bc
> > >
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C637455562183497049%7CUnknow
> > >
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > >
> WwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VkxuhmhDifzOxxfIgFz9PR5gKC1
> > > SyQhGeSHYysX1Co4%3D&amp;reserved=0
> > >
> >
> > For the customer case, it seem not the same issue. the customer issue
> > is caused by clock source change while parent has no clock output.
> > This is inherit limitation for the CCM clock slice when using the
> > smart interface to change the clock parent.
> >
> > For current mmc timeout issue, I think we can have a try with
> > nand_usdhc_bus clock gated at the beginning of kernel boot, directly
> > modify the nand_usdhc_bus Clock's HW register gate bit in
> > clock-imx8mq.c.
> 
> While this might be an option to fix this specific issue, I would hope we can
> come up with something more generic, as the current clock framework
> behavior allows to violate the system specification constraint that parent
> clocks must not be disabled when any of the children are active. This seems
> like a fundamental issue and might hurt us also with other clocks than this
> specific nand_usdhc_bus clock.

Yes, my proposal is for debug purpose. We will do further debug on our EVK board too.

> 
> Can you tell us if there were other issues found with the PLL1/2 gating patch?
> The fact that, according to Bough, it's reverted in your tree seems to suggest
> this.

It is mainly because that the PLL1/2 derived clocks are shared between Cortex-A domain & Cortex-M domain.
M4 domain may also need some of these clocks enabled even A core domain does not use it. There is no
well-defined HW mechanism like CCM CCGR domain control to manage the PLL divider's gate based on each domain's request.
So I reverted that patch in our internal tree before we find other more solid solution for shared clock management.


BR
Jacky Bai
> 
> Regards,
> Lucas

RE: sdhci timeout on imx8mq

[Jacky Bai]

> Subject: Re: sdhci timeout on imx8mq
> 
> Hi Jacky,
> 
> Am Donnerstag, dem 07.01.2021 um 01:30 +0000 schrieb Jacky Bai:
> > > -----Original Message-----
> > > From: Fabio Estevam [mailto:festevam@gmail.com]
> > > Sent: Thursday, January 7, 2021 2:57 AM
> > > To: Lucas Stach <l.stach@pengutronix.de>
> > > Cc: Bough Chen <haibo.chen@nxp.com>; Angus Ainslie
> <angus@akkea.ca>;
> > > Leonard Crestez <leonard.crestez@nxp.com>; Peng Fan
> > > <peng.fan@nxp.com>; Abel Vesa <abel.vesa@nxp.com>; Stephen Boyd
> > > <sboyd@kernel.org>; Michael Turquette <mturquette@baylibre.com>; Ulf
> > > Hansson <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>;
> > > linux-mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> > > <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>; Sascha
> > > Hauer <kernel@pengutronix.de>; moderated list:ARM/FREESCALE IMX /
> > > MXC ARM ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> > > Subject: Re: sdhci timeout on imx8mq
> > >
> > > Hi Lucas,
> > >
> > > On Tue, Jan 5, 2021 at 12:06 PM Lucas Stach <l.stach@pengutronix.de>
> > > wrote:
> > >
> > > > The reference manual states about this situation: "For any clock,
> > > > its source must be left on when it is kept on. Behavior is
> > > > undefined if this rule is violated."
> > > > And it seems this is exactly what's happening here: some kind of
> > > > glitch is introduced in the nand_usdhc_bus clock, which prevents
> > > > the SDHCI controller from working, even though the clock branch is
> > > > properly enabled later on. On my system the SDHCI timeout and
> > > > following runtime suspend/resume cycle on the nand_usdhc_bus clock
> > > > seem to get it back into a working state.
> > >
> > > I think your analysis is correct and I recall helping a customer
> > > with a similar
> > > issue:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fco
> > > mm
> > > unity.nxp.com%2Ft5%2Fi-MX-Processors%2FExternal-clock-that-provide-
> > > root
> > >
> -clock-for-SAI3-and-SPDIF%2Fm-p%2F1019834&amp;data=04%7C01%7Cping
> > > .bai%40nxp.com%7C8d250a158cce469c378308d8b274d6d1%7C686ea1d
> 3bc
> > >
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C637455562183497049%7CUnknow
> > >
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > >
> WwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VkxuhmhDifzOxxfIgFz9PR5gKC1
> > > SyQhGeSHYysX1Co4%3D&amp;reserved=0
> > >
> >
> > For the customer case, it seem not the same issue. the customer issue
> > is caused by clock source change while parent has no clock output.
> > This is inherit limitation for the CCM clock slice when using the
> > smart interface to change the clock parent.
> >
> > For current mmc timeout issue, I think we can have a try with
> > nand_usdhc_bus clock gated at the beginning of kernel boot, directly
> > modify the nand_usdhc_bus Clock's HW register gate bit in
> > clock-imx8mq.c.
> 
> While this might be an option to fix this specific issue, I would hope we can
> come up with something more generic, as the current clock framework
> behavior allows to violate the system specification constraint that parent
> clocks must not be disabled when any of the children are active. This seems
> like a fundamental issue and might hurt us also with other clocks than this
> specific nand_usdhc_bus clock.

Yes, my proposal is for debug purpose. We will do further debug on our EVK board too.

> 
> Can you tell us if there were other issues found with the PLL1/2 gating patch?
> The fact that, according to Bough, it's reverted in your tree seems to suggest
> this.

It is mainly because that the PLL1/2 derived clocks are shared between Cortex-A domain & Cortex-M domain.
M4 domain may also need some of these clocks enabled even A core domain does not use it. There is no
well-defined HW mechanism like CCM CCGR domain control to manage the PLL divider's gate based on each domain's request.
So I reverted that patch in our internal tree before we find other more solid solution for shared clock management.


BR
Jacky Bai
> 
> Regards,
> Lucas

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: sdhci timeout on imx8mq

[Peng Fan]

Hi Lucas,

> Subject: Re: sdhci timeout on imx8mq
> 
> Hi all,
> 
> Am Mittwoch, dem 08.07.2020 um 01:32 +0000 schrieb BOUGH CHEN:
> > > -----Original Message-----
> > > From: Fabio Estevam [mailto:festevam@gmail.com]
> > > Sent: 2020年7月7日 20:45
> > > To: Angus Ainslie <angus@akkea.ca>
> > > Cc: BOUGH CHEN <haibo.chen@nxp.com>; Ulf Hansson
> > > <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>; linux-
> > > mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> > > <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>; Sascha
> > > Hauer < kernel@pengutronix.de>; moderated list:ARM/FREESCALE IMX /
> > > MXC ARM ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> > > Subject: Re: sdhci timeout on imx8mq
> > >
> > > Hi Angus,
> > >
> > > On Tue, Jun 30, 2020 at 4:39 PM Angus Ainslie <angus@akkea.ca>
> > > wrote:
> > >
> > > > Has there been any progress with this. I'm getting this on about
> > > > 50% of
> > >
> > > Not from my side, sorry.
> > >
> > > Bough,
> > >
> > > Do you know why this problem affects the imx8mq-evk versions that
> > > are populated with the Micron eMMC and not the ones with Sandisk
> > > eMMC?
> >
> > Hi Angus,
> >
> > Can you show me the full fail log? I do not meet this issue on my
> > side, besides, which kind of uboot do you use?
> 
> I was finally able to bisect this issue, which wasn't that much fun due to the
> issue not being reproducible 100%. :/ Turns out that the issue is even more
> interesting than I thought and likely doesn't have anything to do with SDHCI or
> used bootloader versions. Here's my current debugging state:
> 
> I've bisected the issue down to b04383b6a558 (clk: imx8mq: Define gates for
> pll1/2 fixed dividers). The change itself looks fine to me, still CC'ed Leonard for
> good measure.
> 
> In my testing the following partial revert fixes the issue:
> 
> --- a/drivers/clk/imx/clk-imx8mq.c
> +++ b/drivers/clk/imx/clk-imx8mq.c
> @@ -365,7 +365,7 @@ static int imx8mq_clocks_probe(struct
> platform_device *pdev)
>         hws[IMX8MQ_SYS1_PLL_133M_CG] =
> imx_clk_hw_gate("sys1_pll_133m_cg", "sys1_pll_out", base + 0x30, 15);
>         hws[IMX8MQ_SYS1_PLL_160M_CG] =
> imx_clk_hw_gate("sys1_pll_160m_cg", "sys1_pll_out", base + 0x30, 17);
>         hws[IMX8MQ_SYS1_PLL_200M_CG] =
> imx_clk_hw_gate("sys1_pll_200m_cg", "sys1_pll_out", base + 0x30, 19);
> -       hws[IMX8MQ_SYS1_PLL_266M_CG] =
> imx_clk_hw_gate("sys1_pll_266m_cg", "sys1_pll_out", base + 0x30, 21);
>         hws[IMX8MQ_SYS1_PLL_400M_CG] =
> imx_clk_hw_gate("sys1_pll_400m_cg", "sys1_pll_out", base + 0x30, 23);
>         hws[IMX8MQ_SYS1_PLL_800M_CG] =
> imx_clk_hw_gate("sys1_pll_800m_cg", "sys1_pll_out", base + 0x30, 25);
> 
> @@ -375,7 +375,7 @@ static int imx8mq_clocks_probe(struct
> platform_device *pdev)
>         hws[IMX8MQ_SYS1_PLL_133M] =
> imx_clk_hw_fixed_factor("sys1_pll_133m", "sys1_pll_133m_cg", 1, 6);
>         hws[IMX8MQ_SYS1_PLL_160M] =
> imx_clk_hw_fixed_factor("sys1_pll_160m", "sys1_pll_160m_cg", 1, 5);
>         hws[IMX8MQ_SYS1_PLL_200M] =
> imx_clk_hw_fixed_factor("sys1_pll_200m", "sys1_pll_200m_cg", 1, 4);
> -       hws[IMX8MQ_SYS1_PLL_266M] =
> imx_clk_hw_fixed_factor("sys1_pll_266m", "sys1_pll_266m_cg", 1, 3);
> +       hws[IMX8MQ_SYS1_PLL_266M] =
> + imx_clk_hw_fixed_factor("sys1_pll_266m", "sys1_pll_out", 1, 3);
>         hws[IMX8MQ_SYS1_PLL_400M] =
> imx_clk_hw_fixed_factor("sys1_pll_400m", "sys1_pll_400m_cg", 1, 2);
>         hws[IMX8MQ_SYS1_PLL_800M] =
> imx_clk_hw_fixed_factor("sys1_pll_800m", "sys1_pll_800m_cg", 1, 1);
> 
> The sys1_pll_266m is the parent of nand_usdhc_bus. I've validated that the
> SDHCI driver properly enables this bus clock across the problematic card
> access. So what I think is happening here is that both nand_usdhc_bus and
> sys1_pll_266m are initially enabled. Sometime during boot sys1_pll_266m
> gets disabled due to runtime PM on the enet_axi clock, which is a direct child
> of sys1_pll_266m. At this point nand_usdhc_bus is still enabled, but no
> consumer has claimed the clock yet, so the parent clock gets disabled while
> this branch of the clock tree is still active.
> 
> The reference manual states about this situation: "For any clock, its source
> must be left on when it is kept on. Behavior is undefined if this rule is
> violated."

I think you are referring
Clock source control,
For PLLs, we have channel on every PLL, every PFD and every divider. PLL is the
source of PFDs and dividers. For any clock, its source must be left on when it is kept on.
Behavior is undefined if this rule is violated.

I think this is not saying clock root slice.

Regards,
Peng.

> And it seems this is exactly what's happening here: some kind of glitch is
> introduced in the nand_usdhc_bus clock, which prevents the SDHCI controller
> from working, even though the clock branch is properly enabled later on. On
> my system the SDHCI timeout and following runtime suspend/resume cycle
> on the nand_usdhc_bus clock seem to get it back into a working state.
> 
> So I think we need some solution at the clock driver/framework level to
> prevent shutting down parent clocks that have active branches, even if those
> branches aren't claimed by a consumer (yet).
> 
> Regards,
> Lucas

RE: sdhci timeout on imx8mq

[Peng Fan]

Hi Lucas,

> Subject: Re: sdhci timeout on imx8mq
> 
> Hi all,
> 
> Am Mittwoch, dem 08.07.2020 um 01:32 +0000 schrieb BOUGH CHEN:
> > > -----Original Message-----
> > > From: Fabio Estevam [mailto:festevam@gmail.com]
> > > Sent: 2020年7月7日 20:45
> > > To: Angus Ainslie <angus@akkea.ca>
> > > Cc: BOUGH CHEN <haibo.chen@nxp.com>; Ulf Hansson
> > > <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>; linux-
> > > mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> > > <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>; Sascha
> > > Hauer < kernel@pengutronix.de>; moderated list:ARM/FREESCALE IMX /
> > > MXC ARM ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> > > Subject: Re: sdhci timeout on imx8mq
> > >
> > > Hi Angus,
> > >
> > > On Tue, Jun 30, 2020 at 4:39 PM Angus Ainslie <angus@akkea.ca>
> > > wrote:
> > >
> > > > Has there been any progress with this. I'm getting this on about
> > > > 50% of
> > >
> > > Not from my side, sorry.
> > >
> > > Bough,
> > >
> > > Do you know why this problem affects the imx8mq-evk versions that
> > > are populated with the Micron eMMC and not the ones with Sandisk
> > > eMMC?
> >
> > Hi Angus,
> >
> > Can you show me the full fail log? I do not meet this issue on my
> > side, besides, which kind of uboot do you use?
> 
> I was finally able to bisect this issue, which wasn't that much fun due to the
> issue not being reproducible 100%. :/ Turns out that the issue is even more
> interesting than I thought and likely doesn't have anything to do with SDHCI or
> used bootloader versions. Here's my current debugging state:
> 
> I've bisected the issue down to b04383b6a558 (clk: imx8mq: Define gates for
> pll1/2 fixed dividers). The change itself looks fine to me, still CC'ed Leonard for
> good measure.
> 
> In my testing the following partial revert fixes the issue:
> 
> --- a/drivers/clk/imx/clk-imx8mq.c
> +++ b/drivers/clk/imx/clk-imx8mq.c
> @@ -365,7 +365,7 @@ static int imx8mq_clocks_probe(struct
> platform_device *pdev)
>         hws[IMX8MQ_SYS1_PLL_133M_CG] =
> imx_clk_hw_gate("sys1_pll_133m_cg", "sys1_pll_out", base + 0x30, 15);
>         hws[IMX8MQ_SYS1_PLL_160M_CG] =
> imx_clk_hw_gate("sys1_pll_160m_cg", "sys1_pll_out", base + 0x30, 17);
>         hws[IMX8MQ_SYS1_PLL_200M_CG] =
> imx_clk_hw_gate("sys1_pll_200m_cg", "sys1_pll_out", base + 0x30, 19);
> -       hws[IMX8MQ_SYS1_PLL_266M_CG] =
> imx_clk_hw_gate("sys1_pll_266m_cg", "sys1_pll_out", base + 0x30, 21);
>         hws[IMX8MQ_SYS1_PLL_400M_CG] =
> imx_clk_hw_gate("sys1_pll_400m_cg", "sys1_pll_out", base + 0x30, 23);
>         hws[IMX8MQ_SYS1_PLL_800M_CG] =
> imx_clk_hw_gate("sys1_pll_800m_cg", "sys1_pll_out", base + 0x30, 25);
> 
> @@ -375,7 +375,7 @@ static int imx8mq_clocks_probe(struct
> platform_device *pdev)
>         hws[IMX8MQ_SYS1_PLL_133M] =
> imx_clk_hw_fixed_factor("sys1_pll_133m", "sys1_pll_133m_cg", 1, 6);
>         hws[IMX8MQ_SYS1_PLL_160M] =
> imx_clk_hw_fixed_factor("sys1_pll_160m", "sys1_pll_160m_cg", 1, 5);
>         hws[IMX8MQ_SYS1_PLL_200M] =
> imx_clk_hw_fixed_factor("sys1_pll_200m", "sys1_pll_200m_cg", 1, 4);
> -       hws[IMX8MQ_SYS1_PLL_266M] =
> imx_clk_hw_fixed_factor("sys1_pll_266m", "sys1_pll_266m_cg", 1, 3);
> +       hws[IMX8MQ_SYS1_PLL_266M] =
> + imx_clk_hw_fixed_factor("sys1_pll_266m", "sys1_pll_out", 1, 3);
>         hws[IMX8MQ_SYS1_PLL_400M] =
> imx_clk_hw_fixed_factor("sys1_pll_400m", "sys1_pll_400m_cg", 1, 2);
>         hws[IMX8MQ_SYS1_PLL_800M] =
> imx_clk_hw_fixed_factor("sys1_pll_800m", "sys1_pll_800m_cg", 1, 1);
> 
> The sys1_pll_266m is the parent of nand_usdhc_bus. I've validated that the
> SDHCI driver properly enables this bus clock across the problematic card
> access. So what I think is happening here is that both nand_usdhc_bus and
> sys1_pll_266m are initially enabled. Sometime during boot sys1_pll_266m
> gets disabled due to runtime PM on the enet_axi clock, which is a direct child
> of sys1_pll_266m. At this point nand_usdhc_bus is still enabled, but no
> consumer has claimed the clock yet, so the parent clock gets disabled while
> this branch of the clock tree is still active.
> 
> The reference manual states about this situation: "For any clock, its source
> must be left on when it is kept on. Behavior is undefined if this rule is
> violated."

I think you are referring
Clock source control,
For PLLs, we have channel on every PLL, every PFD and every divider. PLL is the
source of PFDs and dividers. For any clock, its source must be left on when it is kept on.
Behavior is undefined if this rule is violated.

I think this is not saying clock root slice.

Regards,
Peng.

> And it seems this is exactly what's happening here: some kind of glitch is
> introduced in the nand_usdhc_bus clock, which prevents the SDHCI controller
> from working, even though the clock branch is properly enabled later on. On
> my system the SDHCI timeout and following runtime suspend/resume cycle
> on the nand_usdhc_bus clock seem to get it back into a working state.
> 
> So I think we need some solution at the clock driver/framework level to
> prevent shutting down parent clocks that have active branches, even if those
> branches aren't claimed by a consumer (yet).
> 
> Regards,
> Lucas

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: sdhci timeout on imx8mq

[Heiko Thiery]

Hi all,

> Hi Jacky,
> 
> Am Donnerstag, dem 07.01.2021 um 01:30 +0000 schrieb Jacky Bai:
> > > -----Original Message-----
> > > From: Fabio Estevam [mailto:festevam@gmail.com]
> > > Sent: Thursday, January 7, 2021 2:57 AM
> > > To: Lucas Stach <l.stach@pengutronix.de>
> > > Cc: Bough Chen <haibo.chen@nxp.com>; Angus Ainslie
> > > <angus@akkea.ca>;
> > > Leonard Crestez <leonard.crestez@nxp.com>; Peng Fan
> > > <peng.fan@nxp.com>; Abel Vesa <abel.vesa@nxp.com>; Stephen Boyd
> > > <sboyd@kernel.org>; Michael Turquette <mturquette@baylibre.com>;
> > > Ulf
> > > Hansson <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>;
> > > linux-mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> > > <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>; Sascha
> > > Hauer <kernel@pengutronix.de>; moderated list:ARM/FREESCALE IMX /
> > > MXC
> > > ARM ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> > > Subject: Re: sdhci timeout on imx8mq
> > > 
> > > Hi Lucas,
> > > 
> > > On Tue, Jan 5, 2021 at 12:06 PM Lucas Stach
> > > <l.stach@pengutronix.de>
> > > wrote:
> > > 
> > > > The reference manual states about this situation: "For any clock,
> > > > its
> > > > source must be left on when it is kept on. Behavior is undefined
> > > > if
> > > > this rule is violated."
> > > > And it seems this is exactly what's happening here: some kind of
> > > > glitch is introduced in the nand_usdhc_bus clock, which prevents
> > > > the
> > > > SDHCI controller from working, even though the clock branch is
> > > > properly enabled later on. On my system the SDHCI timeout and
> > > > following runtime suspend/resume cycle on the nand_usdhc_bus
> > > > clock
> > > > seem to get it back into a working state.
> > > 
> > > I think your analysis is correct and I recall helping a customer
> > > with a similar
> > > issue:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcomm
> > > unity.nxp.com%2Ft5%2Fi-MX-Processors%2FExternal-clock-that-provide-
> > > root
> > > -clock-for-SAI3-and-SPDIF%2Fm-p%2F1019834&amp;data=04%7C01%7Cping
> > > .bai%40nxp.com%7C8d250a158cce469c378308d8b274d6d1%7C686ea1d3bc
> > > 2b4c6fa92cd99c5c301635%7C0%7C0%7C637455562183497049%7CUnknow
> > > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > > WwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VkxuhmhDifzOxxfIgFz9PR5gKC1
> > > SyQhGeSHYysX1Co4%3D&amp;reserved=0
> > > 
> > 
> > For the customer case, it seem not the same issue. the customer issue
> > is caused by clock source change while parent has no clock output.
> > This is inherit limitation for the CCM clock slice when using the
> > smart interface to change the clock parent.
> > 
> > For current mmc timeout issue, I think we can have a try with
> > nand_usdhc_bus clock gated at the beginning of kernel boot, directly
> > modify the nand_usdhc_bus
> > Clock's HW register gate bit in clock-imx8mq.c.
> 
> While this might be an option to fix this specific issue, I would hope
> we can come up with something more generic, as the current clock
> framework behavior allows to violate the system specification
> constraint that parent clocks must not be disabled when any of the
> children are active. This seems like a fundamental issue and might hurt
> us also with other clocks than this specific nand_usdhc_bus clock.

I am not sure if an error in the fec driver has the same or similar cause as this. But I noticed that the SOC hangs when accessing the timecounter register while the FEC is down. The CCGR10 seems to gate the ENET_REF_CLK_ROOT and the ENET_TIMER_CLK_ROOT. The clocks are disabled as soon as the interface is down.

[1] https://lore.kernel.org/lkml/20210220065654.25598-1-heiko.thiery@gmail.com/

> 
> Can you tell us if there were other issues found with the PLL1/2 gating
> patch? The fact that, according to Bough, it's reverted in your tree
> seems to suggest this.
> 
> Regards,
> Lucas

Thank you

-- 
Heiko

Re: sdhci timeout on imx8mq

[Heiko Thiery]

Hi all,

> Hi Jacky,
> 
> Am Donnerstag, dem 07.01.2021 um 01:30 +0000 schrieb Jacky Bai:
> > > -----Original Message-----
> > > From: Fabio Estevam [mailto:festevam@gmail.com]
> > > Sent: Thursday, January 7, 2021 2:57 AM
> > > To: Lucas Stach <l.stach@pengutronix.de>
> > > Cc: Bough Chen <haibo.chen@nxp.com>; Angus Ainslie
> > > <angus@akkea.ca>;
> > > Leonard Crestez <leonard.crestez@nxp.com>; Peng Fan
> > > <peng.fan@nxp.com>; Abel Vesa <abel.vesa@nxp.com>; Stephen Boyd
> > > <sboyd@kernel.org>; Michael Turquette <mturquette@baylibre.com>;
> > > Ulf
> > > Hansson <ulf.hansson@linaro.org>; Guido Günther <agx@sigxcpu.org>;
> > > linux-mmc <linux-mmc@vger.kernel.org>; Adrian Hunter
> > > <adrian.hunter@intel.com>; dl-linux-imx <linux-imx@nxp.com>; Sascha
> > > Hauer <kernel@pengutronix.de>; moderated list:ARM/FREESCALE IMX /
> > > MXC
> > > ARM ARCHITECTURE <linux-arm-kernel@lists.infradead.org>
> > > Subject: Re: sdhci timeout on imx8mq
> > > 
> > > Hi Lucas,
> > > 
> > > On Tue, Jan 5, 2021 at 12:06 PM Lucas Stach
> > > <l.stach@pengutronix.de>
> > > wrote:
> > > 
> > > > The reference manual states about this situation: "For any clock,
> > > > its
> > > > source must be left on when it is kept on. Behavior is undefined
> > > > if
> > > > this rule is violated."
> > > > And it seems this is exactly what's happening here: some kind of
> > > > glitch is introduced in the nand_usdhc_bus clock, which prevents
> > > > the
> > > > SDHCI controller from working, even though the clock branch is
> > > > properly enabled later on. On my system the SDHCI timeout and
> > > > following runtime suspend/resume cycle on the nand_usdhc_bus
> > > > clock
> > > > seem to get it back into a working state.
> > > 
> > > I think your analysis is correct and I recall helping a customer
> > > with a similar
> > > issue:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcomm
> > > unity.nxp.com%2Ft5%2Fi-MX-Processors%2FExternal-clock-that-provide-
> > > root
> > > -clock-for-SAI3-and-SPDIF%2Fm-p%2F1019834&amp;data=04%7C01%7Cping
> > > .bai%40nxp.com%7C8d250a158cce469c378308d8b274d6d1%7C686ea1d3bc
> > > 2b4c6fa92cd99c5c301635%7C0%7C0%7C637455562183497049%7CUnknow
> > > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > > WwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VkxuhmhDifzOxxfIgFz9PR5gKC1
> > > SyQhGeSHYysX1Co4%3D&amp;reserved=0
> > > 
> > 
> > For the customer case, it seem not the same issue. the customer issue
> > is caused by clock source change while parent has no clock output.
> > This is inherit limitation for the CCM clock slice when using the
> > smart interface to change the clock parent.
> > 
> > For current mmc timeout issue, I think we can have a try with
> > nand_usdhc_bus clock gated at the beginning of kernel boot, directly
> > modify the nand_usdhc_bus
> > Clock's HW register gate bit in clock-imx8mq.c.
> 
> While this might be an option to fix this specific issue, I would hope
> we can come up with something more generic, as the current clock
> framework behavior allows to violate the system specification
> constraint that parent clocks must not be disabled when any of the
> children are active. This seems like a fundamental issue and might hurt
> us also with other clocks than this specific nand_usdhc_bus clock.

I am not sure if an error in the fec driver has the same or similar cause as this. But I noticed that the SOC hangs when accessing the timecounter register while the FEC is down. The CCGR10 seems to gate the ENET_REF_CLK_ROOT and the ENET_TIMER_CLK_ROOT. The clocks are disabled as soon as the interface is down.

[1] https://lore.kernel.org/lkml/20210220065654.25598-1-heiko.thiery@gmail.com/

> 
> Can you tell us if there were other issues found with the PLL1/2 gating
> patch? The fact that, according to Bough, it's reverted in your tree
> seems to suggest this.
> 
> Regards,
> Lucas

Thank you

-- 
Heiko

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel