Received: by 2002:a05:7412:bbc7:b0:fc:a2b0:25d7 with SMTP id kh7csp619646rdb; Thu, 1 Feb 2024 20:54:44 -0800 (PST) X-Google-Smtp-Source: AGHT+IHEQUgsTNF8nl4C08gEM0/ZhTNEp6wawuJTOw9kmIf7fFyFeugJXJf+7fOS31M3jeyF4qQc X-Received: by 2002:aa7:980d:0:b0:6dd:a162:9205 with SMTP id e13-20020aa7980d000000b006dda1629205mr4689257pfl.26.1706849684711; Thu, 01 Feb 2024 20:54:44 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706849684; cv=pass; d=google.com; s=arc-20160816; b=BXyp/uFUs6wogIiLVu9m2RrLEULqoLmi9ffoQSHf829keL9CUkOVzQyRMEhqUF/Are GRolQbCB3Sstzp3AGrQLcjwMfJnXE7dLoBza3Vt+jRwiU4ii3MpZBCOH5yoMkFxdr593 QqDEb/ihWIv7hBmGcrPuEZwcqgysHRoZF3GzGes97alqYrkjwE73Ze8pswWR7kna3SWl rXEzcCh5F07WRzuz0lIXfmyHLt7p11Q7MZoCzmEVU2GdzinVYoEGqau9YUmN1Uzofp0Z ge5QVyt1VWfdE2URe+N9dqAQngdpifUKsXi3ahSeQc9bFCuBauEJ/AgwfNx3/1A9K6+s d35g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=OrllvvME+67c5rJL6o9XUwHpXAvWXwcCt+Aoy2EZDu8=; fh=I0cRgFLr6lGXVyRfjUCjfIP/6UqVEp7W3TDW361ZE0c=; b=SBupiAiv6txMhio8ek5Oq0yE/AOuo/xK64+AbnZbGb/67Gm7d5jXmA38B4SgvvLXep btn9dErIBLrih2G+rLJjV05gOwaNv1Ra5imDIzxb7WVNw756qAYuMc9PSEYS7CamvJpw ENN7yBW0I1KpFls3cvnw/AIh9dg6Hg306iHIFenaT2k7UO+fhH1wHT9Q8qO91mIm98/L Ve5Cef4Y0p62rjoUTWFfAxNXanN1WpOPXiUduGR8lKCG0M0n7NeRTB1Twy9H7XLR2YCI 2837eU8pq31NS7Hi0uJ0wHFU6XnLdvqefeAB0jGNVQoKnsICXt+FJMWzdCU5oBnLffnm D6oA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=sfZckKXs; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-bluetooth+bounces-1562-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-bluetooth+bounces-1562-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org X-Forwarded-Encrypted: i=1; AJvYcCU9yfJ/ZEd6xDMNy9H8CbgwB8xQleh0jn1IbHpXAInrr/S4Im2BDSzneyfTWO2+u5TgdHEkZvKvM+HDThnzXNqtUqz5r07fD9cZgJQbuw== Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id h7-20020a63c007000000b005c68da9ca8asi962647pgg.787.2024.02.01.20.54.44 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Feb 2024 20:54:44 -0800 (PST) Received-SPF: pass (google.com: domain of linux-bluetooth+bounces-1562-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=sfZckKXs; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-bluetooth+bounces-1562-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-bluetooth+bounces-1562-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 5928C28FFE8 for ; Fri, 2 Feb 2024 04:54:44 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 732DBF9E9; Fri, 2 Feb 2024 04:54:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sfZckKXs" X-Original-To: linux-bluetooth@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BE3D1F50D; Fri, 2 Feb 2024 04:54:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706849669; cv=none; b=qYBW+DL38Ga+oOFqRnDGj+6PK4a5apTE7SdYETCrPBtYNlx3AiB0mtrCmFMwaHP9nRPSjA+DnLKOdY+m+eP42PwZEQeyyY7mXTzZp8xfNfbOPhM6+sElwt3yeI1giLopKt5PpbfsfaRpcMKeijCzqWvEwsxaRMxZNyKyabC82AY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706849669; c=relaxed/simple; bh=P45zUVKxLg0GSRAnp51QUGRathjmDQ8/gBq5BPY2h30=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Cf/v+7U1fS6hMJd+2IOPQI1olBLLFunOKiMkONPracNRonZ7o5wZ5OvpujuaUYWH6JDr/+8bO1Rsrxu6Vm3bQwk+6kAb9BgbkwBXANdFS4dFyy8PF1rEti1XU+Xf7hoON4dsBl/tGEdg8v6uHEhNDaPRWYXoJ0TmuWY7kQTvfHg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sfZckKXs; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 973B9C433F1; Fri, 2 Feb 2024 04:54:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1706849669; bh=P45zUVKxLg0GSRAnp51QUGRathjmDQ8/gBq5BPY2h30=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=sfZckKXscAq5mFX9knlISzDoHtWKyeI/fCPzumtqoUod5qmScWjfEFVmIHjbefVYw J5crSez6FZwpAav12eKufVKVnrgVN1hnGtKQk7Nvq5XUZWKHAS7jP/Y4semINTRKxQ qiotrsEoX0klAnsDuT8bVNcIUkvLuRGH5GtmjDKei5sw8SZtqkq/MGLxcmumx7bi8C fy5g8fBfbE3j3K+FsNaOkhWRb0ZGaLmbLCLwnyhXncdyYF0SQQ/7QuCTorix4au7Rf kKtJcf0oyetln1vmsxnXOJSYToIZwsFuog2u8RoH82f8y1SGDbl/uh/UWbO4t48EQl Y1n36sdkt5uEQ== Date: Thu, 1 Feb 2024 22:54:25 -0600 From: Bjorn Andersson To: Bartosz Golaszewski Cc: Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Marcel Holtmann , Luiz Augusto von Dentz , Bjorn Helgaas , Neil Armstrong , Alex Elder , Srini Kandagatla , Greg Kroah-Hartman , Arnd Bergmann , Abel Vesa , Manivannan Sadhasivam , Lukas Wunner , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org, linux-pci@vger.kernel.org, Bartosz Golaszewski Subject: Re: [RFC 4/9] power: pwrseq: add a driver for the QCA6390 PMU module Message-ID: References: <20240201155532.49707-1-brgl@bgdev.pl> <20240201155532.49707-5-brgl@bgdev.pl> Precedence: bulk X-Mailing-List: linux-bluetooth@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240201155532.49707-5-brgl@bgdev.pl> On Thu, Feb 01, 2024 at 04:55:27PM +0100, Bartosz Golaszewski wrote: > diff --git a/drivers/power/sequencing/pwrseq-qca6390.c b/drivers/power/sequencing/pwrseq-qca6390.c [..] > +static int pwrseq_qca6390_power_on(struct pwrseq_device *pwrseq) > +{ > + struct pwrseq_qca6390_ctx *ctx = pwrseq_device_get_data(pwrseq); > + int ret; > + > + ret = regulator_bulk_enable(ctx->pdata->num_vregs, ctx->regs); > + if (ret) > + return ret; > + > + gpiod_set_value_cansleep(ctx->bt_gpio, 1); > + gpiod_set_value_cansleep(ctx->wlan_gpio, 1); So it's no longer possible to power these independently? > + > + if (ctx->pdata->pwup_delay_msec) > + msleep(ctx->pdata->pwup_delay_msec); > + > + return 0; > +} > + > +static int pwrseq_qca6390_power_off(struct pwrseq_device *pwrseq) > +{ > + struct pwrseq_qca6390_ctx *ctx = pwrseq_device_get_data(pwrseq); > + > + gpiod_set_value_cansleep(ctx->bt_gpio, 0); > + gpiod_set_value_cansleep(ctx->wlan_gpio, 0); > + The answer that was provided recently was that the WiFi and BT modules absolutely must be modelled together, because there must be a 100ms delay between bt_gpio going low and wlan_gpio going high. If you're not going to address that concern, then I fail to see the reason for adding the power sequence framework - just let the BT and PCI power control (WiFi) do their thing independently. > + return regulator_bulk_disable(ctx->pdata->num_vregs, ctx->regs); > +} > + > +static int pwrseq_qca6390_match(struct pwrseq_device *pwrseq, > + struct device *dev) > +{ > + struct pwrseq_qca6390_ctx *ctx = pwrseq_device_get_data(pwrseq); > + struct device_node *dev_node = dev->of_node; > + > + /* > + * The PMU supplies power to the Bluetooth and WLAN modules. both > + * consume the PMU AON output so check the presence of the > + * 'vddaon-supply' property and whether it leads us to the right > + * device. > + */ > + if (!of_property_present(dev_node, "vddaon-supply")) > + return 0; > + > + struct device_node *reg_node __free(of_node) = > + of_parse_phandle(dev_node, "vddaon-supply", 0); > + if (!reg_node) > + return 0; > + > + /* > + * `reg_node` is the PMU AON regulator, its parent is the `regulators` > + * node and finally its grandparent is the PMU device node that we're > + * looking for. > + */ > + if (!reg_node->parent || !reg_node->parent->parent || > + reg_node->parent->parent != ctx->of_node) > + return 0; Your DeviceTree example gives a sense that a set of supplies feeds the PMU, which then supplies power to the BT and WiFi nodes through some entity that can switch power on and off, and adjust the voltage level. Then comes this function, which indicates that the DeviceTree model was just for show. > + > + return 1; > +} > + > +static int pwrseq_qca6390_probe(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct pwrseq_qca6390_ctx *ctx; > + struct pwrseq_config config; > + int ret, i; > + > + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL); > + if (!ctx) > + return -ENOMEM; > + > + ctx->of_node = dev->of_node; > + > + ctx->pdata = of_device_get_match_data(dev); > + if (!ctx->pdata) > + return dev_err_probe(dev, -ENODEV, > + "Failed to obtain platform data\n"); > + > + if (ctx->pdata->vregs) { > + ctx->regs = devm_kcalloc(dev, ctx->pdata->num_vregs, > + sizeof(*ctx->regs), GFP_KERNEL); > + if (!ctx->regs) > + return -ENOMEM; > + > + for (i = 0; i < ctx->pdata->num_vregs; i++) > + ctx->regs[i].supply = ctx->pdata->vregs[i].name; > + > + ret = devm_regulator_bulk_get(dev, ctx->pdata->num_vregs, > + ctx->regs); > + if (ret < 0) > + return dev_err_probe(dev, ret, > + "Failed to get all regulators\n"); > + > + for (i = 0; i < ctx->pdata->num_vregs; i++) { > + if (!ctx->pdata->vregs[1].load_uA) > + continue; > + > + ret = regulator_set_load(ctx->regs[i].consumer, > + ctx->pdata->vregs[i].load_uA); > + if (ret) > + return dev_err_probe(dev, ret, > + "Failed to set vreg load\n"); > + } > + } > + > + ctx->bt_gpio = devm_gpiod_get_optional(dev, "bt-enable", GPIOD_OUT_LOW); Why are these optional? Does it make sense to have a qca6390 without both of these gpios connected? Regards, Bjorn > + if (IS_ERR(ctx->bt_gpio)) > + return dev_err_probe(dev, PTR_ERR(ctx->bt_gpio), > + "Failed to get the Bluetooth enable GPIO\n"); > + > + ctx->wlan_gpio = devm_gpiod_get_optional(dev, "wlan-enable", > + GPIOD_OUT_LOW); > + if (IS_ERR(ctx->wlan_gpio)) > + return dev_err_probe(dev, PTR_ERR(ctx->wlan_gpio), > + "Failed to get the WLAN enable GPIO\n"); > + > + memset(&config, 0, sizeof(config)); > + > + config.parent = dev; > + config.owner = THIS_MODULE; > + config.drvdata = ctx; > + config.match = pwrseq_qca6390_match; > + config.power_on = pwrseq_qca6390_power_on; > + config.power_off = pwrseq_qca6390_power_off; > + > + ctx->pwrseq = devm_pwrseq_device_register(dev, &config); > + if (IS_ERR(ctx->pwrseq)) > + return dev_err_probe(dev, PTR_ERR(ctx->pwrseq), > + "Failed to register the power sequencer\n"); > + > + return 0; > +} > + > +static const struct of_device_id pwrseq_qca6390_of_match[] = { > + { > + .compatible = "qcom,qca6390-pmu", > + .data = &pwrseq_qca6390_of_data, > + }, > + { } > +}; > +MODULE_DEVICE_TABLE(of, pwrseq_qca6390_of_match); > + > +static struct platform_driver pwrseq_qca6390_driver = { > + .driver = { > + .name = "pwrseq-qca6390", > + .of_match_table = pwrseq_qca6390_of_match, > + }, > + .probe = pwrseq_qca6390_probe, > +}; > +module_platform_driver(pwrseq_qca6390_driver); > + > +MODULE_AUTHOR("Bartosz Golaszewski "); > +MODULE_DESCRIPTION("QCA6390 PMU power sequencing driver"); > +MODULE_LICENSE("GPL"); > -- > 2.40.1 >