Re: [PATCH v2 2/3] PCI: brcmstb: CLKREQ# accomodations of downstream device

[Cyril Brulebois]

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 <jim2101024@xxxxxxxxx> (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… 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,
-- 
Cyril Brulebois (kibi@xxxxxxxxxx)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature