On Mon, 2013-10-14 at 17:39 +0300, Ville Syrjälä wrote:
> On Mon, Oct 14, 2013 at 04:59:13PM +0300, Imre Deak wrote:
> > On Mon, 2013-09-30 at 17:44 +0300, ville.syrjala@xxxxxxxxxxxxxxx wrote:
> > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> > >
> > > Sprite planes support 180 degree rotation. The lower layers are now in
> > > place, so hook in the standard rotation property to expose the feature
> > > to the users.
> > >
> > > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > drivers/gpu/drm/i915/intel_sprite.c | 42 ++++++++++++++++++++++++++++++++++++-
> > > 2 files changed, 42 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > > index 08e96a8..48d4d5f 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -1356,6 +1356,7 @@ typedef struct drm_i915_private {
> > >
> > > struct drm_property *broadcast_rgb_property;
> > > struct drm_property *force_audio_property;
> > > + struct drm_property *rotation_property;
> > >
> > > bool hw_contexts_disabled;
> > > uint32_t hw_context_size;
> > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
> > > index 028a979..49f8238 100644
> > > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > > @@ -1033,6 +1033,30 @@ out_unlock:
> > > return ret;
> > > }
> > >
> > > +static int intel_plane_set_property(struct drm_plane *plane,
> > > + struct drm_property *prop,
> > > + uint64_t val)
> > > +{
> > > + struct drm_i915_private *dev_priv = plane->dev->dev_private;
> > > + struct intel_plane *intel_plane = to_intel_plane(plane);
> > > + uint64_t old_val;
> > > + int ret = -ENOENT;
> > > +
> > > + if (prop == dev_priv->rotation_property) {
> > > + /* exactly one rotation angle please */
> > > + if (hweight32(val & 0xf) != 1)
> > > + return -EINVAL;
> > > +
> > > + old_val = intel_plane->rotation;
> > > + intel_plane->rotation = val;
> > > + ret = intel_plane_restore(plane);
> > > + if (ret)
> > > + intel_plane->rotation = old_val;
> > > + }
> > > +
> > > + return ret;
> > > +}
> > > +
> > > int intel_plane_restore(struct drm_plane *plane)
> > > {
> > > struct intel_plane *intel_plane = to_intel_plane(plane);
> > > @@ -1059,6 +1083,7 @@ static const struct drm_plane_funcs intel_plane_funcs = {
> > > .update_plane = intel_update_plane,
> > > .disable_plane = intel_disable_plane,
> > > .destroy = intel_destroy_plane,
> > > + .set_property = intel_plane_set_property,
> > > };
> > >
> > > static uint32_t ilk_plane_formats[] = {
> > > @@ -1095,6 +1120,7 @@ static uint32_t vlv_plane_formats[] = {
> > > int
> > > intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane)
> > > {
> > > + struct drm_i915_private *dev_priv = dev->dev_private;
> > > struct intel_plane *intel_plane;
> > > unsigned long possible_crtcs;
> > > const uint32_t *plane_formats;
> > > @@ -1168,8 +1194,22 @@ intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane)
> > > &intel_plane_funcs,
> > > plane_formats, num_plane_formats,
> > > false);
> > > - if (ret)
> > > + if (ret) {
> > > kfree(intel_plane);
> > > + goto out;
> > > + }
> > > +
> > > + if (!dev_priv->rotation_property)
> > > + dev_priv->rotation_property =
> > > + drm_mode_create_rotation_property(dev,
> > > + BIT(DRM_ROTATE_0) |
> > > + BIT(DRM_ROTATE_180));
> > > +
> > > + if (dev_priv->rotation_property)
> > > + drm_object_attach_property(&intel_plane->base.base,
> > > + dev_priv->rotation_property,
> > > + intel_plane->rotation);
> >
> > drm_mode_create_rotation_property() can fail silently, I think we should
> > handle it.
>
> I figured I'd just move it to intel_modeset_init() but turns out we
> don't really handle errors there either. Frankly this looks like
> another rathole. Seeing as we already ignore property creation errors
> in other places (in a way that could oops even), I'm just going to
> run away before the urge to fix it all takes over.
Ok, since properties are already unreliable in this sense, I'm fine with
leaving this as-is for now. The series looks ok, so:
Reviewed-by: Imre Deak <imre.deak@xxxxxxxxx>
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
