https://bugs.freedesktop.org/show_bug.cgi?id=67107
--- Comment #10 from Alex Deucher ---
Make sure your kernel has this patch:
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.12&id=ef4e03658420bbf91365647615460668c2510e79
--
You are receiving this mail because:
You are the assign
https://bugs.freedesktop.org/show_bug.cgi?id=67107
--- Comment #9 from Christopher Chmielewski ---
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 mail because:
You are the
On Mon, Sep 16, 2013 at 8:54 AM, Joe Perches wrote:
> On Mon, 2013-09-16 at 08:46 -0700, Olof Johansson wrote:
>> On Mon, Sep 16, 2013 at 8:17 AM, Thierry Reding
>> wrote:
>> > On Wed, Sep 11, 2013 at 09:41:49PM -0700, Olof Johansson wrote:
>> >> This removes two warnings where dma_addr_t variabl
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 leng
On Mon, Sep 16, 2013 at 7:56 PM, Ville Syrjälä
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, but
> if we do we should pro
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:
> http://www.hdmi.org/manuf
On Mon, Sep 16, 2013 at 7:35 PM, Damien Lespiau
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
> extra, non-mandator
https://bugs.freedesktop.org/show_bug.cgi?id=64850
--- Comment #30 from George Emigh ---
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 and now I have 2 wo
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.cg
https://bugs.freedesktop.org/show_bug.cgi?id=64850
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #132 from Sergey ---
Created attachment 85936
--> https://bugs.freedesktop.org/attachment.cgi?id=85936&action=edit
Dmesg for Xorg freeze during video playing.
(In reply to comment #131)
> With latest mesa and libdrm from git it loo
That wraps around the new DRM_SET_CLIENT_CAP ioctl.
v2: SET_CAP -> SET_CLIENT_CAP renaming
Signed-off-by: Damien Lespiau
---
xf86drm.c | 7 +++
xf86drm.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/xf86drm.c b/xf86drm.c
index 4791a05..720952f 100644
--- a/xf86drm.c
+++ b/xf86drm.
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
---
drivers/gpu/
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
> ---
> drivers/gpu/drm/drm_edid.c | 25 +++--
> 1 file chan
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
https://bugzilla.kernel.org/show_bug.cgi?id=60858
--- Comment #13 from Pinak Ahuja ---
(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 complete invalid sta
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #131 from Sergey ---
(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 patch for libdrm
On Fri, Sep 13, 2013 at 04:10:24PM +, Joakim Plate wrote:
> Damien Lespiau 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
> },
> > + { 1920, 1
https://bugs.freedesktop.org/show_bug.cgi?id=64201
darkbasic changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
On Mon, Sep 16, 2013 at 8:17 AM, Thierry Reding
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:
>>
>> drivers/gpu/host1x/hw/
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 pig
Signed-off-by: Damien Lespiau
---
include/drm/drm_mode.h | 36 ++--
xf86drmMode.h | 36 ++--
2 files changed, 44 insertions(+), 28 deletions(-)
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index d41d76b..ec2
v2: SET_CAP -> SET_CLIENT_CAP renaming
Signed-off-by: Damien Lespiau
---
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
+++ b/include/drm/drm.h
@@ -618,6 +618,21 @
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
On Fri, Sep 13, 2013 at 04:04:02PM +, Joakim Plate wrote:
> David Herrmann 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 m
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 intel.com> writes:
> >
> > > +static const struct s3d_mandatory_mode s3d_mandatory_modes[] = {
> > > + { 1920, 1080, 24, 0,
> > > + DRM_MODE_FLAG_3D
This allows to expose the alternate clock versions of the stereo modes.
Signed-off-by: Damien Lespiau
---
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 100644
--- a/drivers/gpu/drm/
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
---
drivers/gpu/drm/drm_crtc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/dr
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 f
https://bugzilla.kernel.org/show_bug.cgi?id=60858
--- Comment #15 from Pinak Ahuja ---
Created attachment 108611
--> https://bugzilla.kernel.org/attachment.cgi?id=108611&action=edit
dmesg with reset and reprogramming patch.
--
You are receiving this mail because:
You are watching the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #130 from Eugene ---
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
dri-devel@lists.freedesktop
https://bugzilla.kernel.org/show_bug.cgi?id=60858
--- Comment #16 from Pinak Ahuja ---
Created attachment 108621
--> https://bugzilla.kernel.org/attachment.cgi?id=108621&action=edit
register dump with reset and reprogramming patch.
--
You are receiving this mail because:
You are watching the
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: Damie
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
DRM_CAP_PRIME
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
---
drivers/gpu/drm/drm_
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 SET_C
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
---
drivers/gpu/drm/drm_crtc_helper.c | 20
include/drm/drm
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
---
drivers/gpu/drm/drm_edid.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c
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
---
drivers/gpu/drm/drm_edid.c | 36 +---
1 file changed, 21 inse
On Mon, 2013-09-16 at 08:46 -0700, Olof Johansson wrote:
> On Mon, Sep 16, 2013 at 8:17 AM, Thierry Reding
> 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_LP
https://bugzilla.kernel.org/show_bug.cgi?id=60858
Pinak Ahuja changed:
What|Removed |Added
Attachment #107431|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=60858
--- Comment #14 from Christian König ---
(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.
Thanks,
Christian.
--
https://bugzilla.kernel.org/show_bug.cgi?id=43441
--- Comment #6 from Adrian Knoth ---
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.
Garbage after first resume
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
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 t
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 av
https://bugzilla.kernel.org/show_bug.cgi?id=43441
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #5 from
https://bugzilla.kernel.org/show_bug.cgi?id=43441
--- Comment #4 from Adrian Knoth ---
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 version is 3.11.
While UM
https://bugs.freedesktop.org/show_bug.cgi?id=59649
--- Comment #13 from Shawn Starr ---
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/ composite enabled + Second L
https://bugs.freedesktop.org/show_bug.cgi?id=60879
--- Comment #40 from Hristo Venev ---
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 are the assignee for
Applied.
Thanks,
Inki Dae
2013/9/11 Wei Yongjun
> From: Wei Yongjun
>
> 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().
>
> Signed-off-by: Wei Yongjun
> ---
> drive
Applied.
Thanks,
Inki Dae
2013/9/5 Sachin Kamat
> 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 [noderef] *kvaddr
> driv
2013/9/5 Sachin Kamat
> 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
> ---
> drivers/gpu/drm/exynos/Kconfig |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --gi
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 josh
On Mon, Sep 16, 2013 at 2:28 AM, Archit Taneja wrote:
> On Friday 13 September 2013 07:44 PM, Rob Clark wrote:
>>
>> On Fri, Sep 13, 2013 at 5:14 AM, Archit Taneja wrote:
>>>
>>> Enable use of DT for DMM/Tiler.
>>>
>>> Originally worked on by Andy Gross.
>>
>>
>> looks good.. but do we want to ge
https://bugs.freedesktop.org/show_bug.cgi?id=69395
--- Comment #6 from darkbasic ---
The fix worked, thanks.
I hope you can help me with my KDE issue too: it's a pity having to use the
Intel HD 4000 which doesn't even support my monitor's resolution (2560x1600).
--
You are receiving this mail b
Enable use of DT for DMM/Tiler.
Originally worked on by Andy Gross.
Cc: Andy Gross
Cc: DRI Development
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers
eter
-- 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>
58 matches
Mail list logo
