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
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 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
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 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 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 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
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 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 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 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 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
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
https://bugs.freedesktop.org/show_bug.cgi?id=60802
Alex Deucher changed:
What|Removed |Added
Summary|(bisect |Corruption with DMA ring on
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 ---
(In reply to comment #5)
> (In reply to comment #4)
> > bisected and first bad commit is: 8696e33f06b0c52195152cc6a0e3d52233f486c1
> > commit 8696e33f06b0c52195152cc6a0e3d52233f486c1
> > Author: Alex Deuch
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=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 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=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
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
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
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.
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
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 +
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 +
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
https://bugs.freedesktop.org/show_bug.cgi?id=56405
Mike Lothian changed:
What|Removed |Added
CC||m...@fireburn.co.uk
--- Comment #55 from
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
--- 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=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
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=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
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=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=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
[+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
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
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
> Date: Sun Jan 20 17:32:21 2013 +0100
>
> drm: review locking for
>
> 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
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
>> 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
nts/20130218/4f292c30/attachment.html>
||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>
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 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/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
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>
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>
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
>
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>
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
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
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>
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.
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
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 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
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 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
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 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 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 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 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 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 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 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 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
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
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>
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)
> +
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 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 bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/b1b4b8ed/attachment.html>
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
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/
hment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/f699eb50/attachment.html>
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
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.
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
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 +
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>
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
93 matches
Mail list logo
