[PATCH v2 0/4] drm/exynos, intel: fix locking for flip/vbl event list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2012/11/8 Rob Clark <rob.clark at linaro.org>

> On Wed, Nov 7, 2012 at 10:25 AM, Inki Dae <inki.dae at samsung.com> wrote:
> >
> >
> > 2012/11/7 Imre Deak <imre.deak at intel.com>
> >>
> >> On Wed, 2012-11-07 at 18:31 +0900, Inki Dae wrote:
> >> > 2012/11/2 Imre Deak <imre.deak at intel.com>
> >> >         The patchset adds the missing event_lock when accessing the
> >> >         vblank_event_list in drm_vblank_off() and as preparation for
> >> >         this
> >> >         also fixes a few other issues in the exynos driver.
> >> >         This is also a dependency for Rob Clark's
> >> >         drm_send_vblank_event()
> >> >         rework as that would trigger a warning for the unhold
> >> >         event_lock without
> >> >         this changeset.
> >> >         The exynos changes are only compile tested, the rest is tested
> >> >         on an
> >> >         Intel IVB machine on top of drm-intel-nightly +
> >> >         drm_send_vblank_event()
> >> >         rework, with i-g-t/flip_test.
> >> > Hi Imre,
> >> > Works fine. But we should wait for Rob's patch set to be merged to
> >> > -next, and this may be rebased on top of latest Rob's patch set again.
> >>
> >> Ok, thanks for checking this. I assume then that this patchset will get
> >> merged through your tree.
> >>
> >> I think Rob's patchset depends on this, so ideally this should go first.
> >> Otherwise the i915 driver would trigger the WARN in his patchset due to
> >> the unheld event_lock.
> >
> >
> > Ok, but I merge it first, shouldn't Rob's patch set be rebased? Anyway
> this
> > is minor issue so I could resolve it. And it seems like that your patch
> set
> > has no dependency of Rob's. I mean that your patch set worked fine
> without
> > Rob's.
>
> I think there should be no hard dependency on my patch set.. the only
> connection is that my patchset without this patch will start showing
> the WARN_ON() traces
>
>
Right, My concern was just merge conflict.


> BR,
> -R
>
> > Thanks,
> > Inki Dae
> >
> >>
> >>
> >> --Imre
> >>
> >>
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> >
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20121108/c5442df9/attachment-0001.html>


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux