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
> Date: Sun Jan 20 17:32:21 2013 +0100
>
> drm: review locking for
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 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:
> >> htt
[+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
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #8 from Alexandre Demers ---
Culprit commit in mesa identified as:
325422c49449acdd8df1eb2ca8ed81f7696c38cc is the first bad commit
commit 325422c49449acdd8df1eb2ca8ed81f7696c38cc
Author: Jerome Glisse
Date: Mon Jan 7 17:45:59 201
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 g
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:
> >> htt
[+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
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 patch
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 in
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
---
drivers/gpu/drm/drm
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.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #7 from Alexandre Demers ---
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 kernel patch over 3.8.0 (afte
https://bugs.freedesktop.org/show_bug.cgi?id=49981
--- Comment #30 from Chav ---
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 multi-head profile han
https://bugs.freedesktop.org/show_bug.cgi?id=60236
--- Comment #36 from Alexandre Demers ---
It doesn't apply correctly on kernel 3.8.0
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@list
Hi Daniel,
On Fri, 15 Feb 2013 08:16:26 -0800 Jesse Barnes
wrote:
>
> On Fri, 15 Feb 2013 10:30:16 +0100
> Daniel Vetter wrote:
>
> > On Fri, Feb 15, 2013 at 3:37 AM, Stephen Rothwell
> > wrote:
> > >
> > > After merging the drm-intel tree, today's linux-next build (x86_64
> > > allmodconfig
https://bugs.freedesktop.org/show_bug.cgi?id=50655
--- Comment #36 from Bryan Quigley ---
I believe this bug is now triggered much faster (within 10 seconds of starting
one of these games). But on the plus side it seems to usually just crash the
game in question. (Running xorg-edgers (git) on U
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 me
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #57 from Mike Lothian ---
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 mail because:
You a
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #56 from Mike Lothian ---
Created attachment 75082
--> https://bugs.freedesktop.org/attachment.cgi?id=75082&action=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
Mike Lothian changed:
What|Removed |Added
CC||m...@fireburn.co.uk
--- Comment #55 from
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
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 repl
hment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/f699eb50/attachment.html>
p 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/
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 b
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)
> +
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
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: drivers/gpu/drm/tegra/drm.h
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/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 B
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 consider
the 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
bug down.
--
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/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 m
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 scanned
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 tegra_dc_ad
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 +
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 t
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 - vm-
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 used
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:
ver = {
OMAPDSS_DEFAULT_PANEL_OPS, /* macro for 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 when
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 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 in
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 patch
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 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
---
drivers/gpu/drm/drm
t 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>
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 me
https://bugs.freedesktop.org/show_bug.cgi?id=59982
--- Comment #16 from Alex Deucher ---
(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 to set this bi
https://bugs.freedesktop.org/show_bug.cgi?id=59982
--- Comment #15 from Brian King ---
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 there anyway to dump the ad
s:
>
> 1. drm reports that 2 connectors: LVDS & 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. T
ne with the given CRTC. 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>
cause typically each CRTC would run at a 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>
ould even 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 b
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 f
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 drm-ne
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 be p
https://bugs.freedesktop.org/show_bug.cgi?id=60969
--- Comment #3 from Alex Deucher ---
Created attachment 75046
--> https://bugs.freedesktop.org/attachment.cgi?id=75046&action=edit
possible fix
Does this patch help?
--
You are receiving this mail because:
You are the assignee for the bug.
_
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 when
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #6 from Alexandre Demers ---
(In reply to comment #5)
> (In reply to comment #4)
> > bisected and first bad commit is: 8696e33f06b0c52195152cc6a0e3d52233f486c1
> > commit 8696e33f06b0c52195152cc6a0e3d52233f486c1
> > Author: Alex Deuch
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
Alex Deucher changed:
What|Removed |Added
Summary|(bisect |Corruption with DMA ring on
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 g
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
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 b
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 f
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 m
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 drm-ne
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
+++ b/drivers/stagin
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 - vm-
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 t
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 used
||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>
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:
__
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
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
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 repl
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 boo
93 matches
Mail list logo
