If the atomic commit fails due to completion wait interruption the
atomic commit object is not freed and is thus leaked. Free it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/msm/msm_atomic.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_at
The kerneldoc blocks for the drm_atomic_helper_*_set_property()
functions seem to have been copied from the plane disable handler
without being properly updated. Fix them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_atomic_helper.c | 15 +--
1 file changed, 9 insertions(+
.
--
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/20150223/d5cc2837/attachment.html>
Signed-off-by: Liu Ying
---
drivers/gpu/drm/imx/parallel-display.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/imx/parallel-display.c
b/drivers/gpu/drm/imx/parallel-display.c
index 5e83e00..900dda6 100644
--- a/drivers/gpu/drm/imx/parallel-display.c
++
On 21.02.2015 01:56, Alex Deucher wrote:
> The atom aux param interface only supports 4 bits for
> the total write transfer size (header + payload). This
> limits us to 12 bytes of payload rather than 16. Add a
> check for this. Reads are not affected.
>
> Signed-off-by: Alex Deucher
> ---
> d
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/2ebe520a/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/2ebfd9df/attachment-0001.html>
=7692704b144b2aa9a57767a43212ceb5aad6638a
--
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/20150223/dfbb6e66/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=90861
--- Comment #13 from Maarten Lankhorst ---
Does attachment 166571 fix the bug for you too? I think that would be the best
version to upstream.
--
You are receiving this mail because:
You are watching the assignee of the bug.
Hi Michael -
Please always cc: the relevant mailing lists; done now.
On Sun, 22 Feb 2015, Michael Leuchtenburg wrote:
> Hi Jani,
>
> I've been trying to figure out how to control the dynamic backlight control
> on my new Dell XPS 13 since the defaults are atrocious - huge swings in
> brightness
On 22.02.2015 12:52, Daniel Vetter wrote:
> On Mon, Feb 16, 2015 at 01:43:07PM +0100, Volker Vogelhuber wrote:
>> I'm currently trying to setup a rendering pipe on an Intel Baytrail E3845
>> cpu.
>> In our product we want to have an FPGA streaming video images to a
>> predefined memory area using
On Sun, 22 Feb 2015, Daniel Vetter wrote:
> In
>
> daniel at phenom:~/linux/src$ git show ccfc08655
copy-paste fail?
J.
> commit ccfc08655d5fd5076828f45fb09194c070f2f63a
> Author: Rob Clark
> Date: Thu Dec 18 16:01:48 2014 -0500
>
> drm: tweak getconnector locking
>
> We need to extend t
Hi Dave,
Two amdkfd fixes for -rc2:
- Fix a bug that caused 15% CPU performance drop in Kaveri. This was caused
because we overwritten the initialization of the first pipe (out of eight),
which is dedicated to radeon operation. The fix was tested by Michel Dänzer.
This bug was introduced
On Mon, Feb 23, 2015 at 09:22:56AM +0100, Volker Vogelhuber wrote:
>
> On 22.02.2015 12:52, Daniel Vetter wrote:
> >On Mon, Feb 16, 2015 at 01:43:07PM +0100, Volker Vogelhuber wrote:
> >>I'm currently trying to setup a rendering pipe on an Intel Baytrail E3845
> >>cpu.
> >>In our product we want t
On Mon, Feb 23, 2015 at 02:50:23AM +0200, Laurent Pinchart wrote:
> The kerneldoc blocks for the drm_atomic_helper_*_set_property()
> functions seem to have been copied from the plane disable handler
> without being properly updated. Fix them.
>
> Signed-off-by: Laurent Pinchart
Merged to drm-mi
On 17/02/15 16:10, Frank Binns wrote:
> Hi Emil,
>
> On 13/02/15 16:38, Emil Velikov wrote:
>> Hi Frank,
>> On 13/02/15 10:51, Frank Binns wrote:
>>> Add a helper function that returns the type of device node from an fd.
>>>
>>> Signed-off-by: Frank Binns
>> Reviewed-by: Emil Velikov
>>
>> Thank
On Sun, Feb 22, 2015 at 03:11:20PM +0100, Daniel Vetter wrote:
> KMS drivers are in full control of their irq and vblank handling, if
> they get a vblank interrupt before drm_vblank_init or after
> drm_vblank_cleanup that's just a driver bug.
>
> For ums driver there's only r128 and radeon which s
On Sun, Feb 15, 2015 at 04:08:31PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Friday 13 February 2015 21:03:42 Daniel Vetter wrote:
> > At driver load we need to tell the vblank code about the state of the
> > pipes, so that the logic around reject vblank_get
On 02/22/2015 06:51 PM, Sylvain Rochet wrote:
> On suspend: switch off CRTC if not already suspended with runtime PM
>
> On resume: switch on CRTC if we were not already suspended from runtime
> PM while suspending.
>
> Signed-off-by: Sylvain Rochet
Reviewed-by: Andrzej Hajda
Regards
Andrzej
On Sun, Feb 22, 2015 at 08:17:04PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Sunday 22 February 2015 19:53:23 Laurent Pinchart wrote:
> > On Sunday 22 February 2015 12:24:20 Daniel Vetter wrote:
> > > With runtime PM the hw might still be off while doing the ->mode_set
> > > callbacks - r
On 16/02/15 23:05, Mikko Rapeli wrote:
> Fixes compilation error:
>
> drm/drm.h:132:2: error: unknown type name âsize_tâ
>
Hi Mikko,
Can you let us know how you're getting these (series-wise) errors ? I've
been meaning to sync the uapi/drm and libdrm headers and would be nice
to have an ext
On Sun, Feb 22, 2015 at 11:59 PM, Jani Nikula wrote:
>
> Hi Michael -
>
> Please always cc: the relevant mailing lists; done now.
>
> On Sun, 22 Feb 2015, Michael Leuchtenburg wrote:
>> Hi Jani,
>>
>> I've been trying to figure out how to control the dynamic backlight control
>> on my new Dell XP
Hi Sylvain,
On Sun, 22 Feb 2015 18:51:02 +0100
Sylvain Rochet wrote:
> This series adds basic PM support for Atmel HLCDC.
>
> This series depends on:
>
> [PATCH] drm: atmel-hlcdc: remove useless pm_runtime_put_sync in probe
> <1423841785-23105-1-git-send-email-boris.brezillon at free-electro
The DRM_KMS_FB_HELPER config is selected only when DRM_MSM_FBDEV config is
selected. The driver accesses drm_fb_helper_* functions even when legacy fbdev
support is disabled in msm. Wrap around these functions with #ifdef checks to
prevent build break.
Signed-off-by: Archit Taneja
---
drivers/gp
Hi,
Since there now is a merge conflict in imx-drm-core, I've rebased the series
onto v4.0-rc1. Also a new driver touched by this change appeared, so the first
patch now includes a fix for am437x-vfpe, too. I'd be happy to get an ack for
that.
This series converts all existing users of of_graph_g
Note that while of_graph_get_next_endpoint decrements the reference count
of the child node passed to it, of_node_put(child) still has to be called
manually when breaking out of the loop.
Signed-off-by: Philipp Zabel
Acked-by: Laurent Pinchart
---
include/linux/of_graph.h | 11 +++
1 fi
This patch adds a function to get a port device tree node by port id,
or reg property value.
Signed-off-by: Philipp Zabel
Acked-by: Laurent Pinchart
---
drivers/of/base.c| 32
include/linux/of_graph.h | 7 +++
2 files changed, 39 insertions(+)
diff
Decrementing the reference count of the previous endpoint node allows to
use the of_graph_get_next_endpoint function in a for_each_... style macro.
All current users of this function that pass a non-NULL prev parameter
(that is, soc_camera and imx-drm) are changed to not decrement the passed
prev a
On 16/02/15 13:46, Tobias Jakobi wrote:
> The reason for this change is to let userspace use the header.
> Currently 'make install' does not install it.
>
Hi Tobias,
Afaict that this was done intentionally. I believe the Samsung guys got
this out only to fulfil the "no drm(render) driver without
On 16/02/15 13:46, Tobias Jakobi wrote:
> v2: Move the commit description into the patch itself.
> Signed-off-by: Tobias Jakobi
> ---
> tests/exynos/exynos_fimg2d_test.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/tests/exynos/exynos_fimg2d_test.c
> b/tests/exynos/exynos_fi
On 16/02/15 13:46, Tobias Jakobi wrote:
> Currently getchar() is used to pause execution after each test.
> The user isn't informed if one is supposed to do anything for
> the tests to continue, so print a simple message to make this
> more clear.
>
> Signed-off-by: Tobias Jakobi
> ---
> tests/e
On 16/02/15 13:46, Tobias Jakobi wrote:
> In almost all functions the base address register is written, so it
> makes sense to have a helper function for this.
>
> Signed-off-by: Tobias Jakobi
> ---
> exynos/exynos_fimg2d.c | 87
> +++---
> 1 file cha
On Mon, Feb 23, 2015 at 11:22:09AM +, Emil Velikov wrote:
> On 16/02/15 13:46, Tobias Jakobi wrote:
> > Currently getchar() is used to pause execution after each test.
> > The user isn't informed if one is supposed to do anything for
> > the tests to continue, so print a simple message to make
On 16/02/15 13:46, Tobias Jakobi wrote:
> Hello,
>
> here are some miscellaneous improvements (small features, bugfixes, spelling
> fixes, etc.) for the exynos component of libdrm. The general idea is to let
> userspace use the G2D engine functionality more
> efficiently.
>
> If someone is int
Hi Dave,
On to, 2015-02-19 at 15:42 +0200, Imre Deak wrote:
> On to, 2015-02-19 at 15:39 +0200, Imre Deak wrote:
> > On to, 2015-02-19 at 12:25 +, Dave Gordon wrote:
> > > On 12/02/15 22:38, Imre Deak wrote:
> > > > On Tue, 2015-02-03 at 11:30 +0100, Daniel Vetter wrote:
> > > >> UMS is no mor
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Damien Grassart changed:
What|Removed |Added
CC||damien at grassart.com
--- Comment #42
Currently most places assume reliable master <> render node mapping.
Although this may work in some cases, it is not correct.
Add a couple of helpers that hide the details and provide the name of
the master/render device name, given an render/master FD.
v2:
- Rename Device and Primary to Master
On Sun, Feb 22, 2015 at 5:38 AM, Daniel Vetter
wrote:
> In
>
> daniel at phenom:~/linux/src$ git show ccfc08655
> commit ccfc08655d5fd5076828f45fb09194c070f2f63a
> Author: Rob Clark
> Date: Thu Dec 18 16:01:48 2014 -0500
>
> drm: tweak getconnector locking
>
> We need to extend the locking
On Mon, 16 Feb 2015, Paul Bolle wrote:
> I still see this on v3.19. I booted with drm.debug=0x4. The almost 2K
> lines in dmesg containing either "[drm" or this WARNING are pasted
> below. I really know nothing about all this, but I do note that only the
> WARNINGS are preceded by:
> [drm:inte
On Mon, 23 Feb 2015, Jani Nikula wrote:
> On Mon, 16 Feb 2015, Paul Bolle wrote:
>> I still see this on v3.19. I booted with drm.debug=0x4. The almost 2K
>> lines in dmesg containing either "[drm" or this WARNING are pasted
>> below. I really know nothing about all this, but I do note that only t
On Mon, Feb 23, 2015 at 5:29 AM, Archit Taneja
wrote:
> The DRM_KMS_FB_HELPER config is selected only when DRM_MSM_FBDEV config is
> selected. The driver accesses drm_fb_helper_* functions even when legacy fbdev
> support is disabled in msm. Wrap around these functions with #ifdef checks to
> pre
Hi all,
A few small patches, that handle the initial step of building the whole
of libdrm with WARN_CFLAGS (-Wall -Wextra and friends).
The first patch makes sure we build everything at make distcheck time,
followed by a couple of warnings-turned-errors, and finally adding the
cflags everywher
To make sure that the release/distribution tarball is not broken for all
the targets. Currently the experimental APIs are disabled by default
amongst others.
Signed-off-by: Emil Velikov
---
Makefile.am | 16
1 file changed, 16 insertions(+)
diff --git a/Makefile.am b/Makefile.a
As one adds WARN_CFLAGS to the build the compiler throws a couple of
lovely error messages. Add the relevant includes to fix them.
error: implicit declaration of function âtimeâ
error: implicit declaration of function âgetoptâ
Cc: Inki Dae
Cc: Kyungmin Park
Signed-off-by: Emil Velik
ioctl() and strcmp() were used without the relevent header being
included.
Signed-off-by: Emil Velikov
---
tests/auth.c | 1 +
tests/getclient.c| 1 +
tests/getstats.c | 1 +
tests/lock.c | 1 +
tests/name_from_fd.c | 1 +
tests/setversion.c | 1 +
tests/updatedraw.c
... minus test/ttmtest. The latter is not really hooked up with the
actual build.
This will give us 66 warnings on a distribution build of which
- 12 -Wunused-variable
- 11 -Wunused-function
- 19 -Wmissing-prototypes
and a few -Wswitch-enum, -Wtype-limits etc.
Adding the CFLAGS gives some expo
Hi Thierry,
do you have any further thoughts on this?
Am Dienstag, den 03.02.2015, 14:30 +0100 schrieb Thierry Reding:
> On Thu, Dec 11, 2014 at 06:32:44PM +0100, Philipp Zabel wrote:
> > Many panel data sheets additionally to typical values list allowed ranges
> > for
> > timings such as hsync/
On Mon, Feb 23, 2015 at 08:33:36AM -0500, Rob Clark wrote:
> On Mon, Feb 23, 2015 at 5:29 AM, Archit Taneja
> wrote:
> > The DRM_KMS_FB_HELPER config is selected only when DRM_MSM_FBDEV config is
> > selected. The driver accesses drm_fb_helper_* functions even when legacy
> > fbdev
> > support i
Hi Emil,
On 23/02/15 12:22, Emil Velikov wrote:
> Currently most places assume reliable master <> render node mapping.
> Although this may work in some cases, it is not correct.
>
> Add a couple of helpers that hide the details and provide the name of
> the master/render device name, given an rend
Hi Philipp,
Thank you for the patch.
Benoit, please see below for a possible issue in the am437x-vpfe driver.
On Monday 23 February 2015 11:54:04 Philipp Zabel wrote:
> Decrementing the reference count of the previous endpoint node allows to
> use the of_graph_get_next_endpoint function in a for
Short follow up to my earlier series "The rocky road to building with
-Wextra". This gets rid of ~20 warnings, with ~45 remainig.
-Emil
As kindly pointed out by GCC.
Signed-off-by: Emil Velikov
---
tests/name_from_fd.c | 3 +--
tests/updatedraw.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/tests/name_from_fd.c b/tests/name_from_fd.c
index e3db413..24af6e6 100644
--- a/tests/name_from_fd.c
+++ b/tests
Cc: Inki Dae
Cc: Kyungmin Park
Signed-off-by: Emil Velikov
---
tests/exynos/exynos_fimg2d_test.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/tests/exynos/exynos_fimg2d_test.c
b/tests/exynos/exynos_fimg2d_test.c
index f141964..17e8e53 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+
Cc: Inki Dae
Cc: Kyungmin Park
Signed-off-by: Emil Velikov
---
tests/exynos/exynos_fimg2d_test.c | 31 ---
1 file changed, 31 deletions(-)
diff --git a/tests/exynos/exynos_fimg2d_test.c
b/tests/exynos/exynos_fimg2d_test.c
index 17e8e53..dc7c5cb 100644
--- a/tests/e
To silence the chatty compiler.
As a future work we may want to merge these with libdrm_lists.h
Cc: Jerome Glisse
Signed-off-by: Emil Velikov
---
tests/radeon/list.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tests/radeon/list.h b/tests/radeon/list.h
index
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/c5575180/attachment.html>
On Mon, Feb 23, 2015 at 9:09 AM, Daniel Vetter wrote:
> On Mon, Feb 23, 2015 at 08:33:36AM -0500, Rob Clark wrote:
>> On Mon, Feb 23, 2015 at 5:29 AM, Archit Taneja
>> wrote:
>> > The DRM_KMS_FB_HELPER config is selected only when DRM_MSM_FBDEV config is
>> > selected. The driver accesses drm_fb
On 23 February 2015 at 14:35, Frank Binns wrote:
> Hi Emil,
>
> On 23/02/15 12:22, Emil Velikov wrote:
>> Currently most places assume reliable master <> render node mapping.
>> Although this may work in some cases, it is not correct.
>>
>> Add a couple of helpers that hide the details and provide
On Mon, Feb 23, 2015 at 10:03:21AM -0500, Rob Clark wrote:
> On Mon, Feb 23, 2015 at 9:09 AM, Daniel Vetter wrote:
> > On Mon, Feb 23, 2015 at 08:33:36AM -0500, Rob Clark wrote:
> >> On Mon, Feb 23, 2015 at 5:29 AM, Archit Taneja
> >> wrote:
> >> > The DRM_KMS_FB_HELPER config is selected only w
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150223/1e456105/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/c1327f35/attachment.html>
ves/dri-devel/attachments/20150223/07a5110b/attachment.html>
Hi,
Am Montag, den 23.02.2015, 11:09 +0800 schrieb Liu Ying:
> Signed-off-by: Liu Ying
thank you for the patch. I've applied it to my branch.
> ---
> drivers/gpu/drm/imx/parallel-display.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/imx/paralle
roperty.
--
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/20150223/f810c554/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/9c10a2af/attachment-0001.html>
The atom aux param interface only supports 4 bits for
the total write transfer size (header + payload). This
limits us to 12 bytes of payload rather than 16. Add a
check for this. Reads are not affected.
v2: switch to WARN_ON_ONCE
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombio
Hi,
once the "Add of-graph helpers to loop over endpoints and find ports by id"
series [1] gets merged, these patches simplify the common case of looping
over all of graph endpoints in a device node.
[1] https://lkml.org/lkml/2015/2/23/115
regards
Philipp
Philipp Zabel (4):
drm: use for_each_
Using the for_each_... macro should make the code a bit shorter and
easier to read.
Signed-off-by: Philipp Zabel
Acked-by: Laurent Pinchart
---
drivers/gpu/drm/drm_of.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_
Using the for_each_... macro should make the code a bit shorter and
easier to read.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/dr
Using the for_each_... macro should make the code bit shorter and
easier to read. This patch also properly decrements the endpoint node
reference count before returning out of the loop.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/imx-drm-core.c | 9 +++--
1 file changed, 3 insertion
Using the for_each_... macro should make the code a bit shorter and
easier to read. Also, when breaking out of the loop, the endpoint node
reference count needs to be decremented.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 11 ---
1 file changed, 4 ins
Hi Philipp,
Thank you for the patch.
On Monday 23 February 2015 17:34:28 Philipp Zabel wrote:
> Using the for_each_... macro should make the code a bit shorter and
> easier to read.
>
> Signed-off-by: Philipp Zabel
Acked-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 1
https://bugzilla.kernel.org/show_bug.cgi?id=93701
Bug ID: 93701
Summary: radeon: two "empty" pixel lines on left side of
screen, rest of screen gets slightly squished
Product: Drivers
Version: 2.5
Kernel Version: 4.0-rc1
https://bugzilla.kernel.org/show_bug.cgi?id=93701
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
https://bugzilla.kernel.org/show_bug.cgi?id=93701
--- Comment #2 from Alex Deucher ---
Please attach your xorg log and dmesg output.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=93701
--- Comment #3 from frederik.hofe at gmail.com ---
Created attachment 168061
--> https://bugzilla.kernel.org/attachment.cgi?id=168061&action=edit
dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=93701
--- Comment #4 from frederik.hofe at gmail.com ---
Created attachment 168071
--> https://bugzilla.kernel.org/attachment.cgi?id=168071&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are watching the assignee of the bug.
ch PTB is 4k
> >> which holds 512 PTEs; if you set it to 1 each PTB is 8k which holds
> >> 1024 PTEs, etc.
> >>
> >> GPUVM is only concerned with memory management and protection. There
> >> are other protection features in other hw blocks for things beyond
> >> memory. For example, on CI and newer asics, the CP and SDMA blocks
> >> execute command buffers in a secure mode that limits them to accessing
> >> only registers that are relevant for those blocks (e.g., gfx or
> >> compute state registers, but not display registers) or only executing
> >> certain packets.
> >>
> >> I hope this helps. Let me know if you have any more questions.
> >>
> >> Alex
> >>
> >> >
> >> >
> >> > thank you,
> >> > Jan
> >> >
> >> > [0]http://developer.amd.com/resources/documentation-articles/developer-guides-manuals/
> >> > [1]http://lists.freedesktop.org/archives/dri-devel/2014-May/058858.html
> >> >
> >> >
> >> > --
> >> > Jan Vesely
> >
> > --
> > Jan Vesely
--
Jan Vesely
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/a2f0631c/attachment.sig>
849411] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[2.856067] [drm] Driver supports precise vblank timestamp query.
[2.862183] radeon 0001:81:00.0: radeon: MSI limited to 32-bit
[2.868058] ppc4xx_setup_msi_irqs: fail allocating msi interrupt
[2.874153] [drm] radeon: irq initialized.
[3.103973] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed
(scratch(0x8504)=0xCAFEDEAD)
[3.112806] radeon 0001:81:00.0: disabling GPU acceleration
[3.128627] [drm] Radeon Display Connectors
[3.133369] [drm] Connector 0:
[3.136481] [drm] DP-1
[3.139089] [drm] HPD1
[3.141665] [drm] DDC: 0x6470 0x6470 0x6474 0x6474 0x6478 0x6478 0x647c
0x647c
[3.149146] [drm] Encoders:
[3.152157] [drm] DFP1: INTERNAL_UNIPHY2
[3.156473] [drm] Connector 1:
[3.159570] [drm] HDMI-A-1
[3.162469] [drm] HPD5
[3.165019] [drm] DDC: 0x6480 0x6480 0x6484 0x6484 0x6488 0x6488 0x648c
0x648c
[3.172436] [drm] Encoders:
[3.175415] [drm] DFP2: INTERNAL_UNIPHY2
[3.179703] [drm] Connector 2:
[3.182766] [drm] DVI-I-1
[3.185570] [drm] HPD4
[3.188117] [drm] DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c
0x645c
[3.195535] [drm] Encoders:
[3.198513] [drm] DFP3: INTERNAL_UNIPHY
[3.202706] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[3.352245] [drm] fb mappable at 0x80475000
[3.356458] [drm] vram apper at 0x8000
[3.360570] [drm] size 8294400
[3.363634] [drm] fb depth is 24
[3.366873] [drm]pitch is 7680
[3.575080] Console: switching to colour frame buffer device 240x67
[3.649278] radeon 0001:81:00.0: fb0: radeondrmfb frame buffer device
[3.656071] radeon 0001:81:00.0: registered panic notifier
[3.666472] [drm] Initialized radeon 2.40.0 20080528 for 0001:81:00.0 on
minor 0
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/254a38bd/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=93701
--- Comment #5 from frederik.hofe at gmail.com ---
Booting with radeon.audio=0 removes this phenomena.
--
You are receiving this mail because:
You are watching the assignee of the bug.
s.freedesktop.org/archives/dri-devel/attachments/20150223/c256fbd0/attachment.html>
The viewport needs the frame size, not the field size.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crtc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 7d827cb..41b460a 100644
-
).
--
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/20150223/af68d379/attachment.html>
ving 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/20150223/da1a3ad8/attachment.html>
ack level setup.
--
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/20150223/04e4e53d/attachment.html>
g/archives/dri-devel/attachments/20150223/0962987c/attachment.html>
On Mon, Feb 23, 2015 at 11:12:39PM +0300, Andrey Skvortsov wrote:
> Hi,
>
> This warning is moved from linux-next to v4.0-rc1 now. After system boot is
> just a black screen.
> I ssh'ed into the machine and saved the log. I attached updated dmesg.log
> with drm.debug=6. Hopefully it helps.
> I
https://bugzilla.kernel.org/show_bug.cgi?id=93701
--- Comment #6 from frederik.hofe at gmail.com ---
I bisected it to this change:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=baa7d8e451f030c049f83f943b9995620d6d6bd3
--
You are receiving this mail because:
You are wa
ently if it did - but then I don't know if the normal case
actually signals full range - and if it doesn't what TVs assume by default.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
&
https://bugzilla.kernel.org/show_bug.cgi?id=93701
Andy Furniss changed:
What|Removed |Added
CC||adf.lists at gmail.com
--- Comment #7 from
ng 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/20150223/c73b5285/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=93701
--- Comment #8 from Frederik vom Hofe ---
Trying this did not fix it for me:
xrandr --output HDMI-0 --off; xrandr --output HDMI-0 --auto
--
You are receiving this mail because:
You are watching the assignee of the bug.
hments/20150223/68ad38d4/attachment.html>
I'm certain that it has dynamic backlight control of some sort, as the
brightness varies based on content. I'm also sure it has an eDP panel, and
an Intel graphics adapter. I'm not certain that DPCD will let me adjust it,
or how to check, though the ChromeOS patch seems to assume that intel + edp
-> DBC adjustable via DPCD.
Michael
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/f0e2b0f1/attachment.html>
ly.
But cherry-picking on v3.19 fixes all warnings drm_wait_one_vblank.
--
Best regards,
Andrey Skvortsov
PGP Key ID: 0x57A3AEAD
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/611cf5fa/attachment.sig>
_scheduled_works+0x2a/0x2a
> > [ 29.296564] [] ? kthread+0x9e/0xa6
> > [ 29.296567] [] ? __kthread_parkme+0x5c/0x5c
> > [ 29.296571] [] ? ret_from_fork+0x7c/0xb0
> > [ 29.296574] [] ? __kthread_parkme+0x5c/0x5c
> > [ 29.296576] ---[ end trace 4742dbfffee243fc ]---
>
> Which makes me wonder whether this is not the more significant warning?
> -Chris
Hi,
This warning is moved from linux-next to v4.0-rc1 now. After system boot is
just a black screen.
I ssh'ed into the machine and saved the log. I attached updated dmesg.log with
drm.debug=6. Hopefully it helps.
If you need any other debug information, traces, core dump or something else.
Feel free to ask.
--
Best regards,
Andrey Skvortsov
PGP Key ID: 0x57A3AEAD
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/9364bfd8/attachment-0001.sig>
> > > Those two warnings are more or less symptoms of the black screen (well
> > > the first is just overzealous). More important would be the drm.debug=6
> > > dmesg from boot along with the gdm.log (or equivalent) aned Xorg.0.log
> > > as my guess is that X (or the display server) is crashing.
>
ov
PGP Key ID: 0x57A3AEAD
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/0431062f/attachment-0001.sig>
On Mon, Feb 23, 2015 at 10:26:58AM +, Emil Velikov wrote:
> On 16/02/15 23:05, Mikko Rapeli wrote:
> > Fixes compilation error:
> >
> > drm/drm.h:132:2: error: unknown type name âsize_tâ
> >
> Hi Mikko,
>
> Can you let us know how you're getting these (series-wise) errors ? I've
> been
99 matches
Mail list logo
