On Sun, Jun 2, 2024, 3:37 PM Colin Percival <cperc...@tarsnap.com> wrote:
> On 6/2/24 14:15, Jessica Clarke wrote: > > On 2 Jun 2024, at 22:01, Colin Percival <cperc...@tarsnap.com> wrote: > >> On 6/2/24 13:43, Jessica Clarke wrote: > >>> fu740_pci_dw: Fix PERST delay and keep asserted for rest of reset > sequence > >>> DELAY takes microseconds not milliseconds, so 100 was too > low. Moreover, > >>> when enabling hw.pci.clear_pcib, PCI emeration would still stop > at one > >>> of the first bridges, but by asserting PERST for the rest of the > reset > >>> sequence that appears to be reliably addressed. > >> > >> Does this need to be a DELAY as opposed to something asynchronous? We > try to > >> avoid lengthy DELAYs in the boot process. > > > > It’s in the middle of device_attach, so you’d need to break it up into > > two stages. I don’t know if we have a good way of doing that for > > delays; I’ve seen other glue code drivers do things like this, but > > there may well be a better way, and if so I’m all ears. > > I don't think there's any good mechanism for doing that, unfortunately. > Part > of the problem is that our device probing scheme is designed around the > idea > that by the time you return from device_attach, you know if the device has > successfully attached; if you discover that the device is broken at a later > time it's too late to assign the unit number to a different device. > This is false. We assign unit in probe, and once assigned you don't want to reassign it. I remember talking to Warner about this a while back in the context of nvme, > but the problem of "the spec says we have to wait a long time and we don't > want to do that serially for every disk" was resolved by our driver > learning > to be opportunistic and ask the disks if they were ready yet instead of > simply > waiting the time stipulated by the spec. > If there's no status register to read, you can't do much. And in an SoC there's only going to be one. So between yhe two, i don't see much benefit to be had. And even if we could do this wait asynchronously, there is nothing else to do in parallel. Maybe something to consider when someone decides to write newnewbus. ;-) > Parallel discovery is something we've talked about, but there's a number of logistical issues to sort out first. Warner > Though given > > you won’t have working PCI (so no USB nor NVMe) until this is done > > there’s probably not much more you can do during boot whilst you wait, > > so it may not be worth pursuing. Also, given the performance of the SoC > > in question, 100ms isn’t something you’d be close to noticing... > > Fair enough, I wasn't sure what sort of hardware this was. Sounds like > we're > fine here; it just caught my eye so I thought I'd ask. > > -- > Colin Percival > FreeBSD Release Engineering Lead & EC2 platform maintainer > Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid >
