[Intel-gfx] [PATCH] drm/i915/dsb: DSB code refactoring

[Ville Syrjälä]

On Wed, Sep 27, 2023 at 07:04:53PM +0300, Jani Nikula wrote:
> On Wed, 27 Sep 2023, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
> > On Wed, Sep 27, 2023 at 05:50:10PM +0300, Jani Nikula wrote:
> >> On Wed, 27 Sep 2023, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
> >> > On Tue, Sep 26, 2023 at 12:34:35PM +0300, Jani Nikula wrote:
> >> >> On Tue, 26 Sep 2023, "Manna, Animesh" <animesh.manna at intel.com> wrote:
> >> >> >> -----Original Message-----
> >> >> >> From: Jani Nikula <jani.nikula at linux.intel.com>
> >> >> >> Sent: Monday, September 25, 2023 6:00 PM
> >> >> >> To: Manna, Animesh <animesh.manna at intel.com>; intel-
> >> >> >> gfx at lists.freedesktop.org
> >> >> >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/dsb: DSB code refactoring
> >> >> >> 
> >> >> >> On Sat, 23 Sep 2023, Animesh Manna <animesh.manna at intel.com> wrote:
> >> >> >> > Refactor DSB implementation to be compatible with Xe driver.
> >> >> >> 
> >> >> >> Sad trombone.
> >> >> >> 
> >> >> >> struct intel_dsb should remain an opaque type. I put effort into hiding its
> >> >> >> definition, so its guts wouldn't be accessed nilly-willy all over the place. If it's
> >> >> >> not hidden, it just will get accessed.
> >> >> >
> >> >> > Hi Jani,
> >> >> >
> >> >> > Xe driver need access to intel_dsb structure, so I can create a new header file intel_dsb_ops.h and keep intel_dsb structure in it. Is it ok?
> >> >> 
> >> >> I just think you need to find a different abstraction level that doesn't
> >> >> involve exposing struct intel_dsb.
> >> >
> >> > I hate the fact that we seem to be adding these ad-hoc wrappers all
> >> > over the place. Someone should just fix xe to give us the same API as
> >> > i915, or a single wrapper should do whatever conversion is needed.
> >> 
> >> I think one of the problems is that i915 doesn't really give us a proper
> >> API either, but requires us to fiddle with the objects' guts, and thus
> >> have access to the struct definitions. In i915, with the include
> >> hierarchies, that effectively means including absolutely
> >> everything. Can't have that in xe.
> >
> > obj+vma is a pretty reasonable API IMO. And we're not doing anything
> > weird with their guts IIRC.
> 
> Okay, I'll take your word for it.
> 
> > But apparently xe decided to not give us
> > that, and instead of adding a single wrapper to bridge the gap we
> > now have several different ad-hoc wrappers for whatever reason.
> 
> For this specific thing? Do we really have several? Or do you mean all
> the different things that bridge the gap between xe and i915-display?

I'm just referring to the all the things where we need to give
a piece of memory to the hardware. So far that seems to be normal
fb scanout, fbdev, dsb, fbc, and apparently hdcp also needs
GPU accessible memory. And flip queue will be another case somewhere
down the line.

-- 
Ville Syrjälä
Intel