From mboxrd@z Thu Jan 1 00:00:00 1970 From: Inki Dae Subject: Re: [RFC 1/1] drm/pl111: Initial drm/kms driver for pl111 Date: Sat, 10 Aug 2013 13:56:56 +0900 Message-ID: References: <1374772648-19151-1-git-send-email-tom.cooksey@arm.com> <1374772648-19151-2-git-send-email-tom.cooksey@arm.com> <20130807164651.GY22035@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1075902467==" Return-path: Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by gabe.freedesktop.org (Postfix) with ESMTP id DA793E5D0A for ; Fri, 9 Aug 2013 21:57:05 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ea20so3530082lab.13 for ; Fri, 09 Aug 2013 21:56:56 -0700 (PDT) In-Reply-To: <20130807164651.GY22035@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Daniel Vetter Cc: linux-fbdev@vger.kernel.org, pawel.moll@arm.com, dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org List-Id: dri-devel@lists.freedesktop.org --===============1075902467== Content-Type: multipart/alternative; boundary=001a11c34e6c794dd804e390b8ca --001a11c34e6c794dd804e390b8ca Content-Type: text/plain; charset=ISO-8859-1 2013/8/8 Daniel Vetter > Just comment a bit on Rob's review with my own opinion. > > On Wed, Aug 07, 2013 at 12:17:21PM -0400, Rob Clark wrote: > > On Thu, Jul 25, 2013 at 1:17 PM, wrote: > > > From: Tom Cooksey > > > > > > This is a mode-setting driver for the pl111 CLCD display controller > > > found on various ARM reference platforms such as the Versatile > > > Express. The driver supports setting of a single mode (640x480) and > > > has only been tested on Versatile Express with a Cortex-A9 core tile. > > > > > > Known issues: > > > * It still includes code to use KDS, which is not going upstream. > > > > review's on > http://lists.freedesktop.org/archives/dri-devel/2013-July/042462.html > > can't hurt > > > > although you might consider submitting a reduced functionality driver > > w/ KDS bits removed in the mean time.. then when the fence stuff is > > merged it is just an incremental patch rather than a whole driver ;-) > > Yeah, I think the KDS bits and comments need to go first before merginge. > > > > > +/* > > > + * Number of flips allowed in flight at any one time. Any more flips > requested > > > + * beyond this value will cause the caller to block until earlier > flips have > > > + * completed. > > > + * > > > + * For performance reasons, this must be greater than the number of > buffers > > > + * used in the rendering pipeline. Note that the rendering pipeline > can contain > > > + * different types of buffer, e.g.: > > > + * - 2 final framebuffers > > > + * - >2 geometry buffers for GPU use-cases > > > + * - >2 vertex buffers for GPU use-cases > > > + * > > > + * For example, a system using 5 geometry buffers could have 5 flips > in flight, > > > + * and so NR_FLIPS_IN_FLIGHT_THRESHOLD must be 5 or greater. > > > + * > > > + * Whilst there may be more intermediate buffers (such as > vertex/geometry) than > > > + * final framebuffers, KDS is used to ensure that GPU rendering waits > for the > > > + * next off-screen buffer, so it doesn't overwrite an on-screen > buffer and > > > + * produce tearing. > > > + */ > > > + > > > > fwiw, this is at least different from how other drivers do triple (or > > > double) buffering. In other drivers (intel, omap, and > > msm/freedreno, that I know of, maybe others too) the xorg driver dri2 > > bits implement the double buffering (ie. send flip event back to > > client immediately and queue up the flip and call page-flip after the > > pageflip event back from kernel. > > > > I'm not saying not to do it this way, I guess I'd like to hear what > > other folks think. I kinda prefer doing this in userspace as it keeps > > the kernel bits simpler (plus it would then work properly on exynosdrm > > or other kms drivers). > > Yeah, if this is just a sw queue then I don't think it makes sense to have > it in the kernel. Afaik the current pageflip interface drm exposes allows > one oustanding flip only, and you _must_ wait for the flip complete event > before you can submit the second one. > Agree. Tizen platform using exynos drm driver also does in same way. And there is another issue we are facing with. Please, assume CPU and GPU are sharing a same buffer. The issue is that in case of using glFlush GL API, 3d app cannot be aware of when GPU access to the buffer is completed: the completion event is sent only to GPU specific API; in our case, MALI specific DDK, so the buffer could be broken if CPU accesses the buffer at once after glFlush. Of course we can use glFinish instead of glFlush but glFinish makes GPU more idle: CPU should wait for the completion of GPU access to the buffer so CPU cannot do anything until that time. So I'd like to know how other folks take care of this issue. In our case, we are using dmabuf sync framework I posted before because I thought we may need buffer access control between CPU and DMA: the user land interfaces are fcntl and select system calls so no having any new additional api. with this feature, 3d app, only using standard GL API, can be aware of the completion event from GPU driver without DRM or other driver API. For this, I will introduce the more stable patch set soon with more features. For this, I'd happy to give me other opinions and advices if there is my missing point. Thanks, Inki Dae > > Ofc if your hardware as a hw-based flip queue (maybe even with frame > targets) that's a different matter, but currently we don't have a drm > interface to expose this. I'd say for merging the basic driver first we > should go with the existing simple pageflip semantics. > > And tbh I don't understand why the amount of buffers you keep in the > render pipeline side of things matters here at all. But I also haven't > read the details of your driver code. > > > > > > +/* > > > + * Here, we choose a conservative value. A lower value is most likely > > > + * suitable for GPU use-cases. > > > + */ > > > +#define NR_FLIPS_IN_FLIGHT_THRESHOLD 16 > > > + > > > +#define CLCD_IRQ_NEXTBASE_UPDATE (1u<<2) > > > + > > > +struct pl111_drm_flip_resource; > > > +struct pl111_drm_cursor_plane; > > > + > > > +enum pl111_bo_type { > > > + PL111_BOT_DMA, > > > + PL111_BOT_SHM > > > +}; > > > + > > > +struct pl111_gem_bo_dma { > > > + dma_addr_t fb_dev_addr; > > > + void *fb_cpu_addr; > > > +}; > > > + > > > +struct pl111_gem_bo_shm { > > > + struct page **pages; > > > + dma_addr_t *dma_addrs; > > > +}; > > > + > > > +struct pl111_gem_bo { > > > + struct drm_gem_object gem_object; > > > + enum pl111_bo_type type; > > > + union { > > > + struct pl111_gem_bo_dma dma; > > > + struct pl111_gem_bo_shm shm; > > > + } backing_data; > > > + struct drm_framebuffer *fb; > > > > this is at least a bit odd.. normally the fb has ref to the bo(s) and > > not the other way around. And the same bo could be referenced by > > multiple fb's which would kinda fall down with this approach. > > I'd say that's just backwards, framebuffers are created from backing > storage objects (which for a gem based driver is a gem object), not the > other way round. What's this exactly used for? > > [snip] > > > > + > > > + /* > > > + * Used to prevent race between pl111_dma_buf_release and > > > + * drm_gem_prime_handle_to_fd > > > + */ > > > + struct mutex export_dma_buf_lock; > > > > hmm, seems a bit suspicious.. the handle reference should keep the > > object live. Ie. either drm_gem_object_lookup() will fail because the > > object is gone (userspace has closed it's handle ref and > > dmabuf->release() already dropped it's ref) or it will succeed and > > you'll have a reference to the bo keeping it from going away if the > > release() comes after. > > The race is real, I have an evil testcase here which Oopses my kernel. I'm > working on a fix (v1 of my patches is submitted a few weeks back, awaiting > review), but I need to rework a few things since now I've also spotted a > leak or two ;-) > > [snip] > > > > +static void vsync_worker(struct work_struct *work) > > > +{ > > > + struct pl111_drm_flip_resource *flip_res; > > > + struct pl111_gem_bo *bo; > > > + struct pl111_drm_crtc *pl111_crtc; > > > + struct drm_device *dev; > > > + int flips_in_flight; > > > + flip_res = > > > + container_of(work, struct pl111_drm_flip_resource, > vsync_work); > > > + > > > + pl111_crtc = to_pl111_crtc(flip_res->crtc); > > > + dev = pl111_crtc->crtc.dev; > > > + > > > + DRM_DEBUG_KMS("DRM Finalizing flip_res=%p\n", flip_res); > > > + > > > + bo = PL111_BO_FROM_FRAMEBUFFER(flip_res->fb); > > > +#ifdef CONFIG_DMA_SHARED_BUFFER_USES_KDS > > > + if (flip_res->worker_release_kds == true) { > > > + spin_lock(&pl111_crtc->current_displaying_lock); > > > + release_kds_resource_and_display(flip_res); > > > + spin_unlock(&pl111_crtc->current_displaying_lock); > > > + } > > > +#endif > > > + /* Release DMA buffer on this flip */ > > > + if (bo->gem_object.export_dma_buf != NULL) > > > + dma_buf_put(bo->gem_object.export_dma_buf); > > > > I think you just want to unref the outgoing bo, and let it drop the > > dmabuf ref when the file ref of the imported bo goes. Or actually, it > > would be better to hold/drop ref's to the fb, rather than the bo. At > > least this will make things simpler if you ever have multi-planar > > support. > > Drivers have no business frobbing around the dma-buf refcount of imported > objects imo, at least if they use all the standard drm prime > infrastructure. And if they're bugs they need to be fixed there, not in > drivers. > > [snip] > > > > +struct drm_framebuffer *pl111_fb_create(struct drm_device *dev, > > > + struct drm_file *file_priv, > > > + struct drm_mode_fb_cmd2 > *mode_cmd) > > > +{ > > > + struct pl111_drm_framebuffer *pl111_fb = NULL; > > > + struct drm_framebuffer *fb = NULL; > > > + struct drm_gem_object *gem_obj; > > > + struct pl111_gem_bo *bo; > > > + > > > + pr_info("DRM %s\n", __func__); > > > + gem_obj = drm_gem_object_lookup(dev, file_priv, > mode_cmd->handles[0]); > > > + if (gem_obj == NULL) { > > > + DRM_ERROR("Could not get gem obj from handle to create > fb\n"); > > > + goto out; > > > + } > > > + > > > + bo = PL111_BO_FROM_GEM(gem_obj); > > > + /* Don't even attempt PL111_BOT_SHM, it's not contiguous */ > > > + BUG_ON(bo->type != PL111_BOT_DMA); > > > > umm, no BUG_ON() is not really a good way to validate userspace input.. > > > > if (bo->type != ...) > > return ERR_PTR(-EINVAL); > > Yep. > > > > + > > > + switch ((char)(mode_cmd->pixel_format & 0xFF)) { > > > + case 'Y': > > > + case 'U': > > > + case 'V': > > > + case 'N': > > > + case 'T': > > > > perhaps we should instead add a drm_format_is_yuv().. or you could > > (ab)use drm_fb_get_bpp_depth().. > > Yeah, I think a new drm_format_is_yuv is asked-for here. Now the bigger > question is why you need this, since the drm core should filter out > formats not in your list of supported ones. Or at least it should ... > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > -- > To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > --001a11c34e6c794dd804e390b8ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2013/8/8 Daniel Vetter <daniel@ffwll.ch>
Just comment a bit on Rob's review with my own opinion.

On Wed, Aug 07, 2013 at 12:17:21PM -0400, Rob Clark wrote:
> On Thu, Jul 25, 2013 at 1:17 PM, =A0<tom.cooksey@arm.com> wrote:
> > From: Tom Cooksey <tom.= cooksey@arm.com>
> >
> > This is a mode-setting driver for the pl111 CLCD display controll= er
> > found on various ARM reference platforms such as the Versatile > > Express. The driver supports setting of a single mode (640x480) a= nd
> > has only been tested on Versatile Express with a Cortex-A9 core t= ile.
> >
> > Known issues:
> > =A0* It still includes code to use KDS, which is not going upstre= am.
>
> review's on http://lists.freedesktop.org/= archives/dri-devel/2013-July/042462.html
> can't hurt
>
> although you might consider submitting a reduced functionality driver<= br> > w/ KDS bits removed in the mean time.. then when the fence stuff is > merged it is just an incremental patch rather than a whole driver ;-)<= br>
Yeah, I think the KDS bits and comments need to go first before mergi= nge.


> > +/*
> > + * Number of flips allowed in flight at any one time. Any more f= lips requested
> > + * beyond this value will cause the caller to block until earlie= r flips have
> > + * completed.
> > + *
> > + * For performance reasons, this must be greater than the number= of buffers
> > + * used in the rendering pipeline. Note that the rendering pipel= ine can contain
> > + * different types of buffer, e.g.:
> > + * - 2 final framebuffers
> > + * - >2 geometry buffers for GPU use-cases
> > + * - >2 vertex buffers for GPU use-cases
> > + *
> > + * For example, a system using 5 geometry buffers could have 5 f= lips in flight,
> > + * and so NR_FLIPS_IN_FLIGHT_THRESHOLD must be 5 or greater.
> > + *
> > + * Whilst there may be more intermediate buffers (such as vertex= /geometry) than
> > + * final framebuffers, KDS is used to ensure that GPU rendering = waits for the
> > + * next off-screen buffer, so it doesn't overwrite an on-scr= een buffer and
> > + * produce tearing.
> > + */
> > +
>
> fwiw, this is at least different from how other drivers do triple (or<= br> > > double) buffering. =A0In other drivers (intel, omap, and
> msm/freedreno, that I know of, maybe others too) the xorg driver dri2<= br> > bits implement the double buffering (ie. send flip event back to
> client immediately and queue up the flip and call page-flip after the<= br> > pageflip event back from kernel.
>
> I'm not saying not to do it this way, I guess I'd like to hear= what
> other folks think. =A0I kinda prefer doing this in userspace as it kee= ps
> the kernel bits simpler (plus it would then work properly on exynosdrm=
> or other kms drivers).

Yeah, if this is just a sw queue then I don't think it make= s sense to have
it in the kernel. Afaik the current pageflip interface drm exposes allows one oustanding flip only, and you _must_ wait for the flip complete event before you can submit the second one.
=A0
Ag= ree. Tizen platform using exynos drm driver also does in same way. And ther= e is another issue we are facing with. Please, assume CPU and GPU are shari= ng a same buffer. The issue is that in case of using glFlush GL API, 3d app= =A0cannot be aware of when GPU access to=A0the buffer is completed:=A0the= =A0completion event is sent only to=A0GPU specific API; in our case, MALI s= pecific DDK,=A0so=A0the=A0buffer=A0could be broken if=A0CPU accesses the bu= ffer at once after glFlush. Of course we can use glFinish instead of glFlus= h but glFinish makes GPU more idle: CPU should wait for the completion of G= PU access to the buffer so CPU cannot do anything until that time. So I'= ;d like to know how other folks take care of this issue.
=A0
In our case,=A0we are using dmabuf sync framework I post= ed before=A0because I=A0thought=A0we may need=A0buffer access control betwe= en CPU and DMA: the user land interfaces are fcntl and select=A0system call= s so no having any new additional api.=A0with this feature, 3d app,=A0only = using standard GL API,=A0can be aware of the completion event from GPU driv= er without DRM or other driver API.=A0For this, I will introduce the more s= table=A0patch set=A0soon with more features.
=A0
For this, I'd happy to give me other opinions and ad= vices if there is my missing point.
=A0
Thanks,
Inki Dae
=A0

Ofc if your hardware as a hw-based flip queue (maybe even with frame
targets) that's a different matter, but currently we don't have a d= rm
interface to expose this. I'd say for merging the basic driver first we=
should go with the existing simple pageflip semantics.

And tbh I don't understand why the amount of buffers you keep in the render pipeline side of things matters here at all. But I also haven't<= br> read the details of your driver code.

>
> > +/*
> > + * Here, we choose a conservative value. A lower value is most l= ikely
> > + * suitable for GPU use-cases.
> > + */
> > +#define NR_FLIPS_IN_FLIGHT_THRESHOLD 16
> > +
> > +#define CLCD_IRQ_NEXTBASE_UPDATE (1u<<2)
> > +
> > +struct pl111_drm_flip_resource;
> > +struct pl111_drm_cursor_plane;
> > +
> > +enum pl111_bo_type {
> > + =A0 =A0 =A0 PL111_BOT_DMA,
> > + =A0 =A0 =A0 PL111_BOT_SHM
> > +};
> > +
> > +struct pl111_gem_bo_dma {
> > + =A0 =A0 =A0 dma_addr_t fb_dev_addr;
> > + =A0 =A0 =A0 void *fb_cpu_addr;
> > +};
> > +
> > +struct pl111_gem_bo_shm {
> > + =A0 =A0 =A0 struct page **pages;
> > + =A0 =A0 =A0 dma_addr_t *dma_addrs;
> > +};
> > +
> > +struct pl111_gem_bo {
> > + =A0 =A0 =A0 struct drm_gem_object gem_object;
> > + =A0 =A0 =A0 enum pl111_bo_type type;
> > + =A0 =A0 =A0 union {
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct pl111_gem_bo_dma dma;
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct pl111_gem_bo_shm shm;
> > + =A0 =A0 =A0 } backing_data;
> > + =A0 =A0 =A0 struct drm_framebuffer *fb;
>
> this is at least a bit odd.. normally the fb has ref to the bo(s) and<= br> > not the other way around. =A0And the same bo could be referenced by > multiple fb's which would kinda fall down with this approach.

I'd say that's just backwards, framebuffers are created= from backing
storage objects (which for a gem based driver is a gem object), not the
other way round. What's this exactly used for?

[snip]

> > +
> > + =A0 =A0 =A0 /*
> > + =A0 =A0 =A0 =A0* Used to prevent race between pl111_dma_buf_rel= ease and
> > + =A0 =A0 =A0 =A0* drm_gem_prime_handle_to_fd
> > + =A0 =A0 =A0 =A0*/
> > + =A0 =A0 =A0 struct mutex export_dma_buf_lock;
>
> hmm, seems a bit suspicious.. the handle reference should keep the
> object live. =A0Ie. either drm_gem_object_lookup() will fail because t= he
> object is gone (userspace has closed it's handle ref and
> dmabuf->release() already dropped it's ref) or it will succeed = and
> you'll have a reference to the bo keeping it from going away if th= e
> release() comes after.

The race is real, I have an evil testcase here which Oopses my kernel= . I'm
working on a fix (v1 of my patches is submitted a few weeks back, awaiting<= br> review), but I need to rework a few things since now I've also spotted = a
leak or two ;-)

[snip]

> > +static void vsync_worker(struct work_struct *work)
> > +{
> > + =A0 =A0 =A0 struct pl111_drm_flip_resource *flip_res;
> > + =A0 =A0 =A0 struct pl111_gem_bo *bo;
> > + =A0 =A0 =A0 struct pl111_drm_crtc *pl111_crtc;
> > + =A0 =A0 =A0 struct drm_device *dev;
> > + =A0 =A0 =A0 int flips_in_flight;
> > + =A0 =A0 =A0 flip_res =3D
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 container_of(work, struct pl111_drm= _flip_resource, vsync_work);
> > +
> > + =A0 =A0 =A0 pl111_crtc =3D to_pl111_crtc(flip_res->crtc); > > + =A0 =A0 =A0 dev =3D pl111_crtc->crtc.dev;
> > +
> > + =A0 =A0 =A0 DRM_DEBUG_KMS("DRM Finalizing flip_res=3D%p\n&= quot;, flip_res);
> > +
> > + =A0 =A0 =A0 bo =3D PL111_BO_FROM_FRAMEBUFFER(flip_res->fb);<= br> > > +#ifdef CONFIG_DMA_SHARED_BUFFER_USES_KDS
> > + =A0 =A0 =A0 if (flip_res->worker_release_kds =3D=3D true) {<= br> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_lock(&pl111_crtc->curre= nt_displaying_lock);
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 release_kds_resource_and_display(fl= ip_res);
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_unlock(&pl111_crtc->cur= rent_displaying_lock);
> > + =A0 =A0 =A0 }
> > +#endif
> > + =A0 =A0 =A0 /* Release DMA buffer on this flip */
> > + =A0 =A0 =A0 if (bo->gem_object.export_dma_buf !=3D NULL)
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_buf_put(bo->gem_object.expor= t_dma_buf);
>
> I think you just want to unref the outgoing bo, and let it drop the > dmabuf ref when the file ref of the imported bo goes. =A0Or actually, = it
> would be better to hold/drop ref's to the fb, rather than the bo. = =A0At
> least this will make things simpler if you ever have multi-planar
> support.

Drivers have no business frobbing around the dma-buf refcount o= f imported
objects imo, at least if they use all the standard drm prime
infrastructure. And if they're bugs they need to be fixed there, not in=
drivers.

[snip]

> > +struct drm_framebuffer *pl111_fb_create(struct drm_device *dev,<= br> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 struct drm_file *file_priv,
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 struct drm_mode_fb_cmd2 *mode_cmd)
> > +{
> > + =A0 =A0 =A0 struct pl111_drm_framebuffer *pl111_fb =3D NULL; > > + =A0 =A0 =A0 struct drm_framebuffer *fb =3D NULL;
> > + =A0 =A0 =A0 struct drm_gem_object *gem_obj;
> > + =A0 =A0 =A0 struct pl111_gem_bo *bo;
> > +
> > + =A0 =A0 =A0 pr_info("DRM %s\n", __func__);
> > + =A0 =A0 =A0 gem_obj =3D drm_gem_object_lookup(dev, file_priv, m= ode_cmd->handles[0]);
> > + =A0 =A0 =A0 if (gem_obj =3D=3D NULL) {
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 DRM_ERROR("Could not get gem o= bj from handle to create fb\n");
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> > + =A0 =A0 =A0 }
> > +
> > + =A0 =A0 =A0 bo =3D PL111_BO_FROM_GEM(gem_obj);
> > + =A0 =A0 =A0 /* Don't even attempt PL111_BOT_SHM, it's n= ot contiguous */
> > + =A0 =A0 =A0 BUG_ON(bo->type !=3D PL111_BOT_DMA);
>
> umm, no BUG_ON() is not really a good way to validate userspace input.= .
>
> =A0 if (bo->type !=3D ...)
> =A0 =A0 return ERR_PTR(-EINVAL);

Yep.

> > +
> > + =A0 =A0 =A0 switch ((char)(mode_cmd->pixel_format & 0xFF= )) {
> > + =A0 =A0 =A0 case 'Y':
> > + =A0 =A0 =A0 case 'U':
> > + =A0 =A0 =A0 case 'V':
> > + =A0 =A0 =A0 case 'N':
> > + =A0 =A0 =A0 case 'T':
>
> perhaps we should instead add a drm_format_is_yuv().. or you could
> (ab)use drm_fb_get_bpp_depth()..

Yeah, I think a new drm_format_is_yuv is asked-for here. Now the bigg= er
question is why you need this, since the drm core should filter out
formats not in your list of supported ones. Or at least it should ...

Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - h= ttp://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev&= quot; in
the body of a message to major= domo@vger.kernel.org
More majordomo info at =A0http://vger.kernel.org/majordomo-info.html

--001a11c34e6c794dd804e390b8ca-- --===============1075902467== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============1075902467==--