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=-2.2 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 8F772C433C1 for ; Tue, 30 Mar 2021 00:56:28 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 0D161619A0 for ; Tue, 30 Mar 2021 00:56:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0D161619A0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=gwZnlnGuwzGlU3g2W5ROgITiWTSkoWYbbglb9oxWOYQ=; b=O6PEXzobUveyOJwHbePS474jg VSYBza+OtJo2EEB8rvU2+iixAIBSh4LkLTn7q9yw3UVtMJDOKxgTwosZoS0pH4iz3rYZBkAjhhFyh ZkXOBcvVWZSZkavi5DlEk7j26l6qL0jGisCi6jocClF+OJNdabvlpXISkdTJSstmyQRO7S/VcR9p1 vfyvqYijQtOho+kBPnmmTZOlWECCL7dNy+yroAvE50luhlA8K4ofqFp6ynp2qrRaNPqc07cok/tLz k9pq7i6J+Kkn1D8zibWOqT4wGHd6lNTpSGAA3PtjoMnraZ+zbpR8c7AC4jqnxkii0Xvg6OWEVYFLC W8pO7v4lQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lR2c6-002GYx-RA; Tue, 30 Mar 2021 00:52:11 +0000 Received: from mail-pl1-x62d.google.com ([2607:f8b0:4864:20::62d]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lQz9B-001RLh-Rb; Mon, 29 Mar 2021 21:10:51 +0000 Received: by mail-pl1-x62d.google.com with SMTP id g10so5030774plt.8; Mon, 29 Mar 2021 14:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=q+dfSzt8E3k72dQZZN8BYdfUgJulz0l62/VUnuugD/Q=; b=e5h7GKzt2mrZjfch0TBXP7PguG7E35lElD54Ng1F3QiItQWma38JgdktTk2DO0exz9 zOfWWlbDXgoSc82BYUgibxYqflSFx+iLpawgfcKJUwifoGQofjAgTcdpoN+tBvigH1tp 5QjqTiK1K17lgBL9VfGEP8tqpi0BBY3Y3i56MOhjmjPlDfkaUmuyBBAleTTWBMkykBLP l2AINYj/z/utyCNPc4UpXfqNusehv68HfhNCJ3XU1rLTfrTlugQteo3mTVP2d/KU4i3Y v4voqfih5IeWIBZ+FT7VgJ9OFVNYJEp0KGIwrv98lmXsvSuGT86isXZvGpidu0vHRHJ5 +/fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=q+dfSzt8E3k72dQZZN8BYdfUgJulz0l62/VUnuugD/Q=; b=eEdvg86KMUgGTAA6KuXw3Pcii7XotUBEi0fNXtiCP0uHL5jQkLO2Vcp5cLbC4Qy4rW V+urbyyHnlI5G9zmbEUoFmqYizZHK/wsv+yjlZqwUCC0yW/59JLdpMGLIht/PJiJu6pb D8tTHhFxxF+sdXnaU+qsPnAzrQHMSX7VSYdnB2Mm98UWyKyPbS6hdnb7fqrOWePTeLk8 Z74o03TGIVAIux4ZQAcnODroGN/8oo+yShpRBtGvWF3/rLKwuqqwb4JxP5po/4xfHNX/ 43WBfvOKkif8CvxrEXfviobrH4RnaaFSLD98CLqFEX3rTjqlES4RsNQ/Pwuv8ZqJNQBl 4fXA== X-Gm-Message-State: AOAM530SnDfzKsuImNmfXUOSB/c20RIJosSOfXwD+LfrZ61HWXvvBqcB etIGw+F0hSgXEQ6BP61a0/s= X-Google-Smtp-Source: ABdhPJyrbfYD2rJKpKvbR3PJaNjuBsIrEMBw2ClPZfivbZa6YlEEhIssVwO2ZsJScXl3GgrLMp6lcQ== X-Received: by 2002:a17:90a:e60b:: with SMTP id j11mr976538pjy.42.1617052204275; Mon, 29 Mar 2021 14:10:04 -0700 (PDT) Received: from [10.67.49.104] ([192.19.223.252]) by smtp.googlemail.com with ESMTPSA id v134sm17826690pfc.182.2021.03.29.14.10.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Mar 2021 14:10:03 -0700 (PDT) Subject: Re: [PATCH v3 2/6] PCI: brcmstb: Add control of EP voltage regulators To: Mark Brown , Jim Quinlan Cc: linux-pci , Nicolas Saenz Julienne , Rob Herring , bcm-kernel-feedback-list , Jim Quinlan , Lorenzo Pieralisi , Bjorn Helgaas , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , open list References: <20210326191906.43567-1-jim2101024@gmail.com> <20210326191906.43567-3-jim2101024@gmail.com> <20210329162539.GG5166@sirena.org.uk> <20210329171613.GI5166@sirena.org.uk> <20210329204543.GJ5166@sirena.org.uk> From: Florian Fainelli Message-ID: Date: Mon, 29 Mar 2021 14:09:58 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210329204543.GJ5166@sirena.org.uk> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210329_221049_757976_06B055FD X-CRM114-Status: GOOD ( 33.22 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 On 3/29/21 1:45 PM, Mark Brown wrote: > On Mon, Mar 29, 2021 at 03:48:46PM -0400, Jim Quinlan wrote: > >> I'm not concerned about a namespace collision and I don't think you >> should be concerned either. First, this driver is for Broadcom STB >> PCIe chips and boards, and we also deliver the DT to the customers. >> We typically do not have any other regulators in the DT besides the >> ones I am proposing. For example, the 7216 SOC DT has 0 other > > You may not describe these regulators in the DT but you must have other > regulators in your system, most devices need power to operate. In any > case "this works for me with my DT on my system and nobody will ever > change our reference design" isn't really a great approach, frankly it's > not a claim I entirely believe and even if it turns out to be true for > your systems if we establish this as being how regulators work for > soldered down PCI devices everyone else is going to want to do the same > thing, most likely making the same claims for how much control they have > over the systems things will run on. > >> regulators -- no namespace collision possible. Our DT-generating >> scripts also flag namespace issues. I admit that this driver is also >> used by RPi chips, but I can easily exclude this feature from the RPI >> if Nicolas has any objection. > > That's certainly an issue, obviously the RPI is the sort of system where > I'd imagine this would be particularly useful. > >> Further, if you want, I can restrict the search to the two regulators >> I am proposing to add to pci-bus.yaml: "vpcie12v-supply" and >> "vpcie3v3-supply". > > No, that doesn't help - what happens if someone uses separate regulators > for different PCI devices? The reason the supplies are device namespaced > is that each device can look up it's own supplies and label them how it > wants without reference to anything else on the board. Alternatively > what happens if some device has another supply it needs to power on (eg, > something that wants a clean LDO output for analogue use)? > >> Is the above enough to alleviate your concerns about global namespace collision? > > Not really. TBH it looks like this driver is keeping the regulators > enabled all the time except for suspend and resume anyway, if that's all > that's going on I'd have thought that you wouldn't need any explicit > management in the driver anyway? Just mark the regualtors as always on > and set up an appropriate suspend mode configuration and everything > should work without the drivers doing anything. Unless your PMIC isn't > able to provide separate suspend mode configuration for the regulators? > We have typically GPIO-controlled and PMIC (via SCMI) controlled regulators. During PCIe enumeration we need these regulators turned on to be successful in training the PCIe link and discover the end-point attached, so there an always on regulator would work. When we enter a system suspend state however there are really two cases: - the end-point supports Wake-on (typically wake-on-WLAN) and we need its power supplied kept on to support that - the end-point does not support or participate in any wake-up, there we want to turn its supplies off to save power How would we go about supporting such an use case with an always on regulator? -- Florian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel