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 B7E49C77B72 for ; Fri, 14 Apr 2023 20:33:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229925AbjDNUdh (ORCPT ); Fri, 14 Apr 2023 16:33:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41740 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229615AbjDNUdf (ORCPT ); Fri, 14 Apr 2023 16:33:35 -0400 Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8BDA15B93; Fri, 14 Apr 2023 13:33:33 -0700 (PDT) Received: by mail-qv1-xf32.google.com with SMTP id qh25so9270027qvb.1; Fri, 14 Apr 2023 13:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681504412; x=1684096412; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=vdK48rxG4KzEvjeD5gYO8w9ZQkzGlmyxMjxEd3WM8Ds=; b=RU4Wt/rZ/iVY6X8bgz7G6eH5EGXYINrl+Fe2IqRIBdpeGETIkmw0oWqFPq9tSvatW9 QLP0WcU6FVa6XrRsBWd3EF3KjVlc4ZwXFw/rDi/vQd3wmrkKNqcDC+lax8OnQuVQvg8n ZLToWWojLfbH1KVrSQZUuFYT72RgmAUqajcirkYTdABfX85XJ/pwJFbVjY5guIe7VtPm 1rY3h84Ys17p/m9Qewtx6F64kK/qSPZ+2WhkVDL3UDWrDGF3PyJrB0hadf7S5ZUEgEnL WsblOVRX1mgrW6OALrKMqe45Y8iHzvGq9gdhy6pUFmxJjqAbqJjaYnEXuIoVFjf4PfFJ dYrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681504412; x=1684096412; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vdK48rxG4KzEvjeD5gYO8w9ZQkzGlmyxMjxEd3WM8Ds=; b=aOtQuOEgLmbW2hlEMKUbm7p5IaRM0bNi6oG641wkDHtPQnowgb7bQ5iIH5/dVaDOTA qNyTSvwnAOWuN8Z8pGk6+c7moy6cGTVjx7VCapFf9fdVPtzU3bqKzPLPoSC8mTD4NdtC Sw7ywRvMHdoJKlBY+od2zhijej5i7YcrFr2csB7GYyL/zAewrtPJjjRblfBXkp91y78t 3L8SI0zsi2r3j55476ciD/Hy5yLJ1uhn46Nu9ZSQaLoE8opahU7gtvewaKrtmGAr9D3l hJi8yTIjjVMmUlzAWxbMh8KRef1l4KkOYQ6C9pmbo+KB+l3KwYXcq7/455MdbMCcp7tp IJdQ== X-Gm-Message-State: AAQBX9d92APcVfldYUzDl9z95vs7YKrFkX1zq4u2U0Z9+REZTMI8oa3v 6A07qlk8NSz6FAMbsHYdcUBgLT/LUx5jNA== X-Google-Smtp-Source: AKy350ZiIPEt9O0PhLwBNN2FE+DwAu7PHpzVSX93modZ5Ct8O98kggmWIhZi585f9U5I40R3pH1m+g== X-Received: by 2002:a05:6214:21e5:b0:5e9:752:766b with SMTP id p5-20020a05621421e500b005e90752766bmr6120380qvj.47.1681504412627; Fri, 14 Apr 2023 13:33:32 -0700 (PDT) Received: from [10.67.48.245] ([192.19.223.252]) by smtp.googlemail.com with ESMTPSA id ei18-20020ad45a12000000b005eac706d223sm1337386qvb.124.2023.04.14.13.33.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Apr 2023 13:33:32 -0700 (PDT) Message-ID: Date: Fri, 14 Apr 2023 13:33:29 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH v2 2/3] PCI: brcmstb: CLKREQ# accomodations of downstream device Content-Language: en-US To: Bjorn Helgaas , 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 , =?UTF-8?Q?Krzysztof_Wilczy=c5=84ski?= , Rob Herring , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , open list References: <20230414202720.GA215111@bhelgaas> From: Florian Fainelli In-Reply-To: <20230414202720.GA215111@bhelgaas> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/14/23 13:27, Bjorn Helgaas wrote: > 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. The problem I see with kernel/module parameters is that it is really hard to differentiate whether they should be applied across all instances of the device/drivers or just for one in particular. The Raspberry Pi 4 is a single pcie-brcmstb instance, but we have other systems supported by that driver on Set-top-box and Cable Modem chips for instance where we may have different types of end-points being connected, some of which could be Multi-chip-module (MCM) where everything is known ahead of time, and sometimes cards that are plugged to full-sized PCIe or mini-PCIe connectors, where some amount of runtime discoverability is involved. Without inventing some custom modular parameter syntax, it may not work that well. The Device Tree properties at least easily allow for per-instance configuration. > > 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 -- Florian 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 88E4CC77B72 for ; Fri, 14 Apr 2023 20:34:32 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=28MB32bIyPRR3p+XCbzN32POM8vwmI/HpxVl6AK7ARA=; b=R3DSP3eT/EywtX SwWIHBpYFM2dtOuF5eGGNFh/DcrUxqYJ5RX6WuDDvHnAvTgHUHe2j/70vKt36q0od0tyZ9hQbtp1z X3KO6EaoHPsFvdok9wij2jXv/LqXWyxVVOB5+iawYu5Z4kPUSBTXulZWAdiwlCtyMmUrJvSYSfFC6 YjPofbgokF1R0dMklkxuQ+VwgPHl4tAopnNZcCy4utHIt+IhyH4JAQ2Gmxg5p9fn+VDWQ1hvteUvl 0iEbJIjwB+Y4QqgI+SsOPfBjNRH6jn3JtJlX1gr7gN9Fw59UzEgfQ1qeHxaozTRDE0TJGBGDB3WDm MXwDpjNSGMxsXdfCQDHw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pnQ71-00AWiH-1V; Fri, 14 Apr 2023 20:33:39 +0000 Received: from mail-qv1-xf2e.google.com ([2607:f8b0:4864:20::f2e]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pnQ6x-00AWhA-1s; Fri, 14 Apr 2023 20:33:36 +0000 Received: by mail-qv1-xf2e.google.com with SMTP id h14so8077812qvr.7; Fri, 14 Apr 2023 13:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681504412; x=1684096412; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=vdK48rxG4KzEvjeD5gYO8w9ZQkzGlmyxMjxEd3WM8Ds=; b=RU4Wt/rZ/iVY6X8bgz7G6eH5EGXYINrl+Fe2IqRIBdpeGETIkmw0oWqFPq9tSvatW9 QLP0WcU6FVa6XrRsBWd3EF3KjVlc4ZwXFw/rDi/vQd3wmrkKNqcDC+lax8OnQuVQvg8n ZLToWWojLfbH1KVrSQZUuFYT72RgmAUqajcirkYTdABfX85XJ/pwJFbVjY5guIe7VtPm 1rY3h84Ys17p/m9Qewtx6F64kK/qSPZ+2WhkVDL3UDWrDGF3PyJrB0hadf7S5ZUEgEnL WsblOVRX1mgrW6OALrKMqe45Y8iHzvGq9gdhy6pUFmxJjqAbqJjaYnEXuIoVFjf4PfFJ dYrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681504412; x=1684096412; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vdK48rxG4KzEvjeD5gYO8w9ZQkzGlmyxMjxEd3WM8Ds=; b=gqNCkzklNyf9bSzjBL2z42bB7qJrdbi7EQroUkycz+DTS4I4/it/ValroiYmevqQJQ gd9KLTLrXM5KYZ1EHzD9kiRgOnwttLh0l5ojQ3Q8bG6JoK0aEbTgFzLgLz2fSCq15eSb YOj5qwNX/VUi6ZEAlMTFEXB48++rPNs3XiJ9bSVPwgcEzkTuSN2PH/moXz9aSRJ9lHd+ wwzLw6wYet8QwmBNm1Q85BOr3dyYDC/tGl033DXsM36v7IQ/7pPjrzCwCLmIUVOGu0aB iKQo6lBe0yz7ysEll9kfY18Qc6eHoWMs20jjodnH+Sji76B97S78CE2HksqE8P+B5PFJ KWyg== X-Gm-Message-State: AAQBX9f1cLao6QGschvmqbI7ql4856hC36C2Eg7dZkTudEW34BfGR+PK /wmJTUgDhW9JMwYzHIiDTms= X-Google-Smtp-Source: AKy350ZiIPEt9O0PhLwBNN2FE+DwAu7PHpzVSX93modZ5Ct8O98kggmWIhZi585f9U5I40R3pH1m+g== X-Received: by 2002:a05:6214:21e5:b0:5e9:752:766b with SMTP id p5-20020a05621421e500b005e90752766bmr6120380qvj.47.1681504412627; Fri, 14 Apr 2023 13:33:32 -0700 (PDT) Received: from [10.67.48.245] ([192.19.223.252]) by smtp.googlemail.com with ESMTPSA id ei18-20020ad45a12000000b005eac706d223sm1337386qvb.124.2023.04.14.13.33.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Apr 2023 13:33:32 -0700 (PDT) Message-ID: Date: Fri, 14 Apr 2023 13:33:29 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH v2 2/3] PCI: brcmstb: CLKREQ# accomodations of downstream device Content-Language: en-US To: Bjorn Helgaas , 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 , =?UTF-8?Q?Krzysztof_Wilczy=c5=84ski?= , Rob Herring , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , open list References: <20230414202720.GA215111@bhelgaas> From: Florian Fainelli In-Reply-To: <20230414202720.GA215111@bhelgaas> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230414_133335_645763_27D646A1 X-CRM114-Status: GOOD ( 30.92 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 4/14/23 13:27, Bjorn Helgaas wrote: > 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. The problem I see with kernel/module parameters is that it is really hard to differentiate whether they should be applied across all instances of the device/drivers or just for one in particular. The Raspberry Pi 4 is a single pcie-brcmstb instance, but we have other systems supported by that driver on Set-top-box and Cable Modem chips for instance where we may have different types of end-points being connected, some of which could be Multi-chip-module (MCM) where everything is known ahead of time, and sometimes cards that are plugged to full-sized PCIe or mini-PCIe connectors, where some amount of runtime discoverability is involved. Without inventing some custom modular parameter syntax, it may not work that well. The Device Tree properties at least easily allow for per-instance configuration. > > 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 -- Florian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel