From: Kevin Groeneveld <kgroeneveld@lenbrook.com>
To: haibo.chen@nxp.com, adrian.hunter@intel.com,
ulf.hansson@linaro.org, shawnguo@kernel.org, robh+dt@kernel.org,
s.hauer@pengutronix.de
Cc: kernel@pengutronix.de, festevam@gmail.com,
linux-mmc@vger.kernel.org, linux-imx@nxp.com,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 4/6] mmc: host: sdhci-esdhc-imx.c: disable auto-tuning when necessary
Date: Mon, 5 Dec 2022 09:59:30 -0500 [thread overview]
Message-ID: <a429ea6c-f2d9-ddc8-15b8-23309b3a5051@lenbrook.com> (raw)
In-Reply-To: <1629285415-7495-4-git-send-email-haibo.chen@nxp.com>
Thank you Haibo for pointing me here from
https://www.spinics.net/lists/linux-mmc/msg73270.html.
On 2021-08-18 07:16, haibo.chen@nxp.com wrote:
> Add a method to enable/disable auto-tuning function. auto-tuning function
> is conflict with sdio interrupt. For sdio device with sdio interrupt,
> need to disable auto-tuning function.
I tested this patch on an imx8mm system and it made things completely
unstable. I was never really able to log into the system properly and
just got lots of messages similar to the following:
[ 31.946640] rcu: INFO: rcu_preempt self-detected stall on CPU
[ 31.952422] rcu: 0-....: (2106 ticks this GP)
idle=849/1/0x4000000000000000 softirq=902/904 fqs=743
[ 31.961663] (t=2100 jiffies g=33 q=1158)
[ 31.965682] Task dump for CPU 0:
[ 31.968915] task:kworker/0:1 state:R running task stack:
0 pid: 33 ppid: 2 flags:0x0000000a
[ 31.978859] Workqueue: 0x0 (pm)
While working on this I also came across
https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/uSDHC-auto-tuning-and-possible-SDIO-failures/ta-p/1352855
which seems to address the same issue as your proposed patch.
That article suggests only enabling auto tuning for one data line as a
workaround. I tried this method and so far it seems to have addressed
the -84 errors I was seeing with SDIO communication to a WiFi module.
Some thoughts / questions:
Why does this proposed patch make my system unstable? (I was testing
with a v5.16 mainline based kernel, but I did not see anything in later
versions of sdhci-esdhc-imx that seemed like this should be a problem.)
Why does this patch try to disable auto tune entirely vs just setting it
up for one data bit as suggested in the NXP knowledge base article?
As some other have suggested it seems like it would be nicer if the
workaround could be applied automatically if the device using the SDIO
interface enabled IRQs. Having to include a non standard entry in the DT
for a hardware bug you may not know about or understand seems error
prone. I guess maybe some device could generate an IRQ before they
actually enable IRQs? In that case maybe a DT entry is required, but
maybe the driver could generate a warning if IRQs are enabled without
the DT entry?
Thanks,
Kevin
WARNING: multiple messages have this Message-ID (diff)
From: Kevin Groeneveld <kgroeneveld@lenbrook.com>
To: haibo.chen@nxp.com, adrian.hunter@intel.com,
ulf.hansson@linaro.org, shawnguo@kernel.org, robh+dt@kernel.org,
s.hauer@pengutronix.de
Cc: kernel@pengutronix.de, festevam@gmail.com,
linux-mmc@vger.kernel.org, linux-imx@nxp.com,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 4/6] mmc: host: sdhci-esdhc-imx.c: disable auto-tuning when necessary
Date: Mon, 5 Dec 2022 09:59:30 -0500 [thread overview]
Message-ID: <a429ea6c-f2d9-ddc8-15b8-23309b3a5051@lenbrook.com> (raw)
In-Reply-To: <1629285415-7495-4-git-send-email-haibo.chen@nxp.com>
Thank you Haibo for pointing me here from
https://www.spinics.net/lists/linux-mmc/msg73270.html.
On 2021-08-18 07:16, haibo.chen@nxp.com wrote:
> Add a method to enable/disable auto-tuning function. auto-tuning function
> is conflict with sdio interrupt. For sdio device with sdio interrupt,
> need to disable auto-tuning function.
I tested this patch on an imx8mm system and it made things completely
unstable. I was never really able to log into the system properly and
just got lots of messages similar to the following:
[ 31.946640] rcu: INFO: rcu_preempt self-detected stall on CPU
[ 31.952422] rcu: 0-....: (2106 ticks this GP)
idle=849/1/0x4000000000000000 softirq=902/904 fqs=743
[ 31.961663] (t=2100 jiffies g=33 q=1158)
[ 31.965682] Task dump for CPU 0:
[ 31.968915] task:kworker/0:1 state:R running task stack:
0 pid: 33 ppid: 2 flags:0x0000000a
[ 31.978859] Workqueue: 0x0 (pm)
While working on this I also came across
https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/uSDHC-auto-tuning-and-possible-SDIO-failures/ta-p/1352855
which seems to address the same issue as your proposed patch.
That article suggests only enabling auto tuning for one data line as a
workaround. I tried this method and so far it seems to have addressed
the -84 errors I was seeing with SDIO communication to a WiFi module.
Some thoughts / questions:
Why does this proposed patch make my system unstable? (I was testing
with a v5.16 mainline based kernel, but I did not see anything in later
versions of sdhci-esdhc-imx that seemed like this should be a problem.)
Why does this patch try to disable auto tune entirely vs just setting it
up for one data bit as suggested in the NXP knowledge base article?
As some other have suggested it seems like it would be nicer if the
workaround could be applied automatically if the device using the SDIO
interface enabled IRQs. Having to include a non standard entry in the DT
for a hardware bug you may not know about or understand seems error
prone. I guess maybe some device could generate an IRQ before they
actually enable IRQs? In that case maybe a DT entry is required, but
maybe the driver could generate a warning if IRQs are enabled without
the DT entry?
Thanks,
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-12-05 15:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-18 11:16 [PATCH v2 1/6] mmc: sdhci-esdhc-imx: remove redundant code for manual tuning haibo.chen
2021-08-18 11:16 ` haibo.chen
2021-08-18 11:16 ` [PATCH v2 2/6] mmc: sdhci-eadhc-imx: select the correct mode for auto tuning haibo.chen
2021-08-18 11:16 ` haibo.chen
2021-08-18 11:16 ` [PATCH v2 3/6] dt-bindings: mmc: fsl-imx-esdhc: add fsl,broken-auto-tuning binding haibo.chen
2021-08-18 11:16 ` [PATCH v2 3/6] dt-bindings: mmc: fsl-imx-esdhc: add fsl, broken-auto-tuning binding haibo.chen
2021-08-18 18:48 ` [PATCH v2 3/6] dt-bindings: mmc: fsl-imx-esdhc: add fsl,broken-auto-tuning binding Rob Herring
2021-08-18 18:48 ` Rob Herring
2021-08-19 14:11 ` [PATCH v2 3/6] dt-bindings: mmc: fsl-imx-esdhc: add fsl, broken-auto-tuning binding Lucas Stach
2021-08-19 14:11 ` Lucas Stach
2021-08-18 11:16 ` [PATCH v2 4/6] mmc: host: sdhci-esdhc-imx.c: disable auto-tuning when necessary haibo.chen
2021-08-18 11:16 ` haibo.chen
2022-12-05 14:59 ` Kevin Groeneveld [this message]
2022-12-05 14:59 ` Kevin Groeneveld
2022-12-09 8:43 ` Bough Chen
2022-12-09 8:43 ` Bough Chen
2021-08-18 11:16 ` [PATCH v2 5/6] arm64: dts: imx8mm-evk: add sdio wifi support haibo.chen
2021-08-18 11:16 ` haibo.chen
2021-08-18 11:16 ` [PATCH v2 6/6] arm64: dts: imx8mn-evk: " haibo.chen
2021-08-18 11:16 ` haibo.chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a429ea6c-f2d9-ddc8-15b8-23309b3a5051@lenbrook.com \
--to=kgroeneveld@lenbrook.com \
--cc=adrian.hunter@intel.com \
--cc=devicetree@vger.kernel.org \
--cc=festevam@gmail.com \
--cc=haibo.chen@nxp.com \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-mmc@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.