[Intel-gfx] [PATCH 10/11] drm/i915: Add 180 degree primary plane rotation support

[Daniel Vetter]

On Thu, Jun 19, 2014 at 01:39:17PM +0530, Jindal, Sonika wrote:
> 
> 
> On 6/19/2014 1:25 PM, Daniel Vetter wrote:
> >On Thu, Jun 19, 2014 at 9:52 AM, Jindal, Sonika <sonika.jindal at intel.com> wrote:
> >>>No, this really should be done in
> >>>drm_fb_helper_restore_fbdev_mode_unlocked in drm_fb_helper.c. Well, in the
> >>>restore_fbdev_mode function in there. Once that's done and once omap is
> >>>also using the generic rotation properties (I think it is already) we can
> >>>remove the rotation handling code from omap's last_close. Please also
> >>>throw a (compile-tested-only) patch on top for that so that Rob Clark can
> >>>pick it up.
> >>>-Daniel
> >>>
> >>Ok, I will add it. So should I add a function pointer say reset_properties
> >>in crtc, which will be called from restore_fbdev_mode?
> >
> >No, I think it should directly reset the relevant properties. This
> >might mean that we have to move the rotation property pointer to
> >struct drm_plane so that restore_fbdev_mode can get at it. Or we wrap
> >up a helper for internal property setting purposes which bails out if
> >the property isn't attached to the relevant object.
> So, I will move rotation_property to drm_plane and for each plane where this
> property is attached, will call drm_object_property_set_value.
> Please correct me if I am wrong.

Yeah, that sounds like a plan.
-Daniel

> >
> >This way it will automatically work for all drivers that support
> >rotation. With a callback we still have the same problem that each
> >driver needs to do their own magic, which means they'll get it wrong.
> >Letting helpers take care of such details gives us a much stronger
> >platfrom with drm drivers.
> >-Daniel
> >

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch