Re: arm gicv3 its command time out / patch

From: Warner Losh <imp_at_bsdimp.com>
Date: Wed, 26 Nov 2025 05:21:59 UTC
On Tue, Nov 25, 2025 at 10:19 PM Michal Meloun <mmel@freebsd.org> 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 <imp@bsdimp.com
> > <mailto:imp@bsdimp.com>> 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 <titus@edc.ro
> >     <mailto:titus@edc.ro>> 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