On Wed, Nov 21, 2012 at 11:05 AM, Alex Deucher <alexdeucher@xxxxxxxxx> wrote: > On Wed, Nov 21, 2012 at 11:23 AM, Rob Clark <robdclark@xxxxxxxxx> wrote: >> 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. > > I'm not sure if its worth the effort to try and push all the > individual patches through the various driver trees it it's all part > of one larger patch set. Seems like it would be easier to just push > the whole set together. I'm ok with either approach.. I'm just rebasing the i915 for danvet, but others can go directly via drm tree if Dave prefers. BR, -R >> >> 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 > > I'm fine with the radeon parts of this just going in via your tree or > drm directly unless you want me to pick it up specifically. > >> >> 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 > > > Same with this one. > > Alex _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
