public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.



  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