On Thu, Nov 27, 2014 at 9:04 PM, Dan Carpenter
wrote:
> On Thu, Nov 27, 2014 at 06:11:30PM +0100, Daniel Vetter wrote:
>> btw not sure whether checker should just look through WARN_ON, we have
>> lots of places where we've historically screwed up and added a WARN_ON +
>> early return to make
On Thu, Nov 27, 2014 at 06:11:30PM +0100, Daniel Vetter wrote:
> btw not sure whether checker should just look through WARN_ON, we have
> lots of places where we've historically screwed up and added a WARN_ON +
> early return to make sure we'll in the future somewhat recover. This is
> really
On Thu, Nov 27, 2014 at 10:55:02AM +0100, Daniel Vetter wrote:
> On Thu, Nov 27, 2014 at 09:41:13AM +0300, Dan Carpenter wrote:
> > Hello Rob Clark,
> >
> > The patch 1ed2f34b4cc0: "drm/atomic: track bitmask of planes attached
> > to crtc" from Nov 21, 2014,
On Thu, Nov 27, 2014 at 06:54:03PM +0300, Dan Carpenter wrote:
> On Thu, Nov 27, 2014 at 10:55:02AM +0100, Daniel Vetter wrote:
> > On Thu, Nov 27, 2014 at 09:41:13AM +0300, Dan Carpenter wrote:
> > > Hello Rob Clark,
> > >
> > > The patch 1ed2f34b4cc0:
On Thu, Nov 27, 2014 at 09:41:13AM +0300, Dan Carpenter wrote:
> Hello Rob Clark,
>
> The patch 1ed2f34b4cc0: "drm/atomic: track bitmask of planes attached
> to crtc" from Nov 21, 2014, leads to the following static checker
> warning:
>
> d
Hello Rob Clark,
The patch 1ed2f34b4cc0: "drm/atomic: track bitmask of planes attached
to crtc" from Nov 21, 2014, leads to the following static checker
warning:
drivers/gpu/drm/drm_atomic.c:368 drm_atomic_set_crtc_for_plane()
error: 'plane_state' dereferencing possib
Chasing plane->state->crtc of planes that are *not* part of the same
atomic update is racy, making it incredibly awkward (or impossible) to
do something simple like iterate over all planes and figure out which
ones are attached to a crtc.
Solve this by adding a bitmask of currently attached
On Fri, Nov 21, 2014 at 03:28:31PM -0500, Rob Clark wrote:
> Chasing plane->state->crtc of planes that are *not* part of the same
> atomic update is racy, making it incredibly awkward (or impossible) to
> do something simple like iterate over all planes and figure out which
> ones are attached to
Chasing plane->state->crtc of planes that are *not* part of the same
atomic update is racy, making it incredibly awkward (or impossible) to
do something simple like iterate over all planes and figure out which
ones are attached to a crtc.
Solve this by adding a bitmask of currently attached
