drm-next update

[Rob Clark]

On Tue, Nov 20, 2012 at 11:53 AM, Ville Syrjälä
<ville.syrjala at 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 at 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