[Intel-gfx] [PATCH] drm/plane-helper: Don't fake-implement primary plane disabling

2014-04-15 Thread Daniel Vetter
After thinking about this topic a bit more I've reached the conclusion that implementing this doesn't make sense: - The locking is all wrong: set_config(NULL) will also unlink encoders and connectors, but those links are protected with the mode_config mutex. In the -disable_plane callback we

Re: [Intel-gfx] [PATCH] drm/plane-helper: Don't fake-implement primary plane disabling

2014-04-15 Thread Ville Syrjälä
On Tue, Apr 15, 2014 at 10:02:43AM +0200, Daniel Vetter wrote: After thinking about this topic a bit more I've reached the conclusion that implementing this doesn't make sense: - The locking is all wrong: set_config(NULL) will also unlink encoders and connectors, but those links are

Re: [Intel-gfx] [PATCH] drm/plane-helper: Don't fake-implement primary plane disabling

2014-04-15 Thread Daniel Vetter
On Tue, Apr 15, 2014 at 12:22 PM, Ville Syrjälä ville.syrj...@linux.intel.com wrote: Although I'm not sure EINVAL is the best choice here. Maybe ENOSYS? We return -EINVAL everywhere else where we don't support a giving config, e.g. lack of dpll, unsupported plane scaling, pixel format mismatch

Re: [Intel-gfx] [PATCH] drm/plane-helper: Don't fake-implement primary plane disabling

2014-04-15 Thread Matt Roper
On Tue, Apr 15, 2014 at 10:02:43AM +0200, Daniel Vetter wrote: After thinking about this topic a bit more I've reached the conclusion that implementing this doesn't make sense: - The locking is all wrong: set_config(NULL) will also unlink encoders and connectors, but those links are