Received: by 10.192.165.148 with SMTP id m20csp392211imm; Fri, 20 Apr 2018 00:36:54 -0700 (PDT) X-Google-Smtp-Source: AIpwx49G0MQSOQsznLgK8gVS/IY1cVT62oeqE4rHjVkuhLrarEBVYfaWkz7hx/qFWM/BTch3PAIk X-Received: by 2002:a17:902:6b4c:: with SMTP id g12-v6mr9222219plt.148.1524209814666; Fri, 20 Apr 2018 00:36:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524209814; cv=none; d=google.com; s=arc-20160816; b=0srziENB8JkPLJ8avnBe1rc2xLZEuVDMylUJLnHClJCTGaHhH7aYiVHtDVOPyW1p1u tHWifxv33v4pIJ6M00Ppx8nrj0HtEZ8OxwC2KP5jiG/HaYUxwRFIQuftUU9+q5TkS5wT EZYcbg7A0cqIFpZ9R5p6Tr3GoQhhZrJIws+tzod/y+wZcnY0GsftEYiHrbfSzoAzbo8c P0sUDOiYZlc8XmGk1I267cuzuS8QFqnrQ35J5xPzDxE0677B2XtSHITPVNJ6z5AVEPn4 VkqSLknENZoQyPFSFF3WuvOwpjlOo/KD0izRCNd0fEgChipyXUip7TzXtszTKIMELC1c kSEw== 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 :arc-authentication-results; bh=N4a2fCxqdf1JA1BqbCGxs1x7yES9kzJ2a90Jo338w6g=; b=MMrhaaXcfZu95dyJGOIBGTy7kLJ5eRVtUq2WaeCcqOf4OEN7Rn5C5U8ODxbW7jAS48 eIT6jVIFQhK5HefrNX2o+HL4I9Ytl8KZJsjDkSA4nsvqdAu3F0I5yx9ypwY9JDbd24WQ 6wD2hzXubH8SZezEHRdNU405XXUUWH3ae3TqXWSuG3W/X2cqubW1+nYB4Ey1JUcdaYw/ ph19HGZoxIqLMfifmrLUOOm3a5XRLC02+2udl3gZmG4/qLU2f/E9asQ2z5VFRV7ttZT6 5lfxV7O7VNpOokDzPmfXJkyQzEX0/FphegTUSeQZXT5Hffj51fptQrNehw7e7fB4XLdj D1OA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=I/ZRJRHw; 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 d20-v6si5437269plr.206.2018.04.20.00.36.40; Fri, 20 Apr 2018 00:36:54 -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=I/ZRJRHw; 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 S1754112AbeDTHfb (ORCPT + 99 others); Fri, 20 Apr 2018 03:35:31 -0400 Received: from mail-io0-f176.google.com ([209.85.223.176]:32893 "EHLO mail-io0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753597AbeDTHf3 (ORCPT ); Fri, 20 Apr 2018 03:35:29 -0400 Received: by mail-io0-f176.google.com with SMTP id s25-v6so3544882ioa.0 for ; Fri, 20 Apr 2018 00:35:29 -0700 (PDT) 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=N4a2fCxqdf1JA1BqbCGxs1x7yES9kzJ2a90Jo338w6g=; b=I/ZRJRHw7FHXaIp0LqVgjCECLVO34WNyT2eN6E2cv36npdQp4vk52kMROFp1FAc67t KCOpA+X4tN0HR13qt0d3ZcuS/m75Y6ftjWcLN5cGBDNg5CGGpBoY4fyXh6soqbB3Sc3D wIaxCcqVkEVhwdmfaxO7s4nwhkj1zF17ck9lQ= 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=N4a2fCxqdf1JA1BqbCGxs1x7yES9kzJ2a90Jo338w6g=; b=dlaxkFrs593/xxHoUXE31RpoovcYBTD278KmOLCE+YXZDbbWzByXlBz0kbV/6DymWh oPX6g3+8kReN5BhT7jecofljUYDFVy5mFa0Q9AmV5SICM7axrAzpjLx/ZyFrAMryRkXN dZYNRXYXm/EQN80HGDf28EcZC+M1Yn8qFaSO9NVvQTdvOnyq/+UPeqVNFmP4iXiEFrmH DC8NRUsNo1S0R5vJUiEvOXXNRtVhpZ60up8rkT6mbUcVKSB/FR0qOjov6pO30IjTi37r h1b5pjntF9o/D/zqISogTkDwDB6eOBP6PBfj3aMzh/WqelH6qlsJRD+SDfF1otl9BSga 6IeA== X-Gm-Message-State: ALQs6tAujV0lmSv/oYBCG4GTgU3XiOhvgC8MyF63hdIhcxPUnJosgdsy dodqnxV+NAHVqL+/MyN+lLPHzBbpOMTCqjfgKQWsAnr3 X-Received: by 2002:a6b:84a6:: with SMTP id o38-v6mr9366618ioi.119.1524209728914; Fri, 20 Apr 2018 00:35:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:734a:0:0:0:0:0 with HTTP; Fri, 20 Apr 2018 00:35:28 -0700 (PDT) In-Reply-To: <20180417121130.25281-1-Eugeniy.Paltsev@synopsys.com> References: <20180417121130.25281-1-Eugeniy.Paltsev@synopsys.com> From: Ulf Hansson Date: Fri, 20 Apr 2018 09:35:28 +0200 Message-ID: Subject: Re: [RFC 0/2] dw_mmc: add multislot support To: Eugeniy Paltsev Cc: "linux-mmc@vger.kernel.org" , Linux Kernel Mailing List , linux-snps-arc@lists.infradead.org, linux-samsung-soc , Linux ARM , Jaehoon Chung , Shawn Lin , Kukjin Kim , Krzysztof Kozlowski , Alexey Brodkin 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 [...] > > 2. Add missing stuff to support multislot mode in DesignWare MMC driver. > * Add missing slot switch to __dw_mci_start_request() function. > * Refactor set_ios function: > a) Calculate common clock which is > suitable for all slots instead of directly use clock value > provided by mmc core. We calculate common clock as the minimum > among each used slot clocks. This clock is calculated in > dw_mci_calc_common_clock() function which is called > from set_ios() > b) Disable clock only if no other slots are ON. > c) Setup clock directly in set_ios() only if no other slots > are ON. Otherwise adjust clock in __dw_mci_start_request() > function before slot switch. > d) Move timings and bus_width setup to separate funcions. > * Use timing field in each slot structure instead of common field in > host structure. > * Add locks to serialize access to registers. Sorry, but this is a hack to *try* to make multi-slot work and this isn't sufficient. There were good reasons to why the earlier non-working multi slot support was removed from dw_mmc. Let me elaborate a bit for your understanding. The core uses a host lock (mmc_claim|release_host()) to serialize operations and commands, as to confirm to the SD/SDIO/(e)MMC specs. The above changes gives no guarantees for this. To make that work, we would need a "mmc bus lock" to be managed by the core. However, inventing a "mmc bus lock" would lead to other problems related to I/O scheduling for upper layers - it simply breaks. For example, I/O requests for one card/slot can then starve I/O requests reaching another card/slot. [...] Kind regards Uffe