Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2412810imu; Wed, 21 Nov 2018 11:13:09 -0800 (PST) X-Google-Smtp-Source: AFSGD/Ujzw9AOcejzCTjyVlyF1eykdFckERfrb2hepp401Cf4CubwZWlRd2/1YJAqhQ6CfFO5zID X-Received: by 2002:a17:902:bc43:: with SMTP id t3mr2416195plz.124.1542827589602; Wed, 21 Nov 2018 11:13:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542827589; cv=none; d=google.com; s=arc-20160816; b=YoH7uTVel1+v6rj5JRjC8o6TWreQ8Iu/1UNvyfQlFCGIUi/a+o3B20N+2yr4nZTN38 0u8YSXjkrmR//BZ6YPRwdpDEfk9LL+JW/uvL9GUMOH7/6PTLBRYVt1vSJChaMJ5Y5ZhS 51ytmqpb42GN+AYvcCZbrL6Z/DOQ2alur45foqps4j1VWyvJSyZDqKd/xl2O9kCeQH1r pBK+HPmQHbUzeQFuBQSuyk3S55I/WR/vJE9LVTw54YCY68K2t8UQDO++aYM4qN96GWt3 6iHeEs+pQe1sz0zgiXqlmdy59mvojWJsKT4/3taP8hu6/MyxHDVBtpq/MKVNf2REbfJZ 8spw== 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 :references:in-reply-to:mime-version:dkim-signature; bh=xVor19JQROKickQvk655i16YO8AaQ8r2h6kHhuVRYlY=; b=J+QvSv9j5rVfNBhR0yFNPXxqdECDkeNQfrCwSf7gLfQ9oX+8kpWdjFdYIG/MD1ceZ1 dHnGPuBv/h0apAFhdgBKrCCzoxX1x4SITso8ikWobj36FA2YNDaDLDNd6HSlnqLiEuJK CFF3I9PFSTabhhLwgZt0+B0FhvxQdA1j/UE8dZJZ8RSWqFmEqB/bVqZ8H7fxPCyQm7nH Pzgp5lRLqxHnHS+HMpdBwQCjyt9ic1zceNwUtdkxGa1/6YGlWaJHlJWvW7YdKF3BfnAP 59hIJdZDLTGDd/c9D4e4dqY3XR7voeaqTeJr69a3vuBhFLnuVFzlbQBrPhqFS78MAKmI btsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=HLKwboHp; 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 b8si47168624pgi.575.2018.11.21.11.12.54; Wed, 21 Nov 2018 11:13:09 -0800 (PST) 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=HLKwboHp; 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 S1732691AbeKVEcQ (ORCPT + 99 others); Wed, 21 Nov 2018 23:32:16 -0500 Received: from mail-it1-f195.google.com ([209.85.166.195]:36835 "EHLO mail-it1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731067AbeKVEcP (ORCPT ); Wed, 21 Nov 2018 23:32:15 -0500 Received: by mail-it1-f195.google.com with SMTP id c9so10162160itj.1 for ; Wed, 21 Nov 2018 09:56:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xVor19JQROKickQvk655i16YO8AaQ8r2h6kHhuVRYlY=; b=HLKwboHpgom3depjlX+vyaOFC4zEgLoa07W5QjPD/go9lNsUspZZ3QwUV97KwkaFn+ RuSQ9+80mGilIPU8r1ChLE4c1Ond/lTSVz2ZxQ1+UqN2RzVi6Zb/hAKES9B1CWzeIzvk HJnXpe81XCvJJ74vVgRefqokM57BRYCUyR6no= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xVor19JQROKickQvk655i16YO8AaQ8r2h6kHhuVRYlY=; b=FO33QgD5d8o5MszQ1QeUZt4IZrv2AXRjfCnYQrB0rXDXDMlyroM4mUWno5kNKIEGgP Jd/qdQHsE9aQsqOId1jLKZAVBEvyQJKTRcLLJmJBlqsbvKa8jYJWfhElRTNXIrDqSExB pqZXgm3T+wuRH/zAE5UCxuPhzVny5a2YtfOWgVlw+1pLHkRtUptv9doVQQg8haYwG9W3 YXH92Ev0eR8DLDaY0e2V1IwxAvNy4PuxYvU1TbOfYNiPeOlLkpd5vXierx5zRrKn4kkT 8BsgzgsHpWjmEmLj/sCPlxABHoU5bKMHIEO49J64qg5aOKTBZC5QSanm1LWFQ58mBq4D C+qg== X-Gm-Message-State: AA+aEWYa6TlI8FNAYoZP9XQJg5b1d9vLVW7a+Q126QvUoK9gRtj7YRqo hchsvw8SYdXCMeFaRK/mLBKdu+ItYUg9HqzyKCSWSdVSBvY= X-Received: by 2002:a24:108a:: with SMTP id 132-v6mr6446123ity.78.1542823012798; Wed, 21 Nov 2018 09:56:52 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a02:70c8:0:0:0:0:0 with HTTP; Wed, 21 Nov 2018 09:56:12 -0800 (PST) In-Reply-To: <1541583041-17461-3-git-send-email-ludovic.Barre@st.com> References: <1541583041-17461-1-git-send-email-ludovic.Barre@st.com> <1541583041-17461-3-git-send-email-ludovic.Barre@st.com> From: Ulf Hansson Date: Wed, 21 Nov 2018 18:56:12 +0100 Message-ID: Subject: Re: [PATCH V2 2/2] mmc: mmci: add variant property to send stop cmd if a command fail 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 7 November 2018 at 10:30, Ludovic Barre wrote: > From: Ludovic Barre > > The mmc framework follows the requirement of SD_Specification: > the STOP_TRANSMISSION is sent on multiple write/read commands > and the stop command (alone), not needed on other ADTC commands. > > But, if an error happens on command or data transmission, some > variants require a stop command "STOP_TRANSMISION" to clear the DPSM > "Data Path State Machine". If it's not done the next data > command freezes hardware block. > Needed to support the STM32 sdmmc variant. May I suggest some re-wording of this changelog, as to make it more clear of why this is needed. Something along the lines of: "The current approach with sending a CMD12 (STOP_TRANSMISSION) to complete a data transfer request, either because of using the open ended transmission type or because of receiving an error during a data transfer, isn't sufficient for the STM32 sdmmc variant. More precisely, for STM32 sdmmc the DPSM ("Data Path State Machine" ) needs to be cleared by sending a CMD12, also for the so called ADTC commands. For this reason, add a new mmci variant property and let the driver send a CMD12 to complete ADTC commands, in case it's set." > > Signed-off-by: Ludovic Barre > --- > drivers/mmc/host/mmci.c | 33 +++++++++++++++++++++++++++++++++ > drivers/mmc/host/mmci.h | 4 ++++ > 2 files changed, 37 insertions(+) > > diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c > index 13fa640..47b865d 100644 > --- a/drivers/mmc/host/mmci.c > +++ b/drivers/mmc/host/mmci.c > @@ -21,6 +21,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -57,6 +58,8 @@ void sdmmc_variant_init(struct mmci_host *host); > #else > static inline void sdmmc_variant_init(struct mmci_host *host) {} > #endif > +static void > +mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c); > > static unsigned int fmax = 515633; > > @@ -274,6 +277,7 @@ static struct variant_data variant_stm32_sdmmc = { > .cmdreg_lrsp_crc = MCI_CPSM_STM32_LRSP_CRC, > .cmdreg_srsp_crc = MCI_CPSM_STM32_SRSP_CRC, > .cmdreg_srsp = MCI_CPSM_STM32_SRSP, > + .cmdreg_stop = MCI_CPSM_STM32_CMDSTOP, > .data_cmd_enable = MCI_CPSM_STM32_CMDTRANS, > .irq_pio_mask = MCI_IRQ_PIO_STM32_MASK, > .datactrl_first = true, > @@ -573,6 +577,24 @@ void mmci_dma_error(struct mmci_host *host) > static void > mmci_request_end(struct mmci_host *host, struct mmc_request *mrq) > { > + /* > + * If an error happens on command or data transmission, some variants > + * require a stop command to reinit the DPSM. > + * If it's not done the next data command freeze hardware block. > + */ > + if (host->variant->cmdreg_stop) { > + u32 dpsm; > + > + dpsm = readl_relaxed(host->base + MMCISTATUS); > + dpsm &= MCI_STM32_DPSMACTIVE; > + > + if (dpsm && ((mrq->cmd && mrq->cmd->error) || > + (mrq->data && mrq->data->error))) { > + mmci_start_command(host, &host->stop_abort, 0); > + return; > + } I would rather move this code to a separate function. Also, I think you need something else (or additional) than polling the MMCISTATUS register, as in principle you could end up sending CMD12 several times for the same request, which isn't correct. To me the best solution would probably be to make use of the host->data pointer, as it becomes set when DPSM has been enabled. However, host->data is also cleared in mmci_stop_data() which is being called prior mmci_request_end(). In other words, we need to figure under what conditions the new code above should be triggered/called and then also change the conditions for when mmci_request_end() shall be called. In principle look at callers of mmci_request_end() and mmci_stop_data() and update those paths. > + } > + > writel(0, host->base + MMCICOMMAND); > > BUG_ON(host->data); > @@ -1100,6 +1122,10 @@ mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c) > mmci_reg_delay(host); > } > > + if (host->variant->cmdreg_stop && > + cmd->opcode == MMC_STOP_TRANSMISSION) > + c |= host->variant->cmdreg_stop; > + Hmm. It looks like the above changes, together with the introduction of the variant property, belongs in a separate patch, preceding $subject patch in the series. The reason is, that to me, it makes sense to add the special treatment of the ADTC commands in a separate patch. Can you please split it up and then of course update the change log accordingly!? > c |= cmd->opcode | host->variant->cmdreg_cpsm_enable; > if (cmd->flags & MMC_RSP_PRESENT) { > if (cmd->flags & MMC_RSP_136) > @@ -1950,6 +1976,13 @@ static int mmci_probe(struct amba_device *dev, > mmc->max_busy_timeout = 0; > } > > + /* prepare the stop command, used to abort and reinitialized the DPSM */ > + if (variant->cmdreg_stop) { > + host->stop_abort.opcode = MMC_STOP_TRANSMISSION; > + host->stop_abort.arg = 0; > + host->stop_abort.flags = MMC_RSP_R1B | MMC_CMD_AC; > + } > + > mmc->ops = &mmci_ops; > > /* We support these PM capabilities. */ > diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h > index 550dd39..35372cd 100644 > --- a/drivers/mmc/host/mmci.h > +++ b/drivers/mmc/host/mmci.h > @@ -161,6 +161,7 @@ > #define MCI_ST_CEATAEND (1 << 23) > #define MCI_ST_CARDBUSY (1 << 24) > /* Extended status bits for the STM32 variants */ > +#define MCI_STM32_DPSMACTIVE BIT(12) > #define MCI_STM32_BUSYD0 BIT(20) > > #define MMCICLEAR 0x038 > @@ -264,6 +265,7 @@ struct mmci_host; > * @cmdreg_lrsp_crc: enable value for long response with crc > * @cmdreg_srsp_crc: enable value for short response with crc > * @cmdreg_srsp: enable value for short response without crc > + * @cmdreg_stop: enable value for stop and abort transmission > * @datalength_bits: number of bits in the MMCIDATALENGTH register > * @fifosize: number of bytes that can be written when MMCI_TXFIFOEMPTY > * is asserted (likewise for RX) > @@ -316,6 +318,7 @@ struct variant_data { > unsigned int cmdreg_lrsp_crc; > unsigned int cmdreg_srsp_crc; > unsigned int cmdreg_srsp; > + unsigned int cmdreg_stop; > unsigned int datalength_bits; > unsigned int fifosize; > unsigned int fifohalfsize; > @@ -375,6 +378,7 @@ struct mmci_host { > void __iomem *base; > struct mmc_request *mrq; > struct mmc_command *cmd; > + struct mmc_command stop_abort; > struct mmc_data *data; > struct mmc_host *mmc; > struct clk *clk; > -- > 2.7.4 > Kind regards Uffe