drm-next update

[Rob Clark]

On Wed, Nov 21, 2012 at 11:05 AM, Alex Deucher <alexdeucher at gmail.com> wrote:
> 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.

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