drm-next update

drm-next update

[Dave Airlie]

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!

Dave.

Re: drm-next update

[Thomas Hellstrom]

On 11/20/2012 07:39 AM, Dave Airlie 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!
>
It appears they conflicted with the TTM sync_obj_arg removal patches.
Please apply

[PATCH -next 0/5] drm/ttm: Get rid of a number of atomic 
read-modify-write ops addons
(This is the diff for the latest version of Get rid of a number of 
atomic read-modify-write ops)

[PATCH -next 0/3] vmwgfx stuff for -next rebased
(This is the patches 6/8 that didn't apply previously)

[PATCH -next] drm/ttm: Optimize vm locking using kref_get_unless_zero
(Small patch that gets rid of a write lock around buffer object 
unreferences)

Thanks,
Thomas

Re: drm-next update

[Ville Syrjälä]

On Tue, Nov 20, 2012 at 04:39:39PM +1000, Dave Airlie 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).

I don't the atomic stuff is quite ready for merging yet. However my
code is more or less feature complete now. I have implemented everything
I planned to originally, apart from adding more properties for various
things. And as I mentioned before, Weston is now running quite nicely
on top of my kernel branch.

What's still missing is some refactoring, and possibly some fixes. And
hardly anyone has commented on it, so please everyone have a look and
let me know what you think. Maybe I need to start a blog to get people
interested...

Oh and there's now that 8byte get_user() issue that needs to be sorted
out on x86-32.

As far as the i915 specific stuff goes, I need to get someone to look
at the GPU sync stuff. And then there's the bigger question of whether
we could do the whole atomic page flip thing via the ring, but that's
not something that we need to worry about today.

-- 
Ville Syrjälä
Intel OTC

Re: drm-next update

[Rob Clark]

On Tue, Nov 20, 2012 at 7:40 AM, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
> On Tue, Nov 20, 2012 at 04:39:39PM +1000, Dave Airlie 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).
>
> I don't the atomic stuff is quite ready for merging yet. However my
> code is more or less feature complete now. I have implemented everything
> I planned to originally, apart from adding more properties for various
> things. And as I mentioned before, Weston is now running quite nicely
> on top of my kernel branch.
>
> What's still missing is some refactoring, and possibly some fixes. And
> hardly anyone has commented on it, so please everyone have a look and
> let me know what you think. Maybe I need to start a blog to get people
> interested...

it would be nice to at least pull in the object and signed property
type stuff from my branch, since that is effecting userspace facing
API..

All the plane/crtc/etc state object stuff doesn't effect abi so could
come later, I suppose.  It does touch a lot of drivers even if they
aren't converted to 'atomic', but OTOH I think it makes things much
cleaner and easier to 'atomicify' a driver without duplicating so much
stuff in each driver.  So long term I still think it is the right
thing.  But not sure how much more time I'll spend on it in the near
term.

BR,
-R

> Oh and there's now that 8byte get_user() issue that needs to be sorted
> out on x86-32.
>
> As far as the i915 specific stuff goes, I need to get someone to look
> at the GPU sync stuff. And then there's the bigger question of whether
> we could do the whole atomic page flip thing via the ring, but that's
> not something that we need to worry about today.
>
> --
> Ville Syrjälä
> Intel OTC
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm-next update

[Ville Syrjälä]

On Tue, Nov 20, 2012 at 11:27:20AM -0600, Rob Clark wrote:
> On Tue, Nov 20, 2012 at 7:40 AM, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> > On Tue, Nov 20, 2012 at 04:39:39PM +1000, Dave Airlie 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).
> >
> > I don't the atomic stuff is quite ready for merging yet. However my
> > code is more or less feature complete now. I have implemented everything
> > I planned to originally, apart from adding more properties for various
> > things. And as I mentioned before, Weston is now running quite nicely
> > on top of my kernel branch.
> >
> > What's still missing is some refactoring, and possibly some fixes. And
> > hardly anyone has commented on it, so please everyone have a look and
> > let me know what you think. Maybe I need to start a blog to get people
> > interested...
> 
> it would be nice to at least pull in the object and signed property
> type stuff from my branch, since that is effecting userspace facing
> API..

Yeah, I still need to go over your code properly. What I remember from
the last time I looked at it was that the signed property type is fine
by me, the dynamic flag I don't really agree with, since you probably
can't set it for most things anyway, and the state stuff is touching a
lot of places at the same time, which is somehting I've been trying to
avoid at this stage.

> All the plane/crtc/etc state object stuff doesn't effect abi so could
> come later, I suppose.  It does touch a lot of drivers even if they
> aren't converted to 'atomic', but OTOH I think it makes things much
> cleaner and easier to 'atomicify' a driver without duplicating so much
> stuff in each driver.  So long term I still think it is the right
> thing.  But not sure how much more time I'll spend on it in the near
> term.

I don't really want to push a huge change to all code paths at the same
time. The current setcrtc/pageflip code is known to work (sort of at
least), so if something were to regress we'd possibly have to back out
the whole thing. So I'd like to get the atomic stuff in as a separate
thing first.

Once it's in we can start to fix the state handling, and also start
calling into the atomic code from the legacy code paths.

Another detail we nee to figure out is the actual properties that
we're using. I personally don't like the crtc.SRC_X and crtc.SRC_Y
properties that my code has for example. They don't behave like the
plane properties with the same names, so maybe we should use different
names for them. Well, idelly we wouldn't even have them, but moving all
scanout duties over to planes is another thing I really don't want to
tie into the atomic stuff at this point in time. I suppose we can't
deprecate any properties easily, so we need to make sure we can all
live with the ones we add initially.

-- 
Ville Syrjälä
Intel OTC

Re: drm-next update

[Rob Clark]

On Tue, Nov 20, 2012 at 11:53 AM, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
> On Tue, Nov 20, 2012 at 11:27:20AM -0600, Rob Clark wrote:
>> On Tue, Nov 20, 2012 at 7:40 AM, Ville Syrjälä
>> <ville.syrjala@linux.intel.com> wrote:
>> > On Tue, Nov 20, 2012 at 04:39:39PM +1000, Dave Airlie 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).
>> >
>> > I don't the atomic stuff is quite ready for merging yet. However my
>> > code is more or less feature complete now. I have implemented everything
>> > I planned to originally, apart from adding more properties for various
>> > things. And as I mentioned before, Weston is now running quite nicely
>> > on top of my kernel branch.
>> >
>> > What's still missing is some refactoring, and possibly some fixes. And
>> > hardly anyone has commented on it, so please everyone have a look and
>> > let me know what you think. Maybe I need to start a blog to get people
>> > interested...
>>
>> it would be nice to at least pull in the object and signed property
>> type stuff from my branch, since that is effecting userspace facing
>> API..
>
> Yeah, I still need to go over your code properly. What I remember from
> the last time I looked at it was that the signed property type is fine
> by me, the dynamic flag I don't really agree with, since you probably
> can't set it for most things anyway, and the state stuff is touching a
> lot of places at the same time, which is somehting I've been trying to
> avoid at this stage.

The dynamic flag is a bit of an optimization.  It is really only
intended to be set for properties that can always be changed without
risk of fail.  There is no obligation for a driver to set it, since it
should be an opt-in sort of thing for the driver.  Which also means
that it is safe to add at a later stage, so I don't mind leaving it
for later.  But object and signed property types would be good to have
from the beginning.

>> All the plane/crtc/etc state object stuff doesn't effect abi so could
>> come later, I suppose.  It does touch a lot of drivers even if they
>> aren't converted to 'atomic', but OTOH I think it makes things much
>> cleaner and easier to 'atomicify' a driver without duplicating so much
>> stuff in each driver.  So long term I still think it is the right
>> thing.  But not sure how much more time I'll spend on it in the near
>> term.
>
> I don't really want to push a huge change to all code paths at the same
> time. The current setcrtc/pageflip code is known to work (sort of at
> least), so if something were to regress we'd possibly have to back out
> the whole thing. So I'd like to get the atomic stuff in as a separate
> thing first.

true, although most of the changes for drivers with the state stuff,
before they migrate to atomic, are just braindead search/replace
stuff, so not much risk of breaking things.  Just a pain to merge
through a bunch of different driver trees, that is all.

> Once it's in we can start to fix the state handling, and also start
> calling into the atomic code from the legacy code paths.

yeah, handling legacy ioctls with "atomicified" drivers is an issue..
mainly with the setplane ioctl because we never really defined if it
was async or not or what the meaning is if it is called and the driver
is still pending a flip.  The good news is there aren't many users of
that API yet.  And if we pass the flags to the atomic fxns to indicate
if the update should be async or not, we could just not pass the async
flag in the legacy setplane path.  So I think this is doable.. but
maybe a bit more risky.

We could always handle conversion of legacy paths to atomic as a later
patch, if that helps reduce the risk.

> Another detail we nee to figure out is the actual properties that
> we're using. I personally don't like the crtc.SRC_X and crtc.SRC_Y
> properties that my code has for example. They don't behave like the
> plane properties with the same names, so maybe we should use different
> names for them. Well, idelly we wouldn't even have them, but moving all
> scanout duties over to planes is another thing I really don't want to
> tie into the atomic stuff at this point in time. I suppose we can't
> deprecate any properties easily, so we need to make sure we can all
> live with the ones we add initially.

hmm, maybe it is a good idea to give different property names for crtc
src x/y.  I guess it isn't completely different from plane SRC_X/Y
except there is no scaling and CRTC_X/Y is always 0,0..

OTOH, separating plane and crtc would be a generally nice thing to do
and maybe avoids some hacks.  So I wouldn't object to trying to do
that first before converting stuff to properties/atomic, or at least
as part of the properties/atomic changes.  I think it should not be a
big deal for existing drivers to create a dummy plane that can only be
bound to a single crtc.  And it would mean any userspace that supports
the atomic ioctl also understands hw where scanout engine is decoupled
from crtc.  I hadn't thought about it much yet, but decoupling the
scanout engine from crtc as part of the atomic ioctl avoids an
intermediate generation of userspace clients of the API that we have
to support forever.

BR,
-R

> --
> Ville Syrjälä
> Intel OTC

