Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7106548imu; Thu, 31 Jan 2019 05:10:17 -0800 (PST) X-Google-Smtp-Source: ALg8bN4w5TeyB1PblPkZtx+RKnMAH3u4mrSeyVG/6Om42OnKfX72bHPtVFUUIZt5B9UIqy/yxlUE X-Received: by 2002:a65:500c:: with SMTP id f12mr31075804pgo.226.1548940217050; Thu, 31 Jan 2019 05:10:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548940217; cv=none; d=google.com; s=arc-20160816; b=g1EQxmuSZJYJXL/6PRLJhndS9arScbKJjJJpOJ+kuINQIIgzjZ4tH3BVSuql8Nt8Ka csHpbavOvY9NUPyz5hKYsTfh+FOqx0mOedm9gtK46kuD6yupBojQNMNu0vixkDrlz0aM BOqUNYpQnSslqFh4XsmPSCNKjIKfzzCCUTKJWZSxlTUqhMTcizqTH3O9FzHb6q1JUlS5 in7K7YyTd8IwT507KIGKv8FPEREZn1ny9ZOt/EiuBfFXFB6r3Ri8JjINsOhe8bI5otOu DvV9BFT++glMVZxg/h+Pyu3dEYw/gxmADa58qtx99Jib7baNqJ1GVafifTWLE8XXrzD7 exYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=KZG4FKSGi9I+xs1X1Mmnm8kDaaANL45zlU8FhW+2akw=; b=hs4Z+VmKbLkY7ezsYLuE1Nvx6G+T2ToqqHjLUZmUnDTJmdqUPy8zIFAhWST+QQR8ue 65eS1FEyv4Lf+o7C4LG4ReNhAeQeMECSWN2T35774VGNRT4W0k7M+cWPUBkKcCufAHBr eZyLR8a/xyEaCuKj2FQEY9gEtEWUO4STRTPx4dmKXbBUUV6EB7KhNQrlJKtyaShrAqwr Y4dvWpYif+wL0J80ZxhrLqsKbleHfMJltW4cu/Us9IorGnEjrnAhT6ckBYQ1egmdFO6y GhHC4HC+FohjvbQeaRTW+fLd/8AYFcayTYMQEsuOci3CT6xV8iNI2/JrJG5Jer1RVhit wZjA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 4si4569463pla.299.2019.01.31.05.09.58; Thu, 31 Jan 2019 05:10:17 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733048AbfAaNJc (ORCPT + 99 others); Thu, 31 Jan 2019 08:09:32 -0500 Received: from protonic.xs4all.nl ([83.163.252.89]:58477 "EHLO protonic.nl" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726153AbfAaNJc (ORCPT ); Thu, 31 Jan 2019 08:09:32 -0500 Received: from erd987 (erd987.prtnl [192.168.237.3]) by sparta (Postfix) with ESMTP id CF06144A0058; Thu, 31 Jan 2019 14:10:45 +0100 (CET) Date: Thu, 31 Jan 2019 14:09:30 +0100 From: Robin van der Gracht To: Ulf Hansson Cc: Martin Kepplinger , "linux-mmc@vger.kernel.org" , Linux ARM , Shawn Guo , Sascha Hauer , dl-linux-imx , Linux Kernel Mailing List , Martin Kepplinger Subject: Re: [PATCH v4] mmc: mxs-mmc: Introduce regulator support Message-ID: <20190131140930.05c5b6a5@erd987> In-Reply-To: References: <20190128144119.10092-1-martink@posteo.de> <20190131092006.363d1dd4@erd987> Organization: Protonic Holland X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 31 Jan 2019 13:17:23 +0100 Ulf Hansson wrote: > 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? No I didn't. The slow clock (sleep clock) was always 'on'. > > > > > 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. Ack. Makes more sense than using a regulator (even without specifying 'clocks'). > > 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. @Martin; What do you think? Will you work this out with Ulf? Since I can't test this. Regards, Robin