* dumb BOs and prime @ 2015-12-04 17:49 Rob Herring 2015-12-04 18:07 ` Daniel Stone 2015-12-04 18:21 ` Martin Peres 0 siblings, 2 replies; 9+ messages in thread From: Rob Herring @ 2015-12-04 17:49 UTC (permalink / raw) To: dri-devel; +Cc: Benjamin Gaignard I'm working on getting Android working with DRM drivers. ATM, I'm using virtio-gpu as the driver and trying to get just KMS side working without rendering. I have it working with stock AOSP and the emulated fb with a few additions to the virtio-gpu driver[1]. Now I'm trying to get things working with native KMS using drm_gralloc and drm_hwcomposer (now in AOSP). I've hit one problem though which I'm not sure how to solve without hacking around it. Is prime allowed on dumb BOs? AIUI, dumb buffer allocation is not allowed on render nodes and drmPrimeHandleToFD is not allowed on card0, so I'm stuck. I could open both nodes, but then I want the case of no render node to work. After some searching, I thought it was a matter of needing to do drmAuthMagic, but then found that is considered obsolete[2]. Rob [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git android-4.4 [2] http://www.x.org/wiki/Events/XDC2013/XDC2013DavidHerrmannDRMSecurity/slides.pdf _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dumb BOs and prime 2015-12-04 17:49 dumb BOs and prime Rob Herring @ 2015-12-04 18:07 ` Daniel Stone 2015-12-04 18:21 ` Martin Peres 1 sibling, 0 replies; 9+ messages in thread From: Daniel Stone @ 2015-12-04 18:07 UTC (permalink / raw) To: Rob Herring; +Cc: Benjamin Gaignard, dri-devel Hi Rob, On 4 December 2015 at 17:49, Rob Herring <robh@kernel.org> wrote: > I'm working on getting Android working with DRM drivers. ATM, I'm > using virtio-gpu as the driver and trying to get just KMS side working > without rendering. I have it working with stock AOSP and the emulated > fb with a few additions to the virtio-gpu driver[1]. Now I'm trying to > get things working with native KMS using drm_gralloc and > drm_hwcomposer (now in AOSP). I've hit one problem though which I'm > not sure how to solve without hacking around it. > > Is prime allowed on dumb BOs? AIUI, dumb buffer allocation is not > allowed on render nodes and drmPrimeHandleToFD is not allowed on > card0, so I'm stuck. I could open both nodes, but then I want the case > of no render node to work. After some searching, I thought it was a > matter of needing to do drmAuthMagic, but then found that is > considered obsolete[2]. drmPrimeHandleToFD definitely is allowed on card0; does the driver set the DRIVER_PRIME cap, and have a prime_handle_to_fd hook? Cheers, Daniel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dumb BOs and prime 2015-12-04 17:49 dumb BOs and prime Rob Herring 2015-12-04 18:07 ` Daniel Stone @ 2015-12-04 18:21 ` Martin Peres 2015-12-04 18:40 ` Benjamin Gaignard 1 sibling, 1 reply; 9+ messages in thread From: Martin Peres @ 2015-12-04 18:21 UTC (permalink / raw) To: Rob Herring, dri-devel; +Cc: Benjamin Gaignard On 04/12/15 19:49, Rob Herring wrote: > I'm working on getting Android working with DRM drivers. ATM, I'm > using virtio-gpu as the driver and trying to get just KMS side working > without rendering. I have it working with stock AOSP and the emulated > fb with a few additions to the virtio-gpu driver[1]. Now I'm trying to > get things working with native KMS using drm_gralloc and > drm_hwcomposer (now in AOSP). I've hit one problem though which I'm > not sure how to solve without hacking around it. > > Is prime allowed on dumb BOs? AIUI, dumb buffer allocation is not > allowed on render nodes and drmPrimeHandleToFD is not allowed on > card0, so I'm stuck. I could open both nodes, but then I want the case > of no render node to work. After some searching, I thought it was a > matter of needing to do drmAuthMagic, but then found that is > considered obsolete[2]. Obsolete when using render nodes, but still necessary on usual nodes (/dev/dri/cardX) as far as I remember. The usual nodes can do everything the render nodes can do. Authentication should help! Please make sure you are master or authenticated before doing anything on the usual nodes. > > Rob > > [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git android-4.4 > [2] http://www.x.org/wiki/Events/XDC2013/XDC2013DavidHerrmannDRMSecurity/slides.pdf > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dumb BOs and prime 2015-12-04 18:21 ` Martin Peres @ 2015-12-04 18:40 ` Benjamin Gaignard 2015-12-04 19:23 ` Rob Herring 0 siblings, 1 reply; 9+ messages in thread From: Benjamin Gaignard @ 2015-12-04 18:40 UTC (permalink / raw) To: Martin Peres; +Cc: dri-devel [-- Attachment #1.1: Type: text/plain, Size: 2665 bytes --] Hi Rob, I got the same problem today with sti drm/kms driver and dumb Bo. The issue comes become hwcomposer because is the master and authenticated on /dev/dri/cardX Dumb allocation is done by gralloc which does a new open (so it is not authenticated) on drm node the consequence is that we can't use prime functions... If you use render node you won't be able to call dumb functions. To get out of this I think I will implement additional helpers in gem_cma to have ioctl like DRM_GEM_CMA_CREATE and DRM_GEM_CMA_MMAP and call them instead of dumb so be able to use render node. Of course it is only for drivers which already use gem_cma helpers (like sti) Benjamin Le vendredi 4 décembre 2015, Martin Peres <martin.peres@linux.intel.com> a écrit : > On 04/12/15 19:49, Rob Herring wrote: > >> I'm working on getting Android working with DRM drivers. ATM, I'm >> using virtio-gpu as the driver and trying to get just KMS side working >> without rendering. I have it working with stock AOSP and the emulated >> fb with a few additions to the virtio-gpu driver[1]. Now I'm trying to >> get things working with native KMS using drm_gralloc and >> drm_hwcomposer (now in AOSP). I've hit one problem though which I'm >> not sure how to solve without hacking around it. >> >> Is prime allowed on dumb BOs? AIUI, dumb buffer allocation is not >> allowed on render nodes and drmPrimeHandleToFD is not allowed on >> card0, so I'm stuck. I could open both nodes, but then I want the case >> of no render node to work. After some searching, I thought it was a >> matter of needing to do drmAuthMagic, but then found that is >> considered obsolete[2]. >> > > Obsolete when using render nodes, but still necessary on usual nodes > (/dev/dri/cardX) as far as I remember. The usual nodes can do everything > the render nodes can do. > > Authentication should help! Please make sure you are master or > authenticated before doing anything on the usual nodes. > > >> Rob >> >> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git >> android-4.4 >> [2] >> http://www.x.org/wiki/Events/XDC2013/XDC2013DavidHerrmannDRMSecurity/slides.pdf >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> -- Benjamin Gaignard Graphic Working Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> | Twitter <http://twitter.com/#!/linaroorg> | Blog <http://www.linaro.org/linaro-blog/> [-- Attachment #1.2: Type: text/html, Size: 4813 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dumb BOs and prime 2015-12-04 18:40 ` Benjamin Gaignard @ 2015-12-04 19:23 ` Rob Herring 2015-12-04 23:48 ` Greg Hackmann 0 siblings, 1 reply; 9+ messages in thread From: Rob Herring @ 2015-12-04 19:23 UTC (permalink / raw) To: Benjamin Gaignard; +Cc: dri-devel On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard <benjamin.gaignard@linaro.org> wrote: > Hi Rob, > > I got the same problem today with sti drm/kms driver and dumb Bo. > The issue comes become hwcomposer because is the master and authenticated on > /dev/dri/cardX > Dumb allocation is done by gralloc which does a new open (so it is not > authenticated) on drm node the consequence is that we can't use prime > functions... > If you use render node you won't be able to call dumb functions. > > To get out of this I think I will implement additional helpers in gem_cma to > have ioctl like DRM_GEM_CMA_CREATE and DRM_GEM_CMA_MMAP > and call them instead of dumb so be able to use render node. > Of course it is only for drivers which already use gem_cma helpers (like > sti) That's only marginally better than per driver BO calls which is the whole thing I'm trying to avoid. There should be some way to pass the auth token to gralloc? Rob > > Benjamin > > > Le vendredi 4 décembre 2015, Martin Peres <martin.peres@linux.intel.com> a > écrit : >> >> On 04/12/15 19:49, Rob Herring wrote: >>> >>> I'm working on getting Android working with DRM drivers. ATM, I'm >>> using virtio-gpu as the driver and trying to get just KMS side working >>> without rendering. I have it working with stock AOSP and the emulated >>> fb with a few additions to the virtio-gpu driver[1]. Now I'm trying to >>> get things working with native KMS using drm_gralloc and >>> drm_hwcomposer (now in AOSP). I've hit one problem though which I'm >>> not sure how to solve without hacking around it. >>> >>> Is prime allowed on dumb BOs? AIUI, dumb buffer allocation is not >>> allowed on render nodes and drmPrimeHandleToFD is not allowed on >>> card0, so I'm stuck. I could open both nodes, but then I want the case >>> of no render node to work. After some searching, I thought it was a >>> matter of needing to do drmAuthMagic, but then found that is >>> considered obsolete[2]. >> >> >> Obsolete when using render nodes, but still necessary on usual nodes >> (/dev/dri/cardX) as far as I remember. The usual nodes can do everything the >> render nodes can do. >> >> Authentication should help! Please make sure you are master or >> authenticated before doing anything on the usual nodes. >> >>> >>> Rob >>> >>> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git >>> android-4.4 >>> [2] >>> http://www.x.org/wiki/Events/XDC2013/XDC2013DavidHerrmannDRMSecurity/slides.pdf >>> _______________________________________________ >>> dri-devel mailing list >>> dri-devel@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/dri-devel >>> > > > -- > > Benjamin Gaignard > > Graphic Working Group > > Linaro.org │ Open source software for ARM SoCs > > Follow Linaro: Facebook | Twitter | Blog > > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dumb BOs and prime 2015-12-04 19:23 ` Rob Herring @ 2015-12-04 23:48 ` Greg Hackmann 2015-12-05 10:16 ` Daniel Vetter 2015-12-05 23:40 ` Rob Herring 0 siblings, 2 replies; 9+ messages in thread From: Greg Hackmann @ 2015-12-04 23:48 UTC (permalink / raw) To: Rob Herring, Benjamin Gaignard; +Cc: dri-devel On 12/04/2015 11:23 AM, Rob Herring wrote: > On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard > <benjamin.gaignard@linaro.org> wrote: >> Hi Rob, >> >> I got the same problem today with sti drm/kms driver and dumb Bo. >> The issue comes become hwcomposer because is the master and authenticated on >> /dev/dri/cardX >> Dumb allocation is done by gralloc which does a new open (so it is not >> authenticated) on drm node the consequence is that we can't use prime >> functions... >> If you use render node you won't be able to call dumb functions. >> >> To get out of this I think I will implement additional helpers in gem_cma to >> have ioctl like DRM_GEM_CMA_CREATE and DRM_GEM_CMA_MMAP >> and call them instead of dumb so be able to use render node. >> Of course it is only for drivers which already use gem_cma helpers (like >> sti) > > That's only marginally better than per driver BO calls which is the > whole thing I'm trying to avoid. There should be some way to pass the > auth token to gralloc? > > Rob Frankly, you probably want to approach this by allocating dma-bufs using something external to DRM (probably ion) and then have your hwcomposer import them into DRM when they're passed to the display. Backing gralloc allocations with dumb BOs doesn't really fit the way gralloc is designed: like dma-buf, it's built around passing buffers between different hardware blocks, and some of those buffers may never even touch the display hardware. You'll also run up against other (deliberate) limitations of dumb BOs like not being able to allocate YUV buffers. Unfortunately this currently means adding some shim driver code to create the ion device. (Device-Tree bindings for ion are on my long, long backlog of things to do.) It's not a lot of code, especially if all you need is a CMA heap, but it's still non-zero. Note that supporting dumb BOs in your KMS driver is still useful, since the recovery console in AOSP has KMS support now. In that case it's a single privileged process software-rendering everything, so it bypasses gralloc/hwcomposer and calls directly into libdrm. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dumb BOs and prime 2015-12-04 23:48 ` Greg Hackmann @ 2015-12-05 10:16 ` Daniel Vetter 2015-12-05 23:40 ` Rob Herring 1 sibling, 0 replies; 9+ messages in thread From: Daniel Vetter @ 2015-12-05 10:16 UTC (permalink / raw) To: Greg Hackmann; +Cc: dri-devel, Benjamin Gaignard On Fri, Dec 04, 2015 at 03:48:26PM -0800, Greg Hackmann wrote: > On 12/04/2015 11:23 AM, Rob Herring wrote: > >On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard > ><benjamin.gaignard@linaro.org> wrote: > >>Hi Rob, > >> > >>I got the same problem today with sti drm/kms driver and dumb Bo. > >>The issue comes become hwcomposer because is the master and authenticated on > >>/dev/dri/cardX > >>Dumb allocation is done by gralloc which does a new open (so it is not > >>authenticated) on drm node the consequence is that we can't use prime > >>functions... > >>If you use render node you won't be able to call dumb functions. > >> > >>To get out of this I think I will implement additional helpers in gem_cma to > >>have ioctl like DRM_GEM_CMA_CREATE and DRM_GEM_CMA_MMAP > >>and call them instead of dumb so be able to use render node. > >>Of course it is only for drivers which already use gem_cma helpers (like > >>sti) > > > >That's only marginally better than per driver BO calls which is the > >whole thing I'm trying to avoid. There should be some way to pass the > >auth token to gralloc? > > > >Rob > > Frankly, you probably want to approach this by allocating dma-bufs using > something external to DRM (probably ion) and then have your hwcomposer > import them into DRM when they're passed to the display. > > Backing gralloc allocations with dumb BOs doesn't really fit the way gralloc > is designed: like dma-buf, it's built around passing buffers between > different hardware blocks, and some of those buffers may never even touch > the display hardware. You'll also run up against other (deliberate) > limitations of dumb BOs like not being able to allocate YUV buffers. > > Unfortunately this currently means adding some shim driver code to create > the ion device. (Device-Tree bindings for ion are on my long, long backlog > of things to do.) It's not a lot of code, especially if all you need is a > CMA heap, but it's still non-zero. Yeah at plumbers in seattle we discussed this and pretty much all agreed that for these kind of embedded cases ION makes tons of sense as the backing allocator. Trying to use dumb buffers for everything really isn't how it's meant to be, and it shows in all the hacks added and hoops you still need to jump through. As Greg says there's some polish left to do for really neat ION integration, but we captured that in drivers/staging/android/TODO. > Note that supporting dumb BOs in your KMS driver is still useful, since the > recovery console in AOSP has KMS support now. In that case it's a single > privileged process software-rendering everything, so it bypasses > gralloc/hwcomposer and calls directly into libdrm. Yeah, dumb buffers is for emergency consoles and for boot splash (where loading GL is either not yet possible or too expensive). Anything else will result in sizeable amounts of hurt. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dumb BOs and prime 2015-12-04 23:48 ` Greg Hackmann 2015-12-05 10:16 ` Daniel Vetter @ 2015-12-05 23:40 ` Rob Herring 2015-12-05 23:52 ` Stéphane Marchesin 1 sibling, 1 reply; 9+ messages in thread From: Rob Herring @ 2015-12-05 23:40 UTC (permalink / raw) To: Greg Hackmann; +Cc: dri-devel, Benjamin Gaignard On Fri, Dec 4, 2015 at 5:48 PM, Greg Hackmann <ghackmann@google.com> wrote: > On 12/04/2015 11:23 AM, Rob Herring wrote: >> >> On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard >> <benjamin.gaignard@linaro.org> wrote: >>> >>> Hi Rob, >>> >>> I got the same problem today with sti drm/kms driver and dumb Bo. >>> The issue comes become hwcomposer because is the master and authenticated >>> on >>> /dev/dri/cardX >>> Dumb allocation is done by gralloc which does a new open (so it is not >>> authenticated) on drm node the consequence is that we can't use prime >>> functions... >>> If you use render node you won't be able to call dumb functions. >>> >>> To get out of this I think I will implement additional helpers in gem_cma >>> to >>> have ioctl like DRM_GEM_CMA_CREATE and DRM_GEM_CMA_MMAP >>> and call them instead of dumb so be able to use render node. >>> Of course it is only for drivers which already use gem_cma helpers (like >>> sti) >> >> >> That's only marginally better than per driver BO calls which is the >> whole thing I'm trying to avoid. There should be some way to pass the >> auth token to gralloc? >> >> Rob > > > Frankly, you probably want to approach this by allocating dma-bufs using > something external to DRM (probably ion) and then have your hwcomposer > import them into DRM when they're passed to the display. > > Backing gralloc allocations with dumb BOs doesn't really fit the way gralloc > is designed: like dma-buf, it's built around passing buffers between > different hardware blocks, and some of those buffers may never even touch > the display hardware. You'll also run up against other (deliberate) > limitations of dumb BOs like not being able to allocate YUV buffers. Yes, I realize dumb BO are not the long term nor production solution. ATM, I'm just looking for getting things working on new platforms without the need for lots of userspace changes. Perhaps I could just use fb emulation, but having DRM code paths tested is valuable IMO. > Unfortunately this currently means adding some shim driver code to create > the ion device. (Device-Tree bindings for ion are on my long, long backlog > of things to do.) It's not a lot of code, especially if all you need is a > CMA heap, but it's still non-zero. Laura is working on that. I'm still a bit skeptical about what should go in DT though. > Note that supporting dumb BOs in your KMS driver is still useful, since the > recovery console in AOSP has KMS support now. In that case it's a single > privileged process software-rendering everything, so it bypasses > gralloc/hwcomposer and calls directly into libdrm. I've not seen that. Where does that live? Rob _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dumb BOs and prime 2015-12-05 23:40 ` Rob Herring @ 2015-12-05 23:52 ` Stéphane Marchesin 0 siblings, 0 replies; 9+ messages in thread From: Stéphane Marchesin @ 2015-12-05 23:52 UTC (permalink / raw) To: Rob Herring; +Cc: Benjamin Gaignard, dri-devel On Sat, Dec 5, 2015 at 3:40 PM, Rob Herring <robh@kernel.org> wrote: > On Fri, Dec 4, 2015 at 5:48 PM, Greg Hackmann <ghackmann@google.com> wrote: >> On 12/04/2015 11:23 AM, Rob Herring wrote: >>> >>> On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard >>> <benjamin.gaignard@linaro.org> wrote: >>>> >>>> Hi Rob, >>>> >>>> I got the same problem today with sti drm/kms driver and dumb Bo. >>>> The issue comes become hwcomposer because is the master and authenticated >>>> on >>>> /dev/dri/cardX >>>> Dumb allocation is done by gralloc which does a new open (so it is not >>>> authenticated) on drm node the consequence is that we can't use prime >>>> functions... >>>> If you use render node you won't be able to call dumb functions. >>>> >>>> To get out of this I think I will implement additional helpers in gem_cma >>>> to >>>> have ioctl like DRM_GEM_CMA_CREATE and DRM_GEM_CMA_MMAP >>>> and call them instead of dumb so be able to use render node. >>>> Of course it is only for drivers which already use gem_cma helpers (like >>>> sti) >>> >>> >>> That's only marginally better than per driver BO calls which is the >>> whole thing I'm trying to avoid. There should be some way to pass the >>> auth token to gralloc? >>> >>> Rob >> >> >> Frankly, you probably want to approach this by allocating dma-bufs using >> something external to DRM (probably ion) and then have your hwcomposer >> import them into DRM when they're passed to the display. >> >> Backing gralloc allocations with dumb BOs doesn't really fit the way gralloc >> is designed: like dma-buf, it's built around passing buffers between >> different hardware blocks, and some of those buffers may never even touch >> the display hardware. You'll also run up against other (deliberate) >> limitations of dumb BOs like not being able to allocate YUV buffers. > > Yes, I realize dumb BO are not the long term nor production solution. > ATM, I'm just looking for getting things working on new platforms > without the need for lots of userspace changes. Perhaps I could just > use fb emulation, but having DRM code paths tested is valuable IMO. > >> Unfortunately this currently means adding some shim driver code to create >> the ion device. (Device-Tree bindings for ion are on my long, long backlog >> of things to do.) It's not a lot of code, especially if all you need is a >> CMA heap, but it's still non-zero. > > Laura is working on that. I'm still a bit skeptical about what should > go in DT though. > >> Note that supporting dumb BOs in your KMS driver is still useful, since the >> recovery console in AOSP has KMS support now. In that case it's a single >> privileged process software-rendering everything, so it bypasses >> gralloc/hwcomposer and calls directly into libdrm. > > I've not seen that. Where does that live? https://android.googlesource.com/platform/bootable/recovery/+/1a92c4458dcc983f624a60fb75f9679c213e6814 Stéphane > > Rob > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-12-05 23:53 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-12-04 17:49 dumb BOs and prime Rob Herring 2015-12-04 18:07 ` Daniel Stone 2015-12-04 18:21 ` Martin Peres 2015-12-04 18:40 ` Benjamin Gaignard 2015-12-04 19:23 ` Rob Herring 2015-12-04 23:48 ` Greg Hackmann 2015-12-05 10:16 ` Daniel Vetter 2015-12-05 23:40 ` Rob Herring 2015-12-05 23:52 ` Stéphane Marchesin
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.