On Sun, 20 Sept 2026 at 06:13, John Hubbard <[email protected]> wrote: > > On 9/19/26 8:03 AM, Alexandre Courbot wrote: > > On Fri Sep 18, 2026 at 12:38 PM JST, Dave Airlie wrote: > >> On Wed, 9 Sept 2026 at 14:25, Eliot Courtney <[email protected]> wrote: > >>> > >>> From: Joel Fernandes <[email protected]> > >>> > >>> Add the BAR1 user interface for CPU access to GPU virtual memory through > >>> the BAR1 aperture. > >>> > >>> Signed-off-by: Joel Fernandes <[email protected]> > >>> [ecourtney: map BAR1 in NovaCore, borrow it in Gpu and BarUser, no Devres] > >>> [ecourtney: update for the VramAddress raw API and gsp_resources chipset] > >>> [ecourtney: drop the owned GpuMm, pass it mutably through map and release] > >>> Signed-off-by: Eliot Courtney <[email protected]> > >>> --- > >> > >> BAR 1 and 2 need to be optionally detected and used. At least on SPARK > >> there is only BAR0. > >> > >> I've been playing with John's branch on spark and had to rework this > >> code to make BAR 1 optional. > > > > Thanks Dave - indeed we also hit an issue on a device where the FB > > console was enabled (?), which preventing BAR1 from being used. > > > > That's different: another device driver was using the GPU. People > should Kconfig their system to avoid having two device drivers > trying to claim the same hardware.
At some point nova-core needs to call the remove_conflicting interface to make sure we kick off the overlapping drivers properly. > > Once Nova get a bit further along, it will be a non-issue too, > because Nova can drive either an fbdev, or whatever the modern > alternative to that is. > > > > I know Eliot has a bunch of follow-ups in the pipe, Eliot can we make > > sure to dynamically detect and enable BAR1? Also I'm asking for this now as it it might be easier to make that sort of design decision earlier, rather than trying to revisit it later. Dave.
