Re: arm gicv3 its command time out / patch
Warner Losh <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <CANCZdfqOgKNE52ENsGcUJp+NVCXJK77R6RAKGwCzG0kh=1QgXQ@mail.gmail.com> |
On Tue, Nov 25, 2025 at 10:19 PM Michal Meloun <[email protected]> wrote: > > > On 26.11.2025 5:10, Warner Losh wrote: > > Also, a minor nit in the patch: > > > > + /* Register this device as a interrupt controller */ > > > > should not have moved. Finding the xref doesn't register the interrupt > > controller, but > > > > sc->sc_pic = intr_pic_register(dev, xref); > > > > does and is the real start of the process. > > > > Anyway, I'm looking forward to learning more about this issue. > > > > Warner > > > > On Tue, Nov 25, 2025 at 7:33 PM Warner Losh <[email protected] > > <mailto:[email protected]>> wrote: > > > > What hardware does this fix booting on? What's the setup? The patch > > itself looks OK, but I need to know the environment it runs in to > > understand and evaluate it fully. Thanks! > > > > Warner > > > > On Tue, Nov 25, 2025 at 3:03 PM titus <[email protected] > > <mailto:[email protected]>> wrote: > > > > cubie kernel: its0: <ARM GIC Interrupt Translation Service> > > mem 0x3440000-0x345ffff on gic0 > > cubie kernel: its0: Timeout while waiting for CMD completion. > > > > patch (not ignoring dt dma-noncoherent flag) (adapted from linux > > kernel) > > > > I am preparing a fix for this. One issue is that ITS may sit on a > non-coherent bus. Another issue is that it can sit on a 32-bit bus, so > we must also limit the address range when allocating various > memory-mapped buffers and tables. > > Another issue is that the "dma-noncoherent" property was only added in > Linux 6.15. Therefore, we must also use another method to identify the > necessary quirk if we want to MFC this fix. > > Mainly Rockchip SoCs are affected. > Ah cool! Thanks for the update! Please add me to your review then! I'll be happy to help. Warner