Re: [PATCH] drm/exynos: Make g2d_pm_ops static

2012-08-29 Thread Joonyoung Shim 

On 08/28/2012 05:41 PM, Sachin Kamat wrote:

Fixes the following warning:
drivers/gpu/drm/exynos/exynos_drm_g2d.c:897:1: warning:
symbol 'g2d_pm_ops' was not declared. Should it be static?

Signed-off-by: Sachin Kamat 
---
  drivers/gpu/drm/exynos/exynos_drm_g2d.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 6adfa4e..1065e90 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -894,7 +894,7 @@ static int g2d_resume(struct device *dev)
  }
  #endif
  
-SIMPLE_DEV_PM_OPS(g2d_pm_ops, g2d_suspend, g2d_resume);

+static SIMPLE_DEV_PM_OPS(g2d_pm_ops, g2d_suspend, g2d_resume);


Right, it should be static but i don't get any warning message without 
static.


Thanks.

  
  struct platform_driver g2d_driver = {

.probe  = g2d_probe,


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: -next queue and EDID stuff

2012-08-29 Thread Daniel Vetter 
On Tue, Aug 28, 2012 at 11:18:24PM -0500, Ian Pilcher wrote:
> On 08/28/2012 07:13 PM, Adam Jackson wrote:
> > On 8/28/12 7:33 PM, Ian Pilcher wrote:
> >> Actually, I believe that the error is probably in the Intel driver.  As
> >> I understand it, it shouldn't be sending audio InfoFrames to a non-HDMI
> >> display.
> > 
> > If that's the case then I'd still say "we're doing something else wrong
> > here".  Quirks - at least at the core drm level - are not for working
> > around broken drivers, they're for working around broken displays.
> 
> And I'd agree.
> 
> (Although I suppose one *could* argue that the display is broken in 2
> ways -- it reports audio capabilities that aren't really there, and it
> gets confused by any InfoFrames -- AVI or audio.)
> 
> I don't have the knowledge or time to fix the Intel driver, but I've
> always planned to at least bugzilla the issue.  I can't reasonably do
> so, however, until the user-defined quirks infrastructure is in place,
> so that the behavior can be demonstrated.
> 
> If you prefer to leave the display broken with Intel GPUs, you can
> always just remove the EDID_QUIRK_NO_AUDIO flag:

Wrt intel infoframes issues: Have you retested on latest 3.6-rc kernels?
We've fixed quite a few bugs for our infoframe support recently ...
-Daniel

> 
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -160,6 +160,10 @@  union edid_quirk
> edid_quirk_list[EDID_QUIRK_LIST_SIZE] = {
>   { { { { EDID_MFG_ID('V', 'S', 'C'), cpu_to_le16(5020) } },
>   EDID_QUIRK_FORCE_REDUCED_BLANKING } },
> 
> + /* LG L246WP */
> + { { { { EDID_MFG_ID('G', 'S', 'M'), cpu_to_le16(0x563f) } },
> + EDID_QUIRK_DISABLE_INFOFRAMES } },
> +
>   /*
>* When adding built-in quirks, please adjust EDID_QUIRK_LIST_SIZE to
>* provide some room for user-supplied quirks.
> 
> -- 
> 
> Ian Pilcher arequip...@gmail.com
> "If you're going to shift my paradigm ... at least buy me dinner first."
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PULL] drm-intel-fixes

2012-08-29 Thread Daniel Vetter 
Per usual, I've forgotten all the cc's ... I really need to script this,
I'm too dumb to remember.
-Daniel

On Wed, Aug 29, 2012 at 10:29:43AM +0200, Daniel Vetter wrote:
> Hi Dave,
> 
> Just a few smaller things:
> - Fix up a pipe vs. plane confusion from a refactoring, fixes a regression
>   from 3.1 (Anhua Xu).
> - Fix ivb sprite pixel formats (Vijay).
> - Fixup ppgtt pde placement for machines where the Bios artifically limits
>   the availbale gtt space in the name of ... product differentiation
>   (Chris). This fixes an oops.
> - Yet another no_lvds quirk entry.
> 
> Otherwise nothing outstanding afaik, things are as boring as they should
> be ;-)
> 
> Cheers, Daniel
> 
> The following changes since commit fea7a08acb13524b47711625eebea40a0ede69a0:
> 
>   Linux 3.6-rc3 (2012-08-22 13:29:06 -0700)
> 
> are available in the git repository at:
> 
>   git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes
> 
> for you to fetch changes up to a51d4ed01e5bb39d2cf36a12f9976ab08872c192:
> 
>   i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard (2012-08-24 
> 14:40:09 +0200)
> 
> 
> Calvin Walton (1):
>   i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard
> 
> Chris Wilson (1):
>   drm/i915: Use the correct size of the GTT for placing the per-process 
> entries
> 
> Vijay Purushothaman (1):
>   drm/i915: fix color order for BGR formats on IVB
> 
> Xu, Anhua (1):
>   drm/i915: fix wrong order of parameters in port checking functions
> 
>  drivers/gpu/drm/i915/i915_gem_gtt.c  |2 +-
>  drivers/gpu/drm/i915/intel_display.c |   12 ++--
>  drivers/gpu/drm/i915/intel_lvds.c|8 
>  drivers/gpu/drm/i915/intel_sprite.c  |4 ++--
>  4 files changed, 17 insertions(+), 9 deletions(-)
> -- 
> Daniel Vetter
> Mail: dan...@ffwll.ch
> Mobile: +41 (0)79 365 57 48

-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S

2012-08-29 Thread Paul Menzel 
Date: Wed, 8 Aug 2012 23:12:19 +0200
Subject: [PATCH v2] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S

Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with
vertical stripes in the top half.

In commit bc42aabc [2]

commit bc42aabc6a01b92b0f961d65671564e0e1cd7592
Author: Adam Jackson 
Date:   Wed May 23 16:26:54 2012 -0400

drm/edid/quirks: ViewSonic VA2026w

Adam Jackson added the quirk `EDID_QUIRK_FORCE_REDUCED_BLANKING` which
is also needed for this ASUS monitor.

All log files and output from `xrandr` is included in the referenced
Bugzilla report #17629.

Please note that this monitor only has a VGA (D-Sub) connector [1].

[1] http://www.asus.com/Display/LCD_Monitors/VW222S/
[2] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bc42aabc6a01b92b0f961d65671564e0e1cd7592

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=17629
Signed-off-by: Paul Menzel 
Cc: 
Cc: Adam Jackson 
Cc: Ian Pilcher 
Cc: 
---
v2: • Prepend model number with 0x to fix compilation.
• Update commit message to mention that there is only a VGA connector.

Same comment as in previous patch.

Ian, I did not base this patch on your series, to make it easier to get
back ported. I can easily rebase it though, so hopefully some maintainer
can tell me what to do.
---
 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 75e252e..4befc7f 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -87,6 +87,9 @@ static struct edid_quirk {
int product_id;
u32 quirks;
 } edid_quirk_list[] = {
+   /* ASUS VW222S */
+   { "ACI", 0x22a2, EDID_QUIRK_FORCE_REDUCED_BLANKING },
+
/* Acer AL1706 */
{ "ACR", 44358, EDID_QUIRK_PREFER_LARGE_60 },
/* Acer F51 */
-- 
1.7.10.4


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V4] drm: edid: add support for E-DDC

2012-08-29 Thread Ville Syrjälä 
On Sat, Aug 25, 2012 at 03:13:56PM +0530, Shirish S wrote:
> The current logic for probing ddc is limited to
> 2 blocks (256 bytes), this patch adds support
> for the 4 block (512) data.
> 
> To do this, a single 8-bit segment index is
> passed to the display via the I2C address 30h.
> Data from the selected segment is then immediately
> read via the regular DDC2 address using a repeated
> I2C 'START' signal.
> 
> Signed-off-by: Shirish S 
> ---
>  drivers/gpu/drm/drm_edid.c |   22 ++
>  1 files changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index a8743c3..cde7af0 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned char *buf,
> int block, int len)
>  {
>   unsigned char start = block * EDID_LENGTH;
> + unsigned char segment = block >> 1;
> + unsigned char xfers = segment ? 3 : 2;
>   int ret, retries = 5;
>  
>   /* The core i2c driver will automatically retry the transfer if the
> @@ -264,7 +266,12 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned char *buf,
>*/
>   do {
>   struct i2c_msg msgs[] = {
> - {
> + { /*set segment pointer */

Missing whitespace after '/*'. Perhaps just drop the comment. I don't
see much value in it.

> + .addr   = DDC_SEGMENT_ADDR,
> + .flags  = segment ? 0 : I2C_M_IGNORE_NAK,
> + .len= 1,
> + .buf= &segment,
> + }, {
>   .addr   = DDC_ADDR,
>   .flags  = 0,
>   .len= 1,
> @@ -276,15 +283,22 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned char *buf,
>   .buf= buf,
>   }
>   };
> - ret = i2c_transfer(adapter, msgs, 2);
> + /* Avoid sending the segment addr to not upset non-compliant ddc
> +  * monitors.
> +  */

Wrong indentation and comment style is wrong. I'm guessing this didn't go
through checkpatch.pl.

Otherwise looks OK to me.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: fix double free in radeon_gpu_reset

2012-08-29 Thread Christian König 
radeon_ring_restore is freeing the memory for the saved
ring data. We need to remember that, otherwise we try to
restore the ring data again on the next try. Additional
to that it shouldn't try the reset infinitely if we have
saved ring data.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_device.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index d2e2438..814194f 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1346,12 +1346,15 @@ retry:
for (i = 0; i < RADEON_NUM_RINGS; ++i) {
radeon_ring_restore(rdev, &rdev->ring[i],
ring_sizes[i], ring_data[i]);
+   ring_sizes[i] = 0;
+   ring_data[i] = NULL;
}
 
r = radeon_ib_ring_tests(rdev);
if (r) {
dev_err(rdev->dev, "ib ring test failed (%d).\n", r);
if (saved) {
+   saved = false;
radeon_suspend(rdev);
goto retry;
}
-- 
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V4] drm: edid: add support for E-DDC

2012-08-29 Thread Shirish S 
On Wed, Aug 29, 2012 at 4:08 AM, Ville Syrjälä <
ville.syrj...@linux.intel.com> wrote:

> On Sat, Aug 25, 2012 at 03:13:56PM +0530, Shirish S wrote:
> > The current logic for probing ddc is limited to
> > 2 blocks (256 bytes), this patch adds support
> > for the 4 block (512) data.
> >
> > To do this, a single 8-bit segment index is
> > passed to the display via the I2C address 30h.
> > Data from the selected segment is then immediately
> > read via the regular DDC2 address using a repeated
> > I2C 'START' signal.
> >
> > Signed-off-by: Shirish S 
> > ---
> >  drivers/gpu/drm/drm_edid.c |   22 ++
> >  1 files changed, 18 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index a8743c3..cde7af0 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> > int block, int len)
> >  {
> >   unsigned char start = block * EDID_LENGTH;
> > + unsigned char segment = block >> 1;
> > + unsigned char xfers = segment ? 3 : 2;
> >   int ret, retries = 5;
> >
> >   /* The core i2c driver will automatically retry the transfer if the
> > @@ -264,7 +266,12 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> >*/
> >   do {
> >   struct i2c_msg msgs[] = {
> > - {
> > + { /*set segment pointer */
>
> Missing whitespace after '/*'. Perhaps just drop the comment. I don't
> see much value in it.
>
> Done.

> > + .addr   = DDC_SEGMENT_ADDR,
> > + .flags  = segment ? 0 : I2C_M_IGNORE_NAK,
> > + .len= 1,
> > + .buf= &segment,
> > + }, {
> >   .addr   = DDC_ADDR,
> >   .flags  = 0,
> >   .len= 1,
> > @@ -276,15 +283,22 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> >   .buf= buf,
> >   }
> >   };
> > - ret = i2c_transfer(adapter, msgs, 2);
> > + /* Avoid sending the segment addr to not upset non-compliant ddc
> > +  * monitors.
> > +  */
>
> Wrong indentation and comment style is wrong. I'm guessing this didn't go
> through checkpatch.pl.
>
> I never got tha above as either an error or warning in the checkpatch,
anyways have uploaded patch set 5 incorporating your comments.

> Otherwise looks OK to me.
>
> --
> Ville Syrjälä
> Intel OTC
>

- Shirish

> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: fix double free in radeon_gpu_reset

2012-08-29 Thread Alex Deucher 
On Wed, Aug 29, 2012 at 7:24 AM, Christian König
 wrote:
> radeon_ring_restore is freeing the memory for the saved
> ring data. We need to remember that, otherwise we try to
> restore the ring data again on the next try. Additional
> to that it shouldn't try the reset infinitely if we have
> saved ring data.
>
> Signed-off-by: Christian König 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/radeon/radeon_device.c |3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
> b/drivers/gpu/drm/radeon/radeon_device.c
> index d2e2438..814194f 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -1346,12 +1346,15 @@ retry:
> for (i = 0; i < RADEON_NUM_RINGS; ++i) {
> radeon_ring_restore(rdev, &rdev->ring[i],
> ring_sizes[i], ring_data[i]);
> +   ring_sizes[i] = 0;
> +   ring_data[i] = NULL;
> }
>
> r = radeon_ib_ring_tests(rdev);
> if (r) {
> dev_err(rdev->dev, "ib ring test failed (%d).\n", r);
> if (saved) {
> +   saved = false;
> radeon_suspend(rdev);
> goto retry;
> }
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: Make g2d_pm_ops static

2012-08-29 Thread Sachin Kamat 
On 29 August 2012 12:32, Joonyoung Shim  wrote:
> On 08/28/2012 05:41 PM, Sachin Kamat wrote:
>>
>> Fixes the following warning:
>> drivers/gpu/drm/exynos/exynos_drm_g2d.c:897:1: warning:
>> symbol 'g2d_pm_ops' was not declared. Should it be static?
>>
>> Signed-off-by: Sachin Kamat 
>> ---
>>   drivers/gpu/drm/exynos/exynos_drm_g2d.c |2 +-
>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>> index 6adfa4e..1065e90 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>> @@ -894,7 +894,7 @@ static int g2d_resume(struct device *dev)
>>   }
>>   #endif
>>   -SIMPLE_DEV_PM_OPS(g2d_pm_ops, g2d_suspend, g2d_resume);
>> +static SIMPLE_DEV_PM_OPS(g2d_pm_ops, g2d_suspend, g2d_resume);
>
>
> Right, it should be static but i don't get any warning message without
> static.

You will get it if you enable sparse checking while building the kernel.

>
> Thanks.
>
>
>> struct platform_driver g2d_driver = {
>> .probe  = g2d_probe,
>
>



-- 
With warm regards,
Sachin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: radeon mobility x1600 broken since 3.4.0-rc6 (bisected)

2012-08-29 Thread Hausensteiner Keg 

On 27/08/12 21:04, Hausensteiner Keg wrote:

On 27/08/12 20:29, Jerome Glisse wrote:
On Sun, Aug 26, 2012 at 8:34 PM, Hausensteiner Keg 
 wrote:

...

Does patch

http://people.freedesktop.org/~glisse/0001-drm-radeon-extra-type-safe-for-fence-emission.patch 



Helps ?


Thanks Jerome. Will try patch tonight or tomorrow morning.

How do I check whether the radeon is on an AGP bus?
The lspci output does not mention AGP; line for video controller is:
  01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee 
ATI M56P [Radeon Mobility X1600]

The "lshw" output also shows no signs of AGP.

The dmesg output contains "[0.909546] Linux agpgart interface v0.103" 
but otherwise no mention of "agp" or "AGP".


By the way: tested the 3.5.3 release made today : still corrupt 
graphics. And the v3.5 release (which was oddly working) also showed 
the same corrupt graphics as soon as I forced a rebuild of the initrd 
- maybe an older radeon module somehow ended up in the initrd built by 
"make-kpkg --initrd".




Patch 0001-drm-radeon-extra-type-safe-for-fence-emission applies cleanly 
to both 3.5.3 and 3.6.0-rc3, but makes no difference in either case.


I've done some more bisecting, and the full sequence is:

* Prior to commit bb635567 ("convert fence to uint64_t v4") all works fine.
* Commit bb635567 causes system to freeze on Plymouth startup.
* The following commit (3b7a2b24, "rework fence handling, drop fence 
list v7") causes Plymouth to work again, but causes graphics corruption 
on greeter screen. Pressing ctrl-alt-f2 immediately displays a virtual 
console correctly, and the system is useable. However any attempt to use 
the mouse on the greeter screen triggers further graphics corruption, 
and system appears to hang.


This situation continues up to and including 3.5.3.

In the 3.6 dev cycle, the corruption issue continues up to 9c19415c. 
However the following commit, 876dc9f3 "remove radeon_fence_create" 
instead causes the screen to go black immediately after plymouth 
completes (ie when greeter screen is expected), and ctrl-alt-f2 has no 
effect.


FWIW, looks like two separate issues to me, with 876dc9f3 masking the 
earlier one..


Regards,
Simon
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V5] drm: edid: add support for E-DDC

2012-08-29 Thread Shirish S 
This patch adds support in probing 4 block edid data, for E-DDC.
This is the first test case in CTS, for HDMI compliance.

Changes from V4:
Fix review comments about space and comment indentation.

Based on drm-next branch

Shirish S (1):
  drm: edid: add support for E-DDC

 drivers/gpu/drm/drm_edid.c |   22 +++---
 1 files changed, 19 insertions(+), 3 deletions(-)

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V5] drm: edid: add support for E-DDC

2012-08-29 Thread Shirish S 
The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.

To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the regular DDC2 address using a repeated
I2C 'START' signal.

Signed-off-by: Shirish S 
---
 drivers/gpu/drm/drm_edid.c |   22 +++---
 1 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index bcc4725..b9ffc30 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned 
char *buf,
  int block, int len)
 {
unsigned char start = block * EDID_LENGTH;
+   unsigned char segment = block >> 1;
+   unsigned char xfers = segment ? 3 : 2;
int ret, retries = 5;
 
/* The core i2c driver will automatically retry the transfer if the
@@ -265,6 +267,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
unsigned char *buf,
do {
struct i2c_msg msgs[] = {
{
+   .addr   = DDC_SEGMENT_ADDR,
+   .flags  = segment ? 0 : I2C_M_IGNORE_NAK,
+   .len= 1,
+   .buf= &segment,
+   }, {
.addr   = DDC_ADDR,
.flags  = 0,
.len= 1,
@@ -276,15 +283,24 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
unsigned char *buf,
.buf= buf,
}
};
-   ret = i2c_transfer(adapter, msgs, 2);
+
+   /*
+* Avoid sending the segment addr to not upset non-compliant ddc
+* monitors.
+*/
+   if (!segment)
+   ret = i2c_transfer(adapter, &msgs[1], xfers);
+   else
+   ret = i2c_transfer(adapter, msgs, xfers);
+
if (ret == -ENXIO) {
DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
adapter->name);
break;
}
-   } while (ret != 2 && --retries);
+   } while (ret != xfers && --retries);
 
-   return ret == 2 ? 0 : -1;
+   return ret == xfers ? 0 : -1;
 }
 
 static bool drm_edid_is_zero(u8 *in_edid, int length)
-- 
1.7.0.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V4] drm: edid: add support for E-DDC

2012-08-29 Thread Jean Delvare 
Hi all,

Sorry for breaking message threading but I was not included in
iterations 3 and 4 of this patch.

Random comments about v4:

> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned 
> char *buf,
>   int block, int len)
>  {
> unsigned char start = block * EDID_LENGTH;
> +   unsigned char segment = block >> 1;
> +   unsigned char xfers = segment ? 3 : 2;
> int ret, retries = 5;
>  
> /* The core i2c driver will automatically retry the transfer if the
> @@ -264,7 +266,12 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned char *buf,
>  */
> do {
> struct i2c_msg msgs[] = {
> -   {
> +   { /*set segment pointer */
> +   .addr   = DDC_SEGMENT_ADDR,
> +   .flags  = segment ? 0 : I2C_M_IGNORE_NAK,

I don't get the idea. If segment == 0, this message is never sent, so the
value of field flags doesn't matter. So flags will always be 0 when this
message is sent, so it can be hard-coded.

But from previous discussions my understanding was an agreement on always
using I2C_M_IGNORE_NAK for improved compatibility. So I2C_M_IGNORE_NAK
should be hard-coded, not 0?

> +   .len= 1,
> +   .buf= &segment,
> +   }, {
> .addr   = DDC_ADDR,
> .flags  = 0,
> .len= 1,
> @@ -276,15 +283,22 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned char *buf,
> .buf= buf,
> }
> };
> -   ret = i2c_transfer(adapter, msgs, 2);
> +   /* Avoid sending the segment addr to not upset non-compliant ddc
> +* monitors.
> +*/

s/segment addr/segment/, plus it's abot E-DCC compliance as I understand it,
not DDC.

> +   if (!segment)
> +   ret = i2c_transfer(adapter, &msgs[1], xfers);
> +   else
> +   ret = i2c_transfer(adapter, msgs, xfers);
> +

This can be written:

ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);

Which is more compact and, I suspect, faster.

> if (ret == -ENXIO) {
> DRM_DEBUG_KMS("drm: skipping non-existent adapter 
> %s\n",
> adapter->name);
> break;
> }
> -   } while (ret != 2 && --retries);
> +   } while (ret != xfers && --retries);
>  
> -   return ret == 2 ? 0 : -1;
> +   return ret == xfers ? 0 : -1;
>  }
>  
>  static bool drm_edid_is_zero(u8 *in_edid, int length)

Other than this, your code looks reasonable, not so different from what
I submitted 8 months ago actually. But ISTU you can test the code with
real hardware while I couldn't.

With the changes above applied, you can add:

Reviewed-by: Jean Delvare 

-- 
Jean Delvare
Suse L3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V5] drm: edid: add support for E-DDC

2012-08-29 Thread Daniel Vetter 
On Wed, Aug 29, 2012 at 4:46 PM, Shirish S  wrote:
> The current logic for probing ddc is limited to
> 2 blocks (256 bytes), this patch adds support
> for the 4 block (512) data.
>
> To do this, a single 8-bit segment index is
> passed to the display via the I2C address 30h.
> Data from the selected segment is then immediately
> read via the regular DDC2 address using a repeated
> I2C 'START' signal.
>
> Signed-off-by: Shirish S 

If you resend patches it'd be nice to keep a changelog of the patch
itself somewhere, otherwise it's just more work to figure that out for
reviewers. Also, you can usually attach reviewed-by tags (like mine)
to a patch resend if you don't change the patch massively ...
-Daniel

> ---
>  drivers/gpu/drm/drm_edid.c |   22 +++---
>  1 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index bcc4725..b9ffc30 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned char *buf,
>   int block, int len)
>  {
> unsigned char start = block * EDID_LENGTH;
> +   unsigned char segment = block >> 1;
> +   unsigned char xfers = segment ? 3 : 2;
> int ret, retries = 5;
>
> /* The core i2c driver will automatically retry the transfer if the
> @@ -265,6 +267,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned char *buf,
> do {
> struct i2c_msg msgs[] = {
> {
> +   .addr   = DDC_SEGMENT_ADDR,
> +   .flags  = segment ? 0 : I2C_M_IGNORE_NAK,
> +   .len= 1,
> +   .buf= &segment,
> +   }, {
> .addr   = DDC_ADDR,
> .flags  = 0,
> .len= 1,
> @@ -276,15 +283,24 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned char *buf,
> .buf= buf,
> }
> };
> -   ret = i2c_transfer(adapter, msgs, 2);
> +
> +   /*
> +* Avoid sending the segment addr to not upset non-compliant ddc
> +* monitors.
> +*/
> +   if (!segment)
> +   ret = i2c_transfer(adapter, &msgs[1], xfers);
> +   else
> +   ret = i2c_transfer(adapter, msgs, xfers);
> +
> if (ret == -ENXIO) {
> DRM_DEBUG_KMS("drm: skipping non-existent adapter 
> %s\n",
> adapter->name);
> break;
> }
> -   } while (ret != 2 && --retries);
> +   } while (ret != xfers && --retries);
>
> -   return ret == 2 ? 0 : -1;
> +   return ret == xfers ? 0 : -1;
>  }
>
>  static bool drm_edid_is_zero(u8 *in_edid, int length)
> --
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 18872] [RADEON:KMS:R100:SUSPEND] suspend to ram problems

2012-08-29 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=18872


Alan  changed:

   What|Removed |Added

 Status|NEEDINFO|ASSIGNED




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 29512] [PATCH]radeon rejects EDID with RV350 when hw_i2c=1

2012-08-29 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=29512


Alan  changed:

   What|Removed |Added

  Component|Video(AGP)  |Video(DRI - non Intel)
 AssignedTo|airl...@linux.ie|drivers_video-dri@kernel-bu
   ||gs.osdl.org
Summary|radeon rejects EDID with|[PATCH]radeon rejects EDID
   |RV350 when hw_i2c=1 |with RV350 when hw_i2c=1




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] radeon drm-fixes-3.6

2012-08-29 Thread alexdeucher 
From: Alex Deucher 

Hi Dave,

This is the current set of radeon fixes for 3.6.  Nothing too major.

Highlights:
- fix a gart regression on older IGP chips
- more MSAA fixes
- fix a double free in gpu reset code
- modesetting fixes

The following changes since commit 84f720ecba6716d198b21936d1bf6253e8ab42a1:

  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2012-08-29 
20:09:23 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-3.6

Alex Deucher (4):
  drm/radeon: don't disable plls that are in use by other crtcs
  drm/radeon/atom: rework DIG modesetting on DCE3+
  drm/radeon/atom: powergating fixes for DCE6
  drm/radeon: rework panel mode setup

Christian König (1):
  drm/radeon: fix double free in radeon_gpu_reset

Jerome Glisse (1):
  drm/radeon: force dma32 to fix regression rs4xx,rs6xx,rs740

Marek Olšák (3):
  drm/radeon: fix reading CB_COLORn_MASK from the CS
  drm/radeon: initialize tracked CS state
  drm/radeon: add proper checking of RESOLVE_BOX command for r600-r700

 drivers/gpu/drm/radeon/atombios_crtc.c |   36 -
 drivers/gpu/drm/radeon/atombios_dp.c   |   29 +++-
 drivers/gpu/drm/radeon/atombios_encoders.c |  109 
 drivers/gpu/drm/radeon/r600_cs.c   |   30 +++-
 drivers/gpu/drm/radeon/r600d.h |8 ++
 drivers/gpu/drm/radeon/radeon_device.c |5 +-
 drivers/gpu/drm/radeon/radeon_drv.c|3 +-
 drivers/gpu/drm/radeon/reg_srcs/r600   |1 -
 8 files changed, 115 insertions(+), 106 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: -next queue and EDID stuff

2012-08-29 Thread Ian Pilcher 

On 08/29/2012 02:56 AM, Daniel Vetter wrote:

Wrt intel infoframes issues: Have you retested on latest 3.6-rc kernels?
We've fixed quite a few bugs for our infoframe support recently ...


Tested just now.  The behavior has changed.  I now need to use *both*
flags to make my display work with an Intel GPU.  (Previously, the
NO_AUDIO flag was sufficient to make the display work with Intel
graphics.)  Presumably, the Intel driver is now sending AVI InfoFrames.

Thinking a bit more about this, I'm starting to rethink my assertion
that the Intel driver is at fault here.  On one hand, it doesn't make
any sense to send audio InfoFrames to a non-HDMI display.  (BTW, I'm
assuming that a display with a DisplayPort port will show up as HDMI.)

On the other hand, it can be argued that the DRM layer is giving
conflicting information to the driver -- drm_detect_hdmi_monitor is
returning FALSE, but drm_detect_monitor_audio is returning TRUE.  AFAIK,
this doesn't make any sense either.

This leads me to propose that drm_detect_monitor_audio return FALSE if
either EDID_QUIRK_DISABLE_INFOFRAMES or EDID_QUIRK_NO_AUDIO is set.

bool drm_detect_monitor_audio(struct edid *edid)
{
u8 *edid_ext;
int i, j;
bool has_audio = false;
int start_offset, end_offset;
char buf[EDID_DISPLAY_ID_BUF_SIZE];

if (edid_get_quirks(edid) & (EDID_QUIRK_NO_AUDIO |
 EDID_QUIRK_DISABLE_INFOFRAMES)) {
DRM_INFO("Disabling HDMI audio on display %s "
 "due to EDID quirk\n",
 drm_edid_display_id_format(edid->display_id,
buf, 1));
goto end;
}

...

EDID_QUIRK_DISABLE_INFOFRAMES would then be sufficient to make the LG
L246WP work with both nVidia and Intel GPUs.  (ATI GPUs should work as
well; I just don't have any hardware to test.)

Ajax - Does this address your objections?  If so, I'll spin another
patch set.

Thanks!

--

Ian Pilcher arequip...@gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 54230] New: r600-llvm-compiler completely broken at CAYMAN

2012-08-29 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=54230

 Bug #: 54230
   Summary: r600-llvm-compiler completely broken at CAYMAN
Classification: Unclassified
   Product: DRI
   Version: XOrg CVS
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: v10la...@myway.de


Created attachment 66294
  --> https://bugs.freedesktop.org/attachment.cgi?id=66294
The desktop with compiz.

Today I decided to give the llvm shader compiler a try, so I compiled mesa
(from git) with it enabled.
The result was a completely broken desktop. With the help of a 2d desktop
environment I was able to capture some screenshots/videos from Minecraft (see
attachments).

No information in dmesg and/or Xorg.0.log (I attach them anyway).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 54230] r600-llvm-compiler completely broken at CAYMAN

2012-08-29 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=54230

--- Comment #1 from Thomas Rohloff  2012-08-29 20:49:21 UTC 
---
Created attachment 66295
  --> https://bugs.freedesktop.org/attachment.cgi?id=66295
Minecrafts main menue.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 54230] r600-llvm-compiler completely broken at CAYMAN

2012-08-29 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=54230

--- Comment #2 from Thomas Rohloff  2012-08-29 20:54:31 UTC 
---
Created attachment 66296
  --> https://bugs.freedesktop.org/attachment.cgi?id=66296
dmesg

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 54230] r600-llvm-compiler completely broken at CAYMAN

2012-08-29 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=54230

--- Comment #3 from Thomas Rohloff  2012-08-29 20:55:07 UTC 
---
Created attachment 66297
  --> https://bugs.freedesktop.org/attachment.cgi?id=66297
Xorg.0.log

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: -next queue and EDID stuff

2012-08-29 Thread Adam Jackson 

On 8/29/12 3:53 PM, Ian Pilcher wrote:


Thinking a bit more about this, I'm starting to rethink my assertion
that the Intel driver is at fault here.  On one hand, it doesn't make
any sense to send audio InfoFrames to a non-HDMI display.  (BTW, I'm
assuming that a display with a DisplayPort port will show up as HDMI.)


Nope.

If you connect to the DP port on a monitor, it will claim to be DP: the 
EDID block version will be 1.4, and the digital display feature byte 
will indicate that it's DP:


http://cgit.freedesktop.org/xorg/app/edid-decode/tree/edid-decode.c#n1145

If you connect to the HDMI port on a monitor, it will claim to be HDMI: 
the EDID block version will be 1.3 or higher, there will be a CEA 
extension block, and there will be a vendor-specific data block within 
that extension with a vendor OUI matching that of the HDMI consortium:


http://cgit.freedesktop.org/xorg/app/edid-decode/tree/edid-decode.c#n640


On the other hand, it can be argued that the DRM layer is giving
conflicting information to the driver -- drm_detect_hdmi_monitor is
returning FALSE, but drm_detect_monitor_audio is returning TRUE.  AFAIK,
this doesn't make any sense either.


This might be the actual issue.  drm_detect_monitor_audio() can return 
true for several reasons, but it does _not_ make any claim that the 
monitor is HDMI, only that it has a CEA extension block.  Which is 
certainly ugly, but that's how CEA defined their botch of an extension 
block.


So to me, that says that drivers need to ask _both_ whether the monitor 
supports audio and whether it's HDMI before sending HDMI-specific audio 
signalling.


- ajax
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

drm_vm.c: many arches equate remap_pfn_range() and io_remap_pfn_range()

2012-08-29 Thread Robert P. J. Day 

  a pedantic observation, you can do with it what you wish (i'm not a
list subscriber).  in drivers/gpu/drm/drm_vm.c, we read (line 629):

#if !defined(__arm__)
if (io_remap_pfn_range(vma, vma->vm_start,
   (map->offset + offset) >> PAGE_SHIFT,
   vma->vm_end - vma->vm_start,
   vma->vm_page_prot))
return -EAGAIN;
#else
if (remap_pfn_range(vma, vma->vm_start,
(map->offset + offset) >> PAGE_SHIFT,
vma->vm_end - vma->vm_start,
vma->vm_page_prot))
return -EAGAIN;
#endif

suggesting that only with ARM need we distinguish between those two
routines.  but for various architectures, in pgtable.h, you can see:

#define io_remap_pfn_range  remap_pfn_range

even the arm file contains:

#define io_remap_pfn_range(vma,from,pfn,size,prot) \
remap_pfn_range(vma, from, pfn, size, prot)

so it's not clear what the preprocessor test is for.  admittedly, it
should work, it just seems unnecessary.  and it makes the code more
confusing than it needs to be, but perhaps i've just misread
something.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V5] drm: edid: add support for E-DDC

2012-08-29 Thread Shirish S 
Thanks for the comments Daniel and Jean
I will upload patch set 6.
This shall include Jean's review coments.
And i will tag Daniel,Jean and Ville as reviewed.

Regards,
Shirish S

On Wed, Aug 29, 2012 at 9:12 AM, Daniel Vetter  wrote:

> On Wed, Aug 29, 2012 at 4:46 PM, Shirish S  wrote:
> > The current logic for probing ddc is limited to
> > 2 blocks (256 bytes), this patch adds support
> > for the 4 block (512) data.
> >
> > To do this, a single 8-bit segment index is
> > passed to the display via the I2C address 30h.
> > Data from the selected segment is then immediately
> > read via the regular DDC2 address using a repeated
> > I2C 'START' signal.
> >
> > Signed-off-by: Shirish S 
>
> If you resend patches it'd be nice to keep a changelog of the patch
> itself somewhere, otherwise it's just more work to figure that out for
> reviewers. Also, you can usually attach reviewed-by tags (like mine)
> to a patch resend if you don't change the patch massively ...
> -Daniel
>
> > ---
> >  drivers/gpu/drm/drm_edid.c |   22 +++---
> >  1 files changed, 19 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index bcc4725..b9ffc30 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> >   int block, int len)
> >  {
> > unsigned char start = block * EDID_LENGTH;
> > +   unsigned char segment = block >> 1;
> > +   unsigned char xfers = segment ? 3 : 2;
> > int ret, retries = 5;
> >
> > /* The core i2c driver will automatically retry the transfer if
> the
> > @@ -265,6 +267,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> > do {
> > struct i2c_msg msgs[] = {
> > {
> > +   .addr   = DDC_SEGMENT_ADDR,
> > +   .flags  = segment ? 0 : I2C_M_IGNORE_NAK,
> > +   .len= 1,
> > +   .buf= &segment,
> > +   }, {
> > .addr   = DDC_ADDR,
> > .flags  = 0,
> > .len= 1,
> > @@ -276,15 +283,24 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> > .buf= buf,
> > }
> > };
> > -   ret = i2c_transfer(adapter, msgs, 2);
> > +
> > +   /*
> > +* Avoid sending the segment addr to not upset non-compliant ddc
> > +* monitors.
> > +*/
> > +   if (!segment)
> > +   ret = i2c_transfer(adapter, &msgs[1], xfers);
> > +   else
> > +   ret = i2c_transfer(adapter, msgs, xfers);
> > +
> > if (ret == -ENXIO) {
> > DRM_DEBUG_KMS("drm: skipping non-existent
> adapter %s\n",
> > adapter->name);
> > break;
> > }
> > -   } while (ret != 2 && --retries);
> > +   } while (ret != xfers && --retries);
> >
> > -   return ret == 2 ? 0 : -1;
> > +   return ret == xfers ? 0 : -1;
> >  }
> >
> >  static bool drm_edid_is_zero(u8 *in_edid, int length)
> > --
> > 1.7.0.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: fix dig encoder selection on DCE61

2012-08-29 Thread alexdeucher 
From: Alex Deucher 

Was using the DCE41 code which was wrong. Fixes
blank displays on a number of Trinity systems.

Signed-off-by: Alex Deucher 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/radeon/atombios_encoders.c |   31 +++
 1 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 4a7f95e..6e8803a 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1769,13 +1769,34 @@ static int radeon_atom_pick_dig_encoder(struct 
drm_encoder *encoder)
struct radeon_crtc *radeon_crtc = to_radeon_crtc(encoder->crtc);
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
struct drm_encoder *test_encoder;
-   struct radeon_encoder_atom_dig *dig;
+   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
uint32_t dig_enc_in_use = 0;
 
-   /* DCE4/5 */
-   if (ASIC_IS_DCE4(rdev)) {
-   dig = radeon_encoder->enc_priv;
-   if (ASIC_IS_DCE41(rdev)) {
+   if (ASIC_IS_DCE6(rdev)) {
+   /* DCE6 */
+   switch (radeon_encoder->encoder_id) {
+   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
+   if (dig->linkb)
+   return 1;
+   else
+   return 0;
+   break;
+   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
+   if (dig->linkb)
+   return 3;
+   else
+   return 2;
+   break;
+   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
+   if (dig->linkb)
+   return 5;
+   else
+   return 4;
+   break;
+   }
+   } else if (ASIC_IS_DCE4(rdev)) {
+   /* DCE4/5 */
+   if (ASIC_IS_DCE41(rdev) && !ASIC_IS_DCE61(rdev)) {
/* ontario follows DCE4 */
if (rdev->family == CHIP_PALM) {
if (dig->linkb)
-- 
1.7.7.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [pull] radeon drm-fixes-3.6

2012-08-29 Thread Alex Deucher 
I just pushed one more important fix:

commit 41fa54377057ab38bc3e08ebb46168a7daf2e63b
Author: Alex Deucher 
Date:   Wed Aug 29 19:48:26 2012 -0400

drm/radeon: fix dig encoder selection on DCE61

Was using the DCE41 code which was wrong. Fixes
blank displays on a number of Trinity systems.

Signed-off-by: Alex Deucher 
Cc: sta...@vger.kernel.org

If it's not too late, please make sure this one is included.

On Wed, Aug 29, 2012 at 1:32 PM,   wrote:
> From: Alex Deucher 
>
> Hi Dave,
>
> This is the current set of radeon fixes for 3.6.  Nothing too major.
>
> Highlights:
> - fix a gart regression on older IGP chips
> - more MSAA fixes
> - fix a double free in gpu reset code
> - modesetting fixes
>
> The following changes since commit 84f720ecba6716d198b21936d1bf6253e8ab42a1:
>
>   Merge branch 'drm-intel-fixes' of 
> git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2012-08-29 
> 20:09:23 +1000)
>
> are available in the git repository at:
>
>   git://people.freedesktop.org/~agd5f/linux drm-fixes-3.6
>
> Alex Deucher (4):
>   drm/radeon: don't disable plls that are in use by other crtcs
>   drm/radeon/atom: rework DIG modesetting on DCE3+
>   drm/radeon/atom: powergating fixes for DCE6
>   drm/radeon: rework panel mode setup
>
> Christian König (1):
>   drm/radeon: fix double free in radeon_gpu_reset
>
> Jerome Glisse (1):
>   drm/radeon: force dma32 to fix regression rs4xx,rs6xx,rs740
>
> Marek Olšák (3):
>   drm/radeon: fix reading CB_COLORn_MASK from the CS
>   drm/radeon: initialize tracked CS state
>   drm/radeon: add proper checking of RESOLVE_BOX command for r600-r700
>
>  drivers/gpu/drm/radeon/atombios_crtc.c |   36 -
>  drivers/gpu/drm/radeon/atombios_dp.c   |   29 +++-
>  drivers/gpu/drm/radeon/atombios_encoders.c |  109 
> 
>  drivers/gpu/drm/radeon/r600_cs.c   |   30 +++-
>  drivers/gpu/drm/radeon/r600d.h |8 ++
>  drivers/gpu/drm/radeon/radeon_device.c |5 +-
>  drivers/gpu/drm/radeon/radeon_drv.c|3 +-
>  drivers/gpu/drm/radeon/reg_srcs/r600   |1 -
>  8 files changed, 115 insertions(+), 106 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 52256] Trinity (ARUBA) DP link training problems

2012-08-29 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=52256

--- Comment #8 from Alex Deucher  2012-08-30 00:13:43 UTC ---
Should be fixed in my drm-next-3.6 branch:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.6
there are several patches required.  The patches should show up in stable
kernels as well once Dave pulls them.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V4] drm: edid: add support for E-DDC

2012-08-29 Thread Shirish S 
Hi Jean,

On Wed, Aug 29, 2012 at 6:44 AM, Jean Delvare  wrote:

> Hi all,
>
> Sorry for breaking message threading but I was not included in
> iterations 3 and 4 of this patch.
>
> Random comments about v4:
>
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned
> > char *buf,
> >   int block, int len)
> >  {
> > unsigned char start = block * EDID_LENGTH;
> > +   unsigned char segment = block >> 1;
> > +   unsigned char xfers = segment ? 3 : 2;
> > int ret, retries = 5;
> >
> > /* The core i2c driver will automatically retry the transfer if
> the
> > @@ -264,7 +266,12 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> > unsigned char *buf,
> >  */
> > do {
> > struct i2c_msg msgs[] = {
> > -   {
> > +   { /*set segment pointer */
> > +   .addr   = DDC_SEGMENT_ADDR,
> > +   .flags  = segment ? 0 : I2C_M_IGNORE_NAK,
>
> I don't get the idea. If segment == 0, this message is never sent, so the
> value of field flags doesn't matter. So flags will always be 0 when this
> message is sent, so it can be hard-coded.
>
> Agreed.

> But from previous discussions my understanding was an agreement on always
> using I2C_M_IGNORE_NAK for improved compatibility. So I2C_M_IGNORE_NAK
> should be hard-coded, not 0?
>
After discussion,daniel had asked for a seprate patch for the flags
modification.
Will upload that later.

>
>
> +   .len= 1,
> > +   .buf= &segment,
> > +   }, {
> > .addr   = DDC_ADDR,
> > .flags  = 0,
> > .len= 1,
> > @@ -276,15 +283,22 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> > unsigned char *buf,
> > .buf= buf,
> > }
> > };
> > -   ret = i2c_transfer(adapter, msgs, 2);
> > +   /* Avoid sending the segment addr to not upset non-compliant ddc
> > +* monitors.
> > +*/
>
> s/segment addr/segment/, plus it's abot E-DCC compliance as I understand
> it,
> not DDC.
>
> > +   if (!segment)
> > +   ret = i2c_transfer(adapter, &msgs[1], xfers);
> > +   else
> > +   ret = i2c_transfer(adapter, msgs, xfers);
> > +
>
> This can be written:
>
> ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);
>
> Which is more compact and, I suspect, faster.
>
> Agreed.

> > if (ret == -ENXIO) {
> > DRM_DEBUG_KMS("drm: skipping non-existent
> adapter %s\n",
> > adapter->name);
> > break;
> > }
> > -   } while (ret != 2 && --retries);
> > +   } while (ret != xfers && --retries);
> >
> > -   return ret == 2 ? 0 : -1;
> > +   return ret == xfers ? 0 : -1;
> >  }
> >
> >  static bool drm_edid_is_zero(u8 *in_edid, int length)
>
> Other than this, your code looks reasonable, not so different from what
> I submitted 8 months ago actually. But ISTU you can test the code with
> real hardware while I couldn't.
>
> Your patch never checked for the 3 message transfer complete, it checked
only 2.

With the changes above applied, you can add:
>
> Reviewed-by: Jean Delvare 
>
> Will add your review comments in patch set 5 and your reviewed tag.

Thanks & Regards,
Shirish S

> --
> Jean Delvare
> Suse L3
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 52256] Trinity (ARUBA) DP link training problems

2012-08-29 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=52256

--- Comment #9 from LRN  2012-08-30 01:40:44 UTC ---
Pulled your drm-next-3.6 branch, and merged with current linux master.
Display now works!

There are font rendering problems with X server, but that's another issue.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

2012-08-29 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=26891

--- Comment #34 from Anonymous Helper  2012-08-30 
01:48:07 UTC ---
Created attachment 66308
  --> https://bugs.freedesktop.org/attachment.cgi?id=66308
DSDT table from Macbook Pro 8,2 (EFI boot)

Alex,
Please see the DSDT table from a Macbook Pro booted in EFI mode. Maybe it will
give you some ideas for extracting the VBIOS.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: -next queue and EDID stuff

2012-08-29 Thread Ian Pilcher 
On 08/29/2012 04:38 PM, Adam Jackson wrote:
> So to me, that says that drivers need to ask _both_ whether the monitor
> supports audio and whether it's HDMI before sending HDMI-specific audio
> signalling.

OK, so the burden is on the individual drivers.

In terms of moving forward with the rest of the EDID quirk stuff, are
you OK with either of these options:

* Remove EDID_QUIRK_NO_AUDIO from the flags for the LG L246WP.  It won't
  work "out of the box" with the Intel driver until that driver is
  fixed to not send audio InfoFrames to non-HDMI displays (but anyone
  who has the combination will be able to add their own quirk to make
  it work).

* Leave both flags, because both are accurate.  The display is confused
  by any InfoFrames (audio or AVI), and it is reporting non-existent
  audio capabilities.  The fact that the combination of the two flags
  makes the display work with Intel GPUs is a happy/sad/neutral
  accident, and the driver's behavior is still considered broken.

  (Essentially, this would mean just editing the comments to reflect the
  above reasoning.)

If needed, I can easily create a new patch for either option.  Just let
me know.

Thanks!

-- 

Ian Pilcher arequip...@gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm fixes

2012-08-29 Thread Dave Airlie 

Hi Linus,

a bunch of scattered fixes ati/intel/nouveau, couple of core ones,
nothing too shocking or different.

Dave.

The following changes since commit fea7a08acb13524b47711625eebea40a0ede69a0:

  Linux 3.6-rc3 (2012-08-22 13:29:06 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux.git drm-fixes

for you to fetch changes up to 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b:

  drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S (2012-08-30 
14:14:12 +1000)


Alex Deucher (5):
  drm/radeon: don't disable plls that are in use by other crtcs
  drm/radeon/atom: rework DIG modesetting on DCE3+
  drm/radeon/atom: powergating fixes for DCE6
  drm/radeon: rework panel mode setup
  drm/radeon: fix dig encoder selection on DCE61

Ben Skeggs (1):
  drm/nvc0/copy: check PUNITS to determine which copy engines are disabled

Calvin Walton (1):
  i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard

Chris Wilson (1):
  drm/i915: Use the correct size of the GTT for placing the per-process 
entries

Christian König (1):
  drm/radeon: fix double free in radeon_gpu_reset

Dave Airlie (3):
  Merge branch 'drm-nouveau-fixes' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes
  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
  Merge branch 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes

Forest Bond (1):
  gma500: Consider CRTC initially active.

Jakob Bornecrantz (1):
  drm: Check for invalid cursor flags

Jerome Glisse (1):
  drm/radeon: force dma32 to fix regression rs4xx,rs6xx,rs740

Marek Olšák (3):
  drm/radeon: fix reading CB_COLORn_MASK from the CS
  drm/radeon: initialize tracked CS state
  drm/radeon: add proper checking of RESOLVE_BOX command for r600-r700

Paul Menzel (1):
  drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S

Vijay Purushothaman (1):
  drm/i915: fix color order for BGR formats on IVB

Ville Syrjälä (1):
  drm: Initialize object type when using DRM_MODE() macro

Xu, Anhua (1):
  drm/i915: fix wrong order of parameters in port checking functions

 drivers/gpu/drm/drm_crtc.c |2 +-
 drivers/gpu/drm/drm_edid.c |3 +
 drivers/gpu/drm/gma500/psb_intel_display.c |3 +
 drivers/gpu/drm/i915/i915_gem_gtt.c|2 +-
 drivers/gpu/drm/i915/intel_display.c   |   12 +--
 drivers/gpu/drm/i915/intel_lvds.c  |8 ++
 drivers/gpu/drm/i915/intel_sprite.c|4 +-
 drivers/gpu/drm/nouveau/nouveau_state.c|6 +-
 drivers/gpu/drm/radeon/atombios_crtc.c |   36 ---
 drivers/gpu/drm/radeon/atombios_dp.c   |   29 +++---
 drivers/gpu/drm/radeon/atombios_encoders.c |  140 +++-
 drivers/gpu/drm/radeon/r600_cs.c   |   30 +-
 drivers/gpu/drm/radeon/r600d.h |8 ++
 drivers/gpu/drm/radeon/radeon_device.c |5 +-
 drivers/gpu/drm/radeon/radeon_drv.c|3 +-
 drivers/gpu/drm/radeon/reg_srcs/r600   |1 -
 include/drm/drm_crtc.h |3 +-
 include/drm/drm_mode.h |5 +-
 18 files changed, 174 insertions(+), 126 deletions(-)___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Linaro-mm-sig] [PATCH 2/4] dma-fence: dma-buf synchronization (v8 )

2012-08-29 Thread Francesco Lavra 
Hi,

On Fri, Aug 10, 2012 at 4:57 PM, Maarten Lankhorst
 wrote:

[Snip]

> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> new file mode 100644
> index 000..e0ceddd
> --- /dev/null
> +++ b/include/linux/dma-fence.h
> @@ -0,0 +1,124 @@
> +/*
> + * Fence mechanism for dma-buf to allow for asynchronous dma access
> + *
> + * Copyright (C) 2012 Texas Instruments
> + * Author: Rob Clark 
> + *
> + * This program is free software; you can redistribute it and/or modify
> it
> + * under the terms of the GNU General Public License version 2 as
> published by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License
> along with
> + * this program.  If not, see .
> + */
> +
> +#ifndef __DMA_FENCE_H__
> +#define __DMA_FENCE_H__
> +
> +#include 
> +#include 
> +#include 
> +#include 

Duplicated include.

Regards,
Francesco
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V6] drm: edid: add support for E-DDC

2012-08-29 Thread y 
From: Shirish S 

This patch adds support in probing 4 block edid data, for E-DDC.
This is the first test case in CTS, for HDMI compliance.

Changes from V1:
1. Data type of offset adress updated to unsigned short
2. Updated the buf feild of msg[0]

Changes from V2:
Add switch for DDC and E-DDC

Changes from V3:
Remove switch,and avoid sending of segment data for non E-DDC

Changes from V4:
Fix review comments about space and comment indentation.

Changes from V5:
Compacted the code.

Based on drm-next branch

Shirish S (1):
  drm: edid: add support for E-DDC

 drivers/gpu/drm/drm_edid.c |   19 ---
 1 files changed, 16 insertions(+), 3 deletions(-)

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V6] drm: edid: add support for E-DDC

2012-08-29 Thread y 
From: Shirish S 

This patch adds support in probing 4 block edid data, for E-DDC.
This is the first test case in CTS, for HDMI compliance.

Changes from V1:
1. Data type of offset adress updated to unsigned short
2. Updated the buf feild of msg[0]

Changes from V2:
Add switch for DDC and E-DDC

Changes from V3:
Remove switch,and avoid sending of segment data for non E-DDC

Changes from V4:
Fix review comments about space and comment indentation.

Changes from V5:
Compacted the code.

Based on drm-next branch

Shirish S (1):
  drm: edid: add support for E-DDC

 drivers/gpu/drm/drm_edid.c |   19 ---
 1 files changed, 16 insertions(+), 3 deletions(-)

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6] drm: edid: add support for E-DDC

2012-08-29 Thread y 
From: Shirish S 

The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.

To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the regular DDC2 address using a repeated
I2C 'START' signal.

Signed-off-by: Shirish S 
Reviewed-by: Jean Delvare 
Reviewed-by: Daniel Vetter 
Reviewed-by: Ville Syrjala 
---
 drivers/gpu/drm/drm_edid.c |   19 ---
 1 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index bcc4725..7f62de5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned 
char *buf,
  int block, int len)
 {
unsigned char start = block * EDID_LENGTH;
+   unsigned char segment = block >> 1;
+   unsigned char xfers = segment ? 3 : 2;
int ret, retries = 5;
 
/* The core i2c driver will automatically retry the transfer if the
@@ -265,6 +267,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
unsigned char *buf,
do {
struct i2c_msg msgs[] = {
{
+   .addr   = DDC_SEGMENT_ADDR,
+   .flags  = 0,
+   .len= 1,
+   .buf= &segment,
+   }, {
.addr   = DDC_ADDR,
.flags  = 0,
.len= 1,
@@ -276,15 +283,21 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
unsigned char *buf,
.buf= buf,
}
};
-   ret = i2c_transfer(adapter, msgs, 2);
+
+   /*
+* Avoid sending the segment addr to not upset non-compliant ddc
+* monitors.
+*/
+   ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);
+
if (ret == -ENXIO) {
DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
adapter->name);
break;
}
-   } while (ret != 2 && --retries);
+   } while (ret != xfers && --retries);
 
-   return ret == 2 ? 0 : -1;
+   return ret == xfers ? 0 : -1;
 }
 
 static bool drm_edid_is_zero(u8 *in_edid, int length)
-- 
1.7.0.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V6] drm: edid: add support for E-DDC

2012-08-29 Thread Shirish S 
This patch adds support in probing 4 block edid data, for E-DDC.
This is the first test case in CTS, for HDMI compliance.

Changes from V1:
1. Data type of offset adress updated to unsigned short
2. Updated the buf feild of msg[0]

Changes from V2:
Add switch for DDC and E-DDC

Changes from V3:
Remove switch,and avoid sending of segment data for non E-DDC

Changes from V4:
Fix review comments about space and comment indentation.

Changes from V5:
Compacted the code.

Based on drm-next branch

Shirish S (1):
  drm: edid: add support for E-DDC

 drivers/gpu/drm/drm_edid.c |   19 ---
 1 files changed, 16 insertions(+), 3 deletions(-)

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V6] drm: edid: add support for E-DDC

2012-08-29 Thread Shirish S 
The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.

To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the regular DDC2 address using a repeated
I2C 'START' signal.

Signed-off-by: Shirish S 
Reviewed-by: Jean Delvare 
Reviewed-by: Daniel Vetter 
Reviewed-by: Ville Syrjala 
---
 drivers/gpu/drm/drm_edid.c |   19 ---
 1 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index bcc4725..7f62de5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned 
char *buf,
  int block, int len)
 {
unsigned char start = block * EDID_LENGTH;
+   unsigned char segment = block >> 1;
+   unsigned char xfers = segment ? 3 : 2;
int ret, retries = 5;
 
/* The core i2c driver will automatically retry the transfer if the
@@ -265,6 +267,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
unsigned char *buf,
do {
struct i2c_msg msgs[] = {
{
+   .addr   = DDC_SEGMENT_ADDR,
+   .flags  = 0,
+   .len= 1,
+   .buf= &segment,
+   }, {
.addr   = DDC_ADDR,
.flags  = 0,
.len= 1,
@@ -276,15 +283,21 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
unsigned char *buf,
.buf= buf,
}
};
-   ret = i2c_transfer(adapter, msgs, 2);
+
+   /*
+* Avoid sending the segment addr to not upset non-compliant ddc
+* monitors.
+*/
+   ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);
+
if (ret == -ENXIO) {
DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
adapter->name);
break;
}
-   } while (ret != 2 && --retries);
+   } while (ret != xfers && --retries);
 
-   return ret == 2 ? 0 : -1;
+   return ret == xfers ? 0 : -1;
 }
 
 static bool drm_edid_is_zero(u8 *in_edid, int length)
-- 
1.7.0.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: edid: add support for E-DDC

2012-08-29 Thread y 
From: Shirish S 

The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.

To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the regular DDC2 address using a repeated
I2C 'START' signal.

Signed-off-by: Shirish S 
Reviewed-by: Jean Delvare 
Reviewed-by: Daniel Vetter 
Reviewed-by: Ville Syrjala 
---
 drivers/gpu/drm/drm_edid.c |   19 ---
 1 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index bcc4725..7f62de5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned 
char *buf,
  int block, int len)
 {
unsigned char start = block * EDID_LENGTH;
+   unsigned char segment = block >> 1;
+   unsigned char xfers = segment ? 3 : 2;
int ret, retries = 5;
 
/* The core i2c driver will automatically retry the transfer if the
@@ -265,6 +267,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
unsigned char *buf,
do {
struct i2c_msg msgs[] = {
{
+   .addr   = DDC_SEGMENT_ADDR,
+   .flags  = 0,
+   .len= 1,
+   .buf= &segment,
+   }, {
.addr   = DDC_ADDR,
.flags  = 0,
.len= 1,
@@ -276,15 +283,21 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
unsigned char *buf,
.buf= buf,
}
};
-   ret = i2c_transfer(adapter, msgs, 2);
+
+   /*
+* Avoid sending the segment addr to not upset non-compliant ddc
+* monitors.
+*/
+   ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);
+
if (ret == -ENXIO) {
DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
adapter->name);
break;
}
-   } while (ret != 2 && --retries);
+   } while (ret != xfers && --retries);
 
-   return ret == 2 ? 0 : -1;
+   return ret == xfers ? 0 : -1;
 }
 
 static bool drm_edid_is_zero(u8 *in_edid, int length)
-- 
1.7.0.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: fix dig encoder selection on DCE61

2012-08-29 Thread Michel Dänzer 
On Mit, 2012-08-29 at 20:02 -0400, alexdeuc...@gmail.com wrote: 
> From: Alex Deucher 
> 
> Was using the DCE41 code which was wrong. Fixes
> blank displays on a number of Trinity systems.
> 
> Signed-off-by: Alex Deucher 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/gpu/drm/radeon/atombios_encoders.c |   31 +++
>  1 files changed, 26 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
> b/drivers/gpu/drm/radeon/atombios_encoders.c
> index 4a7f95e..6e8803a 100644
> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
> @@ -1769,13 +1769,34 @@ static int radeon_atom_pick_dig_encoder(struct 
> drm_encoder *encoder)
>   struct radeon_crtc *radeon_crtc = to_radeon_crtc(encoder->crtc);
>   struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
>   struct drm_encoder *test_encoder;
> - struct radeon_encoder_atom_dig *dig;
> + struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
>   uint32_t dig_enc_in_use = 0;
>  
> - /* DCE4/5 */
> - if (ASIC_IS_DCE4(rdev)) {
> - dig = radeon_encoder->enc_priv;
> - if (ASIC_IS_DCE41(rdev)) {
> + if (ASIC_IS_DCE6(rdev)) {
> + /* DCE6 */
> + switch (radeon_encoder->encoder_id) {
> + case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
> + if (dig->linkb)
> + return 1;
> + else
> + return 0;
> + break;
> + case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
> + if (dig->linkb)
> + return 3;
> + else
> + return 2;
> + break;
> + case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
> + if (dig->linkb)
> + return 5;
> + else
> + return 4;
> + break;
> + }
> + } else if (ASIC_IS_DCE4(rdev)) {
> + /* DCE4/5 */
> + if (ASIC_IS_DCE41(rdev) && !ASIC_IS_DCE61(rdev)) {

The !ASIC_IS_DCE61(rdev) seems redundant here. Either way though,

Reviewed-by: Michel Dänzer 


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm_vm.c: many arches equate remap_pfn_range() and io_remap_pfn_range()

2012-08-29 Thread Sascha Hauer 
On Wed, Aug 29, 2012 at 06:29:53PM -0400, Robert P. J. Day wrote:
> 
>   a pedantic observation, you can do with it what you wish (i'm not a
> list subscriber).  in drivers/gpu/drm/drm_vm.c, we read (line 629):
> 
> #if !defined(__arm__)
> if (io_remap_pfn_range(vma, vma->vm_start,
>(map->offset + offset) >> PAGE_SHIFT,
>vma->vm_end - vma->vm_start,
>vma->vm_page_prot))
> return -EAGAIN;
> #else
> if (remap_pfn_range(vma, vma->vm_start,
> (map->offset + offset) >> PAGE_SHIFT,
> vma->vm_end - vma->vm_start,
> vma->vm_page_prot))
> return -EAGAIN;
> #endif

This code goes down to:

commit 4b7fb9b5746554d460e7bc986341d4b2db01e0b6
Author: Jordan Crouse 
Date:   Thu May 27 13:40:26 2010 -0600

drm: Add __arm defines to DRM

Add __arm defines to specify behavior specific for
an ARM processor.

Signed-off-by: Jordan Crouse 
Signed-off-by: Dave Airlie 

Even at that time io_remap_pfn_range on arm was defined as:

> 
> #define io_remap_pfn_range(vma,from,pfn,size,prot) \
> remap_pfn_range(vma, from, pfn, size, prot)
> 
> so it's not clear what the preprocessor test is for.  admittedly, it
> should work, it just seems unnecessary.  and it makes the code more
> confusing than it needs to be, but perhaps i've just misread
> something.

I agree that this shouldn't be necessary.

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43698] On PPC, OpenGL programs use incorrect texture colors.

2012-08-29 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=43698

--- Comment #15 from Joseph Spiros  2012-08-29 
05:36:56 UTC ---
(In reply to comment #14)
> (In reply to comment #13)
> > I'm running into this bug as well, with an iMac G5 containing a Radeon 9600
> > (rv350) chip. It's been a few months since this bug has seen any activity; 
> > is a
> > fix still forthcoming? Is there anything I can do to help? I am not familiar
> > with OpenGL or Mesa's codebase, but I can test on my hardware as needed. 
> > And,
> > well, if this bug has been abandoned, I'm willing to spend some time trying 
> > to
> > familiarize myself enough with the codebase to, at minimum, attempt an 
> > updated
> > patch based on the patches provided previously.
> 
> Is this the latest code?
> 
> I have not tested my Powermac G4 in a long time and it uses out of date Mesa
> (but the colors are correct).

This is with version 8.0.4-2 as packaged by Debian, which is the most recent
package available in the sid (unstable) distribution. So, it's the latest
available in Debian. As far as this bug is concerned, no, I don't believe any
changes have been made that would have fixed this yet.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/exynos: Make g2d_pm_ops static

2012-08-29 Thread Joonyoung Shim 
On 08/28/2012 05:41 PM, Sachin Kamat wrote:
> Fixes the following warning:
> drivers/gpu/drm/exynos/exynos_drm_g2d.c:897:1: warning:
> symbol 'g2d_pm_ops' was not declared. Should it be static?
>
> Signed-off-by: Sachin Kamat 
> ---
>   drivers/gpu/drm/exynos/exynos_drm_g2d.c |2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index 6adfa4e..1065e90 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -894,7 +894,7 @@ static int g2d_resume(struct device *dev)
>   }
>   #endif
>   
> -SIMPLE_DEV_PM_OPS(g2d_pm_ops, g2d_suspend, g2d_resume);
> +static SIMPLE_DEV_PM_OPS(g2d_pm_ops, g2d_suspend, g2d_resume);

Right, it should be static but i don't get any warning message without 
static.

Thanks.

>   
>   struct platform_driver g2d_driver = {
>   .probe  = g2d_probe,

-next queue and EDID stuff

2012-08-29 Thread Daniel Vetter 
On Tue, Aug 28, 2012 at 11:18:24PM -0500, Ian Pilcher wrote:
> On 08/28/2012 07:13 PM, Adam Jackson wrote:
> > On 8/28/12 7:33 PM, Ian Pilcher wrote:
> >> Actually, I believe that the error is probably in the Intel driver.  As
> >> I understand it, it shouldn't be sending audio InfoFrames to a non-HDMI
> >> display.
> > 
> > If that's the case then I'd still say "we're doing something else wrong
> > here".  Quirks - at least at the core drm level - are not for working
> > around broken drivers, they're for working around broken displays.
> 
> And I'd agree.
> 
> (Although I suppose one *could* argue that the display is broken in 2
> ways -- it reports audio capabilities that aren't really there, and it
> gets confused by any InfoFrames -- AVI or audio.)
> 
> I don't have the knowledge or time to fix the Intel driver, but I've
> always planned to at least bugzilla the issue.  I can't reasonably do
> so, however, until the user-defined quirks infrastructure is in place,
> so that the behavior can be demonstrated.
> 
> If you prefer to leave the display broken with Intel GPUs, you can
> always just remove the EDID_QUIRK_NO_AUDIO flag:

Wrt intel infoframes issues: Have you retested on latest 3.6-rc kernels?
We've fixed quite a few bugs for our infoframe support recently ...
-Daniel

> 
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -160,6 +160,10 @@  union edid_quirk
> edid_quirk_list[EDID_QUIRK_LIST_SIZE] = {
>   { { { { EDID_MFG_ID('V', 'S', 'C'), cpu_to_le16(5020) } },
>   EDID_QUIRK_FORCE_REDUCED_BLANKING } },
> 
> + /* LG L246WP */
> + { { { { EDID_MFG_ID('G', 'S', 'M'), cpu_to_le16(0x563f) } },
> + EDID_QUIRK_DISABLE_INFOFRAMES } },
> +
>   /*
>* When adding built-in quirks, please adjust EDID_QUIRK_LIST_SIZE to
>* provide some room for user-supplied quirks.
> 
> -- 
> 
> Ian Pilcher arequipeno at gmail.com
> "If you're going to shift my paradigm ... at least buy me dinner first."
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PULL] drm-intel-fixes

2012-08-29 Thread Daniel Vetter 
Per usual, I've forgotten all the cc's ... I really need to script this,
I'm too dumb to remember.
-Daniel

On Wed, Aug 29, 2012 at 10:29:43AM +0200, Daniel Vetter wrote:
> Hi Dave,
> 
> Just a few smaller things:
> - Fix up a pipe vs. plane confusion from a refactoring, fixes a regression
>   from 3.1 (Anhua Xu).
> - Fix ivb sprite pixel formats (Vijay).
> - Fixup ppgtt pde placement for machines where the Bios artifically limits
>   the availbale gtt space in the name of ... product differentiation
>   (Chris). This fixes an oops.
> - Yet another no_lvds quirk entry.
> 
> Otherwise nothing outstanding afaik, things are as boring as they should
> be ;-)
> 
> Cheers, Daniel
> 
> The following changes since commit fea7a08acb13524b47711625eebea40a0ede69a0:
> 
>   Linux 3.6-rc3 (2012-08-22 13:29:06 -0700)
> 
> are available in the git repository at:
> 
>   git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes
> 
> for you to fetch changes up to a51d4ed01e5bb39d2cf36a12f9976ab08872c192:
> 
>   i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard (2012-08-24 
> 14:40:09 +0200)
> 
> 
> Calvin Walton (1):
>   i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard
> 
> Chris Wilson (1):
>   drm/i915: Use the correct size of the GTT for placing the per-process 
> entries
> 
> Vijay Purushothaman (1):
>   drm/i915: fix color order for BGR formats on IVB
> 
> Xu, Anhua (1):
>   drm/i915: fix wrong order of parameters in port checking functions
> 
>  drivers/gpu/drm/i915/i915_gem_gtt.c  |2 +-
>  drivers/gpu/drm/i915/intel_display.c |   12 ++--
>  drivers/gpu/drm/i915/intel_lvds.c|8 
>  drivers/gpu/drm/i915/intel_sprite.c  |4 ++--
>  4 files changed, 17 insertions(+), 9 deletions(-)
> -- 
> Daniel Vetter
> Mail: daniel at ffwll.ch
> Mobile: +41 (0)79 365 57 48

-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S

2012-08-29 Thread Paul Menzel 
Date: Wed, 8 Aug 2012 23:12:19 +0200
Subject: [PATCH v2] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S

Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with
vertical stripes in the top half.

In commit bc42aabc [2]

commit bc42aabc6a01b92b0f961d65671564e0e1cd7592
Author: Adam Jackson 
Date:   Wed May 23 16:26:54 2012 -0400

drm/edid/quirks: ViewSonic VA2026w

Adam Jackson added the quirk `EDID_QUIRK_FORCE_REDUCED_BLANKING` which
is also needed for this ASUS monitor.

All log files and output from `xrandr` is included in the referenced
Bugzilla report #17629.

Please note that this monitor only has a VGA (D-Sub) connector [1].

[1] http://www.asus.com/Display/LCD_Monitors/VW222S/
[2] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bc42aabc6a01b92b0f961d65671564e0e1cd7592

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=17629
Signed-off-by: Paul Menzel 
Cc: 
Cc: Adam Jackson 
Cc: Ian Pilcher 
Cc: 
---
v2: ? Prepend model number with 0x to fix compilation.
? Update commit message to mention that there is only a VGA connector.

Same comment as in previous patch.

Ian, I did not base this patch on your series, to make it easier to get
back ported. I can easily rebase it though, so hopefully some maintainer
can tell me what to do.
---
 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 75e252e..4befc7f 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -87,6 +87,9 @@ static struct edid_quirk {
int product_id;
u32 quirks;
 } edid_quirk_list[] = {
+   /* ASUS VW222S */
+   { "ACI", 0x22a2, EDID_QUIRK_FORCE_REDUCED_BLANKING },
+
/* Acer AL1706 */
{ "ACR", 44358, EDID_QUIRK_PREFER_LARGE_60 },
/* Acer F51 */
-- 
1.7.10.4
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120829/04fa94eb/attachment.pgp>

[PATCH V4] drm: edid: add support for E-DDC

2012-08-29 Thread Ville Syrjälä 
On Sat, Aug 25, 2012 at 03:13:56PM +0530, Shirish S wrote:
> The current logic for probing ddc is limited to
> 2 blocks (256 bytes), this patch adds support
> for the 4 block (512) data.
> 
> To do this, a single 8-bit segment index is
> passed to the display via the I2C address 30h.
> Data from the selected segment is then immediately
> read via the regular DDC2 address using a repeated
> I2C 'START' signal.
> 
> Signed-off-by: Shirish S 
> ---
>  drivers/gpu/drm/drm_edid.c |   22 ++
>  1 files changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index a8743c3..cde7af0 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned char *buf,
> int block, int len)
>  {
>   unsigned char start = block * EDID_LENGTH;
> + unsigned char segment = block >> 1;
> + unsigned char xfers = segment ? 3 : 2;
>   int ret, retries = 5;
>  
>   /* The core i2c driver will automatically retry the transfer if the
> @@ -264,7 +266,12 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned char *buf,
>*/
>   do {
>   struct i2c_msg msgs[] = {
> - {
> + { /*set segment pointer */

Missing whitespace after '/*'. Perhaps just drop the comment. I don't
see much value in it.

> + .addr   = DDC_SEGMENT_ADDR,
> + .flags  = segment ? 0 : I2C_M_IGNORE_NAK,
> + .len= 1,
> + .buf= &segment,
> + }, {
>   .addr   = DDC_ADDR,
>   .flags  = 0,
>   .len= 1,
> @@ -276,15 +283,22 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned char *buf,
>   .buf= buf,
>   }
>   };
> - ret = i2c_transfer(adapter, msgs, 2);
> + /* Avoid sending the segment addr to not upset non-compliant ddc
> +  * monitors.
> +  */

Wrong indentation and comment style is wrong. I'm guessing this didn't go
through checkpatch.pl.

Otherwise looks OK to me.

-- 
Ville Syrj?l?
Intel OTC

[PATCH] drm/radeon: fix double free in radeon_gpu_reset

2012-08-29 Thread Christian König 
radeon_ring_restore is freeing the memory for the saved
ring data. We need to remember that, otherwise we try to
restore the ring data again on the next try. Additional
to that it shouldn't try the reset infinitely if we have
saved ring data.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon_device.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index d2e2438..814194f 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1346,12 +1346,15 @@ retry:
for (i = 0; i < RADEON_NUM_RINGS; ++i) {
radeon_ring_restore(rdev, &rdev->ring[i],
ring_sizes[i], ring_data[i]);
+   ring_sizes[i] = 0;
+   ring_data[i] = NULL;
}

r = radeon_ib_ring_tests(rdev);
if (r) {
dev_err(rdev->dev, "ib ring test failed (%d).\n", r);
if (saved) {
+   saved = false;
radeon_suspend(rdev);
goto retry;
}
-- 
1.7.9.5

[PATCH V4] drm: edid: add support for E-DDC

2012-08-29 Thread Shirish S 
On Wed, Aug 29, 2012 at 4:08 AM, Ville Syrj?l? <
ville.syrjala at linux.intel.com> wrote:

> On Sat, Aug 25, 2012 at 03:13:56PM +0530, Shirish S wrote:
> > The current logic for probing ddc is limited to
> > 2 blocks (256 bytes), this patch adds support
> > for the 4 block (512) data.
> >
> > To do this, a single 8-bit segment index is
> > passed to the display via the I2C address 30h.
> > Data from the selected segment is then immediately
> > read via the regular DDC2 address using a repeated
> > I2C 'START' signal.
> >
> > Signed-off-by: Shirish S 
> > ---
> >  drivers/gpu/drm/drm_edid.c |   22 ++
> >  1 files changed, 18 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index a8743c3..cde7af0 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> > int block, int len)
> >  {
> >   unsigned char start = block * EDID_LENGTH;
> > + unsigned char segment = block >> 1;
> > + unsigned char xfers = segment ? 3 : 2;
> >   int ret, retries = 5;
> >
> >   /* The core i2c driver will automatically retry the transfer if the
> > @@ -264,7 +266,12 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> >*/
> >   do {
> >   struct i2c_msg msgs[] = {
> > - {
> > + { /*set segment pointer */
>
> Missing whitespace after '/*'. Perhaps just drop the comment. I don't
> see much value in it.
>
> Done.

> > + .addr   = DDC_SEGMENT_ADDR,
> > + .flags  = segment ? 0 : I2C_M_IGNORE_NAK,
> > + .len= 1,
> > + .buf= &segment,
> > + }, {
> >   .addr   = DDC_ADDR,
> >   .flags  = 0,
> >   .len= 1,
> > @@ -276,15 +283,22 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> >   .buf= buf,
> >   }
> >   };
> > - ret = i2c_transfer(adapter, msgs, 2);
> > + /* Avoid sending the segment addr to not upset non-compliant ddc
> > +  * monitors.
> > +  */
>
> Wrong indentation and comment style is wrong. I'm guessing this didn't go
> through checkpatch.pl.
>
> I never got tha above as either an error or warning in the checkpatch,
anyways have uploaded patch set 5 incorporating your comments.

> Otherwise looks OK to me.
>
> --
> Ville Syrj?l?
> Intel OTC
>

- Shirish

> ___
> 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/20120829/59cf9d49/attachment.html>

[PATCH] drm/radeon: fix double free in radeon_gpu_reset

2012-08-29 Thread Alex Deucher 
On Wed, Aug 29, 2012 at 7:24 AM, Christian K?nig
 wrote:
> radeon_ring_restore is freeing the memory for the saved
> ring data. We need to remember that, otherwise we try to
> restore the ring data again on the next try. Additional
> to that it shouldn't try the reset infinitely if we have
> saved ring data.
>
> Signed-off-by: Christian K?nig 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/radeon/radeon_device.c |3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
> b/drivers/gpu/drm/radeon/radeon_device.c
> index d2e2438..814194f 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -1346,12 +1346,15 @@ retry:
> for (i = 0; i < RADEON_NUM_RINGS; ++i) {
> radeon_ring_restore(rdev, &rdev->ring[i],
> ring_sizes[i], ring_data[i]);
> +   ring_sizes[i] = 0;
> +   ring_data[i] = NULL;
> }
>
> r = radeon_ib_ring_tests(rdev);
> if (r) {
> dev_err(rdev->dev, "ib ring test failed (%d).\n", r);
> if (saved) {
> +   saved = false;
> radeon_suspend(rdev);
> goto retry;
> }
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos: Make g2d_pm_ops static

2012-08-29 Thread Sachin Kamat 
On 29 August 2012 12:32, Joonyoung Shim  wrote:
> On 08/28/2012 05:41 PM, Sachin Kamat wrote:
>>
>> Fixes the following warning:
>> drivers/gpu/drm/exynos/exynos_drm_g2d.c:897:1: warning:
>> symbol 'g2d_pm_ops' was not declared. Should it be static?
>>
>> Signed-off-by: Sachin Kamat 
>> ---
>>   drivers/gpu/drm/exynos/exynos_drm_g2d.c |2 +-
>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>> index 6adfa4e..1065e90 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>> @@ -894,7 +894,7 @@ static int g2d_resume(struct device *dev)
>>   }
>>   #endif
>>   -SIMPLE_DEV_PM_OPS(g2d_pm_ops, g2d_suspend, g2d_resume);
>> +static SIMPLE_DEV_PM_OPS(g2d_pm_ops, g2d_suspend, g2d_resume);
>
>
> Right, it should be static but i don't get any warning message without
> static.

You will get it if you enable sparse checking while building the kernel.

>
> Thanks.
>
>
>> struct platform_driver g2d_driver = {
>> .probe  = g2d_probe,
>
>



-- 
With warm regards,
Sachin

radeon mobility x1600 broken since 3.4.0-rc6 (bisected)

2012-08-29 Thread Hausensteiner Keg 
On 27/08/12 21:04, Hausensteiner Keg wrote:
> On 27/08/12 20:29, Jerome Glisse wrote:
>> On Sun, Aug 26, 2012 at 8:34 PM, Hausensteiner Keg 
>>  wrote:
>>> ...
>> Does patch
>>
>> http://people.freedesktop.org/~glisse/0001-drm-radeon-extra-type-safe-for-fence-emission.patch
>>  
>>
>>
>> Helps ?
>
> Thanks Jerome. Will try patch tonight or tomorrow morning.
>
> How do I check whether the radeon is on an AGP bus?
> The lspci output does not mention AGP; line for video controller is:
>   01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee 
> ATI M56P [Radeon Mobility X1600]
> The "lshw" output also shows no signs of AGP.
>
> The dmesg output contains "[0.909546] Linux agpgart interface v0.103" 
> but otherwise no mention of "agp" or "AGP".
>
> By the way: tested the 3.5.3 release made today : still corrupt 
> graphics. And the v3.5 release (which was oddly working) also showed 
> the same corrupt graphics as soon as I forced a rebuild of the initrd 
> - maybe an older radeon module somehow ended up in the initrd built by 
> "make-kpkg --initrd".
>

Patch 0001-drm-radeon-extra-type-safe-for-fence-emission applies cleanly 
to both 3.5.3 and 3.6.0-rc3, but makes no difference in either case.

I've done some more bisecting, and the full sequence is:

* Prior to commit bb635567 ("convert fence to uint64_t v4") all works fine.
* Commit bb635567 causes system to freeze on Plymouth startup.
* The following commit (3b7a2b24, "rework fence handling, drop fence 
list v7") causes Plymouth to work again, but causes graphics corruption 
on greeter screen. Pressing ctrl-alt-f2 immediately displays a virtual 
console correctly, and the system is useable. However any attempt to use 
the mouse on the greeter screen triggers further graphics corruption, 
and system appears to hang.

This situation continues up to and including 3.5.3.

In the 3.6 dev cycle, the corruption issue continues up to 9c19415c. 
However the following commit, 876dc9f3 "remove radeon_fence_create" 
instead causes the screen to go black immediately after plymouth 
completes (ie when greeter screen is expected), and ctrl-alt-f2 has no 
effect.

FWIW, looks like two separate issues to me, with 876dc9f3 masking the 
earlier one..

Regards,
Simon

[PATCH V5] drm: edid: add support for E-DDC

2012-08-29 Thread Shirish S 
This patch adds support in probing 4 block edid data, for E-DDC.
This is the first test case in CTS, for HDMI compliance.

Changes from V4:
Fix review comments about space and comment indentation.

Based on drm-next branch

Shirish S (1):
  drm: edid: add support for E-DDC

 drivers/gpu/drm/drm_edid.c |   22 +++---
 1 files changed, 19 insertions(+), 3 deletions(-)

[PATCH V5] drm: edid: add support for E-DDC

2012-08-29 Thread Shirish S 
The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.

To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the regular DDC2 address using a repeated
I2C 'START' signal.

Signed-off-by: Shirish S 
---
 drivers/gpu/drm/drm_edid.c |   22 +++---
 1 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index bcc4725..b9ffc30 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned 
char *buf,
  int block, int len)
 {
unsigned char start = block * EDID_LENGTH;
+   unsigned char segment = block >> 1;
+   unsigned char xfers = segment ? 3 : 2;
int ret, retries = 5;

/* The core i2c driver will automatically retry the transfer if the
@@ -265,6 +267,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
unsigned char *buf,
do {
struct i2c_msg msgs[] = {
{
+   .addr   = DDC_SEGMENT_ADDR,
+   .flags  = segment ? 0 : I2C_M_IGNORE_NAK,
+   .len= 1,
+   .buf= &segment,
+   }, {
.addr   = DDC_ADDR,
.flags  = 0,
.len= 1,
@@ -276,15 +283,24 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
unsigned char *buf,
.buf= buf,
}
};
-   ret = i2c_transfer(adapter, msgs, 2);
+
+   /*
+* Avoid sending the segment addr to not upset non-compliant ddc
+* monitors.
+*/
+   if (!segment)
+   ret = i2c_transfer(adapter, &msgs[1], xfers);
+   else
+   ret = i2c_transfer(adapter, msgs, xfers);
+
if (ret == -ENXIO) {
DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
adapter->name);
break;
}
-   } while (ret != 2 && --retries);
+   } while (ret != xfers && --retries);

-   return ret == 2 ? 0 : -1;
+   return ret == xfers ? 0 : -1;
 }

 static bool drm_edid_is_zero(u8 *in_edid, int length)
-- 
1.7.0.4

[PATCH V4] drm: edid: add support for E-DDC

2012-08-29 Thread Jean Delvare 
Hi all,

Sorry for breaking message threading but I was not included in
iterations 3 and 4 of this patch.

Random comments about v4:

> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned 
> char *buf,
>   int block, int len)
>  {
> unsigned char start = block * EDID_LENGTH;
> +   unsigned char segment = block >> 1;
> +   unsigned char xfers = segment ? 3 : 2;
> int ret, retries = 5;
>  
> /* The core i2c driver will automatically retry the transfer if the
> @@ -264,7 +266,12 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned char *buf,
>  */
> do {
> struct i2c_msg msgs[] = {
> -   {
> +   { /*set segment pointer */
> +   .addr   = DDC_SEGMENT_ADDR,
> +   .flags  = segment ? 0 : I2C_M_IGNORE_NAK,

I don't get the idea. If segment == 0, this message is never sent, so the
value of field flags doesn't matter. So flags will always be 0 when this
message is sent, so it can be hard-coded.

But from previous discussions my understanding was an agreement on always
using I2C_M_IGNORE_NAK for improved compatibility. So I2C_M_IGNORE_NAK
should be hard-coded, not 0?

> +   .len= 1,
> +   .buf= &segment,
> +   }, {
> .addr   = DDC_ADDR,
> .flags  = 0,
> .len= 1,
> @@ -276,15 +283,22 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned char *buf,
> .buf= buf,
> }
> };
> -   ret = i2c_transfer(adapter, msgs, 2);
> +   /* Avoid sending the segment addr to not upset non-compliant ddc
> +* monitors.
> +*/

s/segment addr/segment/, plus it's abot E-DCC compliance as I understand it,
not DDC.

> +   if (!segment)
> +   ret = i2c_transfer(adapter, &msgs[1], xfers);
> +   else
> +   ret = i2c_transfer(adapter, msgs, xfers);
> +

This can be written:

ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);

Which is more compact and, I suspect, faster.

> if (ret == -ENXIO) {
> DRM_DEBUG_KMS("drm: skipping non-existent adapter 
> %s\n",
> adapter->name);
> break;
> }
> -   } while (ret != 2 && --retries);
> +   } while (ret != xfers && --retries);
>  
> -   return ret == 2 ? 0 : -1;
> +   return ret == xfers ? 0 : -1;
>  }
>  
>  static bool drm_edid_is_zero(u8 *in_edid, int length)

Other than this, your code looks reasonable, not so different from what
I submitted 8 months ago actually. But ISTU you can test the code with
real hardware while I couldn't.

With the changes above applied, you can add:

Reviewed-by: Jean Delvare 

-- 
Jean Delvare
Suse L3

[PATCH V5] drm: edid: add support for E-DDC

2012-08-29 Thread Daniel Vetter 
On Wed, Aug 29, 2012 at 4:46 PM, Shirish S  wrote:
> The current logic for probing ddc is limited to
> 2 blocks (256 bytes), this patch adds support
> for the 4 block (512) data.
>
> To do this, a single 8-bit segment index is
> passed to the display via the I2C address 30h.
> Data from the selected segment is then immediately
> read via the regular DDC2 address using a repeated
> I2C 'START' signal.
>
> Signed-off-by: Shirish S 

If you resend patches it'd be nice to keep a changelog of the patch
itself somewhere, otherwise it's just more work to figure that out for
reviewers. Also, you can usually attach reviewed-by tags (like mine)
to a patch resend if you don't change the patch massively ...
-Daniel

> ---
>  drivers/gpu/drm/drm_edid.c |   22 +++---
>  1 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index bcc4725..b9ffc30 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned char *buf,
>   int block, int len)
>  {
> unsigned char start = block * EDID_LENGTH;
> +   unsigned char segment = block >> 1;
> +   unsigned char xfers = segment ? 3 : 2;
> int ret, retries = 5;
>
> /* The core i2c driver will automatically retry the transfer if the
> @@ -265,6 +267,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned char *buf,
> do {
> struct i2c_msg msgs[] = {
> {
> +   .addr   = DDC_SEGMENT_ADDR,
> +   .flags  = segment ? 0 : I2C_M_IGNORE_NAK,
> +   .len= 1,
> +   .buf= &segment,
> +   }, {
> .addr   = DDC_ADDR,
> .flags  = 0,
> .len= 1,
> @@ -276,15 +283,24 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned char *buf,
> .buf= buf,
> }
> };
> -   ret = i2c_transfer(adapter, msgs, 2);
> +
> +   /*
> +* Avoid sending the segment addr to not upset non-compliant ddc
> +* monitors.
> +*/
> +   if (!segment)
> +   ret = i2c_transfer(adapter, &msgs[1], xfers);
> +   else
> +   ret = i2c_transfer(adapter, msgs, xfers);
> +
> if (ret == -ENXIO) {
> DRM_DEBUG_KMS("drm: skipping non-existent adapter 
> %s\n",
> adapter->name);
> break;
> }
> -   } while (ret != 2 && --retries);
> +   } while (ret != xfers && --retries);
>
> -   return ret == 2 ? 0 : -1;
> +   return ret == xfers ? 0 : -1;
>  }
>
>  static bool drm_edid_is_zero(u8 *in_edid, int length)
> --
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
daniel.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch

[Bug 18872] [RADEON:KMS:R100:SUSPEND] suspend to ram problems

2012-08-29 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=18872


Alan  changed:

   What|Removed |Added

 Status|NEEDINFO|ASSIGNED




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 29512] [PATCH]radeon rejects EDID with RV350 when hw_i2c=1

2012-08-29 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=29512


Alan  changed:

   What|Removed |Added

  Component|Video(AGP)  |Video(DRI - non Intel)
 AssignedTo|airlied at linux.ie|drivers_video-dri at 
kernel-bu
   ||gs.osdl.org
Summary|radeon rejects EDID with|[PATCH]radeon rejects EDID
   |RV350 when hw_i2c=1 |with RV350 when hw_i2c=1




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[pull] radeon drm-fixes-3.6

2012-08-29 Thread alexdeuc...@gmail.com 
From: Alex Deucher 

Hi Dave,

This is the current set of radeon fixes for 3.6.  Nothing too major.

Highlights:
- fix a gart regression on older IGP chips
- more MSAA fixes
- fix a double free in gpu reset code
- modesetting fixes

The following changes since commit 84f720ecba6716d198b21936d1bf6253e8ab42a1:

  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2012-08-29 
20:09:23 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-3.6

Alex Deucher (4):
  drm/radeon: don't disable plls that are in use by other crtcs
  drm/radeon/atom: rework DIG modesetting on DCE3+
  drm/radeon/atom: powergating fixes for DCE6
  drm/radeon: rework panel mode setup

Christian K?nig (1):
  drm/radeon: fix double free in radeon_gpu_reset

Jerome Glisse (1):
  drm/radeon: force dma32 to fix regression rs4xx,rs6xx,rs740

Marek Ol??k (3):
  drm/radeon: fix reading CB_COLORn_MASK from the CS
  drm/radeon: initialize tracked CS state
  drm/radeon: add proper checking of RESOLVE_BOX command for r600-r700

 drivers/gpu/drm/radeon/atombios_crtc.c |   36 -
 drivers/gpu/drm/radeon/atombios_dp.c   |   29 +++-
 drivers/gpu/drm/radeon/atombios_encoders.c |  109 
 drivers/gpu/drm/radeon/r600_cs.c   |   30 +++-
 drivers/gpu/drm/radeon/r600d.h |8 ++
 drivers/gpu/drm/radeon/radeon_device.c |5 +-
 drivers/gpu/drm/radeon/radeon_drv.c|3 +-
 drivers/gpu/drm/radeon/reg_srcs/r600   |1 -
 8 files changed, 115 insertions(+), 106 deletions(-)

-next queue and EDID stuff

2012-08-29 Thread Ian Pilcher 
On 08/29/2012 02:56 AM, Daniel Vetter wrote:
> Wrt intel infoframes issues: Have you retested on latest 3.6-rc kernels?
> We've fixed quite a few bugs for our infoframe support recently ...

Tested just now.  The behavior has changed.  I now need to use *both*
flags to make my display work with an Intel GPU.  (Previously, the
NO_AUDIO flag was sufficient to make the display work with Intel
graphics.)  Presumably, the Intel driver is now sending AVI InfoFrames.

Thinking a bit more about this, I'm starting to rethink my assertion
that the Intel driver is at fault here.  On one hand, it doesn't make
any sense to send audio InfoFrames to a non-HDMI display.  (BTW, I'm
assuming that a display with a DisplayPort port will show up as HDMI.)

On the other hand, it can be argued that the DRM layer is giving
conflicting information to the driver -- drm_detect_hdmi_monitor is
returning FALSE, but drm_detect_monitor_audio is returning TRUE.  AFAIK,
this doesn't make any sense either.

This leads me to propose that drm_detect_monitor_audio return FALSE if
either EDID_QUIRK_DISABLE_INFOFRAMES or EDID_QUIRK_NO_AUDIO is set.

bool drm_detect_monitor_audio(struct edid *edid)
{
 u8 *edid_ext;
 int i, j;
 bool has_audio = false;
 int start_offset, end_offset;
 char buf[EDID_DISPLAY_ID_BUF_SIZE];

 if (edid_get_quirks(edid) & (EDID_QUIRK_NO_AUDIO |
  EDID_QUIRK_DISABLE_INFOFRAMES)) {
 DRM_INFO("Disabling HDMI audio on display %s "
  "due to EDID quirk\n",
  drm_edid_display_id_format(edid->display_id,
 buf, 1));
 goto end;
 }

 ...

EDID_QUIRK_DISABLE_INFOFRAMES would then be sufficient to make the LG
L246WP work with both nVidia and Intel GPUs.  (ATI GPUs should work as
well; I just don't have any hardware to test.)

Ajax - Does this address your objections?  If so, I'll spin another
patch set.

Thanks!

-- 

Ian Pilcher arequipeno at gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."

[Bug 54230] New: r600-llvm-compiler completely broken at CAYMAN

2012-08-29 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=54230

 Bug #: 54230
   Summary: r600-llvm-compiler completely broken at CAYMAN
Classification: Unclassified
   Product: DRI
   Version: XOrg CVS
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: v10lator at myway.de


Created attachment 66294
  --> https://bugs.freedesktop.org/attachment.cgi?id=66294
The desktop with compiz.

Today I decided to give the llvm shader compiler a try, so I compiled mesa
(from git) with it enabled.
The result was a completely broken desktop. With the help of a 2d desktop
environment I was able to capture some screenshots/videos from Minecraft (see
attachments).

No information in dmesg and/or Xorg.0.log (I attach them anyway).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 54230] r600-llvm-compiler completely broken at CAYMAN

2012-08-29 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=54230

--- Comment #1 from Thomas Rohloff  2012-08-29 20:49:21 
UTC ---
Created attachment 66295
  --> https://bugs.freedesktop.org/attachment.cgi?id=66295
Minecrafts main menue.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 54230] r600-llvm-compiler completely broken at CAYMAN

2012-08-29 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=54230

--- Comment #2 from Thomas Rohloff  2012-08-29 20:54:31 
UTC ---
Created attachment 66296
  --> https://bugs.freedesktop.org/attachment.cgi?id=66296
dmesg

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 54230] r600-llvm-compiler completely broken at CAYMAN

2012-08-29 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=54230

--- Comment #3 from Thomas Rohloff  2012-08-29 20:55:07 
UTC ---
Created attachment 66297
  --> https://bugs.freedesktop.org/attachment.cgi?id=66297
Xorg.0.log

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-next queue and EDID stuff

2012-08-29 Thread Adam Jackson 
On 8/29/12 3:53 PM, Ian Pilcher wrote:

> Thinking a bit more about this, I'm starting to rethink my assertion
> that the Intel driver is at fault here.  On one hand, it doesn't make
> any sense to send audio InfoFrames to a non-HDMI display.  (BTW, I'm
> assuming that a display with a DisplayPort port will show up as HDMI.)

Nope.

If you connect to the DP port on a monitor, it will claim to be DP: the 
EDID block version will be 1.4, and the digital display feature byte 
will indicate that it's DP:

http://cgit.freedesktop.org/xorg/app/edid-decode/tree/edid-decode.c#n1145

If you connect to the HDMI port on a monitor, it will claim to be HDMI: 
the EDID block version will be 1.3 or higher, there will be a CEA 
extension block, and there will be a vendor-specific data block within 
that extension with a vendor OUI matching that of the HDMI consortium:

http://cgit.freedesktop.org/xorg/app/edid-decode/tree/edid-decode.c#n640

> On the other hand, it can be argued that the DRM layer is giving
> conflicting information to the driver -- drm_detect_hdmi_monitor is
> returning FALSE, but drm_detect_monitor_audio is returning TRUE.  AFAIK,
> this doesn't make any sense either.

This might be the actual issue.  drm_detect_monitor_audio() can return 
true for several reasons, but it does _not_ make any claim that the 
monitor is HDMI, only that it has a CEA extension block.  Which is 
certainly ugly, but that's how CEA defined their botch of an extension 
block.

So to me, that says that drivers need to ask _both_ whether the monitor 
supports audio and whether it's HDMI before sending HDMI-specific audio 
signalling.

- ajax

drm_vm.c: many arches equate remap_pfn_range() and io_remap_pfn_range()

2012-08-29 Thread Robert P. J. Day 

  a pedantic observation, you can do with it what you wish (i'm not a
list subscriber).  in drivers/gpu/drm/drm_vm.c, we read (line 629):

#if !defined(__arm__)
if (io_remap_pfn_range(vma, vma->vm_start,
   (map->offset + offset) >> PAGE_SHIFT,
   vma->vm_end - vma->vm_start,
   vma->vm_page_prot))
return -EAGAIN;
#else
if (remap_pfn_range(vma, vma->vm_start,
(map->offset + offset) >> PAGE_SHIFT,
vma->vm_end - vma->vm_start,
vma->vm_page_prot))
return -EAGAIN;
#endif

suggesting that only with ARM need we distinguish between those two
routines.  but for various architectures, in pgtable.h, you can see:

#define io_remap_pfn_range  remap_pfn_range

even the arm file contains:

#define io_remap_pfn_range(vma,from,pfn,size,prot) \
remap_pfn_range(vma, from, pfn, size, prot)

so it's not clear what the preprocessor test is for.  admittedly, it
should work, it just seems unnecessary.  and it makes the code more
confusing than it needs to be, but perhaps i've just misread
something.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

[PATCH V5] drm: edid: add support for E-DDC

2012-08-29 Thread Shirish S 
Thanks for the comments Daniel and Jean
I will upload patch set 6.
This shall include Jean's review coments.
And i will tag Daniel,Jean and Ville as reviewed.

Regards,
Shirish S

On Wed, Aug 29, 2012 at 9:12 AM, Daniel Vetter  wrote:

> On Wed, Aug 29, 2012 at 4:46 PM, Shirish S  wrote:
> > The current logic for probing ddc is limited to
> > 2 blocks (256 bytes), this patch adds support
> > for the 4 block (512) data.
> >
> > To do this, a single 8-bit segment index is
> > passed to the display via the I2C address 30h.
> > Data from the selected segment is then immediately
> > read via the regular DDC2 address using a repeated
> > I2C 'START' signal.
> >
> > Signed-off-by: Shirish S 
>
> If you resend patches it'd be nice to keep a changelog of the patch
> itself somewhere, otherwise it's just more work to figure that out for
> reviewers. Also, you can usually attach reviewed-by tags (like mine)
> to a patch resend if you don't change the patch massively ...
> -Daniel
>
> > ---
> >  drivers/gpu/drm/drm_edid.c |   22 +++---
> >  1 files changed, 19 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index bcc4725..b9ffc30 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> >   int block, int len)
> >  {
> > unsigned char start = block * EDID_LENGTH;
> > +   unsigned char segment = block >> 1;
> > +   unsigned char xfers = segment ? 3 : 2;
> > int ret, retries = 5;
> >
> > /* The core i2c driver will automatically retry the transfer if
> the
> > @@ -265,6 +267,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> > do {
> > struct i2c_msg msgs[] = {
> > {
> > +   .addr   = DDC_SEGMENT_ADDR,
> > +   .flags  = segment ? 0 : I2C_M_IGNORE_NAK,
> > +   .len= 1,
> > +   .buf= &segment,
> > +   }, {
> > .addr   = DDC_ADDR,
> > .flags  = 0,
> > .len= 1,
> > @@ -276,15 +283,24 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> > .buf= buf,
> > }
> > };
> > -   ret = i2c_transfer(adapter, msgs, 2);
> > +
> > +   /*
> > +* Avoid sending the segment addr to not upset non-compliant ddc
> > +* monitors.
> > +*/
> > +   if (!segment)
> > +   ret = i2c_transfer(adapter, &msgs[1], xfers);
> > +   else
> > +   ret = i2c_transfer(adapter, msgs, xfers);
> > +
> > if (ret == -ENXIO) {
> > DRM_DEBUG_KMS("drm: skipping non-existent
> adapter %s\n",
> > adapter->name);
> > break;
> > }
> > -   } while (ret != 2 && --retries);
> > +   } while (ret != xfers && --retries);
> >
> > -   return ret == 2 ? 0 : -1;
> > +   return ret == xfers ? 0 : -1;
> >  }
> >
> >  static bool drm_edid_is_zero(u8 *in_edid, int length)
> > --
> > 1.7.0.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> daniel.vetter at ffwll.ch - +41 (0) 79 364 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/20120829/9ab4b82b/attachment-0001.html>

[PATCH] drm/radeon: fix dig encoder selection on DCE61

2012-08-29 Thread alexdeuc...@gmail.com 
From: Alex Deucher 

Was using the DCE41 code which was wrong. Fixes
blank displays on a number of Trinity systems.

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/atombios_encoders.c |   31 +++
 1 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 4a7f95e..6e8803a 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1769,13 +1769,34 @@ static int radeon_atom_pick_dig_encoder(struct 
drm_encoder *encoder)
struct radeon_crtc *radeon_crtc = to_radeon_crtc(encoder->crtc);
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
struct drm_encoder *test_encoder;
-   struct radeon_encoder_atom_dig *dig;
+   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
uint32_t dig_enc_in_use = 0;

-   /* DCE4/5 */
-   if (ASIC_IS_DCE4(rdev)) {
-   dig = radeon_encoder->enc_priv;
-   if (ASIC_IS_DCE41(rdev)) {
+   if (ASIC_IS_DCE6(rdev)) {
+   /* DCE6 */
+   switch (radeon_encoder->encoder_id) {
+   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
+   if (dig->linkb)
+   return 1;
+   else
+   return 0;
+   break;
+   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
+   if (dig->linkb)
+   return 3;
+   else
+   return 2;
+   break;
+   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
+   if (dig->linkb)
+   return 5;
+   else
+   return 4;
+   break;
+   }
+   } else if (ASIC_IS_DCE4(rdev)) {
+   /* DCE4/5 */
+   if (ASIC_IS_DCE41(rdev) && !ASIC_IS_DCE61(rdev)) {
/* ontario follows DCE4 */
if (rdev->family == CHIP_PALM) {
if (dig->linkb)
-- 
1.7.7.5

[pull] radeon drm-fixes-3.6

2012-08-29 Thread Alex Deucher 
I just pushed one more important fix:

commit 41fa54377057ab38bc3e08ebb46168a7daf2e63b
Author: Alex Deucher 
Date:   Wed Aug 29 19:48:26 2012 -0400

drm/radeon: fix dig encoder selection on DCE61

Was using the DCE41 code which was wrong. Fixes
blank displays on a number of Trinity systems.

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org

If it's not too late, please make sure this one is included.

On Wed, Aug 29, 2012 at 1:32 PM,   wrote:
> From: Alex Deucher 
>
> Hi Dave,
>
> This is the current set of radeon fixes for 3.6.  Nothing too major.
>
> Highlights:
> - fix a gart regression on older IGP chips
> - more MSAA fixes
> - fix a double free in gpu reset code
> - modesetting fixes
>
> The following changes since commit 84f720ecba6716d198b21936d1bf6253e8ab42a1:
>
>   Merge branch 'drm-intel-fixes' of 
> git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2012-08-29 
> 20:09:23 +1000)
>
> are available in the git repository at:
>
>   git://people.freedesktop.org/~agd5f/linux drm-fixes-3.6
>
> Alex Deucher (4):
>   drm/radeon: don't disable plls that are in use by other crtcs
>   drm/radeon/atom: rework DIG modesetting on DCE3+
>   drm/radeon/atom: powergating fixes for DCE6
>   drm/radeon: rework panel mode setup
>
> Christian K?nig (1):
>   drm/radeon: fix double free in radeon_gpu_reset
>
> Jerome Glisse (1):
>   drm/radeon: force dma32 to fix regression rs4xx,rs6xx,rs740
>
> Marek Ol??k (3):
>   drm/radeon: fix reading CB_COLORn_MASK from the CS
>   drm/radeon: initialize tracked CS state
>   drm/radeon: add proper checking of RESOLVE_BOX command for r600-r700
>
>  drivers/gpu/drm/radeon/atombios_crtc.c |   36 -
>  drivers/gpu/drm/radeon/atombios_dp.c   |   29 +++-
>  drivers/gpu/drm/radeon/atombios_encoders.c |  109 
> 
>  drivers/gpu/drm/radeon/r600_cs.c   |   30 +++-
>  drivers/gpu/drm/radeon/r600d.h |8 ++
>  drivers/gpu/drm/radeon/radeon_device.c |5 +-
>  drivers/gpu/drm/radeon/radeon_drv.c|3 +-
>  drivers/gpu/drm/radeon/reg_srcs/r600   |1 -
>  8 files changed, 115 insertions(+), 106 deletions(-)

[PATCH V4] drm: edid: add support for E-DDC

2012-08-29 Thread Shirish S 
Hi Jean,

On Wed, Aug 29, 2012 at 6:44 AM, Jean Delvare  wrote:

> Hi all,
>
> Sorry for breaking message threading but I was not included in
> iterations 3 and 4 of this patch.
>
> Random comments about v4:
>
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned
> > char *buf,
> >   int block, int len)
> >  {
> > unsigned char start = block * EDID_LENGTH;
> > +   unsigned char segment = block >> 1;
> > +   unsigned char xfers = segment ? 3 : 2;
> > int ret, retries = 5;
> >
> > /* The core i2c driver will automatically retry the transfer if
> the
> > @@ -264,7 +266,12 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> > unsigned char *buf,
> >  */
> > do {
> > struct i2c_msg msgs[] = {
> > -   {
> > +   { /*set segment pointer */
> > +   .addr   = DDC_SEGMENT_ADDR,
> > +   .flags  = segment ? 0 : I2C_M_IGNORE_NAK,
>
> I don't get the idea. If segment == 0, this message is never sent, so the
> value of field flags doesn't matter. So flags will always be 0 when this
> message is sent, so it can be hard-coded.
>
> Agreed.

> But from previous discussions my understanding was an agreement on always
> using I2C_M_IGNORE_NAK for improved compatibility. So I2C_M_IGNORE_NAK
> should be hard-coded, not 0?
>
After discussion,daniel had asked for a seprate patch for the flags
modification.
Will upload that later.

>
>
> +   .len= 1,
> > +   .buf= &segment,
> > +   }, {
> > .addr   = DDC_ADDR,
> > .flags  = 0,
> > .len= 1,
> > @@ -276,15 +283,22 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> > unsigned char *buf,
> > .buf= buf,
> > }
> > };
> > -   ret = i2c_transfer(adapter, msgs, 2);
> > +   /* Avoid sending the segment addr to not upset non-compliant ddc
> > +* monitors.
> > +*/
>
> s/segment addr/segment/, plus it's abot E-DCC compliance as I understand
> it,
> not DDC.
>
> > +   if (!segment)
> > +   ret = i2c_transfer(adapter, &msgs[1], xfers);
> > +   else
> > +   ret = i2c_transfer(adapter, msgs, xfers);
> > +
>
> This can be written:
>
> ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);
>
> Which is more compact and, I suspect, faster.
>
> Agreed.

> > if (ret == -ENXIO) {
> > DRM_DEBUG_KMS("drm: skipping non-existent
> adapter %s\n",
> > adapter->name);
> > break;
> > }
> > -   } while (ret != 2 && --retries);
> > +   } while (ret != xfers && --retries);
> >
> > -   return ret == 2 ? 0 : -1;
> > +   return ret == xfers ? 0 : -1;
> >  }
> >
> >  static bool drm_edid_is_zero(u8 *in_edid, int length)
>
> Other than this, your code looks reasonable, not so different from what
> I submitted 8 months ago actually. But ISTU you can test the code with
> real hardware while I couldn't.
>
> Your patch never checked for the 3 message transfer complete, it checked
only 2.

With the changes above applied, you can add:
>
> Reviewed-by: Jean Delvare 
>
> Will add your review comments in patch set 5 and your reviewed tag.

Thanks & Regards,
Shirish S

> --
> Jean Delvare
> Suse L3
>
> ___
> 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/20120829/5b818ed7/attachment.html>

[Linaro-mm-sig] [PATCH 2/4] dma-fence: dma-buf synchronization (v8 )

2012-08-29 Thread Francesco Lavra 
Hi,

On Fri, Aug 10, 2012 at 4:57 PM, Maarten Lankhorst
 wrote:

[Snip]

> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> new file mode 100644
> index 000..e0ceddd
> --- /dev/null
> +++ b/include/linux/dma-fence.h
> @@ -0,0 +1,124 @@
> +/*
> + * Fence mechanism for dma-buf to allow for asynchronous dma access
> + *
> + * Copyright (C) 2012 Texas Instruments
> + * Author: Rob Clark 
> + *
> + * This program is free software; you can redistribute it and/or modify
> it
> + * under the terms of the GNU General Public License version 2 as
> published by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License
> along with
> + * this program.  If not, see .
> + */
> +
> +#ifndef __DMA_FENCE_H__
> +#define __DMA_FENCE_H__
> +
> +#include 
> +#include 
> +#include 
> +#include 

Duplicated include.

Regards,
Francesco