[PATCH 0/2] omap/drm: dmm/tiler support for GEM buffers

[Gross, Andy]

On Thu, Dec 8, 2011 at 2:45 AM, Tomi Valkeinen wrote:

> On Wed, 2011-12-07 at 07:29 -0600, Rob Clark wrote:
> > On Wed, Dec 7, 2011 at 3:31 AM, Tomi Valkeinen 
> wrote:
> > > Hi,
> > >
> > > On Mon, 2011-12-05 at 19:19 -0600, Rob Clark wrote:
> > >> From: Rob Clark 
> > >>
> > >> Support for DMM and tiled buffers.  The DMM/TILER block in omap4+ SoC
> > >> provides support for remapping physically discontiguous buffers for
> > >> various DMA initiators (DSS, IVAHD, etc) which do not otherwise
> support
> > >> non-physically contiguous buffers, as well as providing support for
> > >> tiled buffers.
> > >>
> > >> See the descriptions in the following two patches for more details.
> > >
> > > Why is the tiler/dmm driver integrated into the drm driver?
> >
> > Basically because of a big list of reasons to keep it integrated, and
> > no good reason that I could think of to make it a standalone driver.
>
> Well, I think it's good architecture to keep independent things
> separate. Also we have other display frameworks in the kernel than DRM.
>
>
I think we can split it out if we need to support other frameworks.  It
isn't that difficult to do.  If we were to do that, I presume it would
still reside in the gpu/ somewhere.  But I think I'd rather wait until we
have another framework require access.



> > 1) Because the function/usage is most like a GTT in other systems..
> > the usage is really graphics/multimedia related so GEM is a natural
> > way to expose it to userspace.  Other places we want to use tiler
> > buffers, like camera, are neatly handled by using dmabuf to export the
> > GEM buffer to a different device.
> >
> > 2) We went down the separate driver path in the past, and it really
> > exposes a lot of problems.  See the hacks that were done in the past
> > to get wakeup/resume sequencing correct when tiler was a separate
> > driver.  (hint: the table of page addresses needs to be reprogrammed
> > before any access to buffer mapped in DMM is done.. this can be
> > accomplished quite simply by restoring the LUT before enabling any
> > video pipes when it is in a single driver... although that is still in
> > the TODO)
> >
> > 3) Doing some of the more advanced stuff, like page flipping using
> > DMM's synchronized refill to update page addresses synchronized with
> > scannout will, I think, end up being some kinda weird API.. I don't
> > think I'd want to make that a public API exported by one driver
> > consumed by another, but not such a problem if it is just something
> > used internally by one driver.
> >
> > 4) The LUT isn't really big enough to be managed statically like we
> > did in the past.. it needs to be managed dynamically, mapping and
> > evicting buffers.  This is something that is typical with other gfx
> > drivers in their management of their GTT..
> >
> > 5) I wouldn't really want to duplicate the userspace mmap'ing games
> > for 2d buffers in a lot of different drivers.
>
> I can't really argue your points as I'm not familiar with the problems
> with the tiler. So I'm not questioning the decision to integrate the
> tiler code into drm, just expressing my toughts =).
>
> If the tiler driver had only kernel internal API, and no userspace APIs,
> I don't see why it'd be much more difficult to have as a separate driver
> than integrated into DRM. Well, except if the tiler code itself uses
> features offered by DRM extensively, and having the tiler code as an
> independent driver would mean replicating all those features.
>
> I guess it's not quite a fair comparison, but I'm comparing tiler to the
> vrfb driver (well, lib is perhaps a better word for it), which doesn't
> depend on any framework and can be used by any kernel component.
>
>
No I appreciate your input.  I had thoughts along the same line.  But since
I did not have any exported kernel functions, I figured that it should just
sit underneath the omapdrm umbrella (so to speak).
-- next part --
An HTML attachment was scrubbed...
URL: 

Re: [PATCH 0/2] omap/drm: dmm/tiler support for GEM buffers

[Gross, Andy]

On Thu, Dec 8, 2011 at 2:45 AM, Tomi Valkeinen wrote:

> On Wed, 2011-12-07 at 07:29 -0600, Rob Clark wrote:
> > On Wed, Dec 7, 2011 at 3:31 AM, Tomi Valkeinen 
> wrote:
> > > Hi,
> > >
> > > On Mon, 2011-12-05 at 19:19 -0600, Rob Clark wrote:
> > >> From: Rob Clark 
> > >>
> > >> Support for DMM and tiled buffers.  The DMM/TILER block in omap4+ SoC
> > >> provides support for remapping physically discontiguous buffers for
> > >> various DMA initiators (DSS, IVAHD, etc) which do not otherwise
> support
> > >> non-physically contiguous buffers, as well as providing support for
> > >> tiled buffers.
> > >>
> > >> See the descriptions in the following two patches for more details.
> > >
> > > Why is the tiler/dmm driver integrated into the drm driver?
> >
> > Basically because of a big list of reasons to keep it integrated, and
> > no good reason that I could think of to make it a standalone driver.
>
> Well, I think it's good architecture to keep independent things
> separate. Also we have other display frameworks in the kernel than DRM.
>
>
I think we can split it out if we need to support other frameworks.  It
isn't that difficult to do.  If we were to do that, I presume it would
still reside in the gpu/ somewhere.  But I think I'd rather wait until we
have another framework require access.



> > 1) Because the function/usage is most like a GTT in other systems..
> > the usage is really graphics/multimedia related so GEM is a natural
> > way to expose it to userspace.  Other places we want to use tiler
> > buffers, like camera, are neatly handled by using dmabuf to export the
> > GEM buffer to a different device.
> >
> > 2) We went down the separate driver path in the past, and it really
> > exposes a lot of problems.  See the hacks that were done in the past
> > to get wakeup/resume sequencing correct when tiler was a separate
> > driver.  (hint: the table of page addresses needs to be reprogrammed
> > before any access to buffer mapped in DMM is done.. this can be
> > accomplished quite simply by restoring the LUT before enabling any
> > video pipes when it is in a single driver... although that is still in
> > the TODO)
> >
> > 3) Doing some of the more advanced stuff, like page flipping using
> > DMM's synchronized refill to update page addresses synchronized with
> > scannout will, I think, end up being some kinda weird API.. I don't
> > think I'd want to make that a public API exported by one driver
> > consumed by another, but not such a problem if it is just something
> > used internally by one driver.
> >
> > 4) The LUT isn't really big enough to be managed statically like we
> > did in the past.. it needs to be managed dynamically, mapping and
> > evicting buffers.  This is something that is typical with other gfx
> > drivers in their management of their GTT..
> >
> > 5) I wouldn't really want to duplicate the userspace mmap'ing games
> > for 2d buffers in a lot of different drivers.
>
> I can't really argue your points as I'm not familiar with the problems
> with the tiler. So I'm not questioning the decision to integrate the
> tiler code into drm, just expressing my toughts =).
>
> If the tiler driver had only kernel internal API, and no userspace APIs,
> I don't see why it'd be much more difficult to have as a separate driver
> than integrated into DRM. Well, except if the tiler code itself uses
> features offered by DRM extensively, and having the tiler code as an
> independent driver would mean replicating all those features.
>
> I guess it's not quite a fair comparison, but I'm comparing tiler to the
> vrfb driver (well, lib is perhaps a better word for it), which doesn't
> depend on any framework and can be used by any kernel component.
>
>
No I appreciate your input.  I had thoughts along the same line.  But since
I did not have any exported kernel functions, I figured that it should just
sit underneath the omapdrm umbrella (so to speak).
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] omap/drm: dmm/tiler support for GEM buffers

[Tomi Valkeinen]

On Wed, 2011-12-07 at 07:29 -0600, Rob Clark wrote:
> On Wed, Dec 7, 2011 at 3:31 AM, Tomi Valkeinen  
> wrote:
> > Hi,
> >
> > On Mon, 2011-12-05 at 19:19 -0600, Rob Clark wrote:
> >> From: Rob Clark 
> >>
> >> Support for DMM and tiled buffers.  The DMM/TILER block in omap4+ SoC
> >> provides support for remapping physically discontiguous buffers for
> >> various DMA initiators (DSS, IVAHD, etc) which do not otherwise support
> >> non-physically contiguous buffers, as well as providing support for
> >> tiled buffers.
> >>
> >> See the descriptions in the following two patches for more details.
> >
> > Why is the tiler/dmm driver integrated into the drm driver?
> 
> Basically because of a big list of reasons to keep it integrated, and
> no good reason that I could think of to make it a standalone driver.

Well, I think it's good architecture to keep independent things
separate. Also we have other display frameworks in the kernel than DRM.

> 1) Because the function/usage is most like a GTT in other systems..
> the usage is really graphics/multimedia related so GEM is a natural
> way to expose it to userspace.  Other places we want to use tiler
> buffers, like camera, are neatly handled by using dmabuf to export the
> GEM buffer to a different device.
> 
> 2) We went down the separate driver path in the past, and it really
> exposes a lot of problems.  See the hacks that were done in the past
> to get wakeup/resume sequencing correct when tiler was a separate
> driver.  (hint: the table of page addresses needs to be reprogrammed
> before any access to buffer mapped in DMM is done.. this can be
> accomplished quite simply by restoring the LUT before enabling any
> video pipes when it is in a single driver... although that is still in
> the TODO)
> 
> 3) Doing some of the more advanced stuff, like page flipping using
> DMM's synchronized refill to update page addresses synchronized with
> scannout will, I think, end up being some kinda weird API.. I don't
> think I'd want to make that a public API exported by one driver
> consumed by another, but not such a problem if it is just something
> used internally by one driver.
> 
> 4) The LUT isn't really big enough to be managed statically like we
> did in the past.. it needs to be managed dynamically, mapping and
> evicting buffers.  This is something that is typical with other gfx
> drivers in their management of their GTT..
> 
> 5) I wouldn't really want to duplicate the userspace mmap'ing games
> for 2d buffers in a lot of different drivers.

I can't really argue your points as I'm not familiar with the problems
with the tiler. So I'm not questioning the decision to integrate the
tiler code into drm, just expressing my toughts =).

If the tiler driver had only kernel internal API, and no userspace APIs,
I don't see why it'd be much more difficult to have as a separate driver
than integrated into DRM. Well, except if the tiler code itself uses
features offered by DRM extensively, and having the tiler code as an
independent driver would mean replicating all those features.

I guess it's not quite a fair comparison, but I'm comparing tiler to the
vrfb driver (well, lib is perhaps a better word for it), which doesn't
depend on any framework and can be used by any kernel component.

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: 

Re: [PATCH 0/2] omap/drm: dmm/tiler support for GEM buffers

[Tomi Valkeinen]

On Wed, 2011-12-07 at 07:29 -0600, Rob Clark wrote:
> On Wed, Dec 7, 2011 at 3:31 AM, Tomi Valkeinen  wrote:
> > Hi,
> >
> > On Mon, 2011-12-05 at 19:19 -0600, Rob Clark wrote:
> >> From: Rob Clark 
> >>
> >> Support for DMM and tiled buffers.  The DMM/TILER block in omap4+ SoC
> >> provides support for remapping physically discontiguous buffers for
> >> various DMA initiators (DSS, IVAHD, etc) which do not otherwise support
> >> non-physically contiguous buffers, as well as providing support for
> >> tiled buffers.
> >>
> >> See the descriptions in the following two patches for more details.
> >
> > Why is the tiler/dmm driver integrated into the drm driver?
> 
> Basically because of a big list of reasons to keep it integrated, and
> no good reason that I could think of to make it a standalone driver.

Well, I think it's good architecture to keep independent things
separate. Also we have other display frameworks in the kernel than DRM.

> 1) Because the function/usage is most like a GTT in other systems..
> the usage is really graphics/multimedia related so GEM is a natural
> way to expose it to userspace.  Other places we want to use tiler
> buffers, like camera, are neatly handled by using dmabuf to export the
> GEM buffer to a different device.
> 
> 2) We went down the separate driver path in the past, and it really
> exposes a lot of problems.  See the hacks that were done in the past
> to get wakeup/resume sequencing correct when tiler was a separate
> driver.  (hint: the table of page addresses needs to be reprogrammed
> before any access to buffer mapped in DMM is done.. this can be
> accomplished quite simply by restoring the LUT before enabling any
> video pipes when it is in a single driver... although that is still in
> the TODO)
> 
> 3) Doing some of the more advanced stuff, like page flipping using
> DMM's synchronized refill to update page addresses synchronized with
> scannout will, I think, end up being some kinda weird API.. I don't
> think I'd want to make that a public API exported by one driver
> consumed by another, but not such a problem if it is just something
> used internally by one driver.
> 
> 4) The LUT isn't really big enough to be managed statically like we
> did in the past.. it needs to be managed dynamically, mapping and
> evicting buffers.  This is something that is typical with other gfx
> drivers in their management of their GTT..
> 
> 5) I wouldn't really want to duplicate the userspace mmap'ing games
> for 2d buffers in a lot of different drivers.

I can't really argue your points as I'm not familiar with the problems
with the tiler. So I'm not questioning the decision to integrate the
tiler code into drm, just expressing my toughts =).

If the tiler driver had only kernel internal API, and no userspace APIs,
I don't see why it'd be much more difficult to have as a separate driver
than integrated into DRM. Well, except if the tiler code itself uses
features offered by DRM extensively, and having the tiler code as an
independent driver would mean replicating all those features.

I guess it's not quite a fair comparison, but I'm comparing tiler to the
vrfb driver (well, lib is perhaps a better word for it), which doesn't
depend on any framework and can be used by any kernel component.

 Tomi



signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] omap/drm: dmm/tiler support for GEM buffers

[Tomi Valkeinen]

Hi,

On Mon, 2011-12-05 at 19:19 -0600, Rob Clark wrote:
> From: Rob Clark 
> 
> Support for DMM and tiled buffers.  The DMM/TILER block in omap4+ SoC
> provides support for remapping physically discontiguous buffers for
> various DMA initiators (DSS, IVAHD, etc) which do not otherwise support
> non-physically contiguous buffers, as well as providing support for
> tiled buffers.
> 
> See the descriptions in the following two patches for more details.

Why is the tiler/dmm driver integrated into the drm driver?

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: 

[PATCH 0/2] omap/drm: dmm/tiler support for GEM buffers

[Rob Clark]

On Wed, Dec 7, 2011 at 3:31 AM, Tomi Valkeinen  wrote:
> Hi,
>
> On Mon, 2011-12-05 at 19:19 -0600, Rob Clark wrote:
>> From: Rob Clark 
>>
>> Support for DMM and tiled buffers. ?The DMM/TILER block in omap4+ SoC
>> provides support for remapping physically discontiguous buffers for
>> various DMA initiators (DSS, IVAHD, etc) which do not otherwise support
>> non-physically contiguous buffers, as well as providing support for
>> tiled buffers.
>>
>> See the descriptions in the following two patches for more details.
>
> Why is the tiler/dmm driver integrated into the drm driver?

Basically because of a big list of reasons to keep it integrated, and
no good reason that I could think of to make it a standalone driver.

1) Because the function/usage is most like a GTT in other systems..
the usage is really graphics/multimedia related so GEM is a natural
way to expose it to userspace.  Other places we want to use tiler
buffers, like camera, are neatly handled by using dmabuf to export the
GEM buffer to a different device.

2) We went down the separate driver path in the past, and it really
exposes a lot of problems.  See the hacks that were done in the past
to get wakeup/resume sequencing correct when tiler was a separate
driver.  (hint: the table of page addresses needs to be reprogrammed
before any access to buffer mapped in DMM is done.. this can be
accomplished quite simply by restoring the LUT before enabling any
video pipes when it is in a single driver... although that is still in
the TODO)

3) Doing some of the more advanced stuff, like page flipping using
DMM's synchronized refill to update page addresses synchronized with
scannout will, I think, end up being some kinda weird API.. I don't
think I'd want to make that a public API exported by one driver
consumed by another, but not such a problem if it is just something
used internally by one driver.

4) The LUT isn't really big enough to be managed statically like we
did in the past.. it needs to be managed dynamically, mapping and
evicting buffers.  This is something that is typical with other gfx
drivers in their management of their GTT..

5) I wouldn't really want to duplicate the userspace mmap'ing games
for 2d buffers in a lot of different drivers.

The code is structured such that it could be separated in the future,
if there is any good reason too.  But so far I've been unable to think
of one.

BR,
-R


> ?Tomi
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Re: [PATCH 0/2] omap/drm: dmm/tiler support for GEM buffers

[Rob Clark]

On Wed, Dec 7, 2011 at 3:31 AM, Tomi Valkeinen  wrote:
> Hi,
>
> On Mon, 2011-12-05 at 19:19 -0600, Rob Clark wrote:
>> From: Rob Clark 
>>
>> Support for DMM and tiled buffers.  The DMM/TILER block in omap4+ SoC
>> provides support for remapping physically discontiguous buffers for
>> various DMA initiators (DSS, IVAHD, etc) which do not otherwise support
>> non-physically contiguous buffers, as well as providing support for
>> tiled buffers.
>>
>> See the descriptions in the following two patches for more details.
>
> Why is the tiler/dmm driver integrated into the drm driver?

Basically because of a big list of reasons to keep it integrated, and
no good reason that I could think of to make it a standalone driver.

1) Because the function/usage is most like a GTT in other systems..
the usage is really graphics/multimedia related so GEM is a natural
way to expose it to userspace.  Other places we want to use tiler
buffers, like camera, are neatly handled by using dmabuf to export the
GEM buffer to a different device.

2) We went down the separate driver path in the past, and it really
exposes a lot of problems.  See the hacks that were done in the past
to get wakeup/resume sequencing correct when tiler was a separate
driver.  (hint: the table of page addresses needs to be reprogrammed
before any access to buffer mapped in DMM is done.. this can be
accomplished quite simply by restoring the LUT before enabling any
video pipes when it is in a single driver... although that is still in
the TODO)

3) Doing some of the more advanced stuff, like page flipping using
DMM's synchronized refill to update page addresses synchronized with
scannout will, I think, end up being some kinda weird API.. I don't
think I'd want to make that a public API exported by one driver
consumed by another, but not such a problem if it is just something
used internally by one driver.

4) The LUT isn't really big enough to be managed statically like we
did in the past.. it needs to be managed dynamically, mapping and
evicting buffers.  This is something that is typical with other gfx
drivers in their management of their GTT..

5) I wouldn't really want to duplicate the userspace mmap'ing games
for 2d buffers in a lot of different drivers.

The code is structured such that it could be separated in the future,
if there is any good reason too.  But so far I've been unable to think
of one.

BR,
-R


>  Tomi
>
>
> ___
> 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

Re: [PATCH 0/2] omap/drm: dmm/tiler support for GEM buffers

[Tomi Valkeinen]

Hi,

On Mon, 2011-12-05 at 19:19 -0600, Rob Clark wrote:
> From: Rob Clark 
> 
> Support for DMM and tiled buffers.  The DMM/TILER block in omap4+ SoC
> provides support for remapping physically discontiguous buffers for
> various DMA initiators (DSS, IVAHD, etc) which do not otherwise support
> non-physically contiguous buffers, as well as providing support for
> tiled buffers.
> 
> See the descriptions in the following two patches for more details.

Why is the tiler/dmm driver integrated into the drm driver?

 Tomi



signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] omap/drm: dmm/tiler support for GEM buffers

[Rob Clark]

From: Rob Clark 

Support for DMM and tiled buffers.  The DMM/TILER block in omap4+ SoC
provides support for remapping physically discontiguous buffers for
various DMA initiators (DSS, IVAHD, etc) which do not otherwise support
non-physically contiguous buffers, as well as providing support for
tiled buffers.

See the descriptions in the following two patches for more details.

