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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9D836C433EF for ; Mon, 25 Oct 2021 22:45:08 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 567C06103C for ; Mon, 25 Oct 2021 22:45:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 567C06103C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=AbP7kpJa67GVUNbNamxGR8NsjNmCPNVJanOUUQZ+kxI=; b=GbcoIhYM4LMgj0 pVxpcI4bsCyGBln9lk5fwdAT2t0xRKTvbadx+BQ45RRorazczEDpGvdwMFCRihmge9xLaZGDtzdpB DWqxm9uEOUXhr1MhDb19DPH2VIQ+jyJObJv4Kx0u24KcL96wi/lADt+KWbSA8MCRNS9dCbGmEOYwM lWEZQtwraJHdF6W4zxr/HUhFRaBZkwfbCL/1OpL9AFIHIykRWw2bO3tq4AtOLmNmxox1PFGDHfkry T+iBPYAJLD2Gal5k42UJAy5bMYQNAdoB04yS4E2EkGbAWIqb8l94ZezIJ+4gNvMjuiejC8fHgpf9S fy6C8D5XwAdykq6rcGpQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mf8h1-000F5q-Ku; Mon, 25 Oct 2021 22:43:47 +0000 Received: from mail-oi1-f174.google.com ([209.85.167.174]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mf8gx-000F5D-TG; Mon, 25 Oct 2021 22:43:45 +0000 Received: by mail-oi1-f174.google.com with SMTP id o4so17716983oia.10; Mon, 25 Oct 2021 15:43:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=1zjj/3+jDmSGNtrIuN16WKRctTcCSeqDtgzJGB+OWrs=; b=A5Vt7jOMEk/V1E0P7G7ewgeOkcDX5kIah63rqfAp8fskzSHw2mETxFJIK6aqQYcNRV dpwPJSZJV6PUeeOecJlhb/Jx5z0bAYt0HIGKInbQHU+l3H6k4fUwHgTNKWaEZOQNNRXF tJ7V+X0oTt12PzBbgSRFr9Rg5T1oypZf8QvDkmdM/90f7cUQBZVWuoB4QxVCUlLrM2XQ aIYdkWmsbGD2CQbpJKP91k1MdEnP2qierOmVF6TZuw9krngAuxlWYAZa/xt4etX4UTZA ZNRj170UhjEQYEP6k5AVs8UznyRswGkwUC5kgI0IdCGaep3+60UAXYzl1IknreyDQWeu nwDQ== X-Gm-Message-State: AOAM533ZHZ2ppUjhSiKpvNyfildiBbpP7AyEcWfyGyB4x1gDYmkC3VbG rFIf77iimkvYS7DNh4td/A== X-Google-Smtp-Source: ABdhPJxslTyNOctaJkhkls43SqUyyiF/zFw3Q/U2zDEfYhotZ16/ogssJrH6Prv1gdTLP8j5+iDZDQ== X-Received: by 2002:a05:6808:243:: with SMTP id m3mr15025428oie.14.1635201822105; Mon, 25 Oct 2021 15:43:42 -0700 (PDT) Received: from robh.at.kernel.org (66-90-148-213.dyn.grandenetworks.net. [66.90.148.213]) by smtp.gmail.com with ESMTPSA id l1sm4025475oic.30.2021.10.25.15.43.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Oct 2021 15:43:41 -0700 (PDT) Received: (nullmailer pid 1222123 invoked by uid 1000); Mon, 25 Oct 2021 22:43:40 -0000 Date: Mon, 25 Oct 2021 17:43:40 -0500 From: Rob Herring To: Florian Fainelli Cc: Mark Brown , Jim Quinlan , Jim Quinlan , "open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS" , Nicolas Saenz Julienne , "maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE" , Lorenzo Pieralisi , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Bjorn Helgaas , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , open list Subject: Re: [PATCH v5 4/6] PCI: brcmstb: Add control of subdevice voltage regulators Message-ID: References: <20211022140714.28767-1-jim2101024@gmail.com> <20211022140714.28767-5-jim2101024@gmail.com> <2eec973e-e9f0-1ef7-a090-734dab5db815@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <2eec973e-e9f0-1ef7-a090-734dab5db815@gmail.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211025_154343_975877_6E4B0A29 X-CRM114-Status: GOOD ( 47.94 ) 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 Mon, Oct 25, 2021 at 03:04:34PM -0700, Florian Fainelli wrote: > On 10/25/21 7:58 AM, Mark Brown wrote: > > On Mon, Oct 25, 2021 at 09:50:09AM -0400, Jim Quinlan wrote: > >> On Fri, Oct 22, 2021 at 3:47 PM Mark Brown wrote: > >>> On Fri, Oct 22, 2021 at 03:15:59PM -0400, Jim Quinlan wrote: > > > >>> That sounds like it just shouldn't be a regulator at all, perhaps the > >>> board happens to need a regulator there but perhaps it needs a clock, > >>> GPIO or some specific sequence of actions. It sounds like you need some > >>> sort of quirking mechanism to cope with individual boards with board > >>> specific bindings. > > > >> The boards involved may have no PCIe sockets, or run the gamut of the different > >> PCIe sockets. They all offer gpio(s) to turn off/on their power supply(s) to > >> make their PCIe device endpoint functional. It is not viable to add > >> new Linux quirk or DT > >> code for each board. First is the volume and variety of the boards > >> that use our SOCs.. Second, is > >> our lack of information/control: often, the board is designed by one > >> company (not us), and > >> given to another company as the middleman, and then they want the > >> features outlined > >> in my aforementioned commit message. > > > > Other vendors have plenty of variation in board design yet we still have > > device trees that describe the hardware, I can't see why these systems > > should be so different. It is entirely normal for system integrators to > > collaborate on this and even upstream their own code, this happens all > > the time, there is no need for everything to be implemented directly the > > SoC vendor. > > This is all well and good and there is no disagreement here that it > should just be that way but it does not reflect what Jim and I are > confronted with on a daily basis. We work in a tightly controlled > environment using a waterfall approach, whatever we come up with as a > SoC vendor gets used usually without further modification by the OEMs, > when OEMs do change things we have no visibility into anyway. > > We have a boot loader that goes into great lengths to tailor the FDT > blob passed to the kernel to account for board-specific variations, PCIe > voltage regulators being just one of those variations. This is usually > how we quirk and deal with any board specific details, so I fail to > understand what you mean by "quirks that match a common pattern". > > Also, I don't believe other vendors are quite as concerned with > conserving power as we are, it could be that they are just better at it > through different ways, or we have a particular sensitivity to the subject. > > > > > If there are generic quirks that match a common pattern seen in a lot of > > board then properties can be defined for those, this is in fact the > > common case. This is no reason to just shove in some random thing that > > doesn't describe the hardware, that's a great way to end up stuck with > > an ABI that is fragile and difficult to understand or improve. > > I would argue that at least 2 out of the 4 supplies proposed do describe > hardware signals. The latter two are more abstract to say the least, > however I believe it is done that way because they are composite > supplies controlling both the 12V and 3.3V supplies coming into a PCIe > device (Jim is that right?). So how do we call the latter supply then? > vpcie12v3v...-supply? > > > Potentially some of these things should be being handled in the bindings > > and drivers drivers for the relevant PCI devices rather than in the PCI > > controller. > > The description and device tree binding can be and should be in a PCI > device binding rather than pci-bus.yaml. > > The handling however goes back to the chicken and egg situation that we > talked about multiple times before: no supply -> no link UP -> no > enumeration -> no PCI device, therefore no driver can have a chance to > control the regulator. These are not hotplug capable systems by the way, > but even if they were, we would still run into the same problem. Given > that most reference boards do have mechanical connectors that people can > plug random devices into, we cannot provide a compatible string > containing the PCI vendor/device ID ahead of time because we don't know > what will be plugged in. I thought you didn't have connectors or was it just they are non-standard? If the latter case, what are the supply rails for the connector? I'd be okay if there's no compatible as long as there's not a continual stream of DT properties trying to describe power sequencing requirements. > In the case of a MCM, we would, but then we > only solved about 15% of the boards we need to support, so we have not > really progressed much. MCM is multi-chip module? Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel