On Thu, Aug 8, 2013 at 6:32 AM, Inki Dae wrote:
>
>
>> -Original Message-
>> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
>> Vetter
>> Sent: Thursday, August 08, 2013 8:21 AM
>> To: Inki Dae
>> Cc: Daniel Vetter; Intel Graphics Development; DRI Development
>> Sub
On Wed, Aug 07, 2013 at 07:39:13PM +0100, Damien Lespiau wrote:
> A few styles issues have creept in here, fix them before touching this
> code again.
You could also sprinke a bit of constness into these functions while
you're touching them.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gp
On Wed, Aug 07, 2013 at 07:39:14PM +0100, Damien Lespiau wrote:
> HDMI 1.4 adds 4 "4k x 2k" modes in the the CEA vendor specific block.
>
> With this commit, we now parse this block and expose the 4k modes that
> we find there.
>
> Signed-off-by: Damien Lespiau
> Tested-by: Cancan Feng
> Bugzil
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130807/1f33ecdc/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #16 from Torsten Krah ---
Some interesting effect running my second bisect kernel which is bad (green).
Turned my monitor off while next kernel is building, after turning it on again,
green is gone.
--
You are receiving this mail bec
On Thu, Aug 08, 2013 at 03:34:17AM +0200, Laurent Pinchart wrote:
> Hi Dave,
>
> (CC'ing Simon Horman, the shmobile tree maintainer)
>
> On Thursday 08 August 2013 10:57:33 Dave Airlie wrote:
> > On Thu, Aug 8, 2013 at 10:43 AM, Laurent Pinchart wrote:
> > > Hi Dave,
> > >
> > > I've got a coupl
Hi Guennadi and LMML,
I'm working on a camera controller driver for Tegra, which is using
soc_camera. But we also need to use Tegra specific host1x interface
like syncpt APIs.
Since host1x is quite Tegra specific framework which is in
drivers/gpu/host1x and has several host1x's client driver like
This makes it so that reloading a module does not cause all the
connector ids to change, which are user-visible and sometimes used
for configuration.
Signed-off-by: Ilia Mirkin
---
v2 -> v3:
- rename ida struct name to... ida. (i'm ready to accept my "creative name
of the year" award.)
- fi
The old idr_preload() used percpu buffers - since the
bitmap/radix/whatever tree only grew by fixed sized nodes, it only had
to ensure there was a node available in the percpu buffer and disable
preemption. This conveniently meant that you didn't have to pass the idr
you were going to allocate from
Our new idr implementation does its own locking, instead of forcing it
onto the callers like the old implementation.
Many of the existing idr users need locking for more than just
idr_alloc()/idr_remove()/idr_find() - they're taking refcounts and such
under their locks and we can't touch those.
B
On Wed, Aug 07, 2013 at 01:41:27PM -0400, Rob Clark wrote:
> Signed-off-by: Rob Clark
Patches 5-9 are Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/omapdrm/Makefile | 3 -
> drivers/gpu/drm/omapdrm/omap_gem.c | 8 +-
> drivers/gpu/drm/omapdrm/omap_gem_helpers.c | 124
Hi, Daniel. You can repost your patch set including the below my patch. And
my patch numbering is wrong. Sorry about that.
[PATCH 1/4] -> [PATCH 4/4]
Thanks,
Inki Dae
> -Original Message-
> From: Inki Dae [mailto:inki@samsung.com]
> Sent: Thursday, August 08, 2013 1:40 PM
> To: dan.
___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.fre
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 3cd56e1..fd76449
2013/8/8 Alex Deucher :
> Some more radeon fixes. Mostly dpm and uvd fixes. Fixes hangs
> with dpm on more rv6xx asics, and fixes suspend and resume with UVD.
That
fix audio dto calculation on DCE3+
looks promising, I had no idea you're working on that. Thanks for
releasing that!
Maybe you coul
; exynos related codes from your patch set. Otherwise, we have to work
> twice.
> > one is the additional work for resolving exynos broken issue by your
> patch
> > set, and other is to replace existing dmabuf stuff of exynos to common
> > drm_gem_dmabuf.
>
> Yeah np, I'll drop exynos then.
>
Thanks a lot. :)
Thanks,
Inki Dae
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130807/173816da/attachment.html>
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Thursday, August 08, 2013 8:21 AM
> To: Inki Dae
> Cc: Daniel Vetter; Intel Graphics Development; DRI Development
> Subject: Re: [PATCH 1/3] drm: use common drm_gem_dmabuf_relea
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #15 from Torsten Krah ---
AddOn:
RC1 did fail after vista did run.
My first bisect kernel between rc1 and 3.9 did boot well (building next one).
After this i can boot to 3.10.5 without any green, so it seems the 3.9.x kernel
does som
Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130807/ea97b375/attachment.html>
On Wed, Aug 07, 2013 at 12:09:32PM +0200, Daniel Vetter wrote:
> This fixes a WARN in i915_gem_free_object when the
> obj->pages_pin_count isn't 0.
>
> v2: Add locking to unmap, noticed by Chris Wilson. Note that even
> though we call unmap with our own dev->struct_mutex held that won't
> result i
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #14 from Torsten Krah ---
So that is REALLY the trick.
After booting to windows (vista 32bit, latest stable Ati Radeon driver), its
green again when booting to 3.10.5.
I don't even know now what i have done that it did work a few minut
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #13 from Torsten Krah ---
Created attachment 107149
--> https://bugzilla.kernel.org/attachment.cgi?id=107149&action=edit
camera image
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #12 from Torsten Krah ---
Created attachment 107148
--> https://bugzilla.kernel.org/attachment.cgi?id=107148&action=edit
hdmi regs 3.10.5 with radeon.audio=1 and green
--
You are receiving this mail because:
You are watching the as
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #11 from Torsten Krah ---
Created attachment 107147
--> https://bugzilla.kernel.org/attachment.cgi?id=107147&action=edit
dmesg 3.10.5 green
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #10 from Torsten Krah ---
I am lost now a little bit.
To make sure rc1 did fail also i've installed all mainline ppa kernels from
3.9.11 to 3.10.5 including rc ones, to possible get a smaller bisect window.
Just bootet into 3.10rc1 a
This makes it so that reloading a module does not cause all the
connector ids to change, which are user-visible and sometimes used
for configuration.
Signed-off-by: Ilia Mirkin
---
v2 -> v3:
- rename ida struct name to... ida. (i'm ready to accept my "creative name
of the year" award.)
- fi
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #9 from Torsten Krah ---
Created attachment 107146
--> https://bugzilla.kernel.org/attachment.cgi?id=107146&action=edit
hdmi regs 3.10.5 with radeon.audio=1
--
You are receiving this mail because:
You are watching the assignee of t
https://bugzilla.kernel.org/show_bug.cgi?id=60716
Bug ID: 60716
Summary: Black screen with nouveau if brightness = 0 or 100
Product: Drivers
Version: 2.5
Kernel Version: 3.11-rc4 (and oldier?)
Hardware: All
OS: Linux
achments/20130807/30f849a3/attachment.html>
On Wed, Aug 07, 2013 at 01:41:19PM -0400, Rob Clark wrote:
> A small helper to queue up work to do, from workqueue context, after a
> flip. Typically useful to defer unreffing buffers that may be read by
> the display controller until vblank.
>
> Signed-off-by: Rob Clark
Since you have this nic
HDMI 1.4 adds 4 "4k x 2k" modes in the the CEA vendor specific block.
With this commit, we now parse this block and expose the 4k modes that
we find there.
Signed-off-by: Damien Lespiau
Tested-by: Cancan Feng
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67030
---
drivers/gpu/drm/drm_
A few styles issues have creept in here, fix them before touching this
code again.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 95d6f4b..51
This series parses one of the dark corners of the EDID to expose "4k x 2k"
modes to userspace. Those modes are part of HDMI 1.4.
To complete the 4k HDMI support, one needs:
* Hardware able to output a 300 MHz TMDS clock (Haswell can do that) and
Daniel's patch to bump that limit in the kern
ope to try a few things myself soon,
but I'll test a patch promptly.
--
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/20130807/8e0fdaec/attachment.html>
On 08/07/2013 07:21 PM, Daniel Vetter wrote:
> On Wed, Aug 07, 2013 at 07:18:45PM +0900, Joonyoung Shim wrote:
>> On 08/07/2013 06:55 PM, Daniel Vetter wrote:
>>> On Wed, Aug 7, 2013 at 11:40 AM, Inki Dae wrote:
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ff
https://bugzilla.kernel.org/show_bug.cgi?id=60709
Torsten Krah changed:
What|Removed |Added
Attachment #107141|0 |1
is obsolete|
On 08/07/2013 06:55 PM, Daniel Vetter wrote:
> On Wed, Aug 7, 2013 at 11:40 AM, Inki Dae wrote:
>>> -Original Message-
>>> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch]
>>> Sent: Wednesday, August 07, 2013 6:15 PM
>>> To: DRI Development
>>> Cc: Intel Graphics Development; Daniel
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #7 from Rafa? Mi?ecki ---
Whoops, your avivotool is too old to support "hdmi" (or you mispelled it).
Could you update avivotool, please?
After updating I'll need output of "avivotool regs hdmi" from 3.9 and 3.10,
both using radeon.aud
Hi Guennadi and LMML,
I'm working on a camera controller driver for Tegra, which is using
soc_camera. But we also need to use Tegra specific host1x interface
like syncpt APIs.
Since host1x is quite Tegra specific framework which is in
drivers/gpu/host1x and has several host1x's client driver like
Hi David,
On Wednesday 07 August 2013 18:12:23 David Herrmann wrote:
> On Wed, Aug 7, 2013 at 5:53 PM, Laurent Pinchart wrote:
> > On Wednesday 07 August 2013 15:53:15 David Herrmann wrote:
> >> We currently rely on gcc dead-code elimination so the drm_agp_* helpers
> >> are not called if drm_core
Just comment a bit on Rob's review with my own opinion.
On Wed, Aug 07, 2013 at 12:17:21PM -0400, Rob Clark wrote:
> On Thu, Jul 25, 2013 at 1:17 PM, wrote:
> > From: Tom Cooksey
> >
> > This is a mode-setting driver for the pl111 CLCD display controller
> > found on various ARM reference platf
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch]
> Sent: Wednesday, August 07, 2013 6:15 PM
> To: DRI Development
> Cc: Intel Graphics Development; Daniel Vetter; Inki Dae
> Subject: [PATCH 1/3] drm: use common drm_gem_dmabuf_release in i915/exynos
> drivers
>
Hi Dave,
(CC'ing Simon Horman, the shmobile tree maintainer)
On Thursday 08 August 2013 10:57:33 Dave Airlie wrote:
> On Thu, Aug 8, 2013 at 10:43 AM, Laurent Pinchart wrote:
> > Hi Dave,
> >
> > I've got a couple of arch/arm/ patches that depend on this series and that
> > I would like to get m
> >> > Didn't you say that programmatically describing device placement
> >> > constraints was an unbounded problem? I guess we would have to
> >> > accept that it's not possible to describe all possible constraints
> >> > and instead find a way to describe the common ones?
> >>
> >> well, the poi
On Wed, Aug 07, 2013 at 08:50:20PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Aug 07, 2013 at 12:09:32PM +0200, Daniel Vetter wrote:
> > This fixes a WARN in i915_gem_free_object when the
> > obj->pages_pin_count isn't 0.
> >
> > v2: Add locking to unmap, noticed by Chris Wilson. Note that even
https://bugs.freedesktop.org/show_bug.cgi?id=67876
--- Comment #2 from jim.cro...@gmail.com ---
thank you Alex, the firmware page helped some.
Turns out I needed more than the CEDAR_smc.bin,
(which fwiw was never warned about)
[1.756212] radeon :01:00.0: radeon_uvd: Can't load firmware
"
Hi Dave,
Some more radeon fixes. Mostly dpm and uvd fixes. Fixes hangs
with dpm on more rv6xx asics, and fixes suspend and resume with UVD.
The following changes since commit adfb8e51332153016857194b85309150ac560286:
drm/radeon: fix 64 bit divide in SI spm code (2013-08-04 11:03:14 +1000)
a
Hi
On Wed, Aug 7, 2013 at 5:53 PM, Laurent Pinchart
wrote:
> Hi David,
>
> On Wednesday 07 August 2013 15:53:15 David Herrmann wrote:
>> We currently rely on gcc dead-code elimination so the drm_agp_* helpers
>> are not called if drm_core_has_AGP() is false. That's ugly as hell so
>> provide "sta
On Wed, Aug 7, 2013 at 5:53 PM, miaou sami wrote:
> Hi,
>
> thanks for your reply.
> Here is the dmesg.
>
> Let me know if you need further testing.
As I suspected, on your system all the performance levels are the same:
[8.961675] == power state 0 ==
[8.961677] ui class: none
[8.96
On Thu, Aug 8, 2013 at 10:43 AM, Laurent Pinchart
wrote:
> Hi Dave,
>
> I've got a couple of arch/arm/ patches that depend on this series and that I
> would like to get merged in v3.12. They should go upstream through the arm-soc
> tree. Would you be able to provide a stable branch with this patch
Hi David,
On Wednesday 07 August 2013 15:53:15 David Herrmann wrote:
> We currently rely on gcc dead-code elimination so the drm_agp_* helpers
> are not called if drm_core_has_AGP() is false. That's ugly as hell so
> provide "static inline" dummies for the case that AGP is disabled.
Please note t
On Wed, Aug 07, 2013 at 12:09:32PM +0200, Daniel Vetter wrote:
> This fixes a WARN in i915_gem_free_object when the
> obj->pages_pin_count isn't 0.
>
> v2: Add locking to unmap, noticed by Chris Wilson. Note that even
> though we call unmap with our own dev->struct_mutex held that won't
> result i
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #6 from Torsten Krah ---
Created attachment 107142
--> https://bugzilla.kernel.org/attachment.cgi?id=107142&action=edit
hdmi regs 3.10.5 with radeon.audio=0
--
You are receiving this mail because:
You are watching the assignee of t
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #5 from Torsten Krah ---
Created attachment 107141
--> https://bugzilla.kernel.org/attachment.cgi?id=107141&action=edit
hdmi regs 3.9.11 with radeon.audio=1
--
You are receiving this mail because:
You are watching the assignee of t
Hi Dave,
I've got a couple of arch/arm/ patches that depend on this series and that I
would like to get merged in v3.12. They should go upstream through the arm-soc
tree. Would you be able to provide a stable branch with this patch set based
on one of the 3.11-rcX tags ? Ideally that branch sho
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #83 from Hrvoje Senjan ---
(In reply to comment #82)
> (In reply to comment #81)
> > Similar as Sergey. It's pretty stable now, and boots correctly 100%, but
> > sometimes it can hang during usage. Found the following in the log:
>
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #82 from Alex Deucher ---
(In reply to comment #81)
> Similar as Sergey. It's pretty stable now, and boots correctly 100%, but
> sometimes it can hang during usage. Found the following in the log:
Do you also get GPU hangs with dpm
https://bugzilla.kernel.org/show_bug.cgi?id=60709
Rafa? Mi?ecki changed:
What|Removed |Added
CC||zajec5 at gmail.com
--- Comment #4 from R
It's my megabyte, I want to use it! At this point in init
vbios is copied over already, so there's no reason it cannot
used to hold other data now.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/ramnvc0.c
b/drivers/gpu/drm/nouveau/core/subdev/fb/ramnvc0.
Allocating type=0 marks the memory as free. This allows the ltcg memory to be
allocated twice. Add a BUG_ON in core/mm.c to prevent this ever happening again.
Additionally some registers were not initialized in init, this causes them to be
uninitialized after suspend.
Signed-off-by: Maarten Lankho
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #81 from Hrvoje Senjan ---
Similar as Sergey. It's pretty stable now, and boots correctly 100%, but
sometimes it can hang during usage. Found the following in the log:
Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: GPU lock
This was already required before, but no check in the kernel was done to
enforce it.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 73cf240..ddb065c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_displa
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #3 from Torsten Krah ---
Created attachment 107140
--> https://bugzilla.kernel.org/attachment.cgi?id=107140&action=edit
dmesg 3.10.3 with radeon.audio=1
--
You are receiving this mail because:
You are watching the assignee of the b
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #2 from Torsten Krah ---
Yes i am using radeon.audio=1. Disabling this makes 3.10.5 work without green
screen.
Attaching dmesg from 3.10.3 - thought it was .2, sorry.
I'll try to bisect - may take some time, i'll try asap.
--
You ar
https://bugzilla.kernel.org/show_bug.cgi?id=60709
Torsten Krah changed:
What|Removed |Added
Summary|With 3.10.2 / 3.10.5 screen |With 3.10.3 / 3.10.5 screen
On 08/07/2013 03:44 PM, Borislav Petkov wrote:
> On Sun, Jun 09, 2013 at 07:01:36PM -0400, Matthew Garrett wrote:
>> Windows 8 introduced new policy for backlight control by pushing it out to
>> graphics drivers. This appears to have coincided with a range of vendors
>> adding Windows 8 checks to t
On Wed, Aug 07, 2013 at 09:37:52PM +0900, Inki Dae wrote:
> 2013/8/7 Daniel Vetter
>
> > On Wed, Aug 7, 2013 at 2:01 PM, Inki Dae wrote:
> > >
> > >
> > > 2013/8/7 Daniel Vetter
> > >>
> > >> On Wed, Aug 07, 2013 at 07:18:45PM +0900, Joonyoung Shim wrote:
> > >> > On 08/07/2013 06:55 PM, Daniel
We currently rely on gcc dead-code elimination so the drm_agp_* helpers
are not called if drm_core_has_AGP() is false. That's ugly as hell so
provide "static inline" dummies for the case that AGP is disabled.
Fixes a build-regression introduced by:
commit 28ec711cd427f8b61f73712a43b8100ba8ca933
https://bugs.freedesktop.org/show_bug.cgi?id=67800
--- Comment #4 from Alex Deucher ---
This may be a duplicate of bug 65958. Does setting the env var RADEON_VA=0 in
your /etc/environment fix the issue?
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #16 from Torsten Krah ---
Some interesting effect running my second bisect kernel which is bad (green).
Turned my monitor off while next kernel is building, after turning it on again,
green is gone.
--
You are receiving this mail bec
https://bugzilla.kernel.org/show_bug.cgi?id=60710
--- Comment #6 from Chris Rankin ---
(In reply to Alex Deucher from comment #5)
> Well a warm reboot may not have fuly reset the hardware; the bad state may
> have persisted.
What "warm reboot"? IIRC, I powered the laptop down and came back to it
Hi Dave,
Some more radeon fixes. Mostly dpm and uvd fixes. Fixes hangs
with dpm on more rv6xx asics, and fixes suspend and resume with UVD.
The following changes since commit adfb8e51332153016857194b85309150ac560286:
drm/radeon: fix 64 bit divide in SI spm code (2013-08-04 11:03:14 +1000)
a
v2: Fix rebase fail that removed a necessary hunk
Signed-off-by: Damien Lespiau
---
edid-decode.c | 67 +++
1 file changed, 67 insertions(+)
diff --git a/edid-decode.c b/edid-decode.c
index 5061228..083ddd9 100644
--- a/edid-decode.c
+++ b
On Wed, Aug 7, 2013 at 5:53 PM, miaou sami wrote:
> Hi,
>
> thanks for your reply.
> Here is the dmesg.
>
> Let me know if you need further testing.
As I suspected, on your system all the performance levels are the same:
[8.961675] == power state 0 ==
[8.961677] ui class: none
[8.96
Signed-off-by: Damien Lespiau
---
edid-decode.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/edid-decode.c b/edid-decode.c
index 7aed3c6..58297c9 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -861,6 +861,44 @@ cea_hdmi_block(unsigned char *x)
Signed-off-by: Damien Lespiau
---
edid-decode.c | 69 +--
1 file changed, 67 insertions(+), 2 deletions(-)
diff --git a/edid-decode.c b/edid-decode.c
index 5061228..7aed3c6 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -32,8 +32,6 @@
#
---
data/samsung-UE40D8000YU-hmdi | Bin 0 -> 256 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 data/samsung-UE40D8000YU-hmdi
diff --git a/data/samsung-UE40D8000YU-hmdi b/data/samsung-UE40D8000YU-hmdi
new file mode 100644
index
Signed-off-by: Damien Lespiau
---
edid-decode.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/edid-decode.c b/edid-decode.c
index 55e48a7..5061228 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -659,6 +659,13 @@ cea_video_block(unsigned char *x)
Signed-off-by: Damien Lespiau
---
edid-decode.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/edid-decode.c b/edid-decode.c
index 7515181..55e48a7 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -705,7 +705,7 @@ cea_hdmi_block(unsigned char *x)
if
Signed-off-by: Damien Lespiau
---
data/skyworth-50e780u-hdmi | Bin 0 -> 256 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 data/skyworth-50e780u-hdmi
diff --git a/data/skyworth-50e780u-hdmi b/data/skyworth-50e780u-hdmi
new file mode 100644
index
0
Signed-off-by: Damien Lespiau
---
edid-decode.c | 84 +--
1 file changed, 82 insertions(+), 2 deletions(-)
diff --git a/edid-decode.c b/edid-decode.c
index 9840db6..7515181 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -32,6 +32,8 @@
#
A bit more context than the previous patch that was a bit alone. This series
parses yet a bit more of the EDID:
- The HDMI VICs in the HDMI vendor specific block (HDMI 1.4, 4k modes)
- The CEA Video Capability Data Block
It also includes 2 EDIDs of TVs that have those bits.
--
Damien
t home and send it to dri-devel.
Thanks
David
-- next part --
A non-text attachment was scrubbed...
Name: drm_agp_fix.patch
Type: application/octet-stream
Size: 8616 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130807/1f11e9d2/attachment-0001.obj>
A small helper to queue up work to do, from workqueue context, after a
flip. Typically useful to defer unreffing buffers that may be read by
the display controller until vblank.
v1: original
v2: wire up docbook + couple docbook fixes
Signed-off-by: Rob Clark
Acked-by: Daniel Vetter
---
Docume
My Latitude E6510 has the following graphics HW:
01:00.0 VGA compatible controller: nVidia Corporation GT218 [NVS 3100M] (rev
a2) (prog-if 00 [VGA controller])
Subsystem: Dell Latitude E6510
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at e200 (32-bit, non-
Hi Daniel,
On Wednesday 07 August 2013 14:19:34 Daniel Vetter wrote:
> On Wed, Aug 7, 2013 at 2:17 PM, Laurent Pinchart wrote:
> > The drm_agp_clear() function is only defined on platforms with AGP
> > support. Move the drm_core_has_AGP() check from drm_agp_clear() to the
> > caller to let the com
On Wed, Aug 7, 2013 at 1:49 PM, Daniel Vetter wrote:
> On Wed, Aug 07, 2013 at 01:41:19PM -0400, Rob Clark wrote:
>> A small helper to queue up work to do, from workqueue context, after a
>> flip. Typically useful to defer unreffing buffers that may be read by
>> the display controller until vbla
On Wed, Aug 7, 2013 at 2:17 PM, Laurent Pinchart
wrote:
> The drm_agp_clear() function is only defined on platforms with AGP
> support. Move the drm_core_has_AGP() check from drm_agp_clear() to the
> caller to let the compiler optimize the drm_agp_clear() call away.
>
> Signed-off-by: Laurent Pinc
The drm_agp_clear() function is only defined on platforms with AGP
support. Move the drm_core_has_AGP() check from drm_agp_clear() to the
caller to let the compiler optimize the drm_agp_clear() call away.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_agpsupport.c | 2 +-
drivers/gpu/dr
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #15 from Torsten Krah ---
AddOn:
RC1 did fail after vista did run.
My first bisect kernel between rc1 and 3.9 did boot well (building next one).
After this i can boot to 3.10.5 without any green, so it seems the 3.9.x kernel
does som
On Wed, Aug 7, 2013 at 1:33 PM, Tom Cooksey wrote:
>
>> >> > Didn't you say that programmatically describing device placement
>> >> > constraints was an unbounded problem? I guess we would have to
>> >> > accept that it's not possible to describe all possible constraints
>> >> > and instead find a
On Wed, Aug 7, 2013 at 2:01 PM, Inki Dae wrote:
>
>
> 2013/8/7 Daniel Vetter
>>
>> On Wed, Aug 07, 2013 at 07:18:45PM +0900, Joonyoung Shim wrote:
>> > On 08/07/2013 06:55 PM, Daniel Vetter wrote:
>> > >On Wed, Aug 7, 2013 at 11:40 AM, Inki Dae wrote:
>> > >>>-Original Message-
>> > >>>F
On Tue, Aug 06, 2013 at 08:32:19PM +0100, Damien Lespiau wrote:
> Let's use the drivers/video/hmdi.c and drm infoframe helpers to build
> our infoframes.
>
> v2: Simplify the logic to compute the buffer size. We can just take the
> maximum infoframe size rounded to 32, which happens to be what the
On Tue, Aug 06, 2013 at 08:32:18PM +0100, Damien Lespiau wrote:
> First step in the move to the shared infoframe infrastructure, let's
> move the different infoframe helpers and the write_infoframe() vfunc to
> a type (enum hdmi_infoframe_type) and a buffer + len instead of using
> our struct dip_i
On Tue, Aug 06, 2013 at 08:32:16PM +0100, Damien Lespiau wrote:
> If the user if this API is providing a bigger buffer than the infoframe
> size, it could be for a could reason. For instance it could be because
> it gives the buffer that will be written to the hardware, up to the
> maximum of an in
On Wed, Aug 7, 2013 at 1:33 PM, Tom Cooksey wrote:
>
>> >> > Didn't you say that programmatically describing device placement
>> >> > constraints was an unbounded problem? I guess we would have to
>> >> > accept that it's not possible to describe all possible constraints
>> >> > and instead find a
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #14 from Torsten Krah ---
So that is REALLY the trick.
After booting to windows (vista 32bit, latest stable Ati Radeon driver), its
green again when booting to 3.10.5.
I don't even know now what i have done that it did work a few minut
oh, whoops, this one is already on drm-next
On Wed, Aug 7, 2013 at 1:41 PM, Rob Clark wrote:
> Because, there is no reason for it not to be const.
>
> v1: original
> v2: fix compile break in vmwgfx, and couple related cleanups suggested
> by Ville Syrj?l?
>
> Signed-off-by: Rob Clark
> ---
>
> -Original Message-
> From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-soc-
> owner at vger.kernel.org] On Behalf Of Vikas Sajjan
> Sent: Wednesday, August 07, 2013 1:11 PM
> To: Sachin Kamat
> Cc: Vikas Sajjan; linux-samsung-soc; dri-devel at lists.freedesktop.org;
On Wed, Aug 07, 2013 at 04:28:35AM -0400, Ilia Mirkin wrote:
> On Wed, Aug 7, 2013 at 4:00 AM, Ville Syrj?l?
> wrote:
> > On Tue, Jul 30, 2013 at 03:51:49AM -0400, Ilia Mirkin wrote:
> >> @@ -722,8 +741,9 @@ int drm_connector_init(struct drm_device *dev,
> >> connector->dev = dev;
> >>
1 - 100 of 276 matches
Mail list logo
