this patch adds mode_fixup feature for hdmi module that
specific driver changes current mode to driver desired mode
properly.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_connector.c | 25 +++-
drivers/gpu/drm/exynos/exynos_drm_crtc.c |
From: Eun-Chul Kim
Signed-off-by: Eun-Chul Kim
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_connector.c | 16 ++
drivers/gpu/drm/exynos/exynos_drm_drv.h |4 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 27 ++
https://bugs.freedesktop.org/show_bug.cgi?id=46004
--- Comment #4 from Pavel Ondračka 2012-02-14
00:36:35 PST ---
Created attachment 57014
--> https://bugs.freedesktop.org/attachment.cgi?id=57014
RADEON_DEBUG=fp,vp log (piglit pass)
The patch doesn't help. Attaching a new log with
6d4b35c036
https://bugs.freedesktop.org/show_bug.cgi?id=46019
Bug #: 46019
Summary: blur position incorrect
Classification: Unclassified
Product: Mesa
Version: 8.0
Platform: Other
OS/Version: All
Status: NEW
Severity: n
Hi, Kamil.
Sorry for being late.
Below is my comments.
> -Original Message-
> From: Kamil Debski [mailto:k.deb...@samsung.com]
> Sent: Saturday, February 11, 2012 2:32 AM
> To: dri-devel@lists.freedesktop.org
> Cc: kyungmin.p...@samsung.com; inki@samsung.com;
> jy0922.s...@samsung.com
https://bugs.freedesktop.org/show_bug.cgi?id=34155
--- Comment #8 from Marco Albanese 2012-02-14 01:15:48 PST
---
After last kernel upgrade ( 3.2.0-1-486 with Debian patches ) I don't get the
error messages anymore.
Would you like me to check the value of r with your patch using the previous
https://bugs.freedesktop.org/show_bug.cgi?id=34155
Michel Dänzer changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
On Mon, 13 Feb 2012 23:26:23 +0100, Daniel Vetter wrote:
> On Mon, Feb 13, 2012 at 09:49:35PM +, Chris Wilson wrote:
> > On Mon, 13 Feb 2012 21:38:38 +0100, Daniel Vetter wrote:
> > However, the outstanding issue is that we need to separate the gmbus
> > i2c adapter from the gpio i2c adapter
On Mon, Feb 13, 2012 at 05:36:54PM -0500, Yufeng Shen wrote:
> Moved gmbus_mutex below intel_gmbus and added comments.
> Rebased to drm-intel-next-queued.
>
>
>
> GMBUS has several ports and each has it's own corresponding
> I2C adp
https://bugs.freedesktop.org/show_bug.cgi?id=45984
--- Comment #5 from Michel Dänzer 2012-02-14 01:49:28 PST
---
> 2) Run ./piglit-run.py tests/r600.tests results/r600.results
BTW, you should use quick-driver.tests these days. I assume that doesn't affect
this bug though.
> Xserver crashes w
Hi, Kamil.
Sorry. our patch has no problem and this is my mistake. so your patch has
been merged to our git repository.
Thanks.
> -Original Message-
> From: Inki Dae [mailto:inki@samsung.com]
> Sent: Tuesday, February 14, 2012 5:58 PM
> To: 'Kamil Debski'; 'dri-devel@lists.freedesktop
On Tue, Feb 14, 2012 at 7:52 AM, Inki Dae wrote:
> this patch set fixes page flip and mode setting issues and also
> hdmi v1.4 support.
Adding hdmi v1.4 support doesn't seem like a fix to me, it seems like
a new feature.
This should be in a -next tree, if you want to have fixes in 3.3 then
pleas
https://bugs.freedesktop.org/show_bug.cgi?id=45968
--- Comment #9 from Tobias Diedrich 2012-02-14
03:00:35 PST ---
FWIW using HDMI on 3.3-rc I can go up to 2560x1440@48, but 2560x1440@60 is
above the 340MHz pixelclock limit for one link.
I installed XP yesterday and found that it shows the sam
Hi Dave,
qa just reported on the latest drm-intel-next tree testing and found no
regression. My own testing also hasn't revealed any surprises. The old
tree had 3 outstanding issues:
- this pull request contains a fix for the harmless but annoying i855gm
dmesg splatter issue
- an otherwise harml
https://bugs.freedesktop.org/show_bug.cgi?id=45968
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Mon, Feb 13, 2012 at 9:29 PM, Jan Engelhardt wrote:
> Hello,
>
>
> the SONY PCG U3 device has a
>
> 00:0c.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon
> Mobility M6 LY [1002:4c59]
>
> graphics card. With linux 3.1.10, X.org server 7.6_1.10.4 and
> xf86-video-ati-6.14.2, switc
https://bugs.freedesktop.org/show_bug.cgi?id=45968
--- Comment #11 from Roland Scheidegger 2012-02-14
10:04:35 PST ---
(In reply to comment #9)
> FWIW using HDMI on 3.3-rc I can go up to 2560x1440@48, but 2560x1440@60 is
> above the 340MHz pixelclock limit for one link.
I'm surprised this old
On Tue, Feb 14, 2012 at 10:38:11AM +0300, Dan Carpenter wrote:
> We store stuff in texdw[7] so this array needs to have 8 elements.
>
> Signed-off-by: Dan Carpenter
Reviewed-by: Jerome Glisse
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
> b/drivers/gpu/drm/radeon/evergreen_cs.c
> ind
We store stuff in texdw[7] so this array needs to have 8 elements.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 2ed17f7..49203b6 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/everg
https://bugs.freedesktop.org/show_bug.cgi?id=27184
--- Comment #19 from tomi.or...@ncircle.nullnet.fi 2012-02-14 10:43:41 PST ---
Sorry about the disappearence for a long time. I thought I had enabled the
notifications for this bug.
It seems that I still have this very same problem even with ker
https://bugs.freedesktop.org/show_bug.cgi?id=27184
--- Comment #20 from Alex Deucher 2012-02-14 11:07:38 PST ---
Does kernel 3.3rc3 or newer work any better?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are t
https://bugs.freedesktop.org/show_bug.cgi?id=27184
--- Comment #21 from Oliver Winker 2012-02-14 12:36:44
PST ---
Hi,
Just for info: in my case, since quite some time using 3.1 and 3.2 (and on
debian xorg 7.6+11, radeon 6.14.3-2) the screen wake-up works quite reliable
now,
without the xset d
https://bugs.freedesktop.org/show_bug.cgi?id=45880
--- Comment #3 from Jerome Glisse 2012-02-14 12:54:39
PST ---
I pushed a fix please confirm that it also works for you
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because:
This way we can free up the bus->adaptor.algo_data pointer and make it
available for use with the bitbanging fallback algo.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 13 -
drivers/gpu/drm/i915/intel_i2c.c |6 +++---
2 files changed, 11 insertions(+), 8
I'd like to export the corresponding functions from the i2c core
so that I can use them in fallback bit-banging in i915.ko
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_i2c.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
d
i915 has a hw i2c controller (gmbus) but for a bunch of stupid reasons
we need to be able to fall back to the bit-banging algo on gpio pins.
The current code sets up a 2nd i2c controller for the same i2c bus using
the bit-banging algo. This has a bunch of issues, the major one being
that userspace
When we set up the gpio fallback, we always have a 1:1 relationship
with an intel_gmbus. Exploit that to store all gpio related data in
there, too. This is a preparation step to merge the tw i2c adapters
controlling the same bus into one.
Just mundane code-munging in this patch.
Signed-Off-by: Da
... and directly call the newly exported i2c bit-banging functions.
The code is still pretty convoluted because we only set up the gpio
i2c stuff when actually falling back, resulting in more complexity
than necessary. This will be fixed up in the next patch.
Signed-Off-by: Daniel Vetter
---
dr
This way we can simplify the setup and teardown a bit.
Because we don't actually allocate anything anymore for the force_bit
case, we can now convert that into a boolean.
Also and the functionality supported by the bit-banging together with
what gmbus can do, so that this doesn't randomly change
With the rework to merge the bit-banging fallback into the gmbus
i2c adapter we've gotten rid of the deadlock possibility that
originally lead to the disabling of this code.
This reverts the revert
commit 826c7e4147f902737b281e8a5a7d7aa33fd63316
Author: Jean Delvare
Date: Sat Jun 4 19:34:56 20
This way we can simplify the setup and teardown a bit.
Because we don't actually allocate anything anymore for the force_bit
case, we can now convert that into a boolean.
Also and the functionality supported by the bit-banging together with
what gmbus can do, so that this doesn't randomly change
On Tue, Feb 14, 2012 at 19:37, Daniel Vetter wrote:
>/* Hardware may not support GMBUS over these pins? Try GPIO
> bitbanging instead. */
> - bus->force_bit = intel_gpio_create(bus, bus->reg0 & 0xff);
> - if (!bus->force_bit)
> - ret = -ENOMEM;
> - else
> -
Hi, Dave.
I'm so sorry. I will resent it removing new feature.
Thanks,
Inki Dae
> -Original Message-
> From: Dave Airlie [mailto:airl...@gmail.com]
> Sent: Tuesday, February 14, 2012 7:54 PM
> To: Inki Dae
> Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
> kyungmin.p...@samsung.c
On Sun, 12 Feb 2012 11:00:43 +0100
Michel Dänzer wrote:
> On Sam, 2012-02-11 at 21:00 +0100, acrux wrote:
> >
> > Just a curiosity, i've only two powerpc machines[1] equipped with PCIE
> > videocards and both them are not able to boot with radeonkms.
> > Modern PCI-E videocards are not recogniz
I am resending the patch set removing new features from previous one.
this patch set fixes page flip issue and releases some resources
and these new features will be sent to drm-next later.
this is based on git repository below:
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git,
br
From: Joonyoung Shim
if one process is terminated by ctrl-c while two processes are
using pageflip feature then for last pageflip event,
user can't get poll from kernel side so this patch fixes the problem.
Signed-off-by: Joonyoung Shim
Signed-off-by: Inki Dae
Signed-off-by: Kyoungmin Park
--
From: Masanari Iida
Correct spelling "sucessful" to "successful" in
drivers/gpu/drm/exynos/exynos_mixer.c
Signed-off-by: Masanari Iida
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_mixer.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
d
basically, all crtcs are possible to clone each other.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_core.c|3 ++
drivers/gpu/drm/exynos/exynos_drm_drv.c |4 +++
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 34 +
From: Joonyoung Shim
Signed-off-by: Joonyoung Shim
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_mixer.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/e
with vblank_refcount = 1, there was the case that drm_vblank_put
is called by specific page flip function so this patch fixes the
issue.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c |6 +++---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |
this function ins't needed anymore.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 70 ++---
1 files changed, 4 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/d
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 76a111f..58820eb 100644
-
From: Kamil Debski
First of all #ifdef __KERNEL__ was added to exynos_drm.h to
mark the part that should be left out of userspace.
Secondly exynos_drm.h was added to include/drm/Kbuild, so it
will be included when doing make headers_install.
Signed-off-by: Kamil Debski
Signed-off-by: Inki Dae
On Wed, 2012-02-15 at 03:23 +0100, acrux wrote:
> On Sun, 12 Feb 2012 11:00:43 +0100
> Michel Dänzer wrote:
>
> > On Sam, 2012-02-11 at 21:00 +0100, acrux wrote:
> > >
> > > Just a curiosity, i've only two powerpc machines[1] equipped with PCIE
> > > videocards and both them are not able to boo
https://bugs.freedesktop.org/show_bug.cgi?id=46004
--- Comment #5 from Tom Stellard 2012-02-14 19:38:21 PST
---
I'm guessing that this is a bug in the vertex shader. Does running with
RADEON_NO_TCL=1 fix it?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- Y
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #15 from Alexandre Demers 2012-02-14
22:44:50 UTC ---
I'm now running kernel 3.3-rc3 and some applications are completely freezing my
system. I haven't seen anything special in the various logs. The only error
available is about a c
https://bugs.freedesktop.org/show_bug.cgi?id=27184
--- Comment #22 from tomi.or...@ncircle.nullnet.fi 2012-02-14 22:49:18 PST ---
(In reply to comment #20)
> Does kernel 3.3rc3 or newer work any better?
I tested with the latest git version from yesterday evening
(13d261932bbfff7f45f288c5c8cce431
On Mit, 2012-02-15 at 13:50 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2012-02-15 at 03:23 +0100, acrux wrote:
> > On Sun, 12 Feb 2012 11:00:43 +0100
> > Michel Dänzer wrote:
> >
> > > On Sam, 2012-02-11 at 21:00 +0100, acrux wrote:
> > > >
> > > > Just a curiosity, i've only two powerpc m
k in return path of radeon_fence_count_emitted" fixes=0Athe problem. Tested=
on top of 47492a23a and 3.3.0-rc3+00188-g3ec1e88.=0A=0A=0AThanks,=0A=0AMik=
ko
> -Original Message-
> From: Masanari Iida [mailto:standby24x7 at gmail.com]
> Sent: Monday, February 13, 2012 11:11 PM
> To: inki.dae at samsung.com; jy0922.shim at samsung.com; sw0312.kim at
> samsung.com;
> dri-devel at lists.freedesktop.org
> Cc: trivial at kernel.org; linux-kernel a
https://bugs.freedesktop.org/show_bug.cgi?id=46005
--- Comment #1 from Tom Stellard 2012-02-13 18:51:03
PST ---
This is a r300 compiler bug. Flow control doesn't work very well for vertex
shaders at the moment. I have been slowly working on fixing this, but I'm not
quite done yet.
--
Config
Hello,
the SONY PCG U3 device has a
00:0c.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon
Mobility M6 LY [1002:4c59]
graphics card. With linux 3.1.10, X.org server 7.6_1.10.4 and
xf86-video-ati-6.14.2, switching from KMS'd console to X on tty7
yields a white screen that also st
On Tue, Feb 14, 2012 at 2:18 AM, Eric Anholt wrote:
> On Thu, ?9 Feb 2012 00:19:31 +0100, Ben Widawsky wrote:
>> Mostly copied from i915 gtt mmaps, this will properly fault in pages as
>> the user tries to use them. The only thing of note are that no
>> prefaulting occurs, so perhaps some kind of
this patch set fixes page flip and mode setting issues and also
hdmi v1.4 support.
this is based on git repository below:
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git,
branch name: drm-fixes
commit-id: 28a4d5675857f6386930a324317281cb8ed1e5d0
and you can refer to our working
From: Masanari Iida
Correct spelling "sucessful" to "successful" in
drivers/gpu/drm/exynos/exynos_mixer.c
Signed-off-by: Masanari Iida
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_mixer.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
d
From: Joonyoung Shim
Signed-off-by: Joonyoung Shim
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 1152 +++---
drivers/gpu/drm/exynos/exynos_hdmi.h | 10 +-
drivers/gpu/drm/exynos/regs-hdmi.h | 306 --
i
From: Joonyoung Shim
Signed-off-by: Joonyoung Shim
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_mixer.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/e
From: Joonyoung Shim
Signed-off-by: Joonyoung Shim
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exyn
From: Joonyoung Shim
if one process is terminated by ctrl-c while two processes are
using pageflip feature then for last pageflip event,
user can't get poll from kernel side so this patch fixes the problem.
Signed-off-by: Joonyoung Shim
Signed-off-by: Inki Dae
Signed-off-by: Kyoungmin Park
--
basically, all crtcs are possible to clone each other.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_core.c|3 ++
drivers/gpu/drm/exynos/exynos_drm_drv.c |4 +++
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 34 +
this function ins't needed anymore.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 70 ++---
1 files changed, 4 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/d
with vblank_refcount = 1, there was the case that drm_vblank_put
is called by specific page flip function so this patch fixes the
issue.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c |6 +++---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 76a111f..58820eb 100644
-
this patch adds mode_fixup feature for hdmi module that
specific driver changes current mode to driver desired mode
properly.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_connector.c | 25 +++-
drivers/gpu/drm/exynos/exynos_drm_crtc.c |
From: Eun-Chul Kim
Signed-off-by: Eun-Chul Kim
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_connector.c | 16 ++
drivers/gpu/drm/exynos/exynos_drm_drv.h |4 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 27 ++
https://bugs.freedesktop.org/show_bug.cgi?id=46004
--- Comment #4 from Pavel Ondra?ka 2012-02-14
00:36:35 PST ---
Created attachment 57014
--> https://bugs.freedesktop.org/attachment.cgi?id=57014
RADEON_DEBUG=fp,vp log (piglit pass)
The patch doesn't help. Attaching a new log with
6d4b35c036
https://bugs.freedesktop.org/show_bug.cgi?id=46019
Bug #: 46019
Summary: blur position incorrect
Classification: Unclassified
Product: Mesa
Version: 8.0
Platform: Other
OS/Version: All
Status: NEW
Severity: n
Hi, Kamil.
Sorry for being late.
Below is my comments.
> -Original Message-
> From: Kamil Debski [mailto:k.debski at samsung.com]
> Sent: Saturday, February 11, 2012 2:32 AM
> To: dri-devel at lists.freedesktop.org
> Cc: kyungmin.park at samsung.com; inki.dae at samsung.com;
> jy0922.shim
https://bugs.freedesktop.org/show_bug.cgi?id=34155
--- Comment #8 from Marco Albanese 2012-02-14 01:15:48
PST ---
After last kernel upgrade ( 3.2.0-1-486 with Debian patches ) I don't get the
error messages anymore.
Would you like me to check the value of r with your patch using the previous
https://bugs.freedesktop.org/show_bug.cgi?id=34155
Michel D?nzer changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
On Mon, 13 Feb 2012 23:26:23 +0100, Daniel Vetter wrote:
> On Mon, Feb 13, 2012 at 09:49:35PM +, Chris Wilson wrote:
> > On Mon, 13 Feb 2012 21:38:38 +0100, Daniel Vetter
> > wrote:
> > However, the outstanding issue is that we need to separate the gmbus
> > i2c adapter from the gpio i2c ada
On Mon, Feb 13, 2012 at 05:36:54PM -0500, Yufeng Shen wrote:
> Moved gmbus_mutex below intel_gmbus and added comments.
> Rebased to drm-intel-next-queued.
>
>
>
> GMBUS has several ports and each has it's own corresponding
> I2C adp
https://bugs.freedesktop.org/show_bug.cgi?id=45984
--- Comment #5 from Michel D?nzer 2012-02-14 01:49:28
PST ---
> 2) Run ./piglit-run.py tests/r600.tests results/r600.results
BTW, you should use quick-driver.tests these days. I assume that doesn't affect
this bug though.
> Xserver crashes w
Hi, Kamil.
Sorry. our patch has no problem and this is my mistake. so your patch has
been merged to our git repository.
Thanks.
> -Original Message-
> From: Inki Dae [mailto:inki.dae at samsung.com]
> Sent: Tuesday, February 14, 2012 5:58 PM
> To: 'Kamil Debski'; 'dri-devel at lists.freed
On Tue, Feb 14, 2012 at 7:52 AM, Inki Dae wrote:
> this patch set fixes page flip and mode setting issues and also
> hdmi v1.4 support.
Adding hdmi v1.4 support doesn't seem like a fix to me, it seems like
a new feature.
This should be in a -next tree, if you want to have fixes in 3.3 then
pleas
https://bugs.freedesktop.org/show_bug.cgi?id=45968
--- Comment #9 from Tobias Diedrich
2012-02-14 03:00:35 PST ---
FWIW using HDMI on 3.3-rc I can go up to 2560x1440 at 48, but 2560x1440 at 60
is above the 340MHz pixelclock limit for one link.
I installed XP yesterday and found that it shows t
Hi Dave,
qa just reported on the latest drm-intel-next tree testing and found no
regression. My own testing also hasn't revealed any surprises. The old
tree had 3 outstanding issues:
- this pull request contains a fix for the harmless but annoying i855gm
dmesg splatter issue
- an otherwise harml
https://bugs.freedesktop.org/show_bug.cgi?id=45968
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Mon, Feb 13, 2012 at 9:29 PM, Jan Engelhardt wrote:
> Hello,
>
>
> the SONY PCG U3 device has a
>
> 00:0c.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon
> Mobility M6 LY [1002:4c59]
>
> graphics card. With linux 3.1.10, X.org server 7.6_1.10.4 and
> xf86-video-ati-6.14.2, switc
https://bugs.freedesktop.org/show_bug.cgi?id=45968
--- Comment #11 from Roland Scheidegger 2012-02-14
10:04:35 PST ---
(In reply to comment #9)
> FWIW using HDMI on 3.3-rc I can go up to 2560x1440 at 48, but 2560x1440 at 60
> is above the 340MHz pixelclock limit for one link.
I'm surprised thi
On Tue, Feb 14, 2012 at 10:38:11AM +0300, Dan Carpenter wrote:
> We store stuff in texdw[7] so this array needs to have 8 elements.
>
> Signed-off-by: Dan Carpenter
Reviewed-by: Jerome Glisse
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
> b/drivers/gpu/drm/radeon/evergreen_cs.c
> ind
We store stuff in texdw[7] so this array needs to have 8 elements.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 2ed17f7..49203b6 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/everg
https://bugs.freedesktop.org/show_bug.cgi?id=27184
--- Comment #19 from tomi.orava at ncircle.nullnet.fi 2012-02-14 10:43:41 PST
---
Sorry about the disappearence for a long time. I thought I had enabled the
notifications for this bug.
It seems that I still have this very same problem even with
https://bugs.freedesktop.org/show_bug.cgi?id=27184
--- Comment #20 from Alex Deucher 2012-02-14 11:07:38 PST
---
Does kernel 3.3rc3 or newer work any better?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are
https://bugs.freedesktop.org/show_bug.cgi?id=27184
--- Comment #21 from Oliver Winker 2012-02-14
12:36:44 PST ---
Hi,
Just for info: in my case, since quite some time using 3.1 and 3.2 (and on
debian xorg 7.6+11, radeon 6.14.3-2) the screen wake-up works quite reliable
now,
without the xset d
https://bugs.freedesktop.org/show_bug.cgi?id=45880
--- Comment #3 from Jerome Glisse 2012-02-14
12:54:39 PST ---
I pushed a fix please confirm that it also works for you
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because:
This way we can free up the bus->adaptor.algo_data pointer and make it
available for use with the bitbanging fallback algo.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 13 -
drivers/gpu/drm/i915/intel_i2c.c |6 +++---
2 files changed, 11 insertions(+), 8
I'd like to export the corresponding functions from the i2c core
so that I can use them in fallback bit-banging in i915.ko
Cc: nouveau at lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_i2c.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
i915 has a hw i2c controller (gmbus) but for a bunch of stupid reasons
we need to be able to fall back to the bit-banging algo on gpio pins.
The current code sets up a 2nd i2c controller for the same i2c bus using
the bit-banging algo. This has a bunch of issues, the major one being
that userspace
When we set up the gpio fallback, we always have a 1:1 relationship
with an intel_gmbus. Exploit that to store all gpio related data in
there, too. This is a preparation step to merge the tw i2c adapters
controlling the same bus into one.
Just mundane code-munging in this patch.
Signed-Off-by: Da
... and directly call the newly exported i2c bit-banging functions.
The code is still pretty convoluted because we only set up the gpio
i2c stuff when actually falling back, resulting in more complexity
than necessary. This will be fixed up in the next patch.
Signed-Off-by: Daniel Vetter
---
dr
This way we can simplify the setup and teardown a bit.
Because we don't actually allocate anything anymore for the force_bit
case, we can now convert that into a boolean.
Also and the functionality supported by the bit-banging together with
what gmbus can do, so that this doesn't randomly change
With the rework to merge the bit-banging fallback into the gmbus
i2c adapter we've gotten rid of the deadlock possibility that
originally lead to the disabling of this code.
This reverts the revert
commit 826c7e4147f902737b281e8a5a7d7aa33fd63316
Author: Jean Delvare
Date: Sat Jun 4 19:34:56 20
This way we can simplify the setup and teardown a bit.
Because we don't actually allocate anything anymore for the force_bit
case, we can now convert that into a boolean.
Also and the functionality supported by the bit-banging together with
what gmbus can do, so that this doesn't randomly change
code more
clean.
Reviewed-by: Eugeni Dodonov
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120214/a59f3d5e/attachment.htm>
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #15 from Alexandre Demers
2012-02-14 22:44:50 UTC ---
I'm now running kernel 3.3-rc3 and some applications are completely freezing my
system. I haven't seen anything special in the various logs. The only error
available is about a c
96 matches
Mail list logo
