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 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
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
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=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
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
... 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
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
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
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(-)
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
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=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:
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=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=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
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
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
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
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
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 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 |
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
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: 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
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
--
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
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
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
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
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
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 ++
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 |
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 |
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
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: 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
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: 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
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
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
> -
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
https://bugs.freedesktop.org/show_bug.cgi?id=45968
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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
... 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
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
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
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
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
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
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
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:
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=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=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
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
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=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
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
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
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
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
> -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=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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=34155
Michel D?nzer changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
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=46019
Bug #: 46019
Summary: blur position incorrect
Classification: Unclassified
Product: Mesa
Version: 8.0
Platform: Other
OS/Version: All
Status: NEW
Severity: n
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
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
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
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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
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
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
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=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
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
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=34155
Michel Dänzer changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
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
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=46019
Bug #: 46019
Summary: blur position incorrect
Classification: Unclassified
Product: Mesa
Version: 8.0
Platform: Other
OS/Version: All
Status: NEW
Severity: n
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
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
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 ++
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 |
96 matches
Mail list logo
