[Intel-gfx] [PATCH v4 08/10] drm/i915/dsb: Enable gamma lut programming using DSB.

[Sharma, Shashank]

On 9/3/2019 1:29 PM, Jani Nikula wrote:
> On Tue, 03 Sep 2019, "Sharma, Shashank" <shashank.sharma at intel.com> wrote:
>>> -----Original Message-----
>>> From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On Behalf Of Jani
>>> Nikula
>>> Sent: Friday, August 30, 2019 7:02 PM
>>> To: Manna, Animesh <animesh.manna at intel.com>; intel-gfx at lists.freedesktop.org
>>> Subject: Re: [Intel-gfx] [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.

Sure, it makes sense to simplify this in steps.

- Shashank

> BR,
> Jani.
>
>