On Tue, 7 Jun 2011 13:07:42 -0700, Jesse Barnes
wrote:
> The video sprites support video surface formats natively and can handle
> scaling well. So add support for them using the new DRM core overlay
> support functions.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/Makefile
On Tue, 7 Jun 2011 13:07:41 -0700, Jesse Barnes
wrote:
> The old overlay block has all sorts of quirks and is very different than
> ILK+ video sprites. So rename it to legacy to make that clear and clash
> less with core overlay support.
>
> Signed-off-by: Jesse Barnes
> ---
> @@ -191,7 +191,
ves/dri-devel/attachments/20110607/9abbcb49/attachment.html>
-- next part --
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Tr
On Tue, Jun 07, 2011 at 12:17:01PM +0100, Alan Cox wrote:
> > Currently I don't use any sophisticated memory allocater like GEM
> > or similar. I helped myself with simple dma_alloc where needed. At
>
> GEM is actually pretty sane when you get your head around it a spot. The
> main thing it took m
> I'm not sure I understand you correctly. I have no address space on the
> card side since my 'card' just uses main memory. The memory I need must
> be a physically contiguous portion of sdram. I'm afraid shmem backing
> memory is not of much use for me.
I hadn't realised you had that underlying
https://bugzilla.kernel.org/show_bug.cgi?id=34802
haya...@gmail.com changed:
What|Removed |Added
CC||haya...@gmail.com
--- Comment #1 f
https://bugs.freedesktop.org/show_bug.cgi?id=37075
--- Comment #5 from Marek Olšák 2011-06-07 16:25:27 PDT ---
I can't reproduce this on r580. The bunny looks alright here.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: --
https://bugs.freedesktop.org/show_bug.cgi?id=37075
--- Comment #5 from Marek Ol??k 2011-06-07 16:25:27 PDT
---
I can't reproduce this on r580. The bunny looks alright here.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: -
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #8 from Marek Olšák 2011-06-07 16:20:33 PDT ---
Created an attachment (id=47694)
View: https://bugs.freedesktop.org/attachment.cgi?id=47694
Review: https://bugs.freedesktop.org/review?bug=37171&attachment=47694
patch
Could you pos
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #8 from Marek Ol??k 2011-06-07 16:20:33 PDT
---
Created an attachment (id=47694)
View: https://bugs.freedesktop.org/attachment.cgi?id=47694
Review: https://bugs.freedesktop.org/review?bug=37171&attachment=47694
patch
Could you po
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #7 from Marek Olšák 2011-06-07 16:16:37 PDT ---
The messages like this:
fixme:d3d:debug_d3dformat Unrecognized 0x36314644 (as fourcc: DF16)
WINED3DFORMAT!
fixme:d3d:wined3d_get_format Can't find format unrecognized (0x36314644) in th
https://bugs.freedesktop.org/show_bug.cgi?id=37171
--- Comment #7 from Marek Ol??k 2011-06-07 16:16:37 PDT
---
The messages like this:
fixme:d3d:debug_d3dformat Unrecognized 0x36314644 (as fourcc: DF16)
WINED3DFORMAT!
fixme:d3d:wined3d_get_format Can't find format unrecognized (0x36314644) in t
On Tuesday 07 June 2011, Ben Hutchings wrote:
> On Tue, Jun 07, 2011 at 01:22:29PM +0200, Arnd Bergmann wrote:
> > I guess what happened is that some variables are traditionally marked
> > as volatile although they shouldn't be, and most architectures have
> > adapted their bitops to make the warn
https://bugs.freedesktop.org/show_bug.cgi?id=37227
--- Comment #1 from Marek Olšák 2011-06-07 15:46:09 PDT ---
Is this with HyperZ enabled?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for th
https://bugs.freedesktop.org/show_bug.cgi?id=37274
Marek Olšák changed:
What|Removed |Added
Summary|r300g: rs690, crash in |Crash in draw_llvm_shader23
https://bugs.freedesktop.org/show_bug.cgi?id=37227
--- Comment #1 from Marek Ol??k 2011-06-07 15:46:09 PDT
---
Is this with HyperZ enabled?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for t
https://bugs.freedesktop.org/show_bug.cgi?id=37274
Marek Ol??k changed:
What|Removed |Added
Summary|r300g: rs690, crash in |Crash in draw_llvm_shader23
https://bugs.freedesktop.org/show_bug.cgi?id=37470
Marek Olšák changed:
What|Removed |Added
Component|Drivers/Gallium/r300|Mesa core
AssignedTo|dri-devel@lis
https://bugs.freedesktop.org/show_bug.cgi?id=37470
Marek Ol??k changed:
What|Removed |Added
Component|Drivers/Gallium/r300|Mesa core
AssignedTo|dri-devel at
https://bugs.freedesktop.org/show_bug.cgi?id=37911
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=37911
Marek Ol??k changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Tue, Jun 7, 2011 at 2:54 PM, Ilija Hadzic
wrote:
> debug statement for GUI idle interrupt is wrong and incorrectly
> reports CP EOP interrupt; trivial issue, but confusing for
> someone trying to distinguish interrupt sources while debugging
> ... fixed
>
> Signed-off-by: Ilija Hadzic
Reviewe
debug statement for GUI idle interrupt is wrong and incorrectly
reports CP EOP interrupt; trivial issue, but confusing for
someone trying to distinguish interrupt sources while debugging
... fixed
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
drivers/gpu/drm/radeo
https://bugs.freedesktop.org/show_bug.cgi?id=37028
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=37028
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
. and some comments to make it easier to understand.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 14 +++---
include/drm/ttm/ttm_bo_api.h |3 ---
include/drm/ttm/ttm_bo_driver.h |6 +++---
include/drm/ttm/ttm_memory.h |
While working on the DMA pool concept in the TTM code I re-read
everything once more to make sure I was not missing anything. Whilst doing
that I found some spelling mistakes and some wording that could be improved
a bit. So fixed it up and please consider this patch for 3.1.
On Tue, Jun 07, 2011 at 01:22:29PM +0200, Arnd Bergmann wrote:
> On Tuesday 07 June 2011, Geert Uytterhoeven wrote:
> > You mean the host_busy variable in the IDE code?
> > That would also apply to context_flag in the DRM code:
> >
> > drivers/gpu/drm/drm_context.c:233: warning: passing argument 2
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #22 from Maggioni Marcello 2011-06-07 14:31:57
PDT ---
IT WORKS! Yay! :D
I kind of imagined that the problem was in the initialization of the memory
somehow and this afternoon I was looking at that piece of cone in begin_query,
but
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #22 from Maggioni Marcello 2011-06-07
14:31:57 PDT ---
IT WORKS! Yay! :D
I kind of imagined that the problem was in the initialization of the memory
somehow and this afternoon I was looking at that piece of cone in begin_query,
but
https://bugzilla.kernel.org/show_bug.cgi?id=36892
Niels Ole Salscheider changed:
What|Removed |Added
CC||niels_ole at salscheider-onlin
https://bugzilla.kernel.org/show_bug.cgi?id=36892
--- Comment #5 from Niels Ole Salscheider
2011-06-07 14:18:17 ---
btw: I do not know why it was out of memory in the first error message. I have
8GB of ram but usually less than 4GB are used (most of it for virtuoso-t and
nepomukservices)
-
These small changes should allow GEM to be used with non shmem objects as
well as shmem objects. In the GMA500 case it allows the base framebuffer to
appear as a GEM object and thus acquire a handle and work with KMS.
For i915 it ought to be trivial to get back the wasted memory but putting the
sy
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #21 from Pierre-Eric Pelloux-Prayer 2011-06-07
14:14:30 PDT ---
Could you please update your git repo ?
agd5f pushed a patch (r600g: always clear query memory) which could correct the
problem (you still need to apply the first one t
https://bugzilla.kernel.org/show_bug.cgi?id=36892
--- Comment #4 from Niels Ole Salscheider
2011-06-07 14:15:02 ---
Created an attachment (id=61082)
--> (https://bugzilla.kernel.org/attachment.cgi?id=61082)
kernel message 4
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?
https://bugzilla.kernel.org/show_bug.cgi?id=36892
--- Comment #3 from Niels Ole Salscheider
2011-06-07 14:14:41 ---
Created an attachment (id=61072)
--> (https://bugzilla.kernel.org/attachment.cgi?id=61072)
kernel message 3
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #21 from Pierre-Eric Pelloux-Prayer
2011-06-07 14:14:30 PDT ---
Could you please update your git repo ?
agd5f pushed a patch (r600g: always clear query memory) which could correct the
problem (you still need to apply the first one t
https://bugzilla.kernel.org/show_bug.cgi?id=36892
--- Comment #2 from Niels Ole Salscheider
2011-06-07 14:14:24 ---
Created an attachment (id=61062)
--> (https://bugzilla.kernel.org/attachment.cgi?id=61062)
kernel message 2
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?
https://bugzilla.kernel.org/show_bug.cgi?id=36892
--- Comment #1 from Niels Ole Salscheider
2011-06-07 14:13:59 ---
Created an attachment (id=61052)
--> (https://bugzilla.kernel.org/attachment.cgi?id=61052)
kernel message
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?ta
https://bugzilla.kernel.org/show_bug.cgi?id=36892
Summary: page faults / general protection faults under heavy 3d
load
Product: Drivers
Version: 2.5
Platform: All
OS/Version: Linux
Tree: Mainline
Statu
On Tue, 7 Jun 2011 13:07:39 -0700
Jesse Barnes wrote:
> +#define DRM_MODE_PLANE_FORMAT_YUV422 1 /* YUV 4:2:2 packed */
> +#define DRM_MODE_PLANE_FORMAT_RGBX101010 2 /* RGB 10bpc, ign. alpha */
> +#define DRM_MODE_PLANE_FORMAT_RGBX8883 /* Standard x:8:8:8
> RGB */
> +
On Tue, 7 Jun 2011 13:07:39 -0700
Jesse Barnes wrote:
> +#define DRM_MODE_PLANE_FORMAT_YUV422 1 /* YUV 4:2:2 packed */
> +#define DRM_MODE_PLANE_FORMAT_RGBX101010 2 /* RGB 10bpc, ign. alpha */
> +#define DRM_MODE_PLANE_FORMAT_RGBX8883 /* Standard x:8:8:8
> RGB */
> +
On Tue, 7 Jun 2011 13:07:39 -0700
Jesse Barnes wrote:
> +/* Planes blend with or override other bits on the CRTC */
> +struct drm_mode_set_plane {
> + __u32 plane_id;
> + __u32 crtc_id;
> + __u32 fb_id; /* contains surface format type */
> +
> + __u32 crtc_x, crtc_y;
> + __u3
On Tue, 7 Jun 2011 13:07:42 -0700, Jesse Barnes
wrote:
> The video sprites support video surface formats natively and can handle
> scaling well. So add support for them using the new DRM core overlay
> support functions.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/Makefile
On Tue, 7 Jun 2011 13:07:39 -0700
Jesse Barnes wrote:
> +/* Planes blend with or override other bits on the CRTC */
> +struct drm_mode_set_plane {
> + __u32 plane_id;
> + __u32 crtc_id;
> + __u32 fb_id; /* contains surface format type */
> +
> + __u32 crtc_x, crtc_y;
> + __u3
On Tue, 7 Jun 2011 13:07:41 -0700, Jesse Barnes
wrote:
> The old overlay block has all sorts of quirks and is very different than
> ILK+ video sprites. So rename it to legacy to make that clear and clash
> less with core overlay support.
>
> Signed-off-by: Jesse Barnes
> ---
> @@ -191,7 +191,
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #20 from Maggioni Marcello 2011-06-07 13:56:47
PDT ---
The second patch doesn't solve for ... I don't know if it is a mine specific
problem or if it is universal for all 5850 owners.
this is the output of GDB for the variables you r
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #20 from Maggioni Marcello 2011-06-07
13:56:47 PDT ---
The second patch doesn't solve for ... I don't know if it is a mine specific
problem or if it is universal for all 5850 owners.
this is the output of GDB for the variables you r
We don't actually use the tiling setup in the CS checker for
evergreen/cayman yet, but we might as well set it up properly
in case we ever enable it.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c| 15 ---
drivers/gpu/drm/radeon/evergreen_cs.c | 12 +++
These small changes should allow GEM to be used with non shmem objects as
well as shmem objects. In the GMA500 case it allows the base framebuffer to
appear as a GEM object and thus acquire a handle and work with KMS.
For i915 it ought to be trivial to get back the wasted memory but putting the
sy
On Tuesday 07 June 2011, Geert Uytterhoeven wrote:
> You mean the host_busy variable in the IDE code?
> That would also apply to context_flag in the DRM code:
>
> drivers/gpu/drm/drm_context.c:233: warning: passing argument 2 of
> ?__constant_test_and_set_bit? discards qualifiers from pointer targ
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #19 from Sven Arvidsson 2011-06-07 13:08:38 PDT ---
(In reply to comment #17)
> What kernel version do you use Sven?
I'm using 2.6.39.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are recei
The old overlay block has all sorts of quirks and is very different than
ILK+ video sprites. So rename it to legacy to make that clear and clash
less with core overlay support.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
drivers/gpu/drm/i915/i915_drv.h |
The video sprites support video surface formats natively and can handle
scaling well. So add support for them using the new DRM core overlay
support functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_reg.h | 52 ++
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 230
drivers/gpu/drm/drm_drv.c |3
This patchset updates the previous one, incorporating the feedback I
received:
1) uses the v4l fourcc codes to communicate pixel format
2) adds a new addfb ioctl that takes a format
3) adds working SNB support for the new code
Comments welcome. I'll be pushing intel-gpu-tools testdisplay su
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #19 from Sven Arvidsson 2011-06-07 13:08:38 PDT ---
(In reply to comment #17)
> What kernel version do you use Sven?
I'm using 2.6.39.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are recei
The video sprites support video surface formats natively and can handle
scaling well. So add support for them using the new DRM core overlay
support functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_reg.h | 52 ++
The old overlay block has all sorts of quirks and is very different than
ILK+ video sprites. So rename it to legacy to make that clear and clash
less with core overlay support.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
drivers/gpu/drm/i915/i915_drv.h |
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 230
drivers/gpu/drm/drm_drv.c |3
This patchset updates the previous one, incorporating the feedback I
received:
1) uses the v4l fourcc codes to communicate pixel format
2) adds a new addfb ioctl that takes a format
3) adds working SNB support for the new code
Comments welcome. I'll be pushing intel-gpu-tools testdisplay su
> I'm not sure I understand you correctly. I have no address space on the
> card side since my 'card' just uses main memory. The memory I need must
> be a physically contiguous portion of sdram. I'm afraid shmem backing
> memory is not of much use for me.
I hadn't realised you had that underlying
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #18 from Pierre-Eric Pelloux-Prayer 2011-06-07
12:52:35 PDT ---
Created an attachment (id=47680)
View: https://bugs.freedesktop.org/attachment.cgi?id=47680
Review: https://bugs.freedesktop.org/review?bug=37028&attachment=47680
2nd
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #18 from Pierre-Eric Pelloux-Prayer
2011-06-07 12:52:35 PDT ---
Created an attachment (id=47680)
View: https://bugs.freedesktop.org/attachment.cgi?id=47680
Review: https://bugs.freedesktop.org/review?bug=37028&attachment=47680
2nd
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #17 from Maggioni Marcello 2011-06-07 12:47:00
PDT ---
What kernel version do you use Sven?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #17 from Maggioni Marcello 2011-06-07
12:47:00 PDT ---
What kernel version do you use Sven?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the
This adds a i.MX51/53 IPU (Image Processing Unit) KMS driver. The
driver has been tested on the i.MX51 babbage board and the i.MX53
LOCO board in different clone mode and dual head setups.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/Kconfig|9 +
drivers/gpu/drm/imx/Makefile |
At least in the embedded world encoders and connectors are not
at all visible in software. Often enough there is a 1:1
relationship between encoders and connectors. Add helpers to
handle this case and to ease driver implementation for SoCs.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/Kconfig
Hi All,
The following adds a KMS driver for the Freescale i.MX51/53 SoCs.
It is far from being ready but I think it is enough to send it
out and get the first comments on it and to show that there's
something going on.
Currently I don't use any sophisticated memory allocater like GEM
or similar.
Hi Sascha,
On Tue, Jun 7, 2011 at 7:45 AM, Sascha Hauer wrote:
...
> +static int __init imx_ipu_init(void)
> +{
> + ? ? ? int32_t ret;
> +
> + ? ? ? ret = platform_driver_register(&imx_ipu_driver);
> + ? ? ? return 0;
Did you intend to return ret here instead?
Regards,
Fabio Estevam
On Tue, 7 Jun 2011 14:35:52 -0400 Konrad Rzeszutek Wilk wrote:
> . and some comments to make it easier to understand.
>
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 14 +++---
> include/drm/ttm/ttm_bo_api.h |3 ---
> include/drm/tt
On Tue, 7 Jun 2011 14:35:52 -0400 Konrad Rzeszutek Wilk wrote:
> . and some comments to make it easier to understand.
>
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 14 +++---
> include/drm/ttm/ttm_bo_api.h |3 ---
> include/drm/tt
On Tue, Jun 7, 2011 at 2:54 PM, Ilija Hadzic
wrote:
> debug statement for GUI idle interrupt is wrong and incorrectly
> reports CP EOP interrupt; trivial issue, but confusing for
> someone trying to distinguish interrupt sources while debugging
> ... fixed
>
> Signed-off-by: Ilija Hadzic
Reviewe
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #16 from Sven Arvidsson 2011-06-07 12:29:19 PDT ---
I'm using a 5670 (Redwood) and the patch seems to solve the problems here. The
test application works with the patch and asserts without it:
query error : 2147483647 != 68698
quer
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #16 from Sven Arvidsson 2011-06-07 12:29:19 PDT ---
I'm using a 5670 (Redwood) and the patch seems to solve the problems here. The
test application works with the patch and asserts without it:
query error : 2147483647 != 68698
quer
> Currently I don't use any sophisticated memory allocater like GEM
> or similar. I helped myself with simple dma_alloc where needed. At
GEM is actually pretty sane when you get your head around it a spot. The
main thing it took me a bit of time to get my head around is that it
allocates backing m
On Tue, Jun 07, 2011 at 12:17:01PM +0100, Alan Cox wrote:
> > Currently I don't use any sophisticated memory allocater like GEM
> > or similar. I helped myself with simple dma_alloc where needed. At
>
> GEM is actually pretty sane when you get your head around it a spot. The
> main thing it took m
debug statement for GUI idle interrupt is wrong and incorrectly
reports CP EOP interrupt; trivial issue, but confusing for
someone trying to distinguish interrupt sources while debugging
... fixed
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
drivers/gpu/drm/radeo
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #15 from Maggioni Marcello 2011-06-07 11:46:29
PDT ---
Yes, you are perfectly right, I looked better to the application and you are
right, but considering that you don't set the "random seed" value with srand
the random sequence is a
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #15 from Maggioni Marcello 2011-06-07
11:46:29 PDT ---
Yes, you are perfectly right, I looked better to the application and you are
right, but considering that you don't set the "random seed" value with srand
the random sequence is a
While working on the DMA pool concept in the TTM code I re-read
everything once more to make sure I was not missing anything. Whilst doing
that I found some spelling mistakes and some wording that could be improved
a bit. So fixed it up and please consider this patch for 3.1.
_
. and some comments to make it easier to understand.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 14 +++---
include/drm/ttm/ttm_bo_api.h |3 ---
include/drm/ttm/ttm_bo_driver.h |6 +++---
include/drm/ttm/ttm_memory.h |
We don't actually use the tiling setup in the CS checker for
evergreen/cayman yet, but we might as well set it up properly
in case we ever enable it.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c| 15 ---
drivers/gpu/drm/radeon/evergreen_cs.c | 12 +++
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #14 from Pierre-Eric Pelloux-Prayer 2011-06-07
10:19:00 PDT ---
Remote debugging is hard :-/
Anyway, your modified app is wrong I think (not only the != / == inversion) :
The app is supposed to :
- draw a cube to a random position
-
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #14 from Pierre-Eric Pelloux-Prayer
2011-06-07 10:19:00 PDT ---
Remote debugging is hard :-/
Anyway, your modified app is wrong I think (not only the != / == inversion) :
The app is supposed to :
- draw a cube to a random position
-
On Mon, 6 Jun 2011 16:23:00 -0700, "Segovia, Benjamin"
wrote:
> Hello all,
>
> I saw at some point that per-process GTT (ppGTT) may be (or is
> already) implemented to handle paging. Right now, I am investigating
> some flat space addressing (ab)using surface states. The idea is to
> create a su
https://bugs.freedesktop.org/show_bug.cgi?id=37168
--- Comment #4 from Sean McNamara 2011-06-07 10:13:26
PDT ---
(In reply to comment #3)
> Followup: I also get the following messages spewed to dmesg every single
> frame,
> regardless if I'm using Mesa 7.10.2 or git master or anything in betwee
essly broken on all hardware in undocumented ways
(and basically no other details than that).
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110607/53b7e199/attachment.pgp>
https://bugs.freedesktop.org/show_bug.cgi?id=37028
Maggioni Marcello changed:
What|Removed |Added
Attachment #47666|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=37168
--- Comment #4 from Sean McNamara 2011-06-07
10:13:26 PDT ---
(In reply to comment #3)
> Followup: I also get the following messages spewed to dmesg every single
> frame,
> regardless if I'm using Mesa 7.10.2 or git master or anything in betwee
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #13 from Maggioni Marcello 2011-06-07 10:12:20
PDT ---
Created an attachment (id=47669)
--> (https://bugs.freedesktop.org/attachment.cgi?id=47669)
Correct test
Ups sorry, I completely botched the test application :D
I placed a "!=
https://bugs.freedesktop.org/show_bug.cgi?id=37028
Maggioni Marcello changed:
What|Removed |Added
Attachment #47666|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #13 from Maggioni Marcello 2011-06-07
10:12:20 PDT ---
Created an attachment (id=47669)
--> (https://bugs.freedesktop.org/attachment.cgi?id=47669)
Correct test
Ups sorry, I completely botched the test application :D
I placed a "!=
Hi Sascha,
On Tue, Jun 7, 2011 at 7:45 AM, Sascha Hauer wrote:
...
> +static int __init imx_ipu_init(void)
> +{
> + int32_t ret;
> +
> + ret = platform_driver_register(&imx_ipu_driver);
> + return 0;
Did you intend to return ret here instead?
Regards,
Fabio Estevam
__
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #12 from Maggioni Marcello 2011-06-07 09:15:59
PDT ---
Created an attachment (id=47666)
--> (https://bugs.freedesktop.org/attachment.cgi?id=47666)
Further tests
Hi, your test application crashes on my system with and without the pa
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #12 from Maggioni Marcello 2011-06-07
09:15:59 PDT ---
Created an attachment (id=47666)
--> (https://bugs.freedesktop.org/attachment.cgi?id=47666)
Further tests
Hi, your test application crashes on my system with and without the pa
On Mon, Jun 6, 2011 at 22:11, Arnd Bergmann wrote:
> On Monday 06 June 2011 22:07:53 Geert Uytterhoeven wrote:
>>
>> This fixes a.o.
>>
>> drivers/ide/ide-io.c: In function ?ide_lock_host?:
>> drivers/ide/ide-io.c:415: warning: passing argument 2 of
>> ?__constant_test_and_set_bit? discards quali
1 - 100 of 135 matches
Mail list logo
