[PATCH] DRM: omapdrm DRM/KMS driver for TI OMAP platforms
On Fri, Nov 25, 2011 at 01:14:00PM -0600, Rob Clark wrote: > btw, Inki, Daniel, Konrad, and everyone who's reviewed this driver > over the (what seems like) years, I'd appreciate r-b's or comments if > you think there is anything remaining that should be done before first > version is merged. I think it's been reviewed to death by now, and > I'd *really* like to make sure it gets merged for 3.3 Honestly I've already looked at this too often and want to spare my review bandwidth for when this moves out of staging. TODO.txt contains all the things I think need to be fixed before that. So Highly-Recommended-for-Staging-by: Daniel Vetter -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[Bug 43248] Starting teeworlds results in black screen
https://bugs.freedesktop.org/show_bug.cgi?id=43248 --- Comment #1 from Sandeep 2011-11-25 12:23:37 PST --- Created attachment 53857 --> https://bugs.freedesktop.org/attachment.cgi?id=53857 output of lspci -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43248] New: Starting teeworlds results in black screen
https://bugs.freedesktop.org/show_bug.cgi?id=43248 Bug #: 43248 Summary: Starting teeworlds results in black screen Classification: Unclassified Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: sandy.8925 at gmail.com Created attachment 53856 --> https://bugs.freedesktop.org/attachment.cgi?id=53856 dmesg output Hardware: Asus K53TA laptop. AMD A6-3400M with integrated Radeon HD6520G and discrete Radeon HD6650M. Display is through 6520G. Software: Ubuntu 11.04 64 bit with kernel 3.2-rc1 and xorg-edgers ppa. When I start teeworlds, the screen goes blank (the display seems to be switched off). However I am able to switch to command line using Ctrl + Alt + F1 and running: sudo service gdm start and sudo service gdm stop restarts Gnome for me. dmesg shows some errors with atombios. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Fri, Nov 25, 2011 at 02:13:22PM +, Dave Airlie wrote: > On Tue, Oct 11, 2011 at 10:23 AM, Sumit Semwal wrote: > > This is the first step in defining a dma buffer sharing mechanism. > > > > A new buffer object dma_buf is added, with operations and API to allow easy > > sharing of this buffer object across devices. > > > > The framework allows: > > - a new buffer-object to be created with fixed size. > > - different devices to 'attach' themselves to this buffer, to facilitate > > ?backing storage negotiation, using dma_buf_attach() API. > > - association of a file pointer with each user-buffer and associated > > ? allocator-defined operations on that buffer. This operation is called the > > ? 'export' operation. > > - this exported buffer-object to be shared with the other entity by asking > > for > > ? its 'file-descriptor (fd)', and sharing the fd across. > > - a received fd to get the buffer object back, where it can be accessed > > using > > ? the associated exporter-defined operations. > > - the exporter and user to share the scatterlist using get_scatterlist and > > ? put_scatterlist operations. > > > > Atleast one 'attach()' call is required to be made prior to calling the > > get_scatterlist() operation. > > > > Couple of building blocks in get_scatterlist() are added to ease > > introduction > > of sync'ing across exporter and users, and late allocation by the exporter. > > > > mmap() file operation is provided for the associated 'fd', as wrapper over > > the > > optional allocator defined mmap(), to be used by devices that might need > > one. > > > > More details are there in the documentation patch. > > > > Some questions, I've started playing around with using this framework > to do buffer sharing between DRM devices, > > Why struct scatterlist and not struct sg_table? it seems like I really > want to use an sg_table, No reason at all besides that intel-gtt is using scatterlist internally (and only kludges the sg_table together in an ad-hoc fashion) and so I haven't noticed. sg_table for more consistency with the dma api sounds good. > I'm not convinced fd's are really useful over just some idr allocated > handle, so far I'm just returning the "fd" to userspace as a handle, > and passing it back in the other side, so I'm not really sure what an > fd wins us here, apart from the mmap thing which I think shouldn't be > here anyways. > (if fd's do win us more we should probably record that in the docs patch). Imo fds are nice because their known and there's already all the preexisting infrastructure for them around. And if we ever get fancy with e.g. sync objects we can easily add poll support (or some insane ioctls). But I agree that "we can mmap" is bust as a reason and should just die. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
I've rebuilt my PRIME interface on top of dmabuf to see how it would work, I've got primed gears running again on top, but I expect all my object lifetime and memory ownership rules need fixing up (i.e. leaks like a sieve). http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-prime-dmabuf has the i915/nouveau patches for the kernel to produce the prime interface. Dave.
[Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
> +struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct device *dev)
> +{
> + ? ? ? struct dma_buf_attachment *attach;
> + ? ? ? int ret;
> +
> + ? ? ? BUG_ON(!dmabuf || !dev);
> +
> + ? ? ? mutex_lock(>lock);
> +
> + ? ? ? attach = kzalloc(sizeof(struct dma_buf_attachment), GFP_KERNEL);
> + ? ? ? if (attach == NULL)
> + ? ? ? ? ? ? ? goto err_alloc;
> +
> + ? ? ? attach->dev = dev;
> + ? ? ? if (dmabuf->ops->attach) {
> + ? ? ? ? ? ? ? ret = dmabuf->ops->attach(dmabuf, dev, attach);
> + ? ? ? ? ? ? ? if (!ret)
> + ? ? ? ? ? ? ? ? ? ? ? goto err_attach;
> + ? ? ? }
> + ? ? ? list_add(>node, >attachments);
> +
I would assume at some point this needed at
attach->dmabuf = dmabuf;
added.
Dave.
[Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Tue, Oct 11, 2011 at 10:23 AM, Sumit Semwal wrote: > This is the first step in defining a dma buffer sharing mechanism. > > A new buffer object dma_buf is added, with operations and API to allow easy > sharing of this buffer object across devices. > > The framework allows: > - a new buffer-object to be created with fixed size. > - different devices to 'attach' themselves to this buffer, to facilitate > ?backing storage negotiation, using dma_buf_attach() API. > - association of a file pointer with each user-buffer and associated > ? allocator-defined operations on that buffer. This operation is called the > ? 'export' operation. > - this exported buffer-object to be shared with the other entity by asking for > ? its 'file-descriptor (fd)', and sharing the fd across. > - a received fd to get the buffer object back, where it can be accessed using > ? the associated exporter-defined operations. > - the exporter and user to share the scatterlist using get_scatterlist and > ? put_scatterlist operations. > > Atleast one 'attach()' call is required to be made prior to calling the > get_scatterlist() operation. > > Couple of building blocks in get_scatterlist() are added to ease introduction > of sync'ing across exporter and users, and late allocation by the exporter. > > mmap() file operation is provided for the associated 'fd', as wrapper over the > optional allocator defined mmap(), to be used by devices that might need one. > > More details are there in the documentation patch. > Some questions, I've started playing around with using this framework to do buffer sharing between DRM devices, Why struct scatterlist and not struct sg_table? it seems like I really want to use an sg_table, I'm not convinced fd's are really useful over just some idr allocated handle, so far I'm just returning the "fd" to userspace as a handle, and passing it back in the other side, so I'm not really sure what an fd wins us here, apart from the mmap thing which I think shouldn't be here anyways. (if fd's do win us more we should probably record that in the docs patch). Dave.
[PATCH] DRM: omapdrm DRM/KMS driver for TI OMAP platforms
btw, Inki, Daniel, Konrad, and everyone who's reviewed this driver
over the (what seems like) years, I'd appreciate r-b's or comments if
you think there is anything remaining that should be done before first
version is merged. I think it's been reviewed to death by now, and
I'd *really* like to make sure it gets merged for 3.3
thanks
BR,
-R
On Sat, Nov 12, 2011 at 12:09 PM, Rob Clark wrote:
> From: Rob Clark
>
> A DRM display driver for TI OMAP platform. ?Similar to omapfb (fbdev)
> and omap_vout (v4l2 display) drivers in the past, this driver uses the
> DSS2 driver to access the display hardware, including support for
> HDMI, DVI, and various types of LCD panels. ?And it implements GEM
> support for buffer allocation (for KMS as well as offscreen buffers
> used by the xf86-video-omap userspace xorg driver).
>
> The driver maps CRTCs to overlays, encoders to overlay-managers, and
> connectors to dssdev's. ?Note that this arrangement might change slightly
> when support for drm_plane overlays is added.
>
> For GEM support, non-scanout buffers are using the shmem backed pages
> provided by GEM core (In drm_gem_object_init()). ?In the case of scanout
> buffers, which need to be physically contiguous, those are allocated
> with CMA and use drm_gem_private_object_init().
>
> See userspace xorg driver:
> git://github.com/robclark/xf86-video-omap.git
>
> Refer to this link for CMA (Continuous Memory Allocator):
> http://lkml.org/lkml/2011/8/19/302
>
> Links to previous versions of the patch:
> v1: http://lwn.net/Articles/458137/
> v2: http://patches.linaro.org/4156/
> v3: http://patches.linaro.org/4688/
> v4: http://patches.linaro.org/4791/
>
> History:
>
> v5: move headers from include/drm at Greg KH's request, minor rebasing
> ? ?on 3.2-rc1, pull in private copies of drm_gem_{get,put}_pages()
> ? ?because "drm/gem: add functions to get/put pages" patch is not
> ? ?merged yet
> v4: bit of rework of encoder/connector _dpms() code, modeset_init()
> ? ?rework to not use nested functions, update TODO.txt
> v3: minor cleanups, improved error handling for dev_load(), some minor
> ? ?API changes that will be needed later for tiled buffer support
> v2: replace omap_vram with CMA for scanout buffer allocation, remove
> ? ?unneeded functions, use dma_addr_t for physical addresses, error
> ? ?handling cleanup, refactor attach/detach pages into common drm
> ? ?functions, split non-userspace-facing API into omap_priv.h, remove
> ? ?plugin API
>
> v1: original
>
> Signed-off-by: Rob Clark
> ---
> ?drivers/staging/Kconfig ? ? ? ? ? ? ? ? ? ?| ? ?2 +
> ?drivers/staging/Makefile ? ? ? ? ? ? ? ? ? | ? ?1 +
> ?drivers/staging/omapdrm/Kconfig ? ? ? ? ? ?| ? 25 +
> ?drivers/staging/omapdrm/Makefile ? ? ? ? ? | ? 12 +
> ?drivers/staging/omapdrm/TODO.txt ? ? ? ? ? | ? 32 ++
> ?drivers/staging/omapdrm/omap_connector.c ? | ?371 +
> ?drivers/staging/omapdrm/omap_crtc.c ? ? ? ?| ?327 +++
> ?drivers/staging/omapdrm/omap_drm.h ? ? ? ? | ?123 +
> ?drivers/staging/omapdrm/omap_drv.c ? ? ? ? | ?810
>
> ?drivers/staging/omapdrm/omap_drv.h ? ? ? ? | ?124 +
> ?drivers/staging/omapdrm/omap_encoder.c ? ? | ?172 ++
> ?drivers/staging/omapdrm/omap_fb.c ? ? ? ? ?| ?261 +
> ?drivers/staging/omapdrm/omap_fbdev.c ? ? ? | ?304 +++
> ?drivers/staging/omapdrm/omap_gem.c ? ? ? ? | ?774 ++
> ?drivers/staging/omapdrm/omap_gem_helpers.c | ?114
> ?drivers/staging/omapdrm/omap_priv.h ? ? ? ?| ? 42 ++
> ?drivers/video/omap2/omapfb/Kconfig ? ? ? ? | ? ?2 +-
> ?17 files changed, 3495 insertions(+), 1 deletions(-)
> ?create mode 100644 drivers/staging/omapdrm/Kconfig
> ?create mode 100644 drivers/staging/omapdrm/Makefile
> ?create mode 100644 drivers/staging/omapdrm/TODO.txt
> ?create mode 100644 drivers/staging/omapdrm/omap_connector.c
> ?create mode 100644 drivers/staging/omapdrm/omap_crtc.c
> ?create mode 100644 drivers/staging/omapdrm/omap_drm.h
> ?create mode 100644 drivers/staging/omapdrm/omap_drv.c
> ?create mode 100644 drivers/staging/omapdrm/omap_drv.h
> ?create mode 100644 drivers/staging/omapdrm/omap_encoder.c
> ?create mode 100644 drivers/staging/omapdrm/omap_fb.c
> ?create mode 100644 drivers/staging/omapdrm/omap_fbdev.c
> ?create mode 100644 drivers/staging/omapdrm/omap_gem.c
> ?create mode 100644 drivers/staging/omapdrm/omap_gem_helpers.c
> ?create mode 100644 drivers/staging/omapdrm/omap_priv.h
>
> diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
> index 25cdff3..eaba39d 100644
> --- a/drivers/staging/Kconfig
> +++ b/drivers/staging/Kconfig
> @@ -132,4 +132,6 @@ source "drivers/staging/nvec/Kconfig"
>
> ?source "drivers/staging/media/Kconfig"
>
> +source "drivers/staging/omapdrm/Kconfig"
> +
> ?endif # STAGING
> diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
> index a25f3f2..c84143a 100644
> --- a/drivers/staging/Makefile
> +++ b/drivers/staging/Makefile
> @@ -57,3 +57,4 @@
Re: [Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Tue, Oct 11, 2011 at 10:23 AM, Sumit Semwal sumit.sem...@ti.com wrote: This is the first step in defining a dma buffer sharing mechanism. A new buffer object dma_buf is added, with operations and API to allow easy sharing of this buffer object across devices. The framework allows: - a new buffer-object to be created with fixed size. - different devices to 'attach' themselves to this buffer, to facilitate backing storage negotiation, using dma_buf_attach() API. - association of a file pointer with each user-buffer and associated allocator-defined operations on that buffer. This operation is called the 'export' operation. - this exported buffer-object to be shared with the other entity by asking for its 'file-descriptor (fd)', and sharing the fd across. - a received fd to get the buffer object back, where it can be accessed using the associated exporter-defined operations. - the exporter and user to share the scatterlist using get_scatterlist and put_scatterlist operations. Atleast one 'attach()' call is required to be made prior to calling the get_scatterlist() operation. Couple of building blocks in get_scatterlist() are added to ease introduction of sync'ing across exporter and users, and late allocation by the exporter. mmap() file operation is provided for the associated 'fd', as wrapper over the optional allocator defined mmap(), to be used by devices that might need one. More details are there in the documentation patch. Some questions, I've started playing around with using this framework to do buffer sharing between DRM devices, Why struct scatterlist and not struct sg_table? it seems like I really want to use an sg_table, I'm not convinced fd's are really useful over just some idr allocated handle, so far I'm just returning the fd to userspace as a handle, and passing it back in the other side, so I'm not really sure what an fd wins us here, apart from the mmap thing which I think shouldn't be here anyways. (if fd's do win us more we should probably record that in the docs patch). Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Fri, Nov 25, 2011 at 02:13:22PM +, Dave Airlie wrote: On Tue, Oct 11, 2011 at 10:23 AM, Sumit Semwal sumit.sem...@ti.com wrote: This is the first step in defining a dma buffer sharing mechanism. A new buffer object dma_buf is added, with operations and API to allow easy sharing of this buffer object across devices. The framework allows: - a new buffer-object to be created with fixed size. - different devices to 'attach' themselves to this buffer, to facilitate backing storage negotiation, using dma_buf_attach() API. - association of a file pointer with each user-buffer and associated allocator-defined operations on that buffer. This operation is called the 'export' operation. - this exported buffer-object to be shared with the other entity by asking for its 'file-descriptor (fd)', and sharing the fd across. - a received fd to get the buffer object back, where it can be accessed using the associated exporter-defined operations. - the exporter and user to share the scatterlist using get_scatterlist and put_scatterlist operations. Atleast one 'attach()' call is required to be made prior to calling the get_scatterlist() operation. Couple of building blocks in get_scatterlist() are added to ease introduction of sync'ing across exporter and users, and late allocation by the exporter. mmap() file operation is provided for the associated 'fd', as wrapper over the optional allocator defined mmap(), to be used by devices that might need one. More details are there in the documentation patch. Some questions, I've started playing around with using this framework to do buffer sharing between DRM devices, Why struct scatterlist and not struct sg_table? it seems like I really want to use an sg_table, No reason at all besides that intel-gtt is using scatterlist internally (and only kludges the sg_table together in an ad-hoc fashion) and so I haven't noticed. sg_table for more consistency with the dma api sounds good. I'm not convinced fd's are really useful over just some idr allocated handle, so far I'm just returning the fd to userspace as a handle, and passing it back in the other side, so I'm not really sure what an fd wins us here, apart from the mmap thing which I think shouldn't be here anyways. (if fd's do win us more we should probably record that in the docs patch). Imo fds are nice because their known and there's already all the preexisting infrastructure for them around. And if we ever get fancy with e.g. sync objects we can easily add poll support (or some insane ioctls). But I agree that we can mmap is bust as a reason and should just die. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
+struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
+ struct device *dev)
+{
+ struct dma_buf_attachment *attach;
+ int ret;
+
+ BUG_ON(!dmabuf || !dev);
+
+ mutex_lock(dmabuf-lock);
+
+ attach = kzalloc(sizeof(struct dma_buf_attachment), GFP_KERNEL);
+ if (attach == NULL)
+ goto err_alloc;
+
+ attach-dev = dev;
+ if (dmabuf-ops-attach) {
+ ret = dmabuf-ops-attach(dmabuf, dev, attach);
+ if (!ret)
+ goto err_attach;
+ }
+ list_add(attach-node, dmabuf-attachments);
+
I would assume at some point this needed at
attach-dmabuf = dmabuf;
added.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
I've rebuilt my PRIME interface on top of dmabuf to see how it would work, I've got primed gears running again on top, but I expect all my object lifetime and memory ownership rules need fixing up (i.e. leaks like a sieve). http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-prime-dmabuf has the i915/nouveau patches for the kernel to produce the prime interface. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] DRM: omapdrm DRM/KMS driver for TI OMAP platforms
On Fri, Nov 25, 2011 at 01:14:00PM -0600, Rob Clark wrote: btw, Inki, Daniel, Konrad, and everyone who's reviewed this driver over the (what seems like) years, I'd appreciate r-b's or comments if you think there is anything remaining that should be done before first version is merged. I think it's been reviewed to death by now, and I'd *really* like to make sure it gets merged for 3.3 Honestly I've already looked at this too often and want to spare my review bandwidth for when this moves out of staging. TODO.txt contains all the things I think need to be fixed before that. So Highly-Recommended-for-Staging-by: Daniel Vetter daniel.vet...@ffwll.ch -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43248] New: Starting teeworlds results in black screen
https://bugs.freedesktop.org/show_bug.cgi?id=43248 Bug #: 43248 Summary: Starting teeworlds results in black screen Classification: Unclassified Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: sandy.8...@gmail.com Created attachment 53856 -- https://bugs.freedesktop.org/attachment.cgi?id=53856 dmesg output Hardware: Asus K53TA laptop. AMD A6-3400M with integrated Radeon HD6520G and discrete Radeon HD6650M. Display is through 6520G. Software: Ubuntu 11.04 64 bit with kernel 3.2-rc1 and xorg-edgers ppa. When I start teeworlds, the screen goes blank (the display seems to be switched off). However I am able to switch to command line using Ctrl + Alt + F1 and running: sudo service gdm start and sudo service gdm stop restarts Gnome for me. dmesg shows some errors with atombios. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43248] Starting teeworlds results in black screen
https://bugs.freedesktop.org/show_bug.cgi?id=43248 --- Comment #1 from Sandeep sandy.8...@gmail.com 2011-11-25 12:23:37 PST --- Created attachment 53857 -- https://bugs.freedesktop.org/attachment.cgi?id=53857 output of lspci -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43248] Starting teeworlds results in black screen
https://bugs.freedesktop.org/show_bug.cgi?id=43248 --- Comment #2 from Sandeep sandy.8...@gmail.com 2011-11-25 16:02:45 PST --- This happens for OpenArena as well. Trine on the other hand works properly (on low detail) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm, i915: Fix memory leak in i915_gem_busy_ioctl().
On Mon, Nov 21, 2011 at 11:16 PM, Keith Packard kei...@keithp.com wrote:
On Mon, 21 Nov 2011 17:23:06 +0100, Daniel Vetter dan...@ffwll.ch wrote:
Indeed, nice catch (albeit totally unlikely to be hit, because the error
only happens when the gpu ceases to progress in the ring, so imo not
stable material). Keith, please pick this up for fixes, thanks.
It's already there and queued for airlied :-)
Thank you guys for reviewing and taking the patch.
Now, while I was looking at the uses of i915_add_request(), I found
the following code :
ret = i915_gem_flush_ring(ring, 0,
I915_GEM_GPU_DOMAINS);
request = kzalloc(sizeof(*request), GFP_KERNEL);
if (ret || request == NULL ||
i915_add_request(ring, NULL, request))
kfree(request);
From above code, we might ended up by calling kfree(request) without
allocating request. Though, it's unlikely cause if request is NULL
then BUG_ON will be hit in i915_add_request(). So, to unify the callee
uses of i915_add_request(), I'm proposing the following patch. Please
let me know what do you guys think. If you guys agree, I can sent a
formal patch.
Index: work/modi.linux-3.1.1/drivers/gpu/drm/i915/i915_gem.c
===
--- work.orig/modi.linux-3.1.1/drivers/gpu/drm/i915/i915_gem.c
+++ work/modi.linux-3.1.1/drivers/gpu/drm/i915/i915_gem.c
@@ -1736,8 +1736,6 @@ i915_add_request(struct intel_ring_buffe
int was_empty;
int ret;
- BUG_ON(request == NULL);
-
ret = ring-add_request(ring, seqno);
if (ret)
return ret;
@@ -2002,9 +2000,11 @@ i915_gem_retire_work_handler(struct work
ret = i915_gem_flush_ring(ring,
0, I915_GEM_GPU_DOMAINS);
request = kzalloc(sizeof(*request), GFP_KERNEL);
- if (ret || request == NULL ||
- i915_add_request(ring, NULL, request))
- kfree(request);
+ if (request) {
+ ret = i915_add_request(ring, NULL, request);
+ if (ret)
+ kfree(request);
+ }
}
idle = list_empty(ring-request_list);
Thanks,
Rakib
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
