On 13/12/15 22:39, Laurent Pinchart wrote:
>> This one moves the function, so it's pretty hard to see what actually
>> was changed.
>
> It's unfortunately needed if we want to avoid forward declarations. I could
> split the patch in two, but given the size of the function and the extent of
> t
Hi Tomi,
On Wednesday 09 December 2015 14:43:19 Tomi Valkeinen wrote:
> On 05/12/15 00:27, Laurent Pinchart wrote:
> > The plane reset handler frees the plane state and allocates a new
> > default state, but when doing so attempt to free the plane state using
> > the base plane state pointer inste
On 05/12/15 00:27, Laurent Pinchart wrote:
> The plane reset handler frees the plane state and allocates a new
> default state, but when doing so attempt to free the plane state using
> the base plane state pointer instead of casting it to the
> driver-specific state object that has been allocate
The plane reset handler frees the plane state and allocates a new
default state, but when doing so attempt to free the plane state using
the base plane state pointer instead of casting it to the
driver-specific state object that has been allocated. Fix it by using
the omap_plane_atomic_destroy_stat
