From: Adrian Hunter <adrian.hunter@intel.com>
To: "Heiko Stübner" <heiko@sntech.de>, ulf.hansson@linaro.org
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, 3 Jun 2024 14:49:34 +0300 [thread overview]
Message-ID: <24c34023-e6c1-471a-ad0e-ee229cba8b3c@intel.com> (raw)
In-Reply-To: <4015176.ZaRXLXkqSa@diego>
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.
>
>
> For my own case I can also just live with the Rockchip irq handler
> patch going in (ideally as a fix) and I just wanted to try to fix this
> will definitly fail if irq-handler not present case.
>
>
> Heiko
>
>
>> However that would probably mean introducing something
>> like struct dwcmshc_pltfm_data as described here:
>>
>> https://lore.kernel.org/linux-mmc/ed900af1-f090-49a9-bc7e-363a28a4ac2b@intel.com/
>>
>>
>>> + priv->vendor_specific_area2 =
>>> + sdhci_readw(host, DWCMSHC_P_VENDOR_AREA2);
>>>
>>> - dwcmshc_cqhci_init(host, pdev);
>>> + dwcmshc_cqhci_init(host, pdev);
>>> + } else {
>>> + dev_warn(&pdev->dev, "can't enable cqe support without irq handler\n");
>>> + }
>>> }
>>>
>>> if (rk_priv)
>>
>>
>
>
>
>
next prev parent reply other threads:[~2024-06-03 11:49 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 [this message]
2024-06-03 12:40 ` Heiko Stuebner
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=24c34023-e6c1-471a-ad0e-ee229cba8b3c@intel.com \
--to=adrian.hunter@intel.com \
--cc=heiko.stuebner@cherry.de \
--cc=heiko@sntech.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