From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AB14BC433DF for ; Fri, 16 Oct 2020 10:51:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4A7232084C for ; Fri, 16 Oct 2020 10:51:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="h1/x/JEN" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2395504AbgJPKvP (ORCPT ); Fri, 16 Oct 2020 06:51:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48638 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2395496AbgJPKvM (ORCPT ); Fri, 16 Oct 2020 06:51:12 -0400 Received: from mail-vs1-xe44.google.com (mail-vs1-xe44.google.com [IPv6:2607:f8b0:4864:20::e44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6FA8DC0613D3 for ; Fri, 16 Oct 2020 03:51:12 -0700 (PDT) Received: by mail-vs1-xe44.google.com with SMTP id r1so1151241vsi.12 for ; Fri, 16 Oct 2020 03:51:12 -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=Xbxr9IqhfBSHOTINIDRRrGXVvLUBIFjfiaN+PDTjgRQ=; b=h1/x/JENjlGBAxLp90NlmELvg20nyWnLhe2fPvUUCrFFVnqXuUlUOdB1tYjeFXV1OL shCcv+r8YSU5nl0KeCt5njRSbPdhMTTKptboeoNGClrKyPbkeHleS/BcWp0PqH+vHvFV O8XdDZF1hPr7i+XLHFrvchx2HkX9wcqYCJhM2T21/JxBmDEj/zBEKC5wgiytnrywvT1a xQLa4WlrL5Q1fznU2MFAXKDIBpbyW900vANTpc8eZ/S+f1MpmR+jgCPQUon0b7WVqAQb fK3Z9ItWOzBAm/gLaVsRynTakRWof4rgR9dRWV+7mxFY9gHLmRQIgJr4j4oWhCk0QOJ0 2lyQ== 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=Xbxr9IqhfBSHOTINIDRRrGXVvLUBIFjfiaN+PDTjgRQ=; b=Utv3+tLVzC+3udY7DFfH+hO70oazcUbfR2sJZzzX2fnMHBwY9QMkI/i6ACt8IekG6T Yo/qo03VCpK13U3kYBMpcnsOkPpyK4QI+G1RouGA8Xv2KRN1AOYGCwcoDtbJnIX1KysI 9J9cIfLhagRkf6Mu1q8RH1ClUL9eQtR8uFi2utn9gIWApDzuow1Cfm/2URzc0J9EBR7g ZX4emYtDZRkrQ/xBfO9ZLfQldRdkm7+fGkbQfjMEYUTkly4CImqstKhuZS3agR1Tmcdc eFI72hw+lbTIbu3GYrkhLyr1oIAB8Prioo79b92wb20Pg1vL5pkq43GIVf9gIJcmpPpd M9RA== X-Gm-Message-State: AOAM530Px2RRds71x0Ie9PndA7GqFjsOkXDZY4pv4qa2L2uQFRB9I8K3 58MSd3eIyLQgwnRTGt1vJVy9rxwE/e4nVZ+ssKLgNg== X-Google-Smtp-Source: ABdhPJxaHgzUhpedWRcsJOLXZxBTwLRwdu9IeczL62z9Gp1yOoyKgss0MK1ty0S0xi2z3ujakcbAn7IalKgFlkEbFuY= X-Received: by 2002:a67:6c86:: with SMTP id h128mr1407272vsc.42.1602845470789; Fri, 16 Oct 2020 03:51:10 -0700 (PDT) MIME-Version: 1.0 References: <20201008020936.19894-1-muhammad.husaini.zulkifli@intel.com> <20201008020936.19894-5-muhammad.husaini.zulkifli@intel.com> In-Reply-To: From: Ulf Hansson Date: Fri, 16 Oct 2020 12:50:34 +0200 Message-ID: Subject: Re: [PATCH v4 4/4] mmc: sdhci-of-arasan: Enable UHS-1 support for Keem Bay SOC To: "Zulkifli, Muhammad Husaini" Cc: "Hunter, Adrian" , Michal Simek , "Shevchenko, Andriy" , "linux-mmc@vger.kernel.org" , Linux ARM , Linux Kernel Mailing List , "Raja Subramanian, Lakshmi Bai" , "Wan Mohamad, Wan Ahmad Zainie" , Arnd Bergmann Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [...] > >> >> >> The SDcard for Keem Bay SOC does not have its own voltage regulator. > >> >> >> There are 2 places to control the voltage. > >> >> >> 1) By setting the AON register calling system-level platform > >> >> >> management > >> >> >layer (SMC) > >> >> >> to set the I/O pads voltage for particular GPIOs line for clk,data and > >cmd. > >> >> >> The reason why I use this keembay_sd_voltage_selection() via > >> >> >> smccc > >> >> >interface it because during voltage switching > >> >> >> I need to access to AON register. On a secure system, we > >> >> >> could not > >> >> >directly access to AON register due to some security concern from > >> >> >driver side, thus > >> >> >> cannot exposed any register or address. > >> >> >> 2) By controlling the GPIO expander value to drive either 1.8V > >> >> >> or 3.3V for > >> >> >power mux input. > >> >> > > >> >> >I see, thanks for clarifying. > >> >> > > >> >> >To me, it sounds like the best fit is to implement a pinctrl (to > >> >> >manage the I/O > >> >> >pads) and a GPIO regulator. > >> >> > > >> >> Even with pinctrl, i still need to use the > >> >> keembay_sd_voltage_selection() > >> >thingy for AON register. > >> > > >> >Yes, I am fine by that. > >> > > >> >Although, as it's really a pinctrl, it deserves to be modelled like > >> >that. Not as a soc specific hack in a mmc host driver. > >> > > >> >> Plus, the GPIO pin that control the sd-voltage is in GPIO Expander > >> >> not using > >> >Keembay SOC GPIO Pin. > >> >> The best option is using the gpio consumer function to toggle the pin. > >> > > >> >As I said, please no. > >> > > >> >The common way to model this is as a GPIO regulator. In this way, you > >> >can even rely on existing mmc DT bindings. All you have to do is to > >> >hook up a vqmmc supply to the mmc node. > >> > > >> >To be clear, as long as there are no arguments for why a pinctrl and > >> >GPIO regulator can't be used - I am not going to pick up the patches. > >> As I mentioned The SDcard does not have its own voltage regulator. > >> It only uses the voltage rails on the mux input. > >> > >> There are 2 things need to be configured before getting the output voltage: > >> > >> 1) V_VDDIO_B : > >> Supplied voltage applied to I/O Rail which is controlled from the Always on > >domain using specific bits in AON_CFG1 register. > >> This is where we set for V_VDDIO_B using the > >keembay_sd_voltage_selection() to set either 1.8v or 3.3v depending on the bit > >value. > >> IMHO, we do not pinctrl to do this. > >> > >> 2) V_VDDIO_B_MAIN: > >> The output V_VDDIO_B_MAIN (OUT1) will be either V_3P3_MAIN (IN1) or > >> V_1P8_MAIN (IN2), depending on the state of GPIO expander Pin value. There > >is a POWER MUX involving here. > >> IMHO, we do not need any gpio regulator/regulator api hook up for this. > >> Most important thing, there is no regulator ic at all. > >> We still need to manually control and toggle the pin value. > >> > >> The final IO voltage is set by V_VDDIO_B (= V_VDDIO_B_MAIN after passing > >through voltage sense resistor). > >> > >> Hope this will clarify. > > > >I think I get it, thanks. > > > >Again, I haven't seen any reasons for why this can't be modelled as a pinctrl and > >a gpio-regulator. So, please convert it to that. > For gpio-regulator, I believe I could not use the current gpio-regulator.c framework as there is no consumer API for me to change the state of gpio pin during voltage switching. The consumer API you want to use, is the regulator consumer API, regulator_enable|disable(), for example. Although, as I stated earlier, the mmc core already provides helper functions for this. I suggest you have a look at mmc_regulator_set_vqmmc() and how it's used by other mmc host drivers. > Do I need to create a specific gpio-regulator driver under drivers/regulator for keem bay? > > I don't think so. Please have a look at Documentation/devicetree/bindings/regulator/gpio-regulator.yaml. This allows you to specify your GPIO regulator in DT. Then from the mmc node you add a "vqmmc-supply" specifier with the phandle to the regulator - that should be it. Kind regards Uffe From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 18AD4C433DF for ; Fri, 16 Oct 2020 10:52:59 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 79329207F7 for ; Fri, 16 Oct 2020 10:52:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="lp2KYc59"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="h1/x/JEN" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 79329207F7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=aGQofwSXvKTikBkpywBBX5dyHeqto8y3h+b7s+A9Lng=; b=lp2KYc59FeAbVzJJlbcpR7H4A +xBSfeDQL0Se3K2OB6LE/j96XwUMZVp2jMW/OPA5X7huodU4SgDwMVQyjyPE0gJzCF8ov/oquznpb jWxonltu6tWQbgBosBI3p3M7vW1aiVb6Elc03AFR0XFk7nQhQaIfjFOL63We7h/+gHJ9esSNmgNOK WaBbYlpRGfWpgHXBmONOUhrFIf95ajZ5qSnvDD3rDDHixq7j636Axhg4Q/+tJF1vP4EvA/BICs/MC 26KL4jLe7vFkWzGw9BMYw69UfaQINPszov4Ep9X5hZ+jHTSApC0him+08ipJCsApgar9KmTQPltVK Fe2cwzgdA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kTNKR-0000Zg-2J; Fri, 16 Oct 2020 10:51:19 +0000 Received: from mail-vs1-xe41.google.com ([2607:f8b0:4864:20::e41]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kTNKO-0000Z5-2A for linux-arm-kernel@lists.infradead.org; Fri, 16 Oct 2020 10:51:17 +0000 Received: by mail-vs1-xe41.google.com with SMTP id d4so1144150vsk.13 for ; Fri, 16 Oct 2020 03:51:12 -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=Xbxr9IqhfBSHOTINIDRRrGXVvLUBIFjfiaN+PDTjgRQ=; b=h1/x/JENjlGBAxLp90NlmELvg20nyWnLhe2fPvUUCrFFVnqXuUlUOdB1tYjeFXV1OL shCcv+r8YSU5nl0KeCt5njRSbPdhMTTKptboeoNGClrKyPbkeHleS/BcWp0PqH+vHvFV O8XdDZF1hPr7i+XLHFrvchx2HkX9wcqYCJhM2T21/JxBmDEj/zBEKC5wgiytnrywvT1a xQLa4WlrL5Q1fznU2MFAXKDIBpbyW900vANTpc8eZ/S+f1MpmR+jgCPQUon0b7WVqAQb fK3Z9ItWOzBAm/gLaVsRynTakRWof4rgR9dRWV+7mxFY9gHLmRQIgJr4j4oWhCk0QOJ0 2lyQ== 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=Xbxr9IqhfBSHOTINIDRRrGXVvLUBIFjfiaN+PDTjgRQ=; b=okO3nhBLal8Rf4buGhY695LiMNWXDoPpyPcYTnxKhVuyDOM02fgvflTZbfmq6VVOhU zPpsYDs+TBeQ3Q4w1BJadImbv7xizSb4WvGm1MHRm0q0mqO2wAcYSB7oDofrgmkerNRL ipaR4M/FW/E4CteDrsCwQyih3jFLB6w8OO3rrhzd4MFjQAHEgFHgUBgidT+ExgEzA+TS nozu5EuscfqNQGaM85g0O4xryWmI4bGiUlXocNM+9zjsw0NHLLR4IlsCXFaPH7cE6PtI LQisyCyQgrMUzDarjy2BIohM4dnVDBXyg/ifIBtGQ3Gd9aL4R2gWRlG2QYE/QSv6ig47 ih9g== X-Gm-Message-State: AOAM530uRzLPuiHPAKz4uL3Z21af9KrIoHb6rDpqWdabTHNzBV6DuIkU 8R7UVJ/WvG1hVvTvbPzxYocrwGWIFjtHjmyl9DKqDrw+fLs/KdmU X-Google-Smtp-Source: ABdhPJxaHgzUhpedWRcsJOLXZxBTwLRwdu9IeczL62z9Gp1yOoyKgss0MK1ty0S0xi2z3ujakcbAn7IalKgFlkEbFuY= X-Received: by 2002:a67:6c86:: with SMTP id h128mr1407272vsc.42.1602845470789; Fri, 16 Oct 2020 03:51:10 -0700 (PDT) MIME-Version: 1.0 References: <20201008020936.19894-1-muhammad.husaini.zulkifli@intel.com> <20201008020936.19894-5-muhammad.husaini.zulkifli@intel.com> In-Reply-To: From: Ulf Hansson Date: Fri, 16 Oct 2020 12:50:34 +0200 Message-ID: Subject: Re: [PATCH v4 4/4] mmc: sdhci-of-arasan: Enable UHS-1 support for Keem Bay SOC To: "Zulkifli, Muhammad Husaini" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201016_065116_115318_A4ED8EAD X-CRM114-Status: GOOD ( 32.53 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Shevchenko, Andriy" , Arnd Bergmann , "Raja Subramanian, Lakshmi Bai" , "linux-mmc@vger.kernel.org" , Linux Kernel Mailing List , "Hunter, Adrian" , "Wan Mohamad, Wan Ahmad Zainie" , Michal Simek , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org [...] > >> >> >> The SDcard for Keem Bay SOC does not have its own voltage regulator. > >> >> >> There are 2 places to control the voltage. > >> >> >> 1) By setting the AON register calling system-level platform > >> >> >> management > >> >> >layer (SMC) > >> >> >> to set the I/O pads voltage for particular GPIOs line for clk,data and > >cmd. > >> >> >> The reason why I use this keembay_sd_voltage_selection() via > >> >> >> smccc > >> >> >interface it because during voltage switching > >> >> >> I need to access to AON register. On a secure system, we > >> >> >> could not > >> >> >directly access to AON register due to some security concern from > >> >> >driver side, thus > >> >> >> cannot exposed any register or address. > >> >> >> 2) By controlling the GPIO expander value to drive either 1.8V > >> >> >> or 3.3V for > >> >> >power mux input. > >> >> > > >> >> >I see, thanks for clarifying. > >> >> > > >> >> >To me, it sounds like the best fit is to implement a pinctrl (to > >> >> >manage the I/O > >> >> >pads) and a GPIO regulator. > >> >> > > >> >> Even with pinctrl, i still need to use the > >> >> keembay_sd_voltage_selection() > >> >thingy for AON register. > >> > > >> >Yes, I am fine by that. > >> > > >> >Although, as it's really a pinctrl, it deserves to be modelled like > >> >that. Not as a soc specific hack in a mmc host driver. > >> > > >> >> Plus, the GPIO pin that control the sd-voltage is in GPIO Expander > >> >> not using > >> >Keembay SOC GPIO Pin. > >> >> The best option is using the gpio consumer function to toggle the pin. > >> > > >> >As I said, please no. > >> > > >> >The common way to model this is as a GPIO regulator. In this way, you > >> >can even rely on existing mmc DT bindings. All you have to do is to > >> >hook up a vqmmc supply to the mmc node. > >> > > >> >To be clear, as long as there are no arguments for why a pinctrl and > >> >GPIO regulator can't be used - I am not going to pick up the patches. > >> As I mentioned The SDcard does not have its own voltage regulator. > >> It only uses the voltage rails on the mux input. > >> > >> There are 2 things need to be configured before getting the output voltage: > >> > >> 1) V_VDDIO_B : > >> Supplied voltage applied to I/O Rail which is controlled from the Always on > >domain using specific bits in AON_CFG1 register. > >> This is where we set for V_VDDIO_B using the > >keembay_sd_voltage_selection() to set either 1.8v or 3.3v depending on the bit > >value. > >> IMHO, we do not pinctrl to do this. > >> > >> 2) V_VDDIO_B_MAIN: > >> The output V_VDDIO_B_MAIN (OUT1) will be either V_3P3_MAIN (IN1) or > >> V_1P8_MAIN (IN2), depending on the state of GPIO expander Pin value. There > >is a POWER MUX involving here. > >> IMHO, we do not need any gpio regulator/regulator api hook up for this. > >> Most important thing, there is no regulator ic at all. > >> We still need to manually control and toggle the pin value. > >> > >> The final IO voltage is set by V_VDDIO_B (= V_VDDIO_B_MAIN after passing > >through voltage sense resistor). > >> > >> Hope this will clarify. > > > >I think I get it, thanks. > > > >Again, I haven't seen any reasons for why this can't be modelled as a pinctrl and > >a gpio-regulator. So, please convert it to that. > For gpio-regulator, I believe I could not use the current gpio-regulator.c framework as there is no consumer API for me to change the state of gpio pin during voltage switching. The consumer API you want to use, is the regulator consumer API, regulator_enable|disable(), for example. Although, as I stated earlier, the mmc core already provides helper functions for this. I suggest you have a look at mmc_regulator_set_vqmmc() and how it's used by other mmc host drivers. > Do I need to create a specific gpio-regulator driver under drivers/regulator for keem bay? > > I don't think so. Please have a look at Documentation/devicetree/bindings/regulator/gpio-regulator.yaml. This allows you to specify your GPIO regulator in DT. Then from the mmc node you add a "vqmmc-supply" specifier with the phandle to the regulator - that should be it. Kind regards Uffe _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel