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@xxxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx