On Tue, 03 Sep 2019, "Sharma, Shashank" <shashank.sharma@xxxxxxxxx> wrote: >> -----Original Message----- >> From: Intel-gfx [mailto:intel-gfx-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Jani >> Nikula >> Sent: Friday, August 30, 2019 7:02 PM >> To: Manna, Animesh <animesh.manna@xxxxxxxxx>; intel-gfx@xxxxxxxxxxxxxxxxxxxxx >> Subject: Re: [PATCH v4 08/10] drm/i915/dsb: Enable gamma lut >> programming using DSB. >> You have tons of functions here that will never have a DSB engine, it >> makes no sense to convert all of them to use the DSB. >> > Jani, > I was thinking even among the 3 engines available per pipe, would it > make more sense to keep them reserve on the basis of user ? like DSB0 > for all pipe operations, DSB1 for all plane, and DSB2 for all encoder > related stuff. We can create a DSB user (like we have for scaler) and > index these engines based on that. Do you think so ? And perhaps use some DSB engines to write immediately, some to write at vblank. However, all of this should be postponed to follow-up work. For now, if we use intel_dsb_write and friends with the dsb parameter as local variable passed in, converting to use a different engine is a metter of changing the preceding intel_dsb_get call to fetch the dsb pointer. Considering the progress of a patch series, the focus should be on getting patches merged. Getting the minimum sebsible enabling of DSB merged should be the focus here. The further iteration should happen in-tree, not out-of-tree. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
