On Fri, 26 Sep 2025, Ville Syrjälä <[email protected]> wrote: > On Wed, Sep 24, 2025 at 07:43:29PM +0300, Jani Nikula wrote: >> >> Jani Nikula (11): >> drm/{i915,xe}/stolen: rename i915_stolen_fb to intel_stolen_node >> drm/xe/stolen: rename fb to node in stolen compat header >> drm/xe/stolen: convert compat stolen macros to inline functions >> drm/xe/stolen: switch from BUG_ON() to WARN_ON() in compat >> drm/i915/stolen: convert intel_stolen_node into a real struct of its >> own >> drm/xe/stolen: convert compat static inlines to proper functions >> drm/{i915,xe}/stolen: make struct intel_stolen_node opaque >> drm/{i915,xe}/stolen: add device pointer to struct intel_stolen_node >> drm/{i915,xe}/stolen: use the stored i915/xe device pointer >> drm/{i915,xe}/stolen: convert stolen interface to struct drm_device >> drm/xe/stolen: use the same types as i915 interface > > Looks fine by me. Series is > Reviewed-by: Ville Syrjälä <[email protected]>
Thanks for the review, pushed to din. > Side note: I have branch somewhere that replaces the raw > drm_mm_node FBC stuff with a real i915_gem_object. I used > that as a way to easily expose the CFB and LLB as files in > debugfs so that I could observe/modify the actual CFB contents. > I should look into making that official to help future FBC > debugging. With the abstraction layer I shouldn't even need > to touch the FBC code itself anymore... Yay! BR, Jani. -- Jani Nikula, Intel
