drm-next update

[Alex Deucher]

On Wed, Nov 21, 2012 at 11:23 AM, Rob Clark <robdclark at gmail.com> wrote:
> On Tue, Nov 20, 2012 at 12:39 AM, Dave Airlie <airlied at gmail.com> 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.

>
> 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