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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 947A0C77B73 for ; Fri, 14 Apr 2023 20:27:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229893AbjDNU10 (ORCPT ); Fri, 14 Apr 2023 16:27:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39168 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229615AbjDNU1Y (ORCPT ); Fri, 14 Apr 2023 16:27:24 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8B12640DF; Fri, 14 Apr 2023 13:27:23 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 25E8A60BBF; Fri, 14 Apr 2023 20:27:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3DAB6C433EF; Fri, 14 Apr 2023 20:27:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681504042; bh=mGto9gKSSTTM0gjfPcNOwu+t1VdaM4q/g495do+Uqt8=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=NvptJXJfYZg8rRDRCNDqhhIXYMXWrNT6H/HO3Adt5dsfOmgNJDBm4RxAjf1RfS/c4 XzKK7VN/DJow762nJWUJh1ECAEVuljiC1xdR64Z5T4YNrT5R9cMjedIcWsJHO5eZBr 0x0rL2c8pf4fLTcAeHUkXmnrQ8HM/AjxDXo6HxQYg5jq49mSX3utwdWL0odxkt4n+2 gnPwFo65d1LHJsEjImH5PZcJt1KqE2B5+QUkofBHcOgZIPfrdPwkLpg2cz9ZCYqPDq y5cegzB+mg5DN9vK6TF35erBUchLXLC2YltXCwOlkiC4kAwLpIwHZc3+ryoa3JHff6 v0hTSj+rCxYdg== Date: Fri, 14 Apr 2023 15:27:20 -0500 From: Bjorn Helgaas To: Jim Quinlan Cc: linux-pci@vger.kernel.org, Nicolas Saenz Julienne , Bjorn Helgaas , Lorenzo Pieralisi , Cyril Brulebois , Phil Elwell , bcm-kernel-feedback-list@broadcom.com, james.quinlan@broadcom.com, Florian Fainelli , Lorenzo Pieralisi , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Rob Herring , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , open list Subject: Re: [PATCH v2 2/3] PCI: brcmstb: CLKREQ# accomodations of downstream device Message-ID: <20230414202720.GA215111@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230411165919.23955-3-jim2101024@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This subject line no verb. Can you add a leading verb to suggest what this patch does? s/accomodations/accommodations/ On Tue, Apr 11, 2023 at 12:59:17PM -0400, Jim Quinlan wrote: > The Broadcom STB/CM PCIe HW core, which is also used in RPi SOCs, must be > deliberately set by the probe() into one of three mutually exclusive modes: > > (a) No CLKREQ# expected or required, refclk is always available. > (b) CLKREQ# is expected to be driven by downstream device when needed. > (c) Bidirectional CLKREQ# for L1SS capable devices. > > Previously, only (b) was supported by the driver, as almost all STB/CM > boards operate in this mode. But now there is interest in activating L1SS > power savings from STB/CM customers, and also interest in accomodating mode > (a) for designs such as the RPi CM4 with IO board. accommodating > The HW+driver is able to tell us when mode (a) mode is needed. But there > is no easy way to tell if L1SS mode should be configured. In certain > situations, getting this wrong may cause a panic during boot time. So we > rely on the DT prop "brcm,enable-l1ss" to tell us when mode (c) is desired. > Using this mode only makes sense when the downstream device is L1SS-capable > and the OS has been configured to activate L1SS > (e.g. policy==powersupersave). I'm really concerned about the user experience here. I assume users do not want to edit the DT based on what device they plug in. They shouldn't need to (and probably won't) know whether the device supports L1SS. I hate kernel/module parameters, but I think even that would be better then having to edit the DT. There's obviously a period of time when L1SS is supported but not yet enabled, so I'm *guessing* the "OS has been configured to activate L1SS" is not actually a requirement, and choosing (c) really just opens the possibility that L1SS can be used? Would be nice to have a hint (maybe a line or two of the panic message) to help users find the fix for a problem they're seeing. Obviously the ideal would be if we could use (c) in all cases, so I assume that's where a panic might happen. What situation would that be? An endpoint that doesn't support L1SS? One that supports L1SS but it's not enabled? Maybe if L1SS isn't configured correctly, e.g., LTR values programmed wrong? Bjorn 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id DBF4AC77B72 for ; Fri, 14 Apr 2023 20:28:20 +0000 (UTC) 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: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:References: List-Owner; bh=E+9pIeyoIIkMNN/8s6aPvrvmRU2K6v/ooxB5H0LrbXM=; b=02OI4KTwEGeEU2 56jylycXUwXrEeoBInAM6+0ggceNZhYoN27h1BPgEwPsCMMZUx5AFI/Q+OjpJLboNdy0PIXtUGpmY 7CD5MfgC5rWUPgQAH0SUz1m0Er+UBPIDVaPbemcAxXTnFNN/pBFWEaLSUW7f7j2FRl5PLxan08Mww vwx7pRjReW5LcABd3zTgpAgACZXqaS6aXd32L+ZPSSG9eGFvk7jMz0Kf9/ObAxn31xHjtyfKyMkbF mTjOC8qPjsE1mWtv0wGqASPKHYOnRzfzoY2CwFydn3Ro7gFW99SBRYpLImJOG38Q4KnrdhBfHoWZc S0NnEJ3+O7nvtM5yK1UA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pnQ11-00AW8F-0K; Fri, 14 Apr 2023 20:27:27 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pnQ0x-00AW7Z-2V; Fri, 14 Apr 2023 20:27:25 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2633A64941; Fri, 14 Apr 2023 20:27:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3DAB6C433EF; Fri, 14 Apr 2023 20:27:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681504042; bh=mGto9gKSSTTM0gjfPcNOwu+t1VdaM4q/g495do+Uqt8=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=NvptJXJfYZg8rRDRCNDqhhIXYMXWrNT6H/HO3Adt5dsfOmgNJDBm4RxAjf1RfS/c4 XzKK7VN/DJow762nJWUJh1ECAEVuljiC1xdR64Z5T4YNrT5R9cMjedIcWsJHO5eZBr 0x0rL2c8pf4fLTcAeHUkXmnrQ8HM/AjxDXo6HxQYg5jq49mSX3utwdWL0odxkt4n+2 gnPwFo65d1LHJsEjImH5PZcJt1KqE2B5+QUkofBHcOgZIPfrdPwkLpg2cz9ZCYqPDq y5cegzB+mg5DN9vK6TF35erBUchLXLC2YltXCwOlkiC4kAwLpIwHZc3+ryoa3JHff6 v0hTSj+rCxYdg== Date: Fri, 14 Apr 2023 15:27:20 -0500 From: Bjorn Helgaas To: Jim Quinlan Cc: linux-pci@vger.kernel.org, Nicolas Saenz Julienne , Bjorn Helgaas , Lorenzo Pieralisi , Cyril Brulebois , Phil Elwell , bcm-kernel-feedback-list@broadcom.com, james.quinlan@broadcom.com, Florian Fainelli , Lorenzo Pieralisi , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Rob Herring , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , open list Subject: Re: [PATCH v2 2/3] PCI: brcmstb: CLKREQ# accomodations of downstream device Message-ID: <20230414202720.GA215111@bhelgaas> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230411165919.23955-3-jim2101024@gmail.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230414_132723_918087_5AAAA007 X-CRM114-Status: GOOD ( 21.54 ) 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 This subject line no verb. Can you add a leading verb to suggest what this patch does? s/accomodations/accommodations/ On Tue, Apr 11, 2023 at 12:59:17PM -0400, Jim Quinlan wrote: > The Broadcom STB/CM PCIe HW core, which is also used in RPi SOCs, must be > deliberately set by the probe() into one of three mutually exclusive modes: > > (a) No CLKREQ# expected or required, refclk is always available. > (b) CLKREQ# is expected to be driven by downstream device when needed. > (c) Bidirectional CLKREQ# for L1SS capable devices. > > Previously, only (b) was supported by the driver, as almost all STB/CM > boards operate in this mode. But now there is interest in activating L1SS > power savings from STB/CM customers, and also interest in accomodating mode > (a) for designs such as the RPi CM4 with IO board. accommodating > The HW+driver is able to tell us when mode (a) mode is needed. But there > is no easy way to tell if L1SS mode should be configured. In certain > situations, getting this wrong may cause a panic during boot time. So we > rely on the DT prop "brcm,enable-l1ss" to tell us when mode (c) is desired. > Using this mode only makes sense when the downstream device is L1SS-capable > and the OS has been configured to activate L1SS > (e.g. policy==powersupersave). I'm really concerned about the user experience here. I assume users do not want to edit the DT based on what device they plug in. They shouldn't need to (and probably won't) know whether the device supports L1SS. I hate kernel/module parameters, but I think even that would be better then having to edit the DT. There's obviously a period of time when L1SS is supported but not yet enabled, so I'm *guessing* the "OS has been configured to activate L1SS" is not actually a requirement, and choosing (c) really just opens the possibility that L1SS can be used? Would be nice to have a hint (maybe a line or two of the panic message) to help users find the fix for a problem they're seeing. Obviously the ideal would be if we could use (c) in all cases, so I assume that's where a panic might happen. What situation would that be? An endpoint that doesn't support L1SS? One that supports L1SS but it's not enabled? Maybe if L1SS isn't configured correctly, e.g., LTR values programmed wrong? Bjorn _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel