[Intel-gfx] [PATCH 16/23] drm/i915: Program planes in bigjoiner mode.

Maarten Lankhorst maarten.lankhorst at linux.intel.com
Fri Sep 27 08:56:16 UTC 2019


Op 26-09-2019 om 21:11 schreef Ville Syrjälä:
> On Thu, Sep 26, 2019 at 07:09:22PM +0300, Ville Syrjälä wrote:
>> On Thu, Sep 26, 2019 at 05:50:05PM +0200, Maarten Lankhorst wrote:
>>> Op 26-09-2019 om 15:06 schreef Ville Syrjälä:
>>>> On Fri, Sep 20, 2019 at 01:42:28PM +0200, Maarten Lankhorst wrote:
>>>>> Now that we can program planes from the update_slave callback, and
>>>>> we have done all fb pinning correctly, it's time to program those
>>>>> planes as well.
>>>>>
>>>>> We use the update_slave callback as it allows us to use the
>>>>> separate states correctly.
>>>>>
>>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
>>>>> ---
>>>>>  .../gpu/drm/i915/display/intel_atomic_plane.c | 53 +++++++++++++++++++
>>>>>  .../gpu/drm/i915/display/intel_atomic_plane.h |  2 +
>>>>>  drivers/gpu/drm/i915/display/intel_display.c  |  4 +-
>>>>>  3 files changed, 57 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
>>>>> index cc088676f0a2..5db091e4ad6a 100644
>>>>> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
>>>>> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
>>>>> @@ -366,6 +366,59 @@ void skl_update_planes_on_crtc(struct intel_atomic_state *state,
>>>>>  	}
>>>>>  }
>>>>>  
>>>>> +void icl_update_bigjoiner_planes_on_crtc(struct intel_atomic_state *state,
>>>>> +					 struct intel_crtc *crtc)
>>>> This plane stuff is where things go very much off the rails IMO.
>>>> Planes should not have to know anything about bigjoiner. They should
>>>> just have their appropriate hw state and blindly bash it into the
>>>> hardware.
>>> We already need this for planar slave/master, what's the issue exactly?
>> That already is too fragile. I don't want this spreading all over
>> the driver and coupling everything to the bigjoiner logic.
>>
>> Here's a crude idea how I think we might avoid this:
>> git://github.com/vsyrjala/linux.git uapi_hw_state_split
>>
>> But I didn't dare boot it yet...
> It took a handful extra fixes to get that to boot. But now I at least
> get a picture on the screen instead of oopses.
>
> Fixes pushed to the same branch.
>
> Looks like still something going wrong with the cursor ioctl though.
>
I've done a uapi-hw split in my series, is that ok with you?

I will do a similar split for planes.



More information about the Intel-gfx mailing list