Andy Gross (1):
  drm/omap: DMM/TILER support for OMAP4+ platform

Rob Clark (1):
  drm/omap: add GEM support for tiled/dmm buffers

 drivers/staging/omapdrm/Makefile   |   10 +-
 drivers/staging/omapdrm/TODO   |6 +
 drivers/staging/omapdrm/omap_dmm_priv.h|  187 
 drivers/staging/omapdrm/omap_dmm_tiler.c   |  672 ++
 drivers/staging/omapdrm/omap_dmm_tiler.h   |  130 +
 drivers/staging/omapdrm/omap_drm.h |2 +-
 drivers/staging/omapdrm/omap_drv.c |   27 +-
 drivers/staging/omapdrm/omap_drv.h |3 +
 drivers/staging/omapdrm/omap_fb.c  |2 +-
 drivers/staging/omapdrm/omap_gem.c |  432 --
 drivers/staging/omapdrm/omap_gem_helpers.c |   55 +++
 drivers/staging/omapdrm/omap_priv.h|7 +-
 drivers/staging/omapdrm/tcm-sita.c |  703 
 drivers/staging/omapdrm/tcm-sita.h |   95 
 drivers/staging/omapdrm/tcm.h  |  326 +
 15 files changed, 2609 insertions(+), 48 deletions(-)
 create mode 100644 drivers/staging/omapdrm/omap_dmm_priv.h
 create mode 100644 drivers/staging/omapdrm/omap_dmm_tiler.c
 create mode 100644 drivers/staging/omapdrm/omap_dmm_tiler.h
 create mode 100644 drivers/staging/omapdrm/tcm-sita.c
 create mode 100644 drivers/staging/omapdrm/tcm-sita.h
 create mode 100644 drivers/staging/omapdrm/tcm.h

-- 
1.7.5.4

[PATCH 0/2] omap/drm: dmm/tiler support for GEM buffers

[Rob Clark]

From: Rob Clark 

Support for DMM and tiled buffers.  The DMM/TILER block in omap4+ SoC
provides support for remapping physically discontiguous buffers for
various DMA initiators (DSS, IVAHD, etc) which do not otherwise support
non-physically contiguous buffers, as well as providing support for
tiled buffers.

See the descriptions in the following two patches for more details.

Andy Gross (1):
  drm/omap: DMM/TILER support for OMAP4+ platform

Rob Clark (1):
  drm/omap: add GEM support for tiled/dmm buffers

 drivers/staging/omapdrm/Makefile   |   10 +-
 drivers/staging/omapdrm/TODO   |6 +
 drivers/staging/omapdrm/omap_dmm_priv.h|  187 
 drivers/staging/omapdrm/omap_dmm_tiler.c   |  672 ++
 drivers/staging/omapdrm/omap_dmm_tiler.h   |  130 +
 drivers/staging/omapdrm/omap_drm.h |2 +-
 drivers/staging/omapdrm/omap_drv.c |   27 +-
 drivers/staging/omapdrm/omap_drv.h |3 +
 drivers/staging/omapdrm/omap_fb.c  |2 +-
 drivers/staging/omapdrm/omap_gem.c |  432 --
 drivers/staging/omapdrm/omap_gem_helpers.c |   55 +++
 drivers/staging/omapdrm/omap_priv.h|7 +-
 drivers/staging/omapdrm/tcm-sita.c |  703 
 drivers/staging/omapdrm/tcm-sita.h |   95 
 drivers/staging/omapdrm/tcm.h  |  326 +
 15 files changed, 2609 insertions(+), 48 deletions(-)
 create mode 100644 drivers/staging/omapdrm/omap_dmm_priv.h
 create mode 100644 drivers/staging/omapdrm/omap_dmm_tiler.c
 create mode 100644 drivers/staging/omapdrm/omap_dmm_tiler.h
 create mode 100644 drivers/staging/omapdrm/tcm-sita.c
 create mode 100644 drivers/staging/omapdrm/tcm-sita.h
 create mode 100644 drivers/staging/omapdrm/tcm.h

-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel