From: Heiko Stuebner <heiko@sntech.de>
To: ulf.hansson@linaro.org, Adrian Hunter <adrian.hunter@intel.com>
Cc: serghox@gmail.com, linux-mmc@vger.kernel.org,
linux-kernel@vger.kernel.org, quentin.schulz@cherry.de,
Heiko Stuebner <heiko.stuebner@cherry.de>
Subject: Re: [PATCH] mmc: sdhci-of-dwcmshc: don't enable CQE without a suitable irq handler
Date: Mon, 03 Jun 2024 14:40:13 +0200 [thread overview]
Message-ID: <6504160.iIbC2pHGDl@phil> (raw)
In-Reply-To: <24c34023-e6c1-471a-ad0e-ee229cba8b3c@intel.com>
Am Montag, 3. Juni 2024, 13:49:34 CEST schrieb Adrian Hunter:
> On 3/06/24 14:26, Heiko Stübner wrote:
> > Am Montag, 3. Juni 2024, 10:01:23 CEST schrieb Adrian Hunter:
> >> On 31/05/24 00:55, Heiko Stuebner wrote:
> >>> From: Heiko Stuebner <heiko.stuebner@cherry.de>
> >>>
> >>> supports-cqe is an established dt property so can appear in devicetrees
> >>> at any time. CQE support in the sdhci-of-dwcmshc driver does require a
> >>> special irq handler in the platform-specific ops, to handle the CQE
> >>> interrupt.
> >>>
> >>> Without this special handler we end up with a spew of unhandled interrupt
> >>> messages on devices with supports-cqe property but without irq handler:
> >>>
> >>> [ 11.624143] mmc0: Unexpected interrupt 0x00004000.
> >>> [ 11.629504] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> >>> [ 11.636711] mmc0: sdhci: Sys addr: 0x00000008 | Version: 0x00000005
> >>> [ 11.643919] mmc0: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000000
> >>> [ 11.651128] mmc0: sdhci: Argument: 0x00018000 | Trn mode: 0x00000033
> >>> [ 11.658336] mmc0: sdhci: Present: 0x13f700f0 | Host ctl: 0x00000034
> >>> [ 11.665545] mmc0: sdhci: Power: 0x00000001 | Blk gap: 0x00000000
> >>> [ 11.672753] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x00000407
> >>> [ 11.679961] mmc0: sdhci: Timeout: 0x0000000e | Int stat: 0x00004000
> >>> [ 11.687169] mmc0: sdhci: Int enab: 0x02ff4000 | Sig enab: 0x02ff4000
> >>> [ 11.694378] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
> >>> [ 11.701586] mmc0: sdhci: Caps: 0x226dc881 | Caps_1: 0x08000007
> >>> [ 11.708794] mmc0: sdhci: Cmd: 0x00000d1e | Max curr: 0x00000000
> >>> [ 11.716003] mmc0: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0x00000000
> >>> [ 11.723211] mmc0: sdhci: Resp[2]: 0x328f5903 | Resp[3]: 0x000007cd
> >>> [ 11.730419] mmc0: sdhci: Host ctl2: 0x0000000f
> >>> [ 11.735392] mmc0: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0xee28f008
> >>> [ 11.742600] mmc0: sdhci: ============================================
> >>>
> >>> So don't enable CQE if a usable interrupt handler is not defined and warn
> >>> instead about this fact.
> >>>
> >>> Fixes: 53ab7f7fe412 ("mmc: sdhci-of-dwcmshc: Implement SDHCI CQE support")
> >>> Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
> >>> ---
> >>> My rk3588-tiger and rk3588-jaguar devicetrees had an accidential
> >>> supports-cqe in their devicetree, which made me run into this problem
> >>> with 6.10-rc1 .
> >>>
> >>> drivers/mmc/host/sdhci-of-dwcmshc.c | 10 +++++++---
> >>> 1 file changed, 7 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/mmc/host/sdhci-of-dwcmshc.c b/drivers/mmc/host/sdhci-of-dwcmshc.c
> >>> index 39edf04fedcf7..4410d4523728d 100644
> >>> --- a/drivers/mmc/host/sdhci-of-dwcmshc.c
> >>> +++ b/drivers/mmc/host/sdhci-of-dwcmshc.c
> >>> @@ -1254,10 +1254,14 @@ static int dwcmshc_probe(struct platform_device *pdev)
> >>>
> >>> /* Setup Command Queue Engine if enabled */
> >>> if (device_property_read_bool(&pdev->dev, "supports-cqe")) {
> >>> - priv->vendor_specific_area2 =
> >>> - sdhci_readw(host, DWCMSHC_P_VENDOR_AREA2);
> >>> + if (pltfm_data && pltfm_data->ops && pltfm_data->ops->irq) {
> >>
> >> ->irq() could be used for other things, so checking it for CQE
> >> support is not appropriate.
> >
> > though here we are in the very limited scope of only the dwcmshc sdhci
> > controller.
>
> I am afraid that does not justify it. It can still create
> problems in the future if that very limited scope changes
> i.e. someone wants to use the ->irq() callback in
> sdhci-of-dwcmshc.c for something else.
>
> >
> > And at this point, any controller using the generic sdhci_dwcmshc_ops
> > will always get the CQE irq handler, while _all other_ controllers
> > will need to define one to handle the CQE irqs.
> >
> > So any variant trying to enable CQE needs to define an irq handler, hence
> > the check simply was meant to not allow CQE enablement without any irq
> > handler, because that will always cause those unhandled irq issues.
> >
> >> If necessary, it would be better to flag which variants support
> >> CQE in their platform data.
> >
> > I guess we can assume that all of the dwcmshc IP variants support
> > CQE, it's just that the implementation is slightly strange in that
> > a DT can enable CQE support and this will cause the driver to enable the
> > CQE interrupt, even if nothing is there to handle it.
>
> Isn't the problem that the IP may support CQE but the driver does
> not for the given variant, but switches it on anyway.
exactly ... that is the problem I have with that accidential "supports-cqe"
in that devicetree.
The sdhci-of-dwmshc has already some
if (pltfm_data == &sdhci_dwcmshc_rk35xx_pdata)
conditionals in its probe function for variant-specific init, so I guess
we could also just move the CQE init into those?
bool supports_cqe = false;
if (pltfm_data == &sdhci_dwcmshc_pdata)
supports_cqe = true;
if (pltfm_data == &sdhci_dwcmshc_rk35xx_pdata)
{
....
supports_cqe = true;
}
Because in the end I would guess once every variant has check it's CQE
support, we'll have all of them supporting it anyway, so that can
handling could than get removed again.
next prev parent reply other threads:[~2024-06-03 12:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-30 21:55 [PATCH] mmc: sdhci-of-dwcmshc: don't enable CQE without a suitable irq handler Heiko Stuebner
2024-06-03 8:01 ` Adrian Hunter
2024-06-03 11:26 ` Heiko Stübner
2024-06-03 11:49 ` Adrian Hunter
2024-06-03 12:40 ` Heiko Stuebner [this message]
2024-06-14 11:30 ` Adrian Hunter
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=6504160.iIbC2pHGDl@phil \
--to=heiko@sntech.de \
--cc=adrian.hunter@intel.com \
--cc=heiko.stuebner@cherry.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=quentin.schulz@cherry.de \
--cc=serghox@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox