This patch adds library and test application for g2d gpu(fimg2d).
The fimg2d hardware is a 2D graphics accelerator(G2D) that
supports Bit Block Transfer(BitBLT).
The library includes the following primitive drawing operations:
.solid fill - This operation fills the given buffer with
the
On Tue, 2013-02-19 at 00:43 +0100, Jiri Slaby wrote:
> On 02/19/2013 12:23 AM, Marcin Slusarz wrote:
> > On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote:
> >> Hi,
> >>
> >> we have a report of WARNING from 3.7.6 in nouveau at
> >> drivers/gpu/drm/nouveau/core/core/mm.c:242 here:
> >>
[+cc Marcin Slusarz, dri-devel]
On Tue, 2013-02-19 at 00:21 +, Christoph Lameter wrote:
> The problem is that the subsystem attempted to call kfree with a pointer
> that was not obtained via a slab allocation.
>
> On Sat, 16 Feb 2013, Denys Fedoryshchenko wrote:
>
> > Hi
> >
> > Worked for
The existing gtt setup code is correct - and so doesn't need to be fixed to
handle compact dma scatter lists similarly to the previous patches. Still,
take the for_each_sg_page macro into use, to get somewhat simpler code.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 67
So far we created a sparse dma scatter list for gem objects, where each
scatter list entry represented only a single page. In the future we'll
have to handle compact scatter lists too where each entry can consist of
multiple pages, for example for objects imported through PRIME.
The previous
So far the assumption was that each dma scatter list entry contains only
a single page. This might not hold in the future, when we'll introduce
compact scatter lists, so prepare for this everywhere in the i915 code
where we walk such a list.
We'll fix the place _creating_ these lists separately
So far the assumption was that each scatter list entry contains a single
page. This might not hold in the future, when we'll introduce compact
scatter lists, so prepare for this here.
Reference: http://www.spinics.net/lists/dri-devel/msg33917.html
Signed-off-by: Imre Deak
---
This series adds support for handling compact dma scatter lists to the
i915 driver. This is a dependency for the related upcoming change in the
PRIME interface:
http://www.spinics.net/lists/dri-devel/msg33917.html
v2:
- Add the sg_for_each_page macro to /lib/scatterlist instead of
drivers/drm.
On Mon, Feb 18, 2013 at 12:16:50PM +0200, Tomi Valkeinen wrote:
> On 2013-02-18 12:03, Daniel Vetter wrote:
> > On Mon, Feb 18, 2013 at 10:02 AM, Tomi Valkeinen wrote:
> >> But my main concern for this series is still that it creates custom
> >> panel stuff, and adds DT bindings for them. Which
On 02/18/2013 04:40 PM, Mark Zhang wrote:
> On 02/18/2013 03:20 PM, Thierry Reding wrote:
[...]
>>
>
> Actually the dc which connects with LVDS doesn't know about 1080p
> stuffs. All the video mode infos stored in this dc is still 1366x768(I
> just checked the register values on my Tegra 30
On Monday 18 February 2013 02:01 PM, Tomi Valkeinen wrote:
> On 2013-02-18 09:23, Archit Taneja wrote:
>
diff --git a/drivers/staging/omapdrm/omap_connector.c
b/drivers/staging/omapdrm/omap_connector.c
index 4cc9ee7..839c6e4 100644
--- a/drivers/staging/omapdrm/omap_connector.c
On 02/18/2013 03:20 PM, Thierry Reding wrote:
> On Mon, Feb 18, 2013 at 03:06:10PM +0800, Mark Zhang wrote:
>> On 02/18/2013 02:48 PM, Thierry Reding wrote:
>>> On Mon, Feb 18, 2013 at 02:17:53PM +0800, Mark Zhang wrote:
On 02/14/2013 12:05 AM, Thierry Reding wrote:
> The sequence for
bed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/f699eb50/attachment.html>
the adapter to determine its state when we hit the
timeout?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/e6028
On Wed, Feb 13, 2013 at 07:40:05PM +0100, Daniel Vetter wrote:
> On Tue, Jan 22, 2013 at 7:55 PM, David Woodhouse
> wrote:
> > On Mon, 2013-01-21 at 19:48 +0100, Daniel Vetter wrote:
> >> We already have the quirk entry for the mobile platform, but also
> >> reports on some desktop versions. So
Hi Steffen,
On 2013-01-25 11:01, Steffen Trumtrar wrote:
> +/* VESA display monitor timing parameters */
> +#define VESA_DMT_HSYNC_LOW BIT(0)
> +#define VESA_DMT_HSYNC_HIGH BIT(1)
> +#define VESA_DMT_VSYNC_LOW BIT(2)
> +#define VESA_DMT_VSYNC_HIGH BIT(3)
> +
Hi Thierry,
Which version is this patch set based on? I tried to apply it on
linux-next 0206 & tot 0215 but failed:
Applying: drm: Add consistency check for page-flipping
Applying: drm/tegra: Add plane support
error: patch failed: drivers/gpu/drm/tegra/drm.h:121
error:
On 02/18/2013 03:01 PM, Thierry Reding wrote:
> On Mon, Feb 18, 2013 at 02:55:04PM +0800, Mark Zhang wrote:
>> On 02/18/2013 02:40 PM, Thierry Reding wrote:
>>> On Mon, Feb 18, 2013 at 02:06:56PM +0800, Mark Zhang wrote:
On 02/14/2013 12:05 AM, Thierry Reding wrote:
> Add support for the
On 02/18/2013 02:48 PM, Thierry Reding wrote:
> On Mon, Feb 18, 2013 at 02:17:53PM +0800, Mark Zhang wrote:
>> On 02/14/2013 12:05 AM, Thierry Reding wrote:
>>> The sequence for replacing the scanout buffer is much shorter than a
>>> full mode change operation so implementing this callback
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/b1b4b8ed/attachment.html>
On 02/18/2013 02:40 PM, Thierry Reding wrote:
> On Mon, Feb 18, 2013 at 02:06:56PM +0800, Mark Zhang wrote:
>> On 02/14/2013 12:05 AM, Thierry Reding wrote:
>>> Add support for the B and C planes which support RGB and YUV pixel
>>> formats and can be used as overlays or hardware cursor. Currently
On 2013-02-18 14:35, Rob Clark wrote:
> On Mon, Feb 18, 2013 at 7:32 AM, Tomi Valkeinen wrote:
>> On 2013-02-18 14:26, Rob Clark wrote:
>>
>>> So I'm not going to get too hung up on supporting current DT bindings
>>> in the future when we have something better. But I needed something
>>
>> I may
eceiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/65831fb3/attachment.html>
On 2013-02-18 14:26, Rob Clark wrote:
> So I'm not going to get too hung up on supporting current DT bindings
> in the future when we have something better. But I needed something
I may be mistaken, but my understanding is that DT bindings are like
kernel's userspace APIs. After they have been
On 02/18/2013 02:17 PM, Mark Zhang wrote:
> On 02/14/2013 12:05 AM, Thierry Reding wrote:
>> The sequence for replacing the scanout buffer is much shorter than a
>> full mode change operation so implementing this callback considerably
>> speeds up cases where only a new framebuffer is to be
On 02/14/2013 12:05 AM, Thierry Reding wrote:
> The sequence for replacing the scanout buffer is much shorter than a
> full mode change operation so implementing this callback considerably
> speeds up cases where only a new framebuffer is to be scanned out.
>
> Signed-off-by: Thierry Reding
>
On 02/14/2013 12:05 AM, Thierry Reding wrote:
> Add support for the B and C planes which support RGB and YUV pixel
> formats and can be used as overlays or hardware cursor. Currently
> only 32-bit RGBA pixel formats are advertised.
>
> Signed-off-by: Thierry Reding
[...]
> +static int
g this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/10d8a84d/attachment.html>
On Thursday 14 February 2013 09:24 PM, Rob Clark wrote:
> On Thu, Feb 14, 2013 at 6:52 AM, Archit Taneja wrote:
>> The omapdrm driver requires omapdss panel drivers to expose ops like detect,
>> set_timings and check_timings. These can be NULL for fixed panel DPI, DBI,
>> DSI
>> and SDI drivers.
On 2013-02-18 12:03, Daniel Vetter wrote:
> On Mon, Feb 18, 2013 at 10:02 AM, Tomi Valkeinen wrote:
>> But my main concern for this series is still that it creates custom
>> panel stuff, and adds DT bindings for them. Which means we need to
>> support those custom DT bindings in the future, even
Hi,
we have a report of WARNING from 3.7.6 in nouveau at
drivers/gpu/drm/nouveau/core/core/mm.c:242 here:
https://bugzilla.novell.com/show_bug.cgi?id=802347#c11
There is an order 4 allocation failure in nouveau_drm_open ->
nouveau_vm_create, i.e. this one failed:
vm->pgt = kcalloc(vm->lpde -
On Mon, Feb 18, 2013 at 10:02 AM, Tomi Valkeinen wrote:
> But my main concern for this series is still that it creates custom
> panel stuff, and adds DT bindings for them. Which means we need to
> support those custom DT bindings in the future, even though it's quite
> sure that CDF should be
On 2013-02-18 01:02, Rob Clark wrote:
> Hi Dave,
>
> Here is pull request for tilcdc drm driver.. it also includes a
> handful of dependent patches from me, plus a couple fixes from Daniel
> Vetter which haven't showed up yet in drm-next.
Why is the TFP410 driver integrated into the tilcdc, but
Patrik Jakobsson wrote:
> I've sent in a patch for this:
> http://lists.freedesktop.org/archives/dri-devel/2013-February/034990.html
> it is slightly different to what I proposed earlier. Would be nice if you
> could
> give it a spin and report back.
Seems to be ok.
Tested-by:
default ops */
.enable = my_panel_enable,
/* ... */
};
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/9878bfb7/attachment.pgp>
>> I'm unsure if I like this or not, and I don't see why its greatly more
>> useful than the interface we have now.
>
> This interface at least solves the problem with having vesafb,
> uvesafb, vgacon, vga16fb, efifb, dvbe, defi and all other similar
> drivers from accessing the system framebuffer
On Mon, Feb 18, 2013 at 7:40 AM, Tomi Valkeinen wrote:
> On 2013-02-18 14:35, Rob Clark wrote:
>> On Mon, Feb 18, 2013 at 7:32 AM, Tomi Valkeinen wrote:
>>> On 2013-02-18 14:26, Rob Clark wrote:
>>>
So I'm not going to get too hung up on supporting current DT bindings
in the future
-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/d483d219/attachment.pgp>
DS & HDMI are present in the system
> 2. The resolution of them are: 1366x768 & 1080p
> 3. Userspace application allocates 2 fbs according to the resolution got
> above.
> 4. call drmModeSetCrtc to switch the fb shown in LVDS to the new fb we
> created.
> 5. At this time, remember the line stride setting in dc which connects
> with LVDS is calculated according to the 1080p resolution. So finally we
> got a corrupt display because we're showing a 1366x768 fb but with
> 1080p's line stride.
I don't see how the 1080p stride would still be relevant here. Setting
the LVDS to the new 1366x768 framebuffer should trigger a full modeset
and therefore set the stride to the value required by the new 1366x768
framebuffer.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/7e6a3642/attachment.pgp>
>
> This series tries to fix the mess with global system framebuffer access in
> device drivers. Currently, architecture initialization sets the "screen_info"
> object according to the system framebuffer that was detected during boot. The
> device driver that can map VMEM first gets access to it.
TC. So if we deallocate the memory when the
plane when it is disabled, we'd have to make sure to remove it from the
core as well. However that would also mean that it disappears from the
list of planes supported by the CRTC and therefore we wouldn't be able
to use it again.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/ced5735c/attachment.pgp>
different
frequency (or even if both ran at the same frequency the VBLANK is very
unlikely to coincide anyway).
So an application that wants to support page-flipping on two outputs
also needs to take care to set them up with different framebuffers, in
which case what you're describing here can't really happen.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/ef80737a/attachment.pgp>
work,
since the planes are resources that need to be registered with the DRM
core and therefore can't be allocated on-demand.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/6dfd1e1d/attachment.pgp>
On Mon, Feb 18, 2013 at 7:32 AM, Tomi Valkeinen wrote:
> On 2013-02-18 14:26, Rob Clark wrote:
>
>> So I'm not going to get too hung up on supporting current DT bindings
>> in the future when we have something better. But I needed something
>
> I may be mistaken, but my understanding is that DT
On Mon, Feb 18, 2013 at 5:03 AM, Daniel Vetter wrote:
> On Mon, Feb 18, 2013 at 10:02 AM, Tomi Valkeinen wrote:
>> But my main concern for this series is still that it creates custom
>> panel stuff, and adds DT bindings for them. Which means we need to
>> support those custom DT bindings in the
On Mon, Feb 18, 2013 at 4:02 AM, Tomi Valkeinen wrote:
> On 2013-02-18 01:02, Rob Clark wrote:
>> Hi Dave,
>>
>> Here is pull request for tilcdc drm driver.. it also includes a
>> handful of dependent patches from me, plus a couple fixes from Daniel
>> Vetter which haven't showed up yet in
on
||Cayman)
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/e1bd1539/attachment.html>
nts/20130218/4f292c30/attachment.html>
Hi Dave
On Sun, Feb 17, 2013 at 11:02 PM, Dave Airlie wrote:
>>
>> This series tries to fix the mess with global system framebuffer access in
>> device drivers. Currently, architecture initialization sets the "screen_info"
>> object according to the system framebuffer that was detected during
On 02/18/2013 03:20 PM, Thierry Reding wrote:
On Mon, Feb 18, 2013 at 03:06:10PM +0800, Mark Zhang wrote:
On 02/18/2013 02:48 PM, Thierry Reding wrote:
On Mon, Feb 18, 2013 at 02:17:53PM +0800, Mark Zhang wrote:
On 02/14/2013 12:05 AM, Thierry Reding wrote:
The sequence for replacing the
On 2013-02-18 01:02, Rob Clark wrote:
Hi Dave,
Here is pull request for tilcdc drm driver.. it also includes a
handful of dependent patches from me, plus a couple fixes from Daniel
Vetter which haven't showed up yet in drm-next.
Why is the TFP410 driver integrated into the tilcdc, but the
On 02/18/2013 04:40 PM, Mark Zhang wrote:
On 02/18/2013 03:20 PM, Thierry Reding wrote:
[...]
Actually the dc which connects with LVDS doesn't know about 1080p
stuffs. All the video mode infos stored in this dc is still 1366x768(I
just checked the register values on my Tegra 30 cardhu). The
Patrik Jakobsson wrote:
I've sent in a patch for this:
http://lists.freedesktop.org/archives/dri-devel/2013-February/034990.html
it is slightly different to what I proposed earlier. Would be nice if you
could
give it a spin and report back.
Seems to be ok.
Tested-by: d.muel...@elsoft.ch
On Mon, Feb 18, 2013 at 10:02 AM, Tomi Valkeinen to...@iki.fi wrote:
But my main concern for this series is still that it creates custom
panel stuff, and adds DT bindings for them. Which means we need to
support those custom DT bindings in the future, even though it's quite
sure that CDF
Hi,
we have a report of WARNING from 3.7.6 in nouveau at
drivers/gpu/drm/nouveau/core/core/mm.c:242 here:
https://bugzilla.novell.com/show_bug.cgi?id=802347#c11
There is an order 4 allocation failure in nouveau_drm_open -
nouveau_vm_create, i.e. this one failed:
vm-pgt = kcalloc(vm-lpde -
On Mon, Feb 18, 2013 at 4:02 AM, Tomi Valkeinen to...@iki.fi wrote:
On 2013-02-18 01:02, Rob Clark wrote:
Hi Dave,
Here is pull request for tilcdc drm driver.. it also includes a
handful of dependent patches from me, plus a couple fixes from Daniel
Vetter which haven't showed up yet in
On 2013-02-18 14:26, Rob Clark wrote:
So I'm not going to get too hung up on supporting current DT bindings
in the future when we have something better. But I needed something
I may be mistaken, but my understanding is that DT bindings are like
kernel's userspace APIs. After they have been
On Mon, Feb 18, 2013 at 5:03 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Mon, Feb 18, 2013 at 10:02 AM, Tomi Valkeinen to...@iki.fi wrote:
But my main concern for this series is still that it creates custom
panel stuff, and adds DT bindings for them. Which means we need to
support those custom
On Mon, Feb 18, 2013 at 7:32 AM, Tomi Valkeinen to...@iki.fi wrote:
On 2013-02-18 14:26, Rob Clark wrote:
So I'm not going to get too hung up on supporting current DT bindings
in the future when we have something better. But I needed something
I may be mistaken, but my understanding is that
On 2013-02-18 14:35, Rob Clark wrote:
On Mon, Feb 18, 2013 at 7:32 AM, Tomi Valkeinen to...@iki.fi wrote:
On 2013-02-18 14:26, Rob Clark wrote:
So I'm not going to get too hung up on supporting current DT bindings
in the future when we have something better. But I needed something
I may be
This patch adds library and test application for g2d gpu(fimg2d).
The fimg2d hardware is a 2D graphics accelerator(G2D) that
supports Bit Block Transfer(BitBLT).
The library includes the following primitive drawing operations:
.solid fill - This operation fills the given buffer with
the
https://bugs.freedesktop.org/show_bug.cgi?id=60802
Alex Deucher ag...@yahoo.com changed:
What|Removed |Added
Summary|(bisect |Corruption with DMA ring
Hi Steffen,
On 2013-01-25 11:01, Steffen Trumtrar wrote:
+/* VESA display monitor timing parameters */
+#define VESA_DMT_HSYNC_LOW BIT(0)
+#define VESA_DMT_HSYNC_HIGH BIT(1)
+#define VESA_DMT_VSYNC_LOW BIT(2)
+#define VESA_DMT_VSYNC_HIGH BIT(3)
+
+/*
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #6 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(In reply to comment #5)
(In reply to comment #4)
bisected and first bad commit is: 8696e33f06b0c52195152cc6a0e3d52233f486c1
commit
On Mon, Feb 18, 2013 at 7:40 AM, Tomi Valkeinen to...@iki.fi wrote:
On 2013-02-18 14:35, Rob Clark wrote:
On Mon, Feb 18, 2013 at 7:32 AM, Tomi Valkeinen to...@iki.fi wrote:
On 2013-02-18 14:26, Rob Clark wrote:
So I'm not going to get too hung up on supporting current DT bindings
in the
https://bugs.freedesktop.org/show_bug.cgi?id=60969
--- Comment #3 from Alex Deucher ag...@yahoo.com ---
Created attachment 75046
-- https://bugs.freedesktop.org/attachment.cgi?id=75046action=edit
possible fix
Does this patch help?
--
You are receiving this mail because:
You are the assignee
On Wed, Feb 13, 2013 at 07:40:05PM +0100, Daniel Vetter wrote:
On Tue, Jan 22, 2013 at 7:55 PM, David Woodhouse dw...@infradead.org wrote:
On Mon, 2013-01-21 at 19:48 +0100, Daniel Vetter wrote:
We already have the quirk entry for the mobile platform, but also
reports on some desktop
https://bugs.freedesktop.org/show_bug.cgi?id=59982
--- Comment #15 from Brian King brk...@linux.vnet.ibm.com ---
Can someone clarify something here? Is the bit that we are waiting to go low a
bit in the adapter's memory? If so, is it the adapter hardware that we are
waiting to set this bit?
Is
https://bugs.freedesktop.org/show_bug.cgi?id=59982
--- Comment #16 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #15)
Can someone clarify something here? Is the bit that we are waiting to go low
a bit in the adapter's memory? If so, is it the adapter hardware that we are
waiting
On Mon, Feb 18, 2013 at 12:16:50PM +0200, Tomi Valkeinen wrote:
On 2013-02-18 12:03, Daniel Vetter wrote:
On Mon, Feb 18, 2013 at 10:02 AM, Tomi Valkeinen to...@iki.fi wrote:
But my main concern for this series is still that it creates custom
panel stuff, and adds DT bindings for them.
So far the assumption was that each scatter list entry contains a single
page. This might not hold in the future, when we'll introduce compact
scatter lists, so prepare for this here.
Reference: http://www.spinics.net/lists/dri-devel/msg33917.html
Signed-off-by: Imre Deak imre.d...@intel.com
---
This series adds support for handling compact dma scatter lists to the
i915 driver. This is a dependency for the related upcoming change in the
PRIME interface:
http://www.spinics.net/lists/dri-devel/msg33917.html
v2:
- Add the sg_for_each_page macro to /lib/scatterlist instead of
drivers/drm.
So far we created a sparse dma scatter list for gem objects, where each
scatter list entry represented only a single page. In the future we'll
have to handle compact scatter lists too where each entry can consist of
multiple pages, for example for objects imported through PRIME.
The previous
So far the assumption was that each dma scatter list entry contains only
a single page. This might not hold in the future, when we'll introduce
compact scatter lists, so prepare for this everywhere in the i915 code
where we walk such a list.
We'll fix the place _creating_ these lists separately
On 2013-02-18 09:23, Archit Taneja wrote:
diff --git a/drivers/staging/omapdrm/omap_connector.c
b/drivers/staging/omapdrm/omap_connector.c
index 4cc9ee7..839c6e4 100644
--- a/drivers/staging/omapdrm/omap_connector.c
+++ b/drivers/staging/omapdrm/omap_connector.c
@@ -110,6 +110,11 @@ static
On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote:
Hi,
we have a report of WARNING from 3.7.6 in nouveau at
drivers/gpu/drm/nouveau/core/core/mm.c:242 here:
https://bugzilla.novell.com/show_bug.cgi?id=802347#c11
There is an order 4 allocation failure in nouveau_drm_open -
On 02/19/2013 12:23 AM, Marcin Slusarz wrote:
On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote:
Hi,
we have a report of WARNING from 3.7.6 in nouveau at
drivers/gpu/drm/nouveau/core/core/mm.c:242 here:
https://bugzilla.novell.com/show_bug.cgi?id=802347#c11
There is an order 4
https://bugs.freedesktop.org/show_bug.cgi?id=56405
Mike Lothian m...@fireburn.co.uk changed:
What|Removed |Added
CC||m...@fireburn.co.uk
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #56 from Mike Lothian m...@fireburn.co.uk ---
Created attachment 75082
-- https://bugs.freedesktop.org/attachment.cgi?id=75082action=edit
Dmesg output
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #57 from Mike Lothian m...@fireburn.co.uk ---
I got lots of radeon: The kernel rejected CS, see dmesg for more information.
from the wine process
If this is a separate issue I'll look into it more tomorrow
--
You are receiving this
Hi Daniel,
On Fri, 15 Feb 2013 08:16:26 -0800 Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Fri, 15 Feb 2013 10:30:16 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Fri, Feb 15, 2013 at 3:37 AM, Stephen Rothwell s...@canb.auug.org.au
wrote:
After merging the drm-intel
https://bugs.freedesktop.org/show_bug.cgi?id=60236
--- Comment #36 from Alexandre Demers alexandre.f.dem...@gmail.com ---
It doesn't apply correctly on kernel 3.8.0
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=49981
--- Comment #30 from Chav chav.re...@gmail.com ---
Macbook Pro 8,2 Late 2011 with Radeon 6750m like Ludovic Watteaux.
In order to get the power profile working with the kernel 3.8rc4 I had to
revert the following commits:
drm/radeon/pm: fix
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #7 from Alexandre Demers alexandre.f.dem...@gmail.com ---
So I followed bug 60236. I sync mesa since the proposed mesa patch had already
been pushed. I tested with kernel 3.8.0 and the bug was still there. I then
applied the proposed
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #8 from Alexandre Demers alexandre.f.dem...@gmail.com ---
Culprit commit in mesa identified as:
325422c49449acdd8df1eb2ca8ed81f7696c38cc is the first bad commit
commit 325422c49449acdd8df1eb2ca8ed81f7696c38cc
Author: Jerome Glisse
[+cc Marcin Slusarz, dri-devel]
On Tue, 2013-02-19 at 00:21 +, Christoph Lameter wrote:
The problem is that the subsystem attempted to call kfree with a pointer
that was not obtained via a slab allocation.
On Sat, 16 Feb 2013, Denys Fedoryshchenko wrote:
Hi
Worked for a while on
On Tue, 2013-02-19 at 00:43 +0100, Jiri Slaby wrote:
On 02/19/2013 12:23 AM, Marcin Slusarz wrote:
On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote:
Hi,
we have a report of WARNING from 3.7.6 in nouveau at
drivers/gpu/drm/nouveau/core/core/mm.c:242 here:
On Tue, Feb 19, 2013 at 12:43:06AM +0100, Jiri Slaby wrote:
On 02/19/2013 12:23 AM, Marcin Slusarz wrote:
On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote:
Hi,
we have a report of WARNING from 3.7.6 in nouveau at
drivers/gpu/drm/nouveau/core/core/mm.c:242 here:
On Fri, Feb 15, 2013 at 11:24:35AM +0100, Daniel Vetter wrote:
/me grabs a few brown paper bags
So it looks like I've broken compilation in
commit 6aed8ec3f76a22217c9ae183d32b1aa990bed069
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Sun Jan 20 17:32:21 2013 +0100
drm:
89 matches
Mail list logo
