Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp4481347ybi; Mon, 15 Jul 2019 09:33:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqzfT2DRZM+oAMBMvHxNiDum0YzTdrIcMrJxP+6/Q6csmW0Oi4biubfSmcbfVUpRxFjWS6Em X-Received: by 2002:a65:5a44:: with SMTP id z4mr27926500pgs.41.1563208407315; Mon, 15 Jul 2019 09:33:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563208407; cv=none; d=google.com; s=arc-20160816; b=abWr6E4iurBxkVbnCrqIRYQnmJxlmM+E253OL6IRwU0czCr5SsZL07tItcHex5YD3J k1Hs3BIjNIAt4LUqgY3EnkQMZpbMe8xVzWJ0JaF++3AVG8NEZN9HZP9BAYI0Er8uKE0N 4QarVmWVDBOust0osFNZci7uxt7QQbTmQ2xloAIZDAXEFksjEjnOwm4wS1VdBBuj7vjm WBU81X62V9yjFe90XZ7MDLR0BGn9IBgKXAiW6QFA6qOqzymgjKPxsD4zJBFOLz7T1YGk vZq7uvSbQEDzo9RHgAjaAZiroSxdzGrglXB+0MvmL9VsGfDZUc2bdhLwTkDDZXGfX18h A7Fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=l9coYjSe3XSNr091GZSS9724rWMOjYgkm8g/YPUGrBk=; b=qCzfrFIxu4wW9n7yF0kANfMNRfBCwqC9HZrBY9a+mms6R+bKjRR7yHHzyvBwkg4fj7 x1m/e7UiKo1Viu6vs4v+x0Ji0R2AAkDhs5UxSlig8FEHvDR9svVf82kVPzFo+lpdFPRW 0KVbsiVz+sjamQ1GtQ1J40YtYZggfUtydHmAMMtleNc636XYCQKeLIB+PNSeS33ias3A dwjc44QvpFIEQSO0svh9A/gDdaUeVeIL+KeEFTI7yBrv9x082QjcBCE1iVC5ZN4lbjLr TSs0oFGkyV/Xf3OSVm5UBHAT/MYd29fUZxzd+QMVvJDqKDCxjKjSLvZhWvygxIKLVgPJ UiFg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=NYNAvMcR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 6si16870975pgb.201.2019.07.15.09.33.10; Mon, 15 Jul 2019 09:33:27 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=NYNAvMcR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731252AbfGOQbx (ORCPT + 99 others); Mon, 15 Jul 2019 12:31:53 -0400 Received: from mail-vs1-f66.google.com ([209.85.217.66]:33193 "EHLO mail-vs1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731069AbfGOQbw (ORCPT ); Mon, 15 Jul 2019 12:31:52 -0400 Received: by mail-vs1-f66.google.com with SMTP id m8so11850388vsj.0 for ; Mon, 15 Jul 2019 09:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l9coYjSe3XSNr091GZSS9724rWMOjYgkm8g/YPUGrBk=; b=NYNAvMcRho+50ikquItIbaA8xyQqZTsW5KuU71/3Q+SoqDVsAy0+FM2d2PDcePt7/n 11RZxGJC6mTRC4h6FGCGzw5ghhxx3RwnG0GjedgAFNGGoDc3a9QiHq+8ObcMmIqDsmmR J3Vsoi/0eyXbw2JYkw6d/qyG0Pcpoe3itkm/WnnZNuH1KiiwADvf3ntPy/+VrYE6PIw6 uIF81NM9pWUyOV4tcN7jlhU8hIQWnXcFmd8zg9BnmqlN0/rWPA8H02F6iWBLylvyWZNz XJSLk/1VCaTu2yjDkpvSOUpRVRh2m0Rv0bmcg2VHCyu5QVYHl7BD6bBxYfh/jlUUzWJe HABQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l9coYjSe3XSNr091GZSS9724rWMOjYgkm8g/YPUGrBk=; b=VcW2VxlUfMWk7ytZg2PH/o5f1jHS9IB4SyGJcvra5/JxmmnSVzztr68l3YHjozpPuV 1vfDjOGIeTCYwO4bBaLuVeANGD/WnZsfn3xjj6O387abwBOyO+Wb0mRgzEG/VBOOIlIT EDSttjIwSAA9TjqzVqZhRVeQtlxpqgwjNuZbWqrixpdZqpiVWF4OHcdj4lOoIH3sTxBc R9KUTXGQ9qHRTEVnmG0cJrFqVoA0MPWOrhmenQ6+tFZnpnSkFlS3ROm/wbMjmSTel9ZZ 2ZlvOMqOZ8l8jeK/xSa2n2TLSUSugqmdvNiwjMP77SOZkftuTOUO10LShqDp1KKlWoJo ZnEQ== X-Gm-Message-State: APjAAAW2zY0sSfBRDVrfKyml3KC6XfeFXsApdIRBEDP7lT6Ye7JcuC7H L+9rDFtd6NMaRq6bNQgC756Z/MedAVdL31orzgK45g== X-Received: by 2002:a67:7a90:: with SMTP id v138mr16907417vsc.200.1563208311475; Mon, 15 Jul 2019 09:31:51 -0700 (PDT) MIME-Version: 1.0 References: <1559577325-19266-1-git-send-email-ludovic.Barre@st.com> <1559577325-19266-2-git-send-email-ludovic.Barre@st.com> In-Reply-To: <1559577325-19266-2-git-send-email-ludovic.Barre@st.com> From: Ulf Hansson Date: Mon, 15 Jul 2019 18:31:15 +0200 Message-ID: Subject: Re: [PATCH V3 1/3] mmc: mmci: fix read status for busy detect To: Ludovic Barre Cc: Rob Herring , Srinivas Kandagatla , Maxime Coquelin , Alexandre Torgue , Linux ARM , Linux Kernel Mailing List , DTML , "linux-mmc@vger.kernel.org" , linux-stm32@st-md-mailman.stormreply.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 3 Jun 2019 at 17:55, Ludovic Barre wrote: > > From: Ludovic Barre > > "busy_detect_flag" is used to read & clear busy value of mmci status. > "busy_detect_mask" is used to manage busy irq of mmci mask. > So to read mmci status the busy_detect_flag must be take account. > if the variant does not support busy detect feature the flag is null > and there is no impact. By reading the changelog, it doesn't tell me the purpose of this change. When going forward, please work harder on your changelogs. Make sure to answer the questions, *why* is this change needed, *what/how* does the change do. > > Not need to re-read the status register in mmci_cmd_irq, the > status parameter can be used. > > Signed-off-by: Ludovic Barre > --- > drivers/mmc/host/mmci.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c > index 356833a..5b5cc45 100644 > --- a/drivers/mmc/host/mmci.c > +++ b/drivers/mmc/host/mmci.c > @@ -1240,7 +1240,7 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd, > */ > if (!host->busy_status && > !(status & (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT)) && > - (readl(base + MMCISTATUS) & host->variant->busy_detect_flag)) { > + (status & host->variant->busy_detect_flag)) { I suggested you to do this change through some of my earlier comments, however I think it should be made as a stand alone change. Anyway, when looking at the details in your series, I decided to try to help out a bit, so I have prepared a couple of related patches for cleaning up and clarifying the busy detection code/comments in mmci. I have incorporated the above change, so let me post them asap. > > /* Clear the busy start IRQ */ > writel(host->variant->busy_detect_mask, > @@ -1517,7 +1517,8 @@ static irqreturn_t mmci_irq(int irq, void *dev_id) > * to make sure that both start and end interrupts are always > * cleared one after the other. > */ > - status &= readl(host->base + MMCIMASK0); > + status &= readl(host->base + MMCIMASK0) | > + host->variant->busy_detect_flag; As I told earlier in the review, this looks wrong to me. It means that you will add the bit for the ->busy_detect_flag to the status field we have just read from the MMCISTATUS register. That means the busy status may be set when it shouldn't. > if (host->variant->busy_detect) > writel(status & ~host->variant->busy_detect_mask, > host->base + MMCICLEAR); > -- > 2.7.4 > By looking at the other changes in the series, I assume @subject patch is intended to prepare for the other changes on top. But it's not really clear. Anyway, in that regards, the below is my observations of what seems to be important part, when supporting busy detection for the stm32 sdmmc variant (except the timeout things in patch2, which I intend to comment separately on). I figured, these are the involved register bits/masks: MMCISTATUS: MCI_STM32_BUSYD0 BIT(20) MCI_STM32_BUSYD0END BIT(21) MMCIMASK0: MCI_STM32_BUSYD0ENDMASK BIT(21) For the legacy ST variant, there is only one register bit in MMCISTATUS that is used for indicating busy (MCI_ST_CARDBUSY BIT(24)). There is no dedicated busy-end bit for the busy-end IRQ, which I believe is the reason to why the current code also is bit messy. It seems like the stm32 sdmmc variant have a separate status bit for the busy-end IRQ, correct? If I understand correctly by looking at patch3, you don't use the dedicated busy-end status bit (MCI_STM32_BUSYD0END), right? Then why not? Thoughts? Kind regards Uffe