Re: drm-next update

[Daniel Vetter]

On Tue, Nov 20, 2012 at 7:39 AM, Dave Airlie <airlied@gmail.com> wrote:
> Daniel: I've pulled -next from you, I'm hoping that is all you have
> for this merge window!

Yeah, winding down, no big stuff pending, just a few small
bits&pieces. If we'll see an -rc7 release, I'll run another manual QA
cycle, otherwise I'll just send you a -fixes pull with it somewhen
next week.

> I've also merge the polling rework, I'll have to spend a bit of time
> testing it I suppose now.

I've noticed that you didn't merge "drm: don't unnecessarily enable
the polling work" (note there's a v2 follow-up). Anything wrong with
it or just overlooked?

Also, there's my small series to integrate some of the helper in-line
kerneldoc into Laurent DRM DocBook, starting with "drm/doc: Helpers
are not a Midlayer!". So of the patches depended upon the dp helper
refactor, but now that's merged they should apply.

Another thing is the clock_monotonic timestamp stuff for
pageflips/vblanks. I'll poke Imre about this again, but I guess we'll
postpone that for 3.9. Otherwise I don't see anything missing.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: drm-next update

[Dave Airlie]

On Wed, Nov 21, 2012 at 8:28 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Nov 20, 2012 at 7:39 AM, Dave Airlie <airlied@gmail.com> wrote:
>> Daniel: I've pulled -next from you, I'm hoping that is all you have
>> for this merge window!
>
> Yeah, winding down, no big stuff pending, just a few small
> bits&pieces. If we'll see an -rc7 release, I'll run another manual QA
> cycle, otherwise I'll just send you a -fixes pull with it somewhen
> next week.
>
>> I've also merge the polling rework, I'll have to spend a bit of time
>> testing it I suppose now.
>
> I've noticed that you didn't merge "drm: don't unnecessarily enable
> the polling work" (note there's a v2 follow-up). Anything wrong with
> it or just overlooked?
>

I thought I did, a4f968d8e50cb7810e08ebb9bf4c8f2b769fdac7

I applied the wrong one and rebased it out, then got the right one later.

> Also, there's my small series to integrate some of the helper in-line
> kerneldoc into Laurent DRM DocBook, starting with "drm/doc: Helpers
> are not a Midlayer!". So of the patches depended upon the dp helper
> refactor, but now that's merged they should apply.

Okay I'll pick them up.

>
> Another thing is the clock_monotonic timestamp stuff for
> pageflips/vblanks. I'll poke Imre about this again, but I guess we'll
> postpone that for 3.9. Otherwise I don't see anything missing.

I merged this, at least the core stuff. It just seemed like it might
go somewhere if it was in the tree :-)

Dave.

Re: drm-next update

[Daniel Vetter]

On Wed, Nov 21, 2012 at 12:11 PM, Dave Airlie <airlied@gmail.com> wrote:
> On Wed, Nov 21, 2012 at 8:28 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Tue, Nov 20, 2012 at 7:39 AM, Dave Airlie <airlied@gmail.com> wrote:
>>> Daniel: I've pulled -next from you, I'm hoping that is all you have
>>> for this merge window!
>>
>> Yeah, winding down, no big stuff pending, just a few small
>> bits&pieces. If we'll see an -rc7 release, I'll run another manual QA
>> cycle, otherwise I'll just send you a -fixes pull with it somewhen
>> next week.
>>
>>> I've also merge the polling rework, I'll have to spend a bit of time
>>> testing it I suppose now.
>>
>> I've noticed that you didn't merge "drm: don't unnecessarily enable
>> the polling work" (note there's a v2 follow-up). Anything wrong with
>> it or just overlooked?
>>
>
> I thought I did, a4f968d8e50cb7810e08ebb9bf4c8f2b769fdac7
>
> I applied the wrong one and rebased it out, then got the right one later.

Yeah, missed that one.

>> Also, there's my small series to integrate some of the helper in-line
>> kerneldoc into Laurent DRM DocBook, starting with "drm/doc: Helpers
>> are not a Midlayer!". So of the patches depended upon the dp helper
>> refactor, but now that's merged they should apply.
>
> Okay I'll pick them up.
>
>>
>> Another thing is the clock_monotonic timestamp stuff for
>> pageflips/vblanks. I'll poke Imre about this again, but I guess we'll
>> postpone that for 3.9. Otherwise I don't see anything missing.
>
> I merged this, at least the core stuff. It just seemed like it might
> go somewhere if it was in the tree :-)

Yeah, missed those too. I'll go and harp about updating the i-g-t
testcases now ;-)

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: drm-next update

[Rob Clark]

On Tue, Nov 20, 2012 at 12:39 AM, Dave Airlie <airlied@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.

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@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm-next update

[Alex Deucher]

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

Re: drm-next update

[Alex Deucher]

On Tue, Nov 20, 2012 at 1:39 AM, Dave Airlie <airlied@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.

We have some stuff internally to push out, but with internal schedules
and the US holiday this week, I'm not sure when I'll be able to get
that into a -next tree.  I'll keep you updated.

Alex

Re: drm-next update

[Rob Clark]

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