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 4A84CC77B78 for ; Wed, 19 Apr 2023 15:57:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233730AbjDSP5z (ORCPT ); Wed, 19 Apr 2023 11:57:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48010 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231467AbjDSP5x (ORCPT ); Wed, 19 Apr 2023 11:57:53 -0400 Received: from stravinsky.debian.org (stravinsky.debian.org [IPv6:2001:41b8:202:deb::311:108]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2240B19A6; Wed, 19 Apr 2023 08:57:52 -0700 (PDT) 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=kDbJlrgL3sjXj3G+1OO7np5Xsz4+mKZQ6I14H0THhkc=; b=aXLiIj2Fq44PA3oRVyjSzdJsSl U78F+oLK669QslhXPSbUOrvkxKfFOQ+fkdZVr4U3xqjJnvh8L3pWM5GBiSnujq1b32CKGFqlmoqFv yWGUjlYOZqaup1qUCZVcYuEa5EpE5FnppaiLFquv92r619fdk/k75AZ0kgzc/ZQrMjOzC/9U/wdPZ rFxgRH5Wnv1/ROhWprkMP23aYcBh2l15TrJhZimWaSxRa/pcRZahbUxZcBZ4Sfnoceqbu2HHhekLM YGmC3WmS6nmL5P0t2eJWKElqtL4aHieYhpSo0M3Kn3hhkrQ9Z9QKo+6Z57B33a8v3fCO6RT3c8ran /SUeMPzA==; 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 1ppABl-005q5R-T2; Wed, 19 Apr 2023 15:57:47 +0000 Date: Wed, 19 Apr 2023 17:57:43 +0200 From: Cyril Brulebois To: Jim Quinlan Cc: Florian Fainelli , linux-pci@vger.kernel.org, Nicolas Saenz Julienne , Bjorn Helgaas , Lorenzo Pieralisi , Phil Elwell , bcm-kernel-feedback-list@broadcom.com, james.quinlan@broadcom.com, 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: <20230419155743.j7lwvgkhdxz2zkrk@mraw.org> Organization: Debian References: <20230411165919.23955-1-jim2101024@gmail.com> <20230411165919.23955-3-jim2101024@gmail.com> <20230413143935.pmbyjk2boxl3rwne@mraw.org> <20230413200646.ddgsoqgmaae343nl@mraw.org> <85a1cca1-f59b-6a0c-dee3-9d9ed5d6b6d1@gmail.com> <20230414161907.zfd2ibshfx4rz56j@mraw.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3kfu6luykgorwo37" Content-Disposition: inline In-Reply-To: X-Debian-User: kibi Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --3kfu6luykgorwo37 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Jim, It might take a few days before getting back to you regarding the various questions you asked. To be on the safe side, I'll probably run a cold boot for each setup a number of times (e.g. 10), so that any possible outlier can be spotted/rejected. And maybe share results off list once we have a better understanding of what's going on. Does that make sense to you? I'll cover a particular topic right away though. Jim Quinlan (2023-04-19): > Second, you say that you used a different "CM4" from the one used in > the Bugzilla report -- what do you mean by that? Are you referring > to the CM4 module proper, whose only change was going from 4GB to 8GB, > or the IO board being used? My testing is done with a standard RPi > CM4 and standard RPi IO board. Before this patch series, the only way > this standard configuration can work for most hobbyist PCI cards (i.e. > floating CLKREQ# pin) is by using Raspian AND adding > "brcm,enable-l1ss" to the DT node. Regarding the IO Board, I'm using the official Compute Module 4 IO Board: https://www.raspberrypi.com/products/compute-module-4-io-board/ I've been using the very same IO Board for all my testing, and what I'm changing is the standard RPi CM4 plugged on it. > I'm guessing that you are using the configuration that you described > to me in a personal email: "[the] chip is embedded directly on the > modified PCB, as opposed to plugged into the PCIe slot on the official > CM4 IO Board". If true, you are testing on a configuration that (a) > is unique to you and your group and (b) must be doing something with > the CLKREQ# signal so that your "before" case does not panic. Is this > the case? That's definitely not the case. True, as mentioned in a personal mail, we've seen problems with a custom PCB, derived from the CM4 IO Board design, but of course there could be some faulty design at work there=E2=80=A6 So we've first researched whether= the same problem could be produced with consumer grade products, and once we've verified that, I opened #217276 on Bugzilla. Since Florian's testing seems overwhelmingly positive, and since I'm seeing definitive improvement with at least one CM4, maybe it would make sense not to block the patch series on the kernel panic I'm seeing with the other CM4, and track that particular issue via a separate bug? Cheers, --=20 Cyril Brulebois (kibi@debian.org) D-I release manager -- Release team member -- Freelance Consultant --3kfu6luykgorwo37 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmRAD3MACgkQ/5FK8MKz VSCfFw//Xgtk24Lz36LgywgbE/sUr33MfyGt97IY+kXL/ODVySpZ1vKIGol4Yv7g 5DuvpJuJTbJjfGEL+LLcw9nMk9Ea+s7X//EMM6PAonKyu34ozQ1itOzkSZ1oDQQA AElqaYCmmyfrH48/85okdcIAcGEwACpoUY5EuS8JLdXlRtF1GvdyHdN0WvZBO39V Lnv97ZtBixmePnW15OkolViaA8W8Oft1/7qaCfsa0V1+14IiGxqNU2m0vmvm0qsz 82iKWzxaZIKJqq6WAzsQwY1b3J/fwWTMp3jd8ccFIdsMFSQEyzmB8O2x/Ue2FwPQ RJCecXhWTGrr2gax56fZwkeq/ZLVDB6hYy1wvwOlkZesR2NJ1TrnBmL4R7NRIiCh vnU4qlhmNZ1/Th4k9DM2llZ7Yt9d6KZHudR4XZYAYBhIWLzji9LJheG+FXpd89My UBujmcT5FwLo1Tg3+79MSP9XCB29a5fB3axUXcR/IGbuuP+pj7v6pwOkMQTE+KO0 4u1UFwGzcKAT0Ffib6o7juOSJMWZZqH6SauZOLS+YwVAYbwKumi8GimK5Gm6BVOh /OH6Fdp+Q+ulS1VX1/Xv8UISJTOe6jt4TkHPk/WcDJct81m0oGuo5bYFpTGtllrq ahVxNYBmNcOsSdRYwPIjZ7hdJPFkelV3+F/54rK37NUc8diJ35Y= =pvP0 -----END PGP SIGNATURE----- --3kfu6luykgorwo37-- 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 E3478C6FD18 for ; Wed, 19 Apr 2023 15:58:58 +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=VLqwsUvF5OwX4nEZyHRrKIaODWrfCw9Y51J/s0Su1zk=; b=sspKCmaNaZkhKVfxy03ffVgZq5 Im5IzNW15F1rbnc9ebKxvK/cIyEZaBrlrnmlc9GbeXKNKRVqSvVD48Zx9V1049B9T9wpeIEgLIee5 jkkFVBkHVy2qpjTRdXB0Uc0o3iIAFrbSLkxsWKecSdNkYsvv5TY0z3J1kNJTZGLNEz+Me7fNccmx4 KAtz0Td6rqRR0/BBFg2OccBd7Fyda4x77OIVFt72AWWBLb32CGWUPdw9TXAywgrWvrqXrA3khPKE3 8nK1mh3wO9cBzvEYkMU0YuRC8rZgsrUUgS8DeWfqOvZ3/Xgc8wixbypsOP7MRySYAzeKnntqLNNZi GHqW9w6w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1ppAC7-005pOW-1G; Wed, 19 Apr 2023 15:58:07 +0000 Received: from stravinsky.debian.org ([2001:41b8:202:deb::311:108]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1ppAC4-005pNI-1X; Wed, 19 Apr 2023 15:58:06 +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=kDbJlrgL3sjXj3G+1OO7np5Xsz4+mKZQ6I14H0THhkc=; b=aXLiIj2Fq44PA3oRVyjSzdJsSl U78F+oLK669QslhXPSbUOrvkxKfFOQ+fkdZVr4U3xqjJnvh8L3pWM5GBiSnujq1b32CKGFqlmoqFv yWGUjlYOZqaup1qUCZVcYuEa5EpE5FnppaiLFquv92r619fdk/k75AZ0kgzc/ZQrMjOzC/9U/wdPZ rFxgRH5Wnv1/ROhWprkMP23aYcBh2l15TrJhZimWaSxRa/pcRZahbUxZcBZ4Sfnoceqbu2HHhekLM YGmC3WmS6nmL5P0t2eJWKElqtL4aHieYhpSo0M3Kn3hhkrQ9Z9QKo+6Z57B33a8v3fCO6RT3c8ran /SUeMPzA==; 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 1ppABl-005q5R-T2; Wed, 19 Apr 2023 15:57:47 +0000 Date: Wed, 19 Apr 2023 17:57:43 +0200 From: Cyril Brulebois To: Jim Quinlan Cc: Florian Fainelli , linux-pci@vger.kernel.org, Nicolas Saenz Julienne , Bjorn Helgaas , Lorenzo Pieralisi , Phil Elwell , bcm-kernel-feedback-list@broadcom.com, james.quinlan@broadcom.com, 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: <20230419155743.j7lwvgkhdxz2zkrk@mraw.org> Organization: Debian References: <20230411165919.23955-1-jim2101024@gmail.com> <20230411165919.23955-3-jim2101024@gmail.com> <20230413143935.pmbyjk2boxl3rwne@mraw.org> <20230413200646.ddgsoqgmaae343nl@mraw.org> <85a1cca1-f59b-6a0c-dee3-9d9ed5d6b6d1@gmail.com> <20230414161907.zfd2ibshfx4rz56j@mraw.org> MIME-Version: 1.0 In-Reply-To: X-Debian-User: kibi X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230419_085804_515979_55318076 X-CRM114-Status: GOOD ( 21.32 ) 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="===============7541448667679827951==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============7541448667679827951== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3kfu6luykgorwo37" Content-Disposition: inline --3kfu6luykgorwo37 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Jim, It might take a few days before getting back to you regarding the various questions you asked. To be on the safe side, I'll probably run a cold boot for each setup a number of times (e.g. 10), so that any possible outlier can be spotted/rejected. And maybe share results off list once we have a better understanding of what's going on. Does that make sense to you? I'll cover a particular topic right away though. Jim Quinlan (2023-04-19): > Second, you say that you used a different "CM4" from the one used in > the Bugzilla report -- what do you mean by that? Are you referring > to the CM4 module proper, whose only change was going from 4GB to 8GB, > or the IO board being used? My testing is done with a standard RPi > CM4 and standard RPi IO board. Before this patch series, the only way > this standard configuration can work for most hobbyist PCI cards (i.e. > floating CLKREQ# pin) is by using Raspian AND adding > "brcm,enable-l1ss" to the DT node. Regarding the IO Board, I'm using the official Compute Module 4 IO Board: https://www.raspberrypi.com/products/compute-module-4-io-board/ I've been using the very same IO Board for all my testing, and what I'm changing is the standard RPi CM4 plugged on it. > I'm guessing that you are using the configuration that you described > to me in a personal email: "[the] chip is embedded directly on the > modified PCB, as opposed to plugged into the PCIe slot on the official > CM4 IO Board". If true, you are testing on a configuration that (a) > is unique to you and your group and (b) must be doing something with > the CLKREQ# signal so that your "before" case does not panic. Is this > the case? That's definitely not the case. True, as mentioned in a personal mail, we've seen problems with a custom PCB, derived from the CM4 IO Board design, but of course there could be some faulty design at work there=E2=80=A6 So we've first researched whether= the same problem could be produced with consumer grade products, and once we've verified that, I opened #217276 on Bugzilla. Since Florian's testing seems overwhelmingly positive, and since I'm seeing definitive improvement with at least one CM4, maybe it would make sense not to block the patch series on the kernel panic I'm seeing with the other CM4, and track that particular issue via a separate bug? Cheers, --=20 Cyril Brulebois (kibi@debian.org) D-I release manager -- Release team member -- Freelance Consultant --3kfu6luykgorwo37 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmRAD3MACgkQ/5FK8MKz VSCfFw//Xgtk24Lz36LgywgbE/sUr33MfyGt97IY+kXL/ODVySpZ1vKIGol4Yv7g 5DuvpJuJTbJjfGEL+LLcw9nMk9Ea+s7X//EMM6PAonKyu34ozQ1itOzkSZ1oDQQA AElqaYCmmyfrH48/85okdcIAcGEwACpoUY5EuS8JLdXlRtF1GvdyHdN0WvZBO39V Lnv97ZtBixmePnW15OkolViaA8W8Oft1/7qaCfsa0V1+14IiGxqNU2m0vmvm0qsz 82iKWzxaZIKJqq6WAzsQwY1b3J/fwWTMp3jd8ccFIdsMFSQEyzmB8O2x/Ue2FwPQ RJCecXhWTGrr2gax56fZwkeq/ZLVDB6hYy1wvwOlkZesR2NJ1TrnBmL4R7NRIiCh vnU4qlhmNZ1/Th4k9DM2llZ7Yt9d6KZHudR4XZYAYBhIWLzji9LJheG+FXpd89My UBujmcT5FwLo1Tg3+79MSP9XCB29a5fB3axUXcR/IGbuuP+pj7v6pwOkMQTE+KO0 4u1UFwGzcKAT0Ffib6o7juOSJMWZZqH6SauZOLS+YwVAYbwKumi8GimK5Gm6BVOh /OH6Fdp+Q+ulS1VX1/Xv8UISJTOe6jt4TkHPk/WcDJct81m0oGuo5bYFpTGtllrq ahVxNYBmNcOsSdRYwPIjZ7hdJPFkelV3+F/54rK37NUc8diJ35Y= =pvP0 -----END PGP SIGNATURE----- --3kfu6luykgorwo37-- --===============7541448667679827951== 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 --===============7541448667679827951==--