On Tue, Nov 20, 2012 at 12:39 AM, Dave Airlie <airlied@xxxxxxxxx> wrote: > Okay just pushed out a bunch of -next queued stuff, > > I've been stuck on another project for a couple of weeks and haven't > really being paying enough attention to -next, so this is a heads up, > if someone has something big they want merged this window and I > haven't seen it yet or merged it yet, you should probably mention it > in a reply to this mail with a summary of where you think its at. > (e.g. atomic nuclear modesetting flipping). > > personal messages follow: > > Thomas: > I merged some of the vmware patches I saw, I got to > [6/8] drm/vmwgfx: Refactor resource management > it didn't apply, it wasn't trivial, so you need to resend the 6/7/8 on > top of this tree, or point me to what I missed that makes it all > magically work! > > Alex/Ben: -next trees if you have anything interesting. > > Daniel: I've pulled -next from you, I'm hoping that is all you have > for this merge window! > I've also merge the polling rework, I'll have to spend a bit of time > testing it I suppose now. > > Imre: merged the monotonic timestamps, please confirm it was okay! > > Thierry: congrats I merged tegra, thanks for the hard work! > > Maarten: merged some of the TTM patches, you might want to send me a > summary of any other TH reviewed that I haven't picked up on yet. > > Anyone else that sent stuff and can't find it and it needs to be in > here, do let me know! I've got a couple patchsets that I suppose need to come in through a few different trees. Dave, maybe for drivers where you don't get pull req's from other trees (udl, i2c, not sure about shmob, imx, or vmwgfx) these could be merged directly via drm tree. For intel/nouveau/radeon/etc, it would be nice if the respective tree maintainers would pull in the patch for their driver. First series, removing legacy drm_connector property fxns and converting everything to use the newer object property fxns. The driver patches have no dependency on drm core. The last patch on drm core cannot be merged until the driver patches are merged. So maybe leave that last one for 3.9 and try and get all the driver patches in 3.8? Let me know if I need to rebase or update any other new code to get rid of legacy drm_connector property fxn usage. bffa1b5 drm/i2c: drm_connector_property -> drm_object_property f921b8a drm/vmwgfx: drm_connector_property -> drm_object_property 696cfcf drm/udl: drm_connector_property -> drm_object_property 6745d89 drm/shmob: drm_connector_property -> drm_object_property f4f1593 drm/radeon: drm_connector_property -> drm_object_property 52673d8 drm/nouveau: drm_connector_property -> drm_object_property 7830a92 drm/gma500: drm_connector_property -> drm_object_property 493663d drm/i915: drm_connector_property -> drm_object_property a4aac9a drm: remove legacy drm_connector_property fxns Second series, the drm_send_vblank_event() helper. The drm core patch which adds this fxn is in drm-next now, so when various driver trees have rebased on latest drm-next they can merge their corresponding driver patch to use the new helper: 8669e97 drm/imx: use drm_send_vblank_event() helper 1b85506 drm/shmob: use drm_send_vblank_event() helper 8efe90e drm/exynos: use drm_send_vblank_event() helper 9438973 drm/radeon: use drm_send_vblank_event() helper 49e6038 drm/nouveau: use drm_send_vblank_event() helper 6af9075 drm/i915: use drm_send_vblank_event() helper BR, -R > Dave. > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
