-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: dmesg-drm-fixes-3.12-AGP-patch-dpm-1.log
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130916/2e662c7b/attachment-0001.ksh>
On Friday 13 September 2013 07:44 PM, Rob Clark wrote:
On Fri, Sep 13, 2013 at 5:14 AM, Archit Taneja arc...@ti.com wrote:
Enable use of DT for DMM/Tiler.
Originally worked on by Andy Gross.
looks good.. but do we want to get information about # of LUT's, etc,
from DT? Or did we decide that
Enable use of DT for DMM/Tiler.
Originally worked on by Andy Gross.
Cc: Andy Gross andy...@gmail.com
Cc: DRI Development dri-devel@lists.freedesktop.org
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 11 +++
1 file changed, 11 insertions(+)
On Mon, Sep 16, 2013 at 2:28 AM, Archit Taneja arc...@ti.com wrote:
On Friday 13 September 2013 07:44 PM, Rob Clark wrote:
On Fri, Sep 13, 2013 at 5:14 AM, Archit Taneja arc...@ti.com wrote:
Enable use of DT for DMM/Tiler.
Originally worked on by Andy Gross.
looks good.. but do we want
CCing devicetree,
-Original Message-
From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
Sent: Tuesday, September 10, 2013 5:28 PM
To: Sean Paul
Cc: Inki Dae; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
2013/9/5 Sachin Kamat sachin.ka...@linaro.org
Now that DRM_EXYNOS depends on OF, we do not need individual
drivers to depend on it.
Right. Applied.
Thanks,
Inki Dae
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/gpu/drm/exynos/Kconfig |2 +-
1 file changed, 1
Applied.
Thanks,
Inki Dae
2013/9/5 Sachin Kamat sachin.ka...@linaro.org
Silences the following warnings:
drivers/gpu/drm/exynos/exynos_drm_fbdev.c:102:40: warning:
incorrect type in assignment (different address spaces)
drivers/gpu/drm/exynos/exynos_drm_fbdev.c:102:40:
expected void
Applied.
Thanks,
Inki Dae
2013/9/11 Wei Yongjun weiyj...@gmail.com
From: Wei Yongjun yongjun_...@trendmicro.com.cn
In case of error, the function drm_prime_pages_to_sg() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().
https://bugs.freedesktop.org/show_bug.cgi?id=60879
--- Comment #40 from Hristo Venev mustrum...@gmail.com ---
After some testing I found out that my GPU crashes on big shaders. 67 32-bit
words is enough to crash it, 50 isn't. How is udiv implemented?
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=59649
--- Comment #13 from Shawn Starr shawn.st...@rogers.com ---
Unsure, i'm using Linux 3.12-rc0 right now, with my patched libdrm and patched
Mesa builds and need to isolate if the resets are being triggered by various
combinations:
1) EXA w/
https://bugzilla.kernel.org/show_bug.cgi?id=43441
--- Comment #4 from Adrian Knoth a...@drcomp.erfurt.thur.de ---
I can report similar (same?) garbage with the following device:
01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
RS482M [Mobility Radeon Xpress 200]
Kernel
https://bugzilla.kernel.org/show_bug.cgi?id=43441
Alex Deucher alexdeuc...@gmail.com changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
Hi Dave,
A couple small msm fixes. Plus drop of set_need_resched().
The following changes since commit 86a7e1224a68511d3a1ae0b7e11581b9d37723ae:
Merge branch 'exynos-drm-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into
drm-next (2013-09-05 17:48:04 +1000)
are
On Wed, Sep 11, 2013 at 09:41:49PM -0700, Olof Johansson wrote:
This removes two warnings where dma_addr_t variables were printed using
%x when built with CONFIG_ARM_LPAE=y, thus having 64-bit dma_addr_t:
drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format '%x' expects argument
of type
Hi Dave,
Just small fixes, and code cleanups.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit d2aebe338ac745f1934d01618f97a30f6bba5fec:
drm/udl: rip out set_need_resched (2013-09-16 08:35:04 +1000)
are available in the git repository
https://bugzilla.kernel.org/show_bug.cgi?id=43441
--- Comment #6 from Adrian Knoth a...@drcomp.erfurt.thur.de ---
The second commit was already part of 3.11, but I had to add the first one.
I'm afraid it doesn't change a thing, the machine still hangs when I try to
suspend for the second time.
https://bugzilla.kernel.org/show_bug.cgi?id=60858
--- Comment #14 from Christian König christian.koe...@amd.com ---
(In reply to Pinak Ahuja from comment #13)
This does not make a difference, still getting the same errors.
Please provide dmesg and register dumps with this patch applied anyway.
https://bugzilla.kernel.org/show_bug.cgi?id=60858
Pinak Ahuja pinak.ah...@gmail.com changed:
What|Removed |Added
Attachment #107431|0 |1
is obsolete|
On Mon, 2013-09-16 at 08:46 -0700, Olof Johansson wrote:
On Mon, Sep 16, 2013 at 8:17 AM, Thierry Reding
thierry.red...@gmail.com wrote:
On Wed, Sep 11, 2013 at 09:41:49PM -0700, Olof Johansson wrote:
This removes two warnings where dma_addr_t variables were printed using
%x when built
So we respect a nice design of having similar functions at the same
level, in this case:
do_hdmi_vsdb_modes()
- add_hdmi_mandatory_stereo_modes()
- add_hdmi_mode()
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/drm_edid.c | 36 +---
When scanning out a 3D mode on HDMI, we need to send an HDMI infoframe
with the corresponding layout to the sink.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/drm_edid.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git
DRM has supported multiple-buffers fbs since the introduction of ADDFB2.
Let's track the number of buffers in a drm_framebuffer in the common
structure so we can use it in the DRM core.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/drm_crtc_helper.c | 20
This ioctl can be used to turn some knobs in a DRM driver. The client
can ask the DRM core for an alternate view of the reality: it can be
useful to be able to instruct the core that the DRM client can handle
new functionnality that would otherwise break current ABI.
v2: Rename to ioctl from
When scanning out a stereo mode, the AVI infoframe vic field has to be
the underlyng 2D VIC. Before that commit, we weren't matching the CEA
mode because of the extra stereo flag and then were setting the VIC
field in the AVI infoframe to 0.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
HDMI 1.4a defines a few layouts that we'd like to expose. This commits
add new modeinfo flags that can be used to list the supported stereo
layouts (when querying the list of modes) and to set a given stereo 3D
mode (when setting a mode).
v2: Add a drm_mode_is_stereo() helper
Signed-off-by:
It's a tiny bit more logical to find the different capabilities you can
use with the GET_CAP ioctl next to the structure rather than putting
them at the end of the file.
v2: Tab align the litterals (David Herrmann)
v3: Make it clearer that DRM_PRIME_CAP_EXPORT/IMPORT are flags of
https://bugzilla.kernel.org/show_bug.cgi?id=60858
--- Comment #16 from Pinak Ahuja pinak.ah...@gmail.com ---
Created attachment 108621
-- https://bugzilla.kernel.org/attachment.cgi?id=108621action=edit
register dump with reset and reprogramming patch.
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #130 from Eugene ken20...@ukr.net ---
Thanks for info. I'll wait to test it.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
https://bugzilla.kernel.org/show_bug.cgi?id=60858
--- Comment #15 from Pinak Ahuja pinak.ah...@gmail.com ---
Created attachment 108611
-- https://bugzilla.kernel.org/attachment.cgi?id=108611action=edit
dmesg with reset and reprogramming patch.
--
You are receiving this mail because:
You are
There are a few things to be flushed out if we want to allow multiple
buffers stereo framebuffers:
- What with drm_planes? what semantics do they follow, what is the
hardware able to do with them?
- How do we define which buffer if the right/left one
- Do we allow flips between 1 buffer
When setting a stereo 3D mode, there can be only one bit set describing
the layout of the frambuffer(s). So reject invalid modes early.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/drm_crtc.c | 4
1 file changed, 4 insertions(+)
diff --git
This allows to expose the alternate clock versions of the stereo modes.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 6b74698..55dac77
On Mon, Sep 16, 2013 at 06:35:12PM +0100, Damien Lespiau wrote:
On Fri, Sep 13, 2013 at 04:10:24PM +, Joakim Plate wrote:
Damien Lespiau damien.lespiau at intel.com writes:
+static const struct s3d_mandatory_mode s3d_mandatory_modes[] = {
+ { 1920, 1080, 24, 0,
+
On Fri, Sep 13, 2013 at 04:04:02PM +, Joakim Plate wrote:
David Herrmann dh.herrmann at gmail.com writes:
So just to be clear: Whenever a mode is present with 3D flags, it is
also a valid non-3D mode? Is this guaranteed?
Well.. Some HDTV's will when they receive a frame packed
This series is the counterpart of HDMI stereo support v4 and a revision of:
http://lists.freedesktop.org/archives/dri-devel/2013-September/044895.html
v2 is just to addresse the name change the DRM_SET_CLIENT_CAP ioctl from
DRM_SET_CAP.
--
Damien
v2: SET_CAP - SET_CLIENT_CAP renaming
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
include/drm/drm.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 71a2ac1..c7df023 100644
--- a/include/drm/drm.h
+++
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
include/drm/drm_mode.h | 36 ++--
xf86drmMode.h | 36 ++--
2 files changed, 44 insertions(+), 28 deletions(-)
diff --git a/include/drm/drm_mode.h
Next installment of the HDMI stereo 3D series, following:
http://lists.freedesktop.org/archives/dri-devel/2013-September/044885.html
Quite a few changes here, and it's starting to feel right:
- We now expose each stereo layout as a separate mode, distinct from the 2D
mode, instead of
On Mon, Sep 16, 2013 at 8:17 AM, Thierry Reding
thierry.red...@gmail.com wrote:
On Wed, Sep 11, 2013 at 09:41:49PM -0700, Olof Johansson wrote:
This removes two warnings where dma_addr_t variables were printed using
%x when built with CONFIG_ARM_LPAE=y, thus having 64-bit dma_addr_t:
https://bugs.freedesktop.org/show_bug.cgi?id=64201
darkbasic darkba...@linuxsystems.it changed:
What|Removed |Added
Status|RESOLVED|REOPENED
On Fri, Sep 13, 2013 at 04:10:24PM +, Joakim Plate wrote:
Damien Lespiau damien.lespiau at intel.com writes:
+static const struct s3d_mandatory_mode s3d_mandatory_modes[] = {
+ { 1920, 1080, 24, 0,
+ DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING
},
+ {
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #131 from Sergey orbitg...@ukr.net ---
(In reply to comment #126)
That's a GPU lock up which may not be related to dpm. I recently fixed an
alignment issue with command buffers that may fix these hangs for you.
you'll need this
https://bugzilla.kernel.org/show_bug.cgi?id=60858
--- Comment #13 from Pinak Ahuja pinak.ah...@gmail.com ---
(In reply to Christian König from comment #10)
Created attachment 108421 [details]
Possible fix.
Please try the attached patch.
It just looks like the BIOS left the UPLL in an
This capability allows user space to control the delivery of modes with
the 3D flags set. This is to not play games with current user space
users not knowing anything about stereo 3D flags and that could try
to set a mode with one or several of those bits set.
So, the plan is to remove the stereo
For now, let's just look at the 3D_present flag of the CEA HDMI vendor
block to detect if the sink supports a small list of then mandatory 3D
formats.
See the HDMI 1.4a 3D extraction for detail:
http://www.hdmi.org/manufacturer/specification.aspx
Signed-off-by: Damien Lespiau
On Mon, Sep 16, 2013 at 06:48:51PM +0100, Damien Lespiau wrote:
When scanning out a 3D mode on HDMI, we need to send an HDMI infoframe
with the corresponding layout to the sink.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/drm_edid.c | 25
That wraps around the new DRM_SET_CLIENT_CAP ioctl.
v2: SET_CAP - SET_CLIENT_CAP renaming
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
xf86drm.c | 7 +++
xf86drm.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/xf86drm.c b/xf86drm.c
index 4791a05..720952f 100644
---
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #132 from Sergey orbitg...@ukr.net ---
Created attachment 85936
-- https://bugs.freedesktop.org/attachment.cgi?id=85936action=edit
Dmesg for Xorg freeze during video playing.
(In reply to comment #131)
With latest mesa and libdrm
https://bugs.freedesktop.org/show_bug.cgi?id=64850
Alex Deucher ag...@yahoo.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Newer versions of gcc seem to wander off into the weeds
when dealing with variable sizes arrays in structs.
Rather than indexing the arrays, use pointer arithmetic.
Fix up spread spectrum tables.
See bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=66932
https://bugs.freedesktop.org/show_bug.cgi?id=64850
--- Comment #30 from George Emigh glem...@yahoo.com ---
Had the same problem with XFX R7750 Core Edition 1G (ATI Cape Verde PRO [Radeon
HD 7750])
I applied the patches found in this bug report to 3.11.0-gentoo kernel, they
seemed to apply fine
On Mon, Sep 16, 2013 at 7:56 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
Oh and now that vactive is actually part of the framebuffer as well, we
need to be more careful in the kernel how we adjust the mode. I can't
recall if we have special hardware needs wrt. the vertical timings,
On Mon, Sep 16, 2013 at 7:35 PM, Damien Lespiau
damien.lesp...@intel.com wrote:
I think it makes quite a bit of sense to have the underlying 2D mode in the
mode structure as this 2d mode is relevant to the 3d mode:
- HDMI stereo modes are defined based on the unerdlying 2D mode. (eg the
On Mon, Sep 16, 2013 at 06:48:48PM +0100, Damien Lespiau wrote:
For now, let's just look at the 3D_present flag of the CEA HDMI vendor
block to detect if the sink supports a small list of then mandatory 3D
formats.
See the HDMI 1.4a 3D extraction for detail:
On Mon, Sep 16, 2013 at 09:29:31PM +0300, Ville Syrjälä wrote:
static int
do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len)
@@ -2582,10 +2662,15 @@ do_hdmi_vsdb_modes(struct drm_connector *connector,
const u8 *db, u8 len)
/* the declared length is not
On Mon, Sep 16, 2013 at 8:54 AM, Joe Perches j...@perches.com wrote:
On Mon, 2013-09-16 at 08:46 -0700, Olof Johansson wrote:
On Mon, Sep 16, 2013 at 8:17 AM, Thierry Reding
thierry.red...@gmail.com wrote:
On Wed, Sep 11, 2013 at 09:41:49PM -0700, Olof Johansson wrote:
This removes two
https://bugs.freedesktop.org/show_bug.cgi?id=67107
--- Comment #9 from Christopher Chmielewski c.chmielew...@outlook.com ---
This still happens with 3.12-rc1, X still starts and runs for about a minute
and then the whole computer freezes and there is no way to recover.
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=67107
--- Comment #10 from Alex Deucher ag...@yahoo.com ---
Make sure your kernel has this patch:
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.12id=ef4e03658420bbf91365647615460668c2510e79
--
You are receiving this mail because:
You
58 matches
Mail list logo
