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 CB473CD1292 for ; Thu, 4 Apr 2024 20:02:16 +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: 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-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ru00pi0T7h8rx6EFv/hOa3NMkpN09kHE0iQFuVqBM1A=; b=V9VsOUNec4hbN4t9OBzPUng31T NU3zW020OQwj2X8rkZlrU1GBQzWUEPSwEoWaUv72cT21vYsL4aO/sKzjfOoqoRBlh/aByW3fTRAjE jO2PyScHd+91v4O1aSeVN/GNBhjLy4JrNdl0gP5nnHihACkNKdX9pyfj9s7+1uKaoJiWInkoZWHOA 3D5MDhaXNFI30CZIkLqa6l0jwc7fALkoYIRBTzPLzfaBPxtumng3qDCsIcM5jAxVI72guOLDKRAJg aZYYqmwrSk1GUzxR7SaTzb71smtAToboEb9TTw/Ga9mGCG1ddKiW2up4DnIgnDfEuLl1ahV5udKh3 D5ufAdcg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rsTHc-000000048aD-3Mjf; Thu, 04 Apr 2024 20:02:00 +0000 Received: from stravinsky.debian.org ([2001:41b8:202:deb::311:108]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rsTHZ-000000048Xx-28cJ; Thu, 04 Apr 2024 20:01:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Ar7Lw4eA7hfvt1/r0rsI3i5UsJ6oVUk1F07naco9tuc=; b=gprRlAjOYiNDqsDOIwPI3iTr/h I/7c/p843XxMifqRrgotVdV7/DiYdU97vaCKV5WTBdztUG8vS24060IFXLWt7q4azpC+V3lmksQYE wn8Mmf9Pp7ZseDLc7y5cTU2in0zlY4g3R2/103+buy3HQRxmZ/0HML9OhHzsJRrKWAKcHzcpi2Eby yLJnkWhVLAmh1ziwp5b3+0vX0uURaKK93avzifOAJi14kj/Ol1OLLG0UJh3/C3Z4POJtZElKXiZe6 Z8V7yRnUdAdTWJPywZdxG2m1DQtJQmAtNcDyZMydCHjnSAOLU0tsGjDGAhm6cekG4/pgiiZVTKcEB mbXjnv8g==; Received: from authenticated user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2) (envelope-from ) id 1rsTHB-00DWaO-8M; Thu, 04 Apr 2024 20:01:34 +0000 Date: Thu, 4 Apr 2024 22:01:29 +0200 From: Cyril Brulebois To: Jim Quinlan Cc: linux-pci@vger.kernel.org, Nicolas Saenz Julienne , Bjorn Helgaas , Lorenzo Pieralisi , Phil Elwell , bcm-kernel-feedback-list@broadcom.com, Conor Dooley , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Florian Fainelli , Jim Quinlan , Krzysztof Kozlowski , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , open list , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , Lorenzo Pieralisi , Rob Herring Subject: Re: [PATCH v9 0/4] PCI: brcmstb: Configure appropriate HW CLKREQ# mode Message-ID: <20240404200129.3qp4qs6zklbk2prl@mraw.org> Organization: Debian References: <20240403213902.26391-1-james.quinlan@broadcom.com> MIME-Version: 1.0 In-Reply-To: <20240403213902.26391-1-james.quinlan@broadcom.com> X-Debian-User: kibi X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240404_130157_560849_6E4EEA87 X-CRM114-Status: GOOD ( 23.74 ) 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: multipart/mixed; boundary="===============6982953551241375828==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============6982953551241375828== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4mlfdkp3wjmc3cs3" Content-Disposition: inline --4mlfdkp3wjmc3cs3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Jim, Jim Quinlan (2024-04-03): > v9 -- v8 was setting an internal bus timeout to accomodate large L1 exit > latencies. After meeting the PCIe HW team it was revealed that the > HW default timeout value was set low for the purposes of HW debuggi= ng > convenience; for nominal operation it needs to be set to a higher > value independent of this submission's purpose. This is now a > separate commit. >=20 > -- With v8, Bjorne asked what was preventing a device from exceeding t= he > time required for the above internal bus timeout. The answer to th= is > is for us to set the endpoints' max latency {no-,}snoop value to > something below this internal timeout value. If the endpoint > respects this value as it should, it will not send an LTR request > with a larger latency value and not put itself in a situation > that requires more latency than is possible for the platform. >=20 > Typically, ACPI or FW sets these max latency values. In most of our > systems we do not have this happening so it is up to the RC driver = to > set these values in the endpoint devices. If the endpoints already > have non-zero values that are lower than what we are setting, we let > them be, as it is possible ACPI or FW set them and knows something > that we do not. >=20 > -- The "clkreq" commit has only been changed to remove the code that w= as > setting the timeout value, as this code is now its own commit. Given the bot's feedback, I took the liberty of running tests on your patch series except with an extra =E2=80=9Cstatic=E2=80=9D keyword. On my b= uild system, gcc 12 wasn't complaining about it but I didn't spend time trying to find the right options, or trying a switch to clang to confirm the before/after situation: -void brcm_set_downstream_devs_ltr_max(struct brcm_pcie *pcie) +static void brcm_set_downstream_devs_ltr_max(struct brcm_pcie *pcie) Anyway, this is still: Tested-by: Cyril Brulebois Test setup: ----------- - using a $CM with the 20230111 EEPROM - on the same CM4 IO Board - with a $PCIE board (PCIe to multiple USB ports) - and the same Samsung USB flash drive + Logitech keyboard. where $CM is one of: - CM4 Lite Rev 1.0 - CM4 8/32 Rev 1.0 - CM4 4/32 Rev 1.1 and $PCIE is one of: - SupaHub PCE6U1C-R02, VER 006 - SupaHub PCE6U1C-R02, VER 006S - Waveshare VIA VL805/806-based Results: -------- 1. Given this is already v9, and given I don't see how this could have possibly changed, I didn't build or tested an unpatched kernel, which I would still expect to produce either a successful boot *without* seeing the devices plugged on the PCIe-to-USB board or the dreaded SError in most cases. 2. With a patched kernel (v6.7-562-g9f8413c4a66f2 + this series + =E2=80=9Cstatic=E2=80=9D in front of brcm_set_downstream_devs_ltr_max()= ), for all $CM/$PCIE combinations, I'm getting a system that boots, sees the flash drive, and gives decent read/write performance on it (plus a functional keyboard). Cheers, --=20 Cyril Brulebois (kibi@debian.org) D-I release manager -- Release team member -- Freelance Consultant --4mlfdkp3wjmc3cs3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmYPBxYACgkQ/5FK8MKz VSCIpw//YwRVw8lAie3wKx/qgQbpoFTlOXGLNFVwWKZFPhIgx5EQg+iWTKffg3EE yoq8uWofgddD3Rcmhspu5a/Af/DX7s7RkrVT3BH3PfwJ+WaAm/60vpVxx8vhNl8r kQvc1mwzuyyqh4BgmpcC2vYSn7ECJNSdawcY0bi4lJvCHmU60Bv1Lg4SQ0cqVKs/ OSjZdwyeLOTfovDQevKD0xRV52WxlrMZg7dhPG2DcUytrKl+36PPEpO6LdzxibCy LPAsklzDMOTgfF/7jTZWgAxyL4c5UslXk1X6zkKyWJTmABlvu2RBt7dgdINTKH68 g+5y5vApXegkbkZDFvFes25QvOZMFNx3JcmHVO4qp2EvsVv4krhAIyFb4BX0Zdjw ORHv2KJQD/x56JweQ/iX72oMz2PKZCpLSTExhLerF2lGrBlubqMLmZqII1MwL6T0 IMwEo1PB4UkBo8wWDZPUhk786Oxp6jNxdNtNRa3caD4KwvQOwP0nbGgSoDN91LHY tTb1cjdE03S0fmihIdIdfBM+dHZGKbQY6SoPGZ+xtyW98Moc6VpI8O0uAIJYO5gP FdQSn0NEOTFYlVDZvldQMkgPaAUi4fRmNOBQu7WWvaUHa+nlSFG7TpjqWJKY+CYJ ekw3PxfOn7Z677QjnBeXPr99kCAqiZBR/KEzs+USaGStNcObWns= =LON4 -----END PGP SIGNATURE----- --4mlfdkp3wjmc3cs3-- --===============6982953551241375828== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============6982953551241375828==--