Den 11.01.2019 02.06, skrev David Lechner:
> On 1/9/19 11:49 AM, Noralf Trønnes wrote:
>> This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty
>> handler. All flushing will now happen in the pipe functions.
>>
>> Also enable the damage plane property for all except repaper which can
>> only do full updates.
>>
>> ili9225:
>> This change made ili9225_init() equal to mipi_dbi_init() so use it.
>>
>> Cc: David Lechner <david@xxxxxxxxxxxxxx>
>> Cc: Eric Anholt <eric@xxxxxxxxxx>
>> Signed-off-by: Noralf Trønnes <noralf@xxxxxxxxxxx>
>> ---
>
> ...
>
>> +static void ili9225_pipe_update(struct drm_simple_display_pipe *pipe,
>> + struct drm_plane_state *old_state)
>> +{
>> + struct drm_plane_state *state = pipe->plane.state;
>> + struct drm_crtc *crtc = &pipe->crtc;
>> + struct drm_rect rect;
>> +
>> + if (drm_atomic_helper_damage_merged(old_state, state, &rect))
>> + ili9225_fb_dirty(state->fb, &rect);
>> +
>> + if (crtc->state->event) {
>> + spin_lock_irq(&crtc->dev->event_lock);
>> + drm_crtc_send_vblank_event(crtc, crtc->state->event);
>> + spin_unlock_irq(&crtc->dev->event_lock);
>> + crtc->state->event = NULL;
>> + }
>> +}
>
> It looks like this function body is repeated 4 times with the only
> difference being the dirty function. Perhaps a helper function is
> called for?
I agree, this is used in several other drivers too. The problem is that
this is magic code to me so I wouldn't even know what to call the
function and certainly not what to put in the docs. So I left it out.
And the drm_crtc_arm_vblank_event() function used elsewhere adds even
more mystery to it all.
>
> Also, I was going to test out this series the displays that I have,
> but I guess I will wait until it is easier to apply the patches.
I will send a version 2 when Maxime has backmerged -rc1.
Noralf.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
