All of lore.kernel.org
 help / color / mirror / Atom feed
* Linux Plumbers Android+Graphics microconf summary
@ 2013-10-10 20:07 John Stultz
  2013-10-10 21:09 ` Daniel Vetter
  0 siblings, 1 reply; 3+ messages in thread
From: John Stultz @ 2013-10-10 20:07 UTC (permalink / raw)
  To: dri-devel, Android Kernel Team; +Cc: Laurent Pinchart

Hey Everyone,

I just wanted to thank once again, all the folks who were able to attend
and participate at the Android+Graphics discussion at Plumbers. For
those who could not attend, A free-link to my summary on LWN is here:
        http://lwn.net/SubscriberLink/569704/a20145dcfbaf70f1/

Hopefully there aren't too many inaccuracies in my summary.


I also wanted to start a thread to try to continue some of the
discussions that went on, and try to make sure we have a sense of the
next steps, now that folks have had some time to think about what all
was said.


Sync:

* Maarten has already started looking at integrating the Android sync
interface on top of his dmabuf-fences.
    http://www.spinics.net/lists/dri-devel/msg46180.html

* Hopefully he and Erik can continue to collaborate to better understand
each others concerns, and we'll be able to get the Android explicit sync
interface upstreamed and out of staging, and integrated into the various
DRM apis needed.



ADF:

* Rob has reposted his atomic modesetting patches, which helps adress
part of some of the issues Greg tried to resolve with ADF, although
there still is the delta vs full update issue.
    http://www.spinics.net/lists/dri-devel/msg46413.html

* Also didn't see any details in the atomic modesetting patches about if
or how explicit syncpoints might be used w/ it.  

    Rob: is that something you have any plans for at this point?  Or are
you looking to someone to try to integrate sync points with your patches?

    Greg: Don't know if you saw the thread above, but having your
feedback and thoughts on Rob's patches would be valuable here.

* The need for KMS helpers to reudce boilerplate seemed to be widely
agreed upon, but I'm not sure if anyone is actually planning to put any
effort.


Other KMS extentions:

* I'll let Laurent pipe in with any other next steps he has.


ION:
* Hoping to merge ion into staging after Colin's fixes to make it less
arm32 specific land in AOSP

    Colin: Those patches seem stalled in Gerrit. Are you planning a next
iteration of the patchset?

* I'm in talks w/ Sumit about making a first pass on using the ion heaps
implementation to back the dmabuf exporter allocation logic.


Any other thoughts, questions or plans here?

thanks
-john

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Linux Plumbers Android+Graphics microconf summary
  2013-10-10 20:07 Linux Plumbers Android+Graphics microconf summary John Stultz
@ 2013-10-10 21:09 ` Daniel Vetter
  2013-10-10 21:58   ` Rob Clark
  0 siblings, 1 reply; 3+ messages in thread
From: Daniel Vetter @ 2013-10-10 21:09 UTC (permalink / raw)
  To: John Stultz; +Cc: Android Kernel Team, Laurent Pinchart, dri-devel

On Thu, Oct 10, 2013 at 01:07:58PM -0700, John Stultz wrote:
> ADF:
> 
> * Rob has reposted his atomic modesetting patches, which helps adress
> part of some of the issues Greg tried to resolve with ADF, although
> there still is the delta vs full update issue.
>     http://www.spinics.net/lists/dri-devel/msg46413.html

I've read up your excellent lwn write-up and tbh I don't understand why
this is an issue - userspace can always opt to emit the full state if it
wants to. And drm already keeps all the properties around somewhere (afaik
at least) so I don't think drivers have to keep track of that much stuff.

So a simple "just write the entire hw state" model should be doable with
not that much work.

> * The need for KMS helpers to reudce boilerplate seemed to be widely
> agreed upon, but I'm not sure if anyone is actually planning to put any
> effort.

Imo this is simply ongoing stuff done on a as-needed basis. Personally I
have some plans to extract more helpers for handling the dp aux
transactions and sink detection.

I have a bit the impression that part of this due to the helper code in
drm_crtc_helper.c which has a lot of driver callbacks and is written with
the usual bread of hw found on desktop gpus in mind. I guess for a lot of
hardware this is simply the wrong abstraction level and interfacing a bit
higher up (e.g. at the level of drm_crtc_helper_set_mode) could be much
more appropriate.

And of course there's always the option of just rolling your own
infrastructure like i915.ko now does.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Linux Plumbers Android+Graphics microconf summary
  2013-10-10 21:09 ` Daniel Vetter
@ 2013-10-10 21:58   ` Rob Clark
  0 siblings, 0 replies; 3+ messages in thread
From: Rob Clark @ 2013-10-10 21:58 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: Android Kernel Team, Laurent Pinchart, dri-devel

On Thu, Oct 10, 2013 at 5:09 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> * Rob has reposted his atomic modesetting patches, which helps adress
>> part of some of the issues Greg tried to resolve with ADF, although
>> there still is the delta vs full update issue.
>>     http://www.spinics.net/lists/dri-devel/msg46413.html
>
> I've read up your excellent lwn write-up and tbh I don't understand why
> this is an issue - userspace can always opt to emit the full state if it
> wants to. And drm already keeps all the properties around somewhere (afaik
> at least) so I don't think drivers have to keep track of that much stuff.

it isn't actually an issue..

Or rather, it would simplify the kernel part to only support the "full
state update" model.. but in a post-x11 linux userspace world, that
isn't really an option for us, since we are moving away from hw
specfic userspace component talking to KMS and "full state" includes
things which are hw specific.

But if you support delta-update then you can support a userspace which
either does full updates or delta updates.  The direction I'm going w/
atomic ioctl... well, it is not as simple as ADF but most of the hard
work is done by the atomic helpers rather than each driver.

BR,
-R

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-10-10 21:58 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-10-10 20:07 Linux Plumbers Android+Graphics microconf summary John Stultz
2013-10-10 21:09 ` Daniel Vetter
2013-10-10 21:58   ` Rob Clark

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.