From: Jim Quinlan <jim2101024@gmail.com> To: Florian Fainelli <f.fainelli@gmail.com> Cc: "Cyril Brulebois" <kibi@debian.org>, linux-pci@vger.kernel.org, "Nicolas Saenz Julienne" <nsaenz@kernel.org>, "Bjorn Helgaas" <bhelgaas@google.com>, "Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>, "Phil Elwell" <phil@raspberrypi.com>, bcm-kernel-feedback-list@broadcom.com, james.quinlan@broadcom.com, "Lorenzo Pieralisi" <lpieralisi@kernel.org>, "Krzysztof Wilczyński" <kw@linux.com>, "Rob Herring" <robh@kernel.org>, "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" <linux-rpi-kernel@lists.infradead.org>, "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org>, "open list" <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v2 2/3] PCI: brcmstb: CLKREQ# accomodations of downstream device Date: Fri, 14 Apr 2023 09:31:18 -0400 [thread overview] Message-ID: <CANCKTBv+jxYRsXXVguwuYrBZFdCO7=-RQPCOrR7pTCcoLuE4aA@mail.gmail.com> (raw) In-Reply-To: <85a1cca1-f59b-6a0c-dee3-9d9ed5d6b6d1@gmail.com> On Fri, Apr 14, 2023 at 8:27 AM Florian Fainelli <f.fainelli@gmail.com> wrote: > > > > On 4/14/2023 5:14 AM, Jim Quinlan wrote: > > On Thu, Apr 13, 2023 at 4:06 PM Cyril Brulebois <kibi@debian.org> wrote: > >> > >> Hi Jim, > >> > >> Jim Quinlan <jim2101024@gmail.com> (2023-04-13): > >>> Can you provide (a) the full boot log prior to applying the patch > >>> series and (b) full boot log after applying the series, using an > >>> IDENTICAL setup. If it fails on both then it has little to do with my > >>> patch series. > >> > >> Just to be clear, the issue I reported was with: > >> - Raspberry Pi Compute Module 4 (Rev 1.1, 4G RAM, 32G storage) > >> - Raspberry Pi Compute Module 4 IO Board > >> - SupaHub PCIe-to-multiple-USB adapter, reference PCE6U1C-R02, VER 006S > >> > >> This was my minimal reproducer for the kernel panic at boot-up, which > >> goes away with either v1 or v2. When I realized I didn't actually check > >> whether the SupaHub board was working correctly, I plugged 2 devices to > >> obtain this setup: > >> - Raspberry Pi Compute Module 4 (Rev 1.1, 4G RAM, 32G storage) > >> - Raspberry Pi Compute Module 4 IO Board > >> - SupaHub PCIe-to-multiple-USB adapter, reference PCE6U1C-R02, VER 006S > >> - Kingston DataTraveler G4 32GB on USB-A port #1 of the SupaHub board. > >> - Logitech K120 keyboard on USB-A port #2 of the SupaHub board. > >> > >> It turns out that this particular revision of the SupaHub board isn't > >> supported by xhci_hcd directly (failing to probe with error -110) and > >> one needs to enable CONFIG_USB_XHCI_PCI_RENESAS=m and also ship its > >> accompanying firmware (/lib/firmware/renesas_usb_fw.mem). With this > >> updated kernel config, I'm able to use the keyboard and to read data > >> from the memory stick without problems (70 MB/s). > >> > >>> In my last series your testing somehow conflated the effect of an > >>> unrelated MMC interrupt issue so please be precise. > >> > >> I wish things would be simpler and didn't involve combinatorics, let > >> alone other bugs/regressions at times, but I'm really trying my best to > >> navigate and report issues and test patches when I can spare some time… > > > > Hi Cyril, > > > > I want to encourage you and others doing testing and bug reporting: > > everyone wins when a bug or issue is reported, fixed, and tested. > > I'm just asking that when you have negative results, that you provide > > information on the "before" and "after" test results of > > the patch series, and run both on the same test environment. > > Cyril, based upon the table and logs you provided whereby you have used > the following: > > - Raspberry Pi Compute Module 4 (Rev 1.0, 8G RAM, 32G storage) > - Raspberry Pi Compute Module 4 IO Board > - SupaHub PCIe-to-multiple-USB adapter, reference PCE6U1C-R02, VER 006S > > in the before/unpatched case we have a PCIe link down and in the > after/patched we have a PCIe link up but a kernel panic. Neither are > great nor resulting in a fully functional PCIe device. The data do not make sense to me. My new code is executed AFTER pcie link up/down determination. Both test results should have the same link status -- either "link up" or "link down". If the system is wishy-washy, i.e. it has link-up in 5/10 boots, then we need to repeat the experiment to compare the "link up" cases only. Or discount the test completely If the system is not wishy-washy, then something has been changed between the "before" and "after" tests. > > Looking at: > > https://www.amazon.co.uk/SupaHub-Express-BandWidth-Capable-Expanding/dp/B092ZQWG5B > > it would appear that it can accept an external power supply, do you have > one connected to that USB expansion card by any chance? Are you able to > boot the kernel before/after if you disconnect any USB peripheral? > > This looks like a broader electrical problem than the scope of this > patch, though it would be neat if we could find a combination that > works. At least with Jim's patch we have a PCIe link with > uni-directional CLKREQ# so we could try a variety of things. > > Does that SupaHub board plugged to the CM4 1.0 system work fine in the > Raspberry Pi kernel tree? > -- > Florian
WARNING: multiple messages have this Message-ID (diff)
From: Jim Quinlan <jim2101024@gmail.com> To: Florian Fainelli <f.fainelli@gmail.com> Cc: "Cyril Brulebois" <kibi@debian.org>, linux-pci@vger.kernel.org, "Nicolas Saenz Julienne" <nsaenz@kernel.org>, "Bjorn Helgaas" <bhelgaas@google.com>, "Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>, "Phil Elwell" <phil@raspberrypi.com>, bcm-kernel-feedback-list@broadcom.com, james.quinlan@broadcom.com, "Lorenzo Pieralisi" <lpieralisi@kernel.org>, "Krzysztof Wilczyński" <kw@linux.com>, "Rob Herring" <robh@kernel.org>, "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" <linux-rpi-kernel@lists.infradead.org>, "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org>, "open list" <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v2 2/3] PCI: brcmstb: CLKREQ# accomodations of downstream device Date: Fri, 14 Apr 2023 09:31:18 -0400 [thread overview] Message-ID: <CANCKTBv+jxYRsXXVguwuYrBZFdCO7=-RQPCOrR7pTCcoLuE4aA@mail.gmail.com> (raw) In-Reply-To: <85a1cca1-f59b-6a0c-dee3-9d9ed5d6b6d1@gmail.com> On Fri, Apr 14, 2023 at 8:27 AM Florian Fainelli <f.fainelli@gmail.com> wrote: > > > > On 4/14/2023 5:14 AM, Jim Quinlan wrote: > > On Thu, Apr 13, 2023 at 4:06 PM Cyril Brulebois <kibi@debian.org> wrote: > >> > >> Hi Jim, > >> > >> Jim Quinlan <jim2101024@gmail.com> (2023-04-13): > >>> Can you provide (a) the full boot log prior to applying the patch > >>> series and (b) full boot log after applying the series, using an > >>> IDENTICAL setup. If it fails on both then it has little to do with my > >>> patch series. > >> > >> Just to be clear, the issue I reported was with: > >> - Raspberry Pi Compute Module 4 (Rev 1.1, 4G RAM, 32G storage) > >> - Raspberry Pi Compute Module 4 IO Board > >> - SupaHub PCIe-to-multiple-USB adapter, reference PCE6U1C-R02, VER 006S > >> > >> This was my minimal reproducer for the kernel panic at boot-up, which > >> goes away with either v1 or v2. When I realized I didn't actually check > >> whether the SupaHub board was working correctly, I plugged 2 devices to > >> obtain this setup: > >> - Raspberry Pi Compute Module 4 (Rev 1.1, 4G RAM, 32G storage) > >> - Raspberry Pi Compute Module 4 IO Board > >> - SupaHub PCIe-to-multiple-USB adapter, reference PCE6U1C-R02, VER 006S > >> - Kingston DataTraveler G4 32GB on USB-A port #1 of the SupaHub board. > >> - Logitech K120 keyboard on USB-A port #2 of the SupaHub board. > >> > >> It turns out that this particular revision of the SupaHub board isn't > >> supported by xhci_hcd directly (failing to probe with error -110) and > >> one needs to enable CONFIG_USB_XHCI_PCI_RENESAS=m and also ship its > >> accompanying firmware (/lib/firmware/renesas_usb_fw.mem). With this > >> updated kernel config, I'm able to use the keyboard and to read data > >> from the memory stick without problems (70 MB/s). > >> > >>> In my last series your testing somehow conflated the effect of an > >>> unrelated MMC interrupt issue so please be precise. > >> > >> I wish things would be simpler and didn't involve combinatorics, let > >> alone other bugs/regressions at times, but I'm really trying my best to > >> navigate and report issues and test patches when I can spare some time… > > > > Hi Cyril, > > > > I want to encourage you and others doing testing and bug reporting: > > everyone wins when a bug or issue is reported, fixed, and tested. > > I'm just asking that when you have negative results, that you provide > > information on the "before" and "after" test results of > > the patch series, and run both on the same test environment. > > Cyril, based upon the table and logs you provided whereby you have used > the following: > > - Raspberry Pi Compute Module 4 (Rev 1.0, 8G RAM, 32G storage) > - Raspberry Pi Compute Module 4 IO Board > - SupaHub PCIe-to-multiple-USB adapter, reference PCE6U1C-R02, VER 006S > > in the before/unpatched case we have a PCIe link down and in the > after/patched we have a PCIe link up but a kernel panic. Neither are > great nor resulting in a fully functional PCIe device. The data do not make sense to me. My new code is executed AFTER pcie link up/down determination. Both test results should have the same link status -- either "link up" or "link down". If the system is wishy-washy, i.e. it has link-up in 5/10 boots, then we need to repeat the experiment to compare the "link up" cases only. Or discount the test completely If the system is not wishy-washy, then something has been changed between the "before" and "after" tests. > > Looking at: > > https://www.amazon.co.uk/SupaHub-Express-BandWidth-Capable-Expanding/dp/B092ZQWG5B > > it would appear that it can accept an external power supply, do you have > one connected to that USB expansion card by any chance? Are you able to > boot the kernel before/after if you disconnect any USB peripheral? > > This looks like a broader electrical problem than the scope of this > patch, though it would be neat if we could find a combination that > works. At least with Jim's patch we have a PCIe link with > uni-directional CLKREQ# so we could try a variety of things. > > Does that SupaHub board plugged to the CM4 1.0 system work fine in the > Raspberry Pi kernel tree? > -- > Florian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-04-14 13:31 UTC|newest] Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-04-11 16:59 [PATCH v2 0/3] PCI: brcmstb: CLKREQ# accomodations of downstream device Jim Quinlan 2023-04-11 16:59 ` Jim Quinlan 2023-04-11 16:59 ` [PATCH v2 1/3] dt-bindings: PCI: brcmstb: Add two optional props Jim Quinlan 2023-04-11 16:59 ` Jim Quinlan 2023-04-12 8:09 ` Krzysztof Kozlowski 2023-04-12 8:09 ` Krzysztof Kozlowski 2023-04-12 11:49 ` Florian Fainelli 2023-04-12 11:49 ` Florian Fainelli 2023-04-12 11:56 ` Krzysztof Kozlowski 2023-04-12 11:56 ` Krzysztof Kozlowski 2023-04-12 14:14 ` Jim Quinlan 2023-04-12 14:14 ` Jim Quinlan 2023-04-12 15:37 ` Rob Herring 2023-04-12 15:37 ` Rob Herring 2023-04-12 16:12 ` Florian Fainelli 2023-04-12 16:12 ` Florian Fainelli 2023-04-18 18:35 ` Rob Herring 2023-04-18 18:35 ` Rob Herring 2023-04-21 19:07 ` Konstantin Ryabitsev 2023-04-21 19:07 ` Konstantin Ryabitsev 2023-04-14 20:14 ` Bjorn Helgaas 2023-04-14 20:14 ` Bjorn Helgaas 2023-04-11 16:59 ` [PATCH v2 2/3] PCI: brcmstb: CLKREQ# accomodations of downstream device Jim Quinlan 2023-04-11 16:59 ` Jim Quinlan 2023-04-13 14:39 ` Cyril Brulebois 2023-04-13 14:39 ` Cyril Brulebois 2023-04-13 14:57 ` Jim Quinlan 2023-04-13 14:57 ` Jim Quinlan 2023-04-13 20:06 ` Cyril Brulebois 2023-04-14 12:14 ` Jim Quinlan 2023-04-14 12:14 ` Jim Quinlan 2023-04-14 12:27 ` Florian Fainelli 2023-04-14 12:27 ` Florian Fainelli 2023-04-14 13:31 ` Jim Quinlan [this message] 2023-04-14 13:31 ` Jim Quinlan 2023-04-14 16:19 ` Cyril Brulebois 2023-04-14 16:19 ` Cyril Brulebois 2023-04-19 14:23 ` Jim Quinlan 2023-04-19 14:23 ` Jim Quinlan 2023-04-19 15:57 ` Cyril Brulebois 2023-04-19 15:57 ` Cyril Brulebois 2023-04-13 14:58 ` Florian Fainelli 2023-04-13 14:58 ` Florian Fainelli 2023-04-14 20:27 ` Bjorn Helgaas 2023-04-14 20:27 ` Bjorn Helgaas 2023-04-14 20:33 ` Florian Fainelli 2023-04-14 20:33 ` Florian Fainelli 2023-04-17 21:41 ` Bjorn Helgaas 2023-04-17 21:41 ` Bjorn Helgaas 2023-04-14 23:14 ` Jim Quinlan 2023-04-14 23:14 ` Jim Quinlan 2023-04-11 16:59 ` [PATCH v2 3/3] PCI: brcmstb: Set PCIe transaction completion timeout Jim Quinlan 2023-04-11 16:59 ` Jim Quinlan 2023-04-12 0:26 ` Cyril Brulebois 2023-04-12 0:26 ` Cyril Brulebois 2023-04-13 18:40 ` [PATCH v2 0/3] PCI: brcmstb: CLKREQ# accomodations of downstream device Florian Fainelli 2023-04-13 18:40 ` Florian Fainelli
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CANCKTBv+jxYRsXXVguwuYrBZFdCO7=-RQPCOrR7pTCcoLuE4aA@mail.gmail.com' \ --to=jim2101024@gmail.com \ --cc=bcm-kernel-feedback-list@broadcom.com \ --cc=bhelgaas@google.com \ --cc=f.fainelli@gmail.com \ --cc=james.quinlan@broadcom.com \ --cc=kibi@debian.org \ --cc=kw@linux.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=linux-rpi-kernel@lists.infradead.org \ --cc=lorenzo.pieralisi@arm.com \ --cc=lpieralisi@kernel.org \ --cc=nsaenz@kernel.org \ --cc=phil@raspberrypi.com \ --cc=robh@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.