On Tue, Apr 1, 2014 at 5:45 PM, Daniel Vetter wrote:
> On Mon, Mar 31, 2014 at 06:03:24PM -0700, Matt Roper wrote:
>> On Fri, Mar 28, 2014 at 09:32:06AM +0100, Daniel Vetter wrote:
>> > On Thu, Mar 27, 2014 at 05:44:31PM -0700, Matt Roper wrote:
>> ...
>> > > + * N.B., we call set_config() direct
k space to
compile the patched kernel. didn't know it would eat up my last 12GB.
--
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
(Arch linux)
Mesa - 10.1.0
Radeon 7520G
--
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/20140402/6b16fbbb/attachment.html>
chives/dri-devel/attachments/20140402/b7221e41/attachment.html>
ves/dri-devel/attachments/20140402/bf4ac2b0/attachment-0001.html>
Hi Inki,
I see you have took also ld9040 driver patch [1].
Could you take the 3rd version of this patch [2].
It fixes build dependencies.
[1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/102592
[2]: http://permalink.gmane.org/gmane.comp.video.dri.devel/102659
Thanks and Regards
Andrzej
Drop the cast from the pointer diff to fix:
drivers/gpu/drm/i915/i915_cmd_parser.c:405:4: warning: format '%td' expects
argument of type 'ptrdiff_t', but argument 5 has type 'long unsigned int'
[-Wformat]
While at it, use %u for u32.
Reported-by: Randy Dunlap
Signed-off-by: Jani Nikula
---
R
On Mon, Mar 31, 2014 at 03:27:54PM +0300, Lauri Kasanen wrote:
> Clients like i915 need to segregate cache domains within the GTT which
> can lead to small amounts of fragmentation. By allocating the uncached
> buffers from the bottom and the cacheable buffers from the top, we can
> reduce the amou
Many drm connectors do not need mode validation.
The patch makes this callback optional and removes dumb implementations.
Signed-off-by: Andrzej Hajda
---
Hi,
This patch is based on the latest drm-next.
I have removed all dumb implementations except for qxl_display.c,
which is not entirely dumb
Clients like i915 need to segregate cache domains within the GTT which
can lead to small amounts of fragmentation. By allocating the uncached
buffers from the bottom and the cacheable buffers from the top, we can
reduce the amount of wasted space and also optimize allocation of the
mappable portion
On Wed, Apr 02, 2014 at 10:34:04AM +0200, Andrzej Hajda wrote:
> Many drm connectors do not need mode validation.
> The patch makes this callback optional and removes dumb implementations.
>
> Signed-off-by: Andrzej Hajda
> ---
> Hi,
>
> This patch is based on the latest drm-next.
> I have remov
Hi,
I was trying to figure out how we are supposed to manage synchronization
between a mode_set and a page_flip called on a crtc.
Say, if a mode_set is immediately followed by a page_flip. The driver
can't process the page_flip straight away since the hardware is still
completing the mode_set.
ee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140402/c3561c3d/attachment.html>
dri-devel/attachments/20140402/047fffe8/attachment.html>
Many drm connectors do not need mode validation.
The patch makes this callback optional and removes dumb implementations.
Signed-off-by: Andrzej Hajda
---
v2:
- added comment and updated DocBook
---
Documentation/DocBook/drm.tmpl | 6 +++---
drivers/gpu/drm/ast/ast_mode.c
Nice idea, but I wouldn't put the decision where to place the buffer
into TTM based on it's size.
Instead please make that a proper TTM placement flag because for example
for VM page tables we want them to be at the end of VRAM, not because
they are big (which they are anyway) but because they
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/cik.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index dd545521..448da65 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/driver
Need to swap on BE.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/cik.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 9bfd3d3..dd545521 100644
--- a/drivers/gpu/drm/
On Wed, Apr 2, 2014 at 5:52 AM, Archit Taneja wrote:
> Hi,
>
> I was trying to figure out how we are supposed to manage synchronization
> between a mode_set and a page_flip called on a crtc.
>
> Say, if a mode_set is immediately followed by a page_flip. The driver can't
> process the page_flip str
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140402/0b571cb4/attachment.html>
On 04/01/2014 02:37 PM, Inki Dae wrote:
> This patch adds super device support to bind sub drivers
> using device tree.
>
> For this, you should add a super device node to each machine dt files
> like belows,
>
> In case of using MIPI-DSI,
> display-subsystem {
> compatible =
On Wed, Apr 2, 2014 at 8:38 AM, Tomi Valkeinen wrote:
> At module unload, omap_fbdev_free() gets called which releases the
> framebuffers. However, the framebuffers are still used by crtcs, and
> will be released only later at vsync. The driver doesn't wait for this,
> and goes on to release the r
> -Original Message-
> From: Bruno Pr?mont [mailto:bonbons at linux-vserver.org]
> Sent: Tuesday, April 01, 2014 4:22 PM
> To: Justin Piszcz
> Cc: linux-kernel at vger.kernel.org; dri-devel at lists.freedesktop.org
> Subject: Re: X.org doesn't start with 3.14: [KMS] drm report modesetting
At the moment it's quite easy to get the following errors when the HDMI
output is enabled or disabled:
[drm:omap_crtc_error_irq] *ERROR* tv: errors: 8000
The reason for the errors is that the omapdrm driver doesn't properly
handle the sync-lost irqs that happen when enabling the DIGIT crtc,
w
At module unload, omap_fbdev_free() gets called which releases the
framebuffers. However, the framebuffers are still used by crtcs, and
will be released only later at vsync. The driver doesn't wait for this,
and goes on to release the rest of the resources, which often
causes a crash.
This patchs
On Wed, Mar 19, 2014 at 11:06 PM, David Herrmann
wrote:
> memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor
> that you can pass to mmap(). It explicitly allows sealing and
> avoids any connection to user-visible mount-points. Thus, it's not
> subject to quotas on mounted
On Tue, Mar 25, 2014 at 7:10 AM, Thierry Reding
wrote:
> On Mon, Mar 24, 2014 at 05:42:26PM +0900, Alexandre Courbot wrote:
> [...]
>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c
>> b/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c
> [...]
>> static int
>> -nvc0_bar_ctor(struct no
On Tue, Mar 25, 2014 at 7:34 AM, Thierry Reding
wrote:
> On Mon, Mar 24, 2014 at 05:42:28PM +0900, Alexandre Courbot wrote:
> [...]
>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/ibus/nvea.c
>> b/drivers/gpu/drm/nouveau/core/subdev/ibus/nvea.c
> [...]
>> +#include
>> +
>> +struct nvea_ibus_
On Wed, Mar 26, 2014 at 1:21 PM, Ben Skeggs wrote:
> On Tue, Mar 25, 2014 at 8:58 AM, Thierry Reding
> wrote:
>> On Mon, Mar 24, 2014 at 05:42:30PM +0900, Alexandre Courbot wrote:
>> [...]
>>> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>>> b/drivers/gpu/drm/nouveau/core/engine
On Wed, Mar 26, 2014 at 1:22 PM, Ben Skeggs wrote:
> On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot
> wrote:
>> Pad the microcode to a multiple of 0x40, otherwise firmware will fail to
>> run from non-prepadded firmware files.
>>
>> Signed-off-by: Alexandre Courbot
>> ---
>> drivers/gpu/dr
On Wed, Mar 26, 2014 at 1:24 PM, Ben Skeggs wrote:
> On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot
> wrote:
>> Add a GR device for GK20A based on NVE4, with the correct classes
>> definitions (GK20A's 3D class is 0xa297).
>>
>> Most of the NVE4 code can be used on GK20A, so make relevant bi
Hi,
Kindly hold the merging of this patch, i shall
update it with proper values, once i receive it from our hardware team.
Regards,
ShirisH S
On Thu, Mar 20, 2014 at 1:05 PM, St?phane Marchesin
wrote:
>
>
>
> On Wed, Mar 12, 2014 at 10:28 PM, Shirish S wrote:
>>
>> This patch adds support for the
.158142] [] (kthread+0xa4/0xb0) from []
(ret_from_fork+0x14/0x24)
Thanking you for your time.
Thanks & Regards,
Vikas
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140402/43e04a33/attachment-0001.html>
When unloading omapdrm driver, the omapdrm platform device is
uninitialized last, after the displays have been disconnected omap_crtc
callbacks have been removed. As the omapdrm pdev uninitialization needs
the features uninitialized in earlier steps, a crash is guaranteed.
This patch fixes the uni
At the moment the DMM driver is never unregistered, even if it's
registered in the omapdrm module's init function. This means we'll get
errors when reloading the omapdrm module.
Fix this by unregistering the DMM driver properly, and also change the
module init to fail if DMM driver cannot be regis
On Wed, Apr 2, 2014 at 8:37 AM, Tomi Valkeinen wrote:
> At the moment the DMM driver is never unregistered, even if it's
> registered in the omapdrm module's init function. This means we'll get
> errors when reloading the omapdrm module.
>
> Fix this by unregistering the DMM driver properly, and a
On Wed, Apr 2, 2014 at 8:37 AM, Tomi Valkeinen wrote:
> When unloading omapdrm driver, the omapdrm platform device is
> uninitialized last, after the displays have been disconnected omap_crtc
> callbacks have been removed. As the omapdrm pdev uninitialization needs
> the features uninitialized in
On Wed, Apr 2, 2014 at 9:52 AM, Alexandre Courbot wrote:
> On Tue, Mar 25, 2014 at 7:34 AM, Thierry Reding
> wrote:
>> On Mon, Mar 24, 2014 at 05:42:28PM +0900, Alexandre Courbot wrote:
>> [...]
>>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/ibus/nvea.c
>>> b/drivers/gpu/drm/nouveau/core/s
Hi
On Wed, Apr 2, 2014 at 3:38 PM, Konstantin Khlebnikov
wrote:
> On Wed, Mar 19, 2014 at 11:06 PM, David Herrmann
> wrote:
>> memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor
>> that you can pass to mmap(). It explicitly allows sealing and
>> avoids any connection to
On Wed, Apr 2, 2014 at 8:37 AM, Tomi Valkeinen wrote:
> At the moment it's quite easy to get the following errors when the HDMI
> output is enabled or disabled:
>
> [drm:omap_crtc_error_irq] *ERROR* tv: errors: 8000
>
> The reason for the errors is that the omapdrm driver doesn't properly
> ha
On Wed, Apr 2, 2014 at 10:14 AM, Alexandre Courbot wrote:
+ /* Need to figure out how to handle sw for gk20a */
+ if (device->chipset == 0xea)
+ goto skip_sw_init;
>>>
>>> The commit message makes it sound like SW isn't needed since gk20a
>>> "lacks any display h
On Wed, Apr 2, 2014 at 8:23 AM, Vikas Patil wrote:
> Hi,
> I am seeing following kernel backtrace on J6 with linux 3.8.13 when trying
> to start IVI LM service. Before starting this I started the X11 and run some
> GLES2/X11 based tests successfully.
>
> The same binaries and my graphics driver ar
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140402/4cb39089/attachment.html>
On Wed, 02 Apr 2014 13:00:00 +0200
Christian K?nig wrote:
> Nice idea, but I wouldn't put the decision where to place the buffer
> into TTM based on it's size.
>
> Instead please make that a proper TTM placement flag because for example
> for VM page tables we want them to be at the end of VRA
Am 02.04.2014 16:54, schrieb Lauri Kasanen:
> On Wed, 02 Apr 2014 13:00:00 +0200
> Christian K?nig wrote:
>
>> Nice idea, but I wouldn't put the decision where to place the buffer
>> into TTM based on it's size.
>>
>> Instead please make that a proper TTM placement flag because for example
>> for
signee for the bug.
-- next part ------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140402/fbef1c7b/attachment.html>
On Wed, Mar 26, 2014 at 1:27 PM, Ben Skeggs wrote:
> On Tue, Mar 25, 2014 at 9:10 AM, Thierry Reding
> wrote:
>> On Mon, Mar 24, 2014 at 05:42:33PM +0900, Alexandre Courbot wrote:
>>> GK20A does not embed a dedicated COPY engine and thus cannot allocate
>>> the copy channel that nouveau_accel_ini
On 04/02/2014 01:24 AM, Jani Nikula wrote:
> Drop the cast from the pointer diff to fix:
>
> drivers/gpu/drm/i915/i915_cmd_parser.c:405:4: warning: format '%td' expects
> argument of type 'ptrdiff_t', but argument 5 has type 'long unsigned int'
> [-Wformat]
>
> While at it, use %u for u32.
>
> R
On Wed, Apr 2, 2014 at 11:18 PM, Ilia Mirkin wrote:
> On Wed, Apr 2, 2014 at 9:52 AM, Alexandre Courbot wrote:
>> On Tue, Mar 25, 2014 at 7:34 AM, Thierry Reding
>> wrote:
>>> On Mon, Mar 24, 2014 at 05:42:28PM +0900, Alexandre Courbot wrote:
>>> [...]
diff --git a/drivers/gpu/drm/nouveau/c
On Wed, Apr 2, 2014 at 6:18 PM, David Herrmann wrote:
> Hi
>
> On Wed, Apr 2, 2014 at 3:38 PM, Konstantin Khlebnikov
> wrote:
>> On Wed, Mar 19, 2014 at 11:06 PM, David Herrmann
>> wrote:
>>> memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor
>>> that you can pass to mm
we're out of memory, or the driver is already register, or some other
similar situation.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140402/5b5dd953/attachment.sig>
On Wed, Mar 26, 2014 at 1:28 PM, Ben Skeggs wrote:
> On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot
> wrote:
>> Set the correct subdev/engine classes when GK20A (0xea) is probed.
>>
>> Signed-off-by: Alexandre Courbot
>> ---
>> drivers/gpu/drm/nouveau/core/engine/device/nve0.c | 20 +++
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140402/577583ee/attachment.html>
archives/dri-devel/attachments/20140402/b6b5c3cf/attachment-0001.html>
Hello Martin Peres,
The patch 18acc6d84eba: "drm/nouveau/bios: fetch the vbios from PROM
using only aligned 32-bit accesses" from Mar 25, 2014, leads to the
following static checker warning:
drivers/gpu/drm/nouveau/core/subdev/bios/base.c:191
nouveau_bios_shadow_prom()
error: pot
Clients like i915 need to segregate cache domains within the GTT which
can lead to small amounts of fragmentation. By allocating the uncached
buffers from the bottom and the cacheable buffers from the top, we can
reduce the amount of wasted space and also optimize allocation of the
mappable portion
This decreases eviction by up to 20%, by improving the fragmentation
quality. No harm in normal cases that fit VRAM fully (PTS gaming suite).
In some cases, even the VRAM-fitting cases improved slightly (openarena, urban
terror).
512kb was measured as the most optimal threshold for 3d workloads
On Wed, Apr 2, 2014 at 1:04 PM, Lauri Kasanen wrote:
> This decreases eviction by up to 20%, by improving the fragmentation
> quality. No harm in normal cases that fit VRAM fully (PTS gaming suite).
>
> In some cases, even the VRAM-fitting cases improved slightly (openarena,
> urban terror).
>
>
nfiguration files).
--
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/20140402/5b89a8a6/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140402/728870de/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140402/c8389f4e/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140402/6d16b7d9/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140402/41154fed/attachment.html>
is 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/20140402/ae331986/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140402/3b4d38fb/attachment.html>
This decreases eviction by up to 20%, by improving the fragmentation
quality. No harm in normal cases that fit VRAM fully (PTS gaming suite).
In some cases, even the VRAM-fitting cases improved slightly (openarena, urban
terror).
512kb was measured as the most optimal threshold for 3d workloads
https://bugzilla.kernel.org/show_bug.cgi?id=40762
steve_northover at hotmail.com changed:
What|Removed |Added
CC||steve_northover at hotmail
try to ssh into the box and change the modes using xrandr directly.
--
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/20140402/9c4ad7b6/attachment.html>
Am 02.04.2014 19:33, schrieb Lauri Kasanen:
> This decreases eviction by up to 20%, by improving the fragmentation
> quality. No harm in normal cases that fit VRAM fully (PTS gaming suite).
>
> In some cases, even the VRAM-fitting cases improved slightly (openarena,
> urban terror).
>
> 512kb was
||
--
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/20140402/009a4824/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140402/7c36e437/attachment.html>
t it got the
core rendering of frames done without stuttering. The XVBA part was not that
ideal though.
--
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/20140402/f1c0b0dc/attachment.html>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140402/9b960a7d/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140402/80f96b55/attachment.html>
ople on this mailing list have probably no idea how XBMC
internally works making it difficult to help us.
--
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/arc
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140402/85faf0f9/attachment.html>
With this commit:
2a0788dc9bc4 x86: Use clflushopt in drm_clflush_virt_range
If clflushopt is available on the system, we use it instead of clflush
in drm_clflush_virt_range. There were two calls to clflush in this
function, but only one was changed to clflushopt. This patch changes
the other c
From: Rahul Sharma
Exynos drm hdmi driver used to get dummy hdmiphy clock to
control the PMU bit for hdmiphy. This clock is removed
during CCF migration. This should also be cleaned from
hdmi driver.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_hdmi.c |8
1 file c
From: Rahul Sharma
Hdmiphy control bit needs to be set before setting the resolution
to hdmi hardware. This was handled using dummy hdmiphy clock which
is removed now.
PMU is already defined as system controller for exynos SoC. Registers
of PMU are accessed using regmap interfaces.
Devicetree b
From: Rahul Sharma
Cleaning up unnecessary i2c read call after hdmiphy configuration.
This check is redundant since check for hdmiphy pll lock status
confirms the correct settings for phy.
Signed-off-by: Rahul Sharma
Signed-off-by: Daniel Kurtz
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 10
From: Rahul Sharma
Enable support for hdmi for exynos5420 hdmiphy. Add
compatible string in the of_match table. Also added
hdmiphy configuration values for exynos5420.
Signed-off-by: Rahul Sharma
Signed-off-by: Shirish S
---
.../devicetree/bindings/video/exynos_hdmi.txt |1 +
drivers
From: Rahul Sharma
Adds apb mapped phy support for exynos5420 hdmi. Replace
dummy hdmiphy clock with regmap calls.
Based on Inki Dae's exynos-drm-next branch.
Rahul Sharma (5):
drm/exynos: remove dummy hdmiphy clock from hdmi driver
drm/exynos: use regmap interface to set hdmiphy control bi
From: Rahul Sharma
Previous SoCs have hdmi phys which are accessible through
dedicated i2c lines. Newer SoCs have Apb mapped hdmi phys.
Hdmi driver is modified to support apb mapped phys.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 142 +-
83 matches
Mail list logo
