Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7063467imu; Thu, 31 Jan 2019 04:26:20 -0800 (PST) X-Google-Smtp-Source: ALg8bN4ke36j3fT9cuxNCHp2PPdqpLzrRpFjaJ3AKzQa+wvfr5md8TFzP/+/A6nwUVZgp+88IYaT X-Received: by 2002:a63:4c4e:: with SMTP id m14mr31674068pgl.173.1548937580340; Thu, 31 Jan 2019 04:26:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548937580; cv=none; d=google.com; s=arc-20160816; b=WVe/b2H2ZNwZUI+AuXngLlNT43a/Hi9Si4YwXGVYS5AAFefQkJEFIYfY0JH3IEGf1L k3S9eOGuDcQ423sb+FcgbsyJGcgdmQL3t6OJ2VeJEaL/4xT1tt8EEL9BoMvDGoCfW1tY VhVtjUkBGIQTfSoMF9ToROS7zuVokkpaEojPD20bbsRSOwp5NwXMSsumuBoqfkuA6PYt ctTYwpltEREV/nHljvipdcKP74DaVRSA4uGT1KmYa9RprtcC8asEMV8TKqbJDs1ea4dN QiG9jE5to5VgDI2FWuctFIo687Fh9IpPR8H7FiTYK+9+i8b6m0PoFmeEF5ipW/S2ZQ5w PK/g== 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=rMkf0gd68B0VNf8LFPErOfYHBzTvWTZG+O/rTFihV4I=; b=FLFj24DHXY9btLthZlTiFqn96PGCrXh8jG5U8/mbay7Flf3h/wKiRIBw3xJ16XaJu4 uf1hIb4/Bqq2mTFU0ERggCKiFJeMei5OpRg1ReS8u74KX36lTT/3mnZnQJO+OL1ixQM6 sBNFxYXoVPX9ahbqd96jCJ2KyQN/UPWtwSrY/UmhOgPnMjoVqw3fGj0amKK3/EaxKcAp QCyVIhZ3Uob5UK7UJObh0FXGbISlOgX1CpZy9E2o6tgPZdYy/rZ/ea1TlrNinoyZUZWK EQ5Qe9BUA7QhAH3jReDwb4fFPTVmWJScP0Bm6Er59P2O2XvhOS28tHEIuVpiaquuPNvh bbYw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=gFD87IvT; 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 p3si4461897plr.376.2019.01.31.04.26.01; Thu, 31 Jan 2019 04:26:20 -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=gFD87IvT; 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 S1732649AbfAaMSB (ORCPT + 99 others); Thu, 31 Jan 2019 07:18:01 -0500 Received: from mail-ua1-f65.google.com ([209.85.222.65]:43766 "EHLO mail-ua1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727259AbfAaMSB (ORCPT ); Thu, 31 Jan 2019 07:18:01 -0500 Received: by mail-ua1-f65.google.com with SMTP id z11so932522uaa.10 for ; Thu, 31 Jan 2019 04:18:00 -0800 (PST) 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=rMkf0gd68B0VNf8LFPErOfYHBzTvWTZG+O/rTFihV4I=; b=gFD87IvTWMiYTaX30KLruBsENu70SjUoCtKw7J911orOOt5Ddm9wDSyGsu1pVrMfHX y/O4khowAnb+sz2/xFi9VudhcqfKlOXfD3vQU92jqLcJwmOjRlCgYwN3fA6/nJDbjspr nGO9f+MyuxEniJsWS+nnG/DLp6MtBSrNaP1uA= 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=rMkf0gd68B0VNf8LFPErOfYHBzTvWTZG+O/rTFihV4I=; b=YSsN0KvSYdoQefa0gDsqNtf4w+lP7B6ccpiswuVsidcAZmELFtf472muSi+vtYcVA8 RB/aGTJMsABDD8p4CXariIuv8qtOSTHlvNS6zw2PkNpSIuqVzIaNk7kzdWsj4Tnn2/Ex cLNiTAUBvAoJWVl2ieU5PKOCO/Xxz3MA4REjmu6ghuWnRPV9LAej6qlGxaxOj/J9ckK9 tWwImL1ucODZrwZWOp7NtUKxY/LRC1TOOn4VO/HA+/UXQZDxIIWX8Kgzmx9MFu5ynfNY a2i8tmAVsaW//miQ6vSgzBHa5fbCzUbz0eFHVS9VAGOyTtksEKMqRFNHJ096AnwzFWNr VV9A== X-Gm-Message-State: AJcUukciTO5+S61SWSCEC7RJ1SJSJxeSG3EawzpfZWqqx3UgjLdwRG7e 8kOuu+545TQchsGhypEqm7xlQ6M/IGL4CAORKJ0Oxw== X-Received: by 2002:ab0:31d5:: with SMTP id e21mr14563931uan.107.1548937079489; Thu, 31 Jan 2019 04:17:59 -0800 (PST) MIME-Version: 1.0 References: <20190128144119.10092-1-martink@posteo.de> <20190131092006.363d1dd4@erd987> In-Reply-To: <20190131092006.363d1dd4@erd987> From: Ulf Hansson Date: Thu, 31 Jan 2019 13:17:23 +0100 Message-ID: Subject: Re: [PATCH v4] mmc: mxs-mmc: Introduce regulator support To: Robin van der Gracht Cc: Martin Kepplinger , "linux-mmc@vger.kernel.org" , Linux ARM , Shawn Guo , Sascha Hauer , dl-linux-imx , Linux Kernel Mailing List , Martin Kepplinger 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 Thu, 31 Jan 2019 at 09:20, Robin van der Gracht wrote: > > On Mon, 28 Jan 2019 22:15:23 +0100 > Ulf Hansson wrote: > > > On Mon, 28 Jan 2019 at 15:41, Martin Kepplinger wrote: > > > > > > From: Martin Kepplinger > > > > > > This adds support for explicitly switching the mmc's power on and off > > > which is needed for example for WL1837 WL1271 wifi controllers on imx28. > > > > > > While the wifi's vmmc-supply regulator can be configured in devicetree, > > > "ip link set wlan0 down" doesn't turn off the VMMC regulator which leads > > > to hangs when loading firmware, for example. > > > > > > Signed-off-by: Martin Kepplinger > > > --- > > > > > > > > > revision history > > > ---------------- > > > v4: re-added forgotten regulator_enable() during probe > > > v3: improve API usage as suggested by Ulf > > > v2: tested patch with changes suggested by Robin > > > v1: question, why https://patchwork.kernel.org/patch/4365751/ didn't get in > > > > > > > > > drivers/mmc/host/mxs-mmc.c | 34 +++++++++++++++++++++++++--------- > > > 1 file changed, 25 insertions(+), 9 deletions(-) > > > > > > diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c > > > index add1e70195ea..23d275269d61 100644 > > > --- a/drivers/mmc/host/mxs-mmc.c > > > +++ b/drivers/mmc/host/mxs-mmc.c > > > @@ -517,6 +517,22 @@ static void mxs_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) > > > else > > > host->bus_width = 0; > > > > > > + switch (ios->power_mode) { > > > + case MMC_POWER_OFF: > > > + if (!IS_ERR(host->mmc->supply.vmmc)) > > > + mmc_regulator_set_ocr(host->mmc, > > > + host->mmc->supply.vmmc, 0); > > > + break; > > > + case MMC_POWER_UP: > > > + if (!IS_ERR(host->mmc->supply.vmmc)) > > > + mmc_regulator_set_ocr(host->mmc, > > > + host->mmc->supply.vmmc, > > > + ios->vdd); > > > + break; > > > + default: > > > + break; > > > + } > > > + > > > if (ios->clock) > > > mxs_ssp_set_clk_rate(&host->ssp, ios->clock); > > > } > > > @@ -588,7 +604,6 @@ static int mxs_mmc_probe(struct platform_device *pdev) > > > struct mmc_host *mmc; > > > struct resource *iores; > > > int ret = 0, irq_err; > > > - struct regulator *reg_vmmc; > > > struct mxs_ssp *ssp; > > > > > > irq_err = platform_get_irq(pdev, 0); > > > @@ -614,14 +629,15 @@ static int mxs_mmc_probe(struct platform_device *pdev) > > > host->mmc = mmc; > > > host->sdio_irq_en = 0; > > > > > > - reg_vmmc = devm_regulator_get(&pdev->dev, "vmmc"); > > > - if (!IS_ERR(reg_vmmc)) { > > > - ret = regulator_enable(reg_vmmc); > > > - if (ret) { > > > - dev_err(&pdev->dev, > > > - "Failed to enable vmmc regulator: %d\n", ret); > > > - goto out_mmc_free; > > > - } > > > + ret = mmc_regulator_get_supply(mmc); > > > + if (ret == -EPROBE_DEFER) > > > + goto out_mmc_free; > > > + > > > + ret = regulator_enable(mmc->supply.vmmc); > > > > This is wrong, as it may cause the regulator usage count to become > > wrongly balanced. > > > > Instead, via ->set_ios() when calling mmc_regulator_set_ocr(), it will > > take care of enabling and disabling the regulator depending of the > > requested vdd voltage level. > > > > > + if (ret) { > > > + dev_err(&pdev->dev, > > > + "Failed to enable vmmc regulator: %d\n", ret); > > > + goto out_mmc_free; > > > } > > > > > > ssp->clk = devm_clk_get(&pdev->dev, NULL); > > > -- > > > 2.20.1 > > > > > > > BTW, you didn't really answer my earlier question about the TI WiFi > > chip. Doesn't you need a special clock for WiFi chip as well? How do > > you intend to manage that? > > I used an external 32K oscillator (SLOW_CLK) for my wl1271. Other > clocks ware generated on the module. Right. How do you control that clock? Did you model it as clock via the common clock framework? > > I had to supply a 'vmmc-supply' in your wl1271 devicetree node, > which will be used to power on/off the wlan module. The supply should > be a (delayed) GPIO controlled 'fixed-regulator' attached to the > wlan_en pin on the module. Right, thanks for explaining. > > 1: Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt > This sounds like a good fit for mmc pwrseq simple. There are already similar users for it. Have a look at: /drivers/mmc/core/pwrseq* If the mmc host driver calls mmc_of_parse() during ->probe(), a pwrseq instance will be hooked up to it. Once the mmc core tries to power up the card it will make use of the attached pwrseq for the mmc host in question. In this way, you can control the clock and GPIO line, in more exact ways that is needed by the WiFi chip. Here is a DT example (look for "mmc-pwrseq-simple"): arch/arm/boot/dts/imx6qdl-sr-som-ti.dtsi This should do the trick for you. On the other hand, I don't mind that you still add regulator support to the driver, along the lines of what $subject patch does, however it may not be exactly what you need for the WiFi case. Kind regards Uffe