[PATCH] trivial: Remove unused variable `tmp' from `radeon_combios_get_lvds_info()'

[Michael Witten]

> Signed-off-by: Michael Witten 
> ---
>  drivers/gpu/drm/radeon/radeon_combios.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
> b/drivers/gpu/drm/radeon/radeon_combios.c
> index 0b3c1e0..7962091 100644
> --- a/drivers/gpu/drm/radeon/radeon_combios.c
> +++ b/drivers/gpu/drm/radeon/radeon_combios.c
> @@ -1175,7 +1175,7 @@ struct radeon_encoder_lvds 
> *radeon_combios_get_lvds_info(struct radeon_encoder
>   uint16_t lcd_info;
>   uint32_t panel_setup;
>   char stmp[30];
> - int tmp, i;
> + int i;
>   struct radeon_encoder_lvds *lvds = NULL;
>
>   lcd_info = combios_get_table_offset(dev, COMBIOS_LCD_INFO_TABLE);
> -- 
> 1.7.11.2.252.gc4a64c8

PLEASE IGNORE THIS!

I made the same mistake that I did 3.5 years ago; the variable `tmp' is NOT 
unused:

http://article.gmane.org/gmane.comp.video.dri.devel/60785

Sorry for the irritation.

Sincerely,
Michael Witten

[PATCH] trivial: Remove unused variable `tmp' from `radeon_combios_get_lvds_info()'

[Michael Witten]

Signed-off-by: Michael Witten 
---
 drivers/gpu/drm/radeon/radeon_combios.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
b/drivers/gpu/drm/radeon/radeon_combios.c
index 0b3c1e0..7962091 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -1175,7 +1175,7 @@ struct radeon_encoder_lvds 
*radeon_combios_get_lvds_info(struct radeon_encoder
uint16_t lcd_info;
uint32_t panel_setup;
char stmp[30];
-   int tmp, i;
+   int i;
struct radeon_encoder_lvds *lvds = NULL;

lcd_info = combios_get_table_offset(dev, COMBIOS_LCD_INFO_TABLE);
-- 
1.7.11.2.252.gc4a64c8

[Patch 0/3] Add ability to override a monitor's EDID information

[Michael Witten]

On Tue, 24 Apr 2012 10:49:06 +0200, Thorsten Schoel wrote:

> Hello everybody,
>
> having a monitor provide wrong or invalid EDID information---or none at
> all---seems to be a problem quite a number of people are facing. A few
> of the non-KMS X-drivers provide individual mechanisms for overriding
> such an EDID with user provided data. To my knowledge at least the
> kernel currently falls short of providing such a mechanism. This set of
> patches attempts to provide one.
>
> It has a number of potential shortcoming to which I was not yet able to
> find any solution. These are:
>
> 1. It uses drm_get_connector_name to identify a connector. I am not
> entirely sure though if these names are guaranteed to be unique (the
> names used in /sys/class/drm seem to suggest they are not). Since they
> are good enough for the kernel's video parameter, though, I figured they
> should be good enough for the present purpose as well.
>
> 2. One of the patches introduces a new kernel parameter (edid_override).
> This parameter takes either the raw edid-data encoded as a hex-string or
> the name of a firmware file from which to load the data. I am a bit
> unhappy with both solutions since the first puts raw data on the command
> line and makes it rather long and the second... well edid-data is not
> exactly firmware in the strict sense. It may be firm, but it is probably
> not ware.
>
> 3. I thought about making the sysfs code more sophisticated so that
> individual bytes could be written at any position within the data. Yet,
> there seems to be no way to truncate a file in sysfs which would be
> important when changing the number of 128 byte blocks the data is made
> up of. In addition, I cannot see what good such a behaviour would be or
> how the obscure use probably is somewhere out there could justify the
> additional complexity. I therefore opted for the approach of only
> allowing writes of complete edid-blobs in one pass.
>
> The patches I submit were tested on an x64 with radeon graphics and on
> an x86 with i915. They were made for 3.4.
>
>  drivers/gpu/drm/drm_edid.c  |  399 
> +++-
>  drivers/gpu/drm/drm_sysfs.c |   43 
>  include/drm/drm_crtc.h  |2
>  3 files changed, 435 insertions(+), 9 deletions(-)

Are you aware of the following recent commit?

  commit da0df92b57311aa1b26a2a90599ed16e1e968b90
  Author: Carsten Emde 
  Date:   Sun Mar 18 22:37:33 2012 +0100
  drm: allow loading an EDID as firmware to override broken monitor

Has some of your work already been implemented?

That being said, the firmware-loading feature of the above commit is not
useful to me, because on my system, it tries to load the EDID data BEFORE
the kernel knows how to access the file system where the requisite file
resides; perhaps something like your command-line EDID data would be useful
to me (and others).

Sincerely,
Michael Witten

Re: [Patch 0/3] Add ability to override a monitor's EDID information

[Michael Witten]

On Tue, 24 Apr 2012 10:49:06 +0200, Thorsten Schoel wrote:

 Hello everybody,

 having a monitor provide wrong or invalid EDID information---or none at
 all---seems to be a problem quite a number of people are facing. A few
 of the non-KMS X-drivers provide individual mechanisms for overriding
 such an EDID with user provided data. To my knowledge at least the
 kernel currently falls short of providing such a mechanism. This set of
 patches attempts to provide one.

 It has a number of potential shortcoming to which I was not yet able to
 find any solution. These are:

 1. It uses drm_get_connector_name to identify a connector. I am not
 entirely sure though if these names are guaranteed to be unique (the
 names used in /sys/class/drm seem to suggest they are not). Since they
 are good enough for the kernel's video parameter, though, I figured they
 should be good enough for the present purpose as well.

 2. One of the patches introduces a new kernel parameter (edid_override).
 This parameter takes either the raw edid-data encoded as a hex-string or
 the name of a firmware file from which to load the data. I am a bit
 unhappy with both solutions since the first puts raw data on the command
 line and makes it rather long and the second... well edid-data is not
 exactly firmware in the strict sense. It may be firm, but it is probably
 not ware.

 3. I thought about making the sysfs code more sophisticated so that
 individual bytes could be written at any position within the data. Yet,
 there seems to be no way to truncate a file in sysfs which would be
 important when changing the number of 128 byte blocks the data is made
 up of. In addition, I cannot see what good such a behaviour would be or
 how the obscure use probably is somewhere out there could justify the
 additional complexity. I therefore opted for the approach of only
 allowing writes of complete edid-blobs in one pass.

 The patches I submit were tested on an x64 with radeon graphics and on
 an x86 with i915. They were made for 3.4.

  drivers/gpu/drm/drm_edid.c  |  399 
 +++-
  drivers/gpu/drm/drm_sysfs.c |   43 
  include/drm/drm_crtc.h  |2
  3 files changed, 435 insertions(+), 9 deletions(-)

Are you aware of the following recent commit?

  commit da0df92b57311aa1b26a2a90599ed16e1e968b90
  Author: Carsten Emde c.e...@osadl.org
  Date:   Sun Mar 18 22:37:33 2012 +0100
  drm: allow loading an EDID as firmware to override broken monitor

Has some of your work already been implemented?

That being said, the firmware-loading feature of the above commit is not
useful to me, because on my system, it tries to load the EDID data BEFORE
the kernel knows how to access the file system where the requisite file
resides; perhaps something like your command-line EDID data would be useful
to me (and others).

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

Re: [PATCH 1/3] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[Michael Witten]

On Sun, 11 Mar 2012 22:23:22 +0100, Carsten Emde wrote:

 On 03/11/2012 02:44 PM, Alan Cox wrote:

 This patch allows to load an EDID data set via the firmware interface.
 It contains data sets of frequently used screen resolutions (1024x768,
 1280x1024, 1680x1050 and 1920x1080). The requested EDID data are
 specified as a module parameter of the drm_kms_helper module, e.g.
 options drm_kms_helper edid_firmware=edid/1280x1024.bin or as kernel
 command line parameter.

 What if the DRM layer and driver are compiled in. They'll come up as
 console before the file system so the firmware request will hang ?

 Admittedly I did not try to compile the DRM layer and driver into the 
 kernel. However, I created an error condition by specifying a 
 non-existing EDID file. In this case, the function returns with error, 
 the mode count remains 0, and the system continues to run as if the 
 edid_firmware= parameter had not been specified.

Unfortunately, as of at least last month, my system hangs when I try to
use your feature (just as described by Alan Cox); the log shows that
during the boot process, there is a one-minute hang:

  [0.175207] [drm] radeon: power management initialized
  [   60.896507] [drm:edid_load] *ERROR* Requesting EDID firmware 
edid/1920x1200.bin failed (err=-2)

Is there any way to make your feature smarter about its timing with
relation to file system accessibility?

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

[PATCH] DRM: bug: RADEON_DEBUGFS_MAX_{NUM_FILES => COMPONENTS}

[Michael Witten]

On Tue, Oct 25, 2011 at 01:35, Ilija Hadzic
 wrote:

> On Mon, 24 Oct 2011, Michael Witten wrote:
>
>> This patch has not yet been applied. What's wrong?
>
> Maybe you are looking at the wrong branch, but I see it in drm-next (it has
> been there since Oct 10)
>
> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next=c245cb9e15055ed5dcf7eaf29232badb0059fdc1

Well! I feel silly!

Thanks.

Re: [PATCH] DRM: bug: RADEON_DEBUGFS_MAX_{NUM_FILES = COMPONENTS}

[Michael Witten]

On Tue, Oct 25, 2011 at 01:35, Ilija Hadzic
ihad...@research.bell-labs.com wrote:

 On Mon, 24 Oct 2011, Michael Witten wrote:

 This patch has not yet been applied. What's wrong?

 Maybe you are looking at the wrong branch, but I see it in drm-next (it has
 been there since Oct 10)

 http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-nextid=c245cb9e15055ed5dcf7eaf29232badb0059fdc1

Well! I feel silly!

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

[PATCH] DRM: bug: RADEON_DEBUGFS_MAX_{NUM_FILES => COMPONENTS}

[Michael Witten]

On Fri, Oct 7, 2011 at 19:20, Michael Witten  wrote:
> Date: Fri, 16 Sep 2011 20:45:30 +
>
> The value of RADEON_DEBUGFS_MAX_NUM_FILES has been used to
> specify the size of an array, each element of which looks
> like this:
>
> ?struct radeon_debugfs {
> ? ? ? ? ?struct drm_info_list ? ?*files;
> ? ? ? ? ?unsigned ? ? ? ? ? ? ? ?num_files;
> ?};
>
> Consequently, the number of debugfs files may be much greater
> than RADEON_DEBUGFS_MAX_NUM_FILES, something that the current
> code ignores:
>
> ?if ((_radeon_debugfs_count + nfiles) > RADEON_DEBUGFS_MAX_NUM_FILES) {
> ? ? ? ? ?DRM_ERROR("Reached maximum number of debugfs files.\n");
> ? ? ? ? ?DRM_ERROR("Report so we increase RADEON_DEBUGFS_MAX_NUM_FILES.\n");
> ? ? ? ? ?return -EINVAL;
> ?}
>
> This commit fixes this mistake, and accordingly renames:
>
> ?RADEON_DEBUGFS_MAX_NUM_FILES
>
> to:
>
> ?RADEON_DEBUGFS_MAX_COMPONENTS
>
> Signed-off-by: Michael Witten 
> ---
> ?drivers/gpu/drm/radeon/radeon.h ? ? ? ?| ? ?2 +-
> ?drivers/gpu/drm/radeon/radeon_device.c | ? 13 -
> ?2 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index c1e056b..dd7bab9 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -102,7 +102,7 @@ extern int radeon_pcie_gen2;
> ?#define RADEON_FENCE_JIFFIES_TIMEOUT ? (HZ / 2)
> ?/* RADEON_IB_POOL_SIZE must be a power of 2 */
> ?#define RADEON_IB_POOL_SIZE ? ? ? ? ? ?16
> -#define RADEON_DEBUGFS_MAX_NUM_FILES ? 32
> +#define RADEON_DEBUGFS_MAX_COMPONENTS ?32
> ?#define RADEONFB_CONN_LIMIT ? ? ? ? ? ?4
> ?#define RADEON_BIOS_NUM_SCRATCH ? ? ? ? ? ? ? ?8
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
> b/drivers/gpu/drm/radeon/radeon_device.c
> index b51e157..31b1f4b 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -981,7 +981,7 @@ struct radeon_debugfs {
> ? ? ? ?struct drm_info_list ? ?*files;
> ? ? ? ?unsigned ? ? ? ? ? ? ? ?num_files;
> ?};
> -static struct radeon_debugfs _radeon_debugfs[RADEON_DEBUGFS_MAX_NUM_FILES];
> +static struct radeon_debugfs _radeon_debugfs[RADEON_DEBUGFS_MAX_COMPONENTS];
> ?static unsigned _radeon_debugfs_count = 0;
>
> ?int radeon_debugfs_add_files(struct radeon_device *rdev,
> @@ -996,14 +996,17 @@ int radeon_debugfs_add_files(struct radeon_device *rdev,
> ? ? ? ? ? ? ? ? ? ? ? ?return 0;
> ? ? ? ? ? ? ? ?}
> ? ? ? ?}
> - ? ? ? if ((_radeon_debugfs_count + nfiles) > RADEON_DEBUGFS_MAX_NUM_FILES) {
> - ? ? ? ? ? ? ? DRM_ERROR("Reached maximum number of debugfs files.\n");
> - ? ? ? ? ? ? ? DRM_ERROR("Report so we increase 
> RADEON_DEBUGFS_MAX_NUM_FILES.\n");
> +
> + ? ? ? i = _radeon_debugfs_count + 1;
> + ? ? ? if (i > RADEON_DEBUGFS_MAX_COMPONENTS) {
> + ? ? ? ? ? ? ? DRM_ERROR("Reached maximum number of debugfs components.\n");
> + ? ? ? ? ? ? ? DRM_ERROR("Report so we increase "
> + ? ? ? ? ? ? ? ? ? ? ? ? "RADEON_DEBUGFS_MAX_COMPONENTS.\n");
> ? ? ? ? ? ? ? ?return -EINVAL;
> ? ? ? ?}
> ? ? ? ?_radeon_debugfs[_radeon_debugfs_count].files = files;
> ? ? ? ?_radeon_debugfs[_radeon_debugfs_count].num_files = nfiles;
> - ? ? ? _radeon_debugfs_count++;
> + ? ? ? _radeon_debugfs_count = i;
> ?#if defined(CONFIG_DEBUG_FS)
> ? ? ? ?drm_debugfs_create_files(files, nfiles,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? rdev->ddev->control->debugfs_root,
> --
> 1.7.6.409.ge7a85
>
>

This patch has not yet been applied. What's wrong?

Sincerely,
Michael Witten

Re: [PATCH] DRM: bug: RADEON_DEBUGFS_MAX_{NUM_FILES = COMPONENTS}

[Michael Witten]

On Fri, Oct 7, 2011 at 19:20, Michael Witten mfwit...@gmail.com wrote:
 Date: Fri, 16 Sep 2011 20:45:30 +

 The value of RADEON_DEBUGFS_MAX_NUM_FILES has been used to
 specify the size of an array, each element of which looks
 like this:

  struct radeon_debugfs {
          struct drm_info_list    *files;
          unsigned                num_files;
  };

 Consequently, the number of debugfs files may be much greater
 than RADEON_DEBUGFS_MAX_NUM_FILES, something that the current
 code ignores:

  if ((_radeon_debugfs_count + nfiles)  RADEON_DEBUGFS_MAX_NUM_FILES) {
          DRM_ERROR(Reached maximum number of debugfs files.\n);
          DRM_ERROR(Report so we increase RADEON_DEBUGFS_MAX_NUM_FILES.\n);
          return -EINVAL;
  }

 This commit fixes this mistake, and accordingly renames:

  RADEON_DEBUGFS_MAX_NUM_FILES

 to:

  RADEON_DEBUGFS_MAX_COMPONENTS

 Signed-off-by: Michael Witten mfwit...@gmail.com
 ---
  drivers/gpu/drm/radeon/radeon.h        |    2 +-
  drivers/gpu/drm/radeon/radeon_device.c |   13 -
  2 files changed, 9 insertions(+), 6 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
 index c1e056b..dd7bab9 100644
 --- a/drivers/gpu/drm/radeon/radeon.h
 +++ b/drivers/gpu/drm/radeon/radeon.h
 @@ -102,7 +102,7 @@ extern int radeon_pcie_gen2;
  #define RADEON_FENCE_JIFFIES_TIMEOUT   (HZ / 2)
  /* RADEON_IB_POOL_SIZE must be a power of 2 */
  #define RADEON_IB_POOL_SIZE            16
 -#define RADEON_DEBUGFS_MAX_NUM_FILES   32
 +#define RADEON_DEBUGFS_MAX_COMPONENTS  32
  #define RADEONFB_CONN_LIMIT            4
  #define RADEON_BIOS_NUM_SCRATCH                8

 diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
 b/drivers/gpu/drm/radeon/radeon_device.c
 index b51e157..31b1f4b 100644
 --- a/drivers/gpu/drm/radeon/radeon_device.c
 +++ b/drivers/gpu/drm/radeon/radeon_device.c
 @@ -981,7 +981,7 @@ struct radeon_debugfs {
        struct drm_info_list    *files;
        unsigned                num_files;
  };
 -static struct radeon_debugfs _radeon_debugfs[RADEON_DEBUGFS_MAX_NUM_FILES];
 +static struct radeon_debugfs _radeon_debugfs[RADEON_DEBUGFS_MAX_COMPONENTS];
  static unsigned _radeon_debugfs_count = 0;

  int radeon_debugfs_add_files(struct radeon_device *rdev,
 @@ -996,14 +996,17 @@ int radeon_debugfs_add_files(struct radeon_device *rdev,
                        return 0;
                }
        }
 -       if ((_radeon_debugfs_count + nfiles)  RADEON_DEBUGFS_MAX_NUM_FILES) {
 -               DRM_ERROR(Reached maximum number of debugfs files.\n);
 -               DRM_ERROR(Report so we increase 
 RADEON_DEBUGFS_MAX_NUM_FILES.\n);
 +
 +       i = _radeon_debugfs_count + 1;
 +       if (i  RADEON_DEBUGFS_MAX_COMPONENTS) {
 +               DRM_ERROR(Reached maximum number of debugfs components.\n);
 +               DRM_ERROR(Report so we increase 
 +                         RADEON_DEBUGFS_MAX_COMPONENTS.\n);
                return -EINVAL;
        }
        _radeon_debugfs[_radeon_debugfs_count].files = files;
        _radeon_debugfs[_radeon_debugfs_count].num_files = nfiles;
 -       _radeon_debugfs_count++;
 +       _radeon_debugfs_count = i;
  #if defined(CONFIG_DEBUG_FS)
        drm_debugfs_create_files(files, nfiles,
                                 rdev-ddev-control-debugfs_root,
 --
 1.7.6.409.ge7a85



This patch has not yet been applied. What's wrong?

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

[PATCH] DRM: bug: RADEON_DEBUGFS_MAX_{NUM_FILES => COMPONENTS}

[Michael Witten]

Date: Fri, 16 Sep 2011 20:45:30 +

The value of RADEON_DEBUGFS_MAX_NUM_FILES has been used to
specify the size of an array, each element of which looks
like this:

  struct radeon_debugfs {
  struct drm_info_list*files;
  unsignednum_files;
  };

Consequently, the number of debugfs files may be much greater
than RADEON_DEBUGFS_MAX_NUM_FILES, something that the current
code ignores:

  if ((_radeon_debugfs_count + nfiles) > RADEON_DEBUGFS_MAX_NUM_FILES) {
  DRM_ERROR("Reached maximum number of debugfs files.\n");
  DRM_ERROR("Report so we increase RADEON_DEBUGFS_MAX_NUM_FILES.\n");
  return -EINVAL;
  }

This commit fixes this mistake, and accordingly renames:

  RADEON_DEBUGFS_MAX_NUM_FILES

to:

  RADEON_DEBUGFS_MAX_COMPONENTS

Signed-off-by: Michael Witten 
---
 drivers/gpu/drm/radeon/radeon.h|2 +-
 drivers/gpu/drm/radeon/radeon_device.c |   13 -
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index c1e056b..dd7bab9 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -102,7 +102,7 @@ extern int radeon_pcie_gen2;
 #define RADEON_FENCE_JIFFIES_TIMEOUT   (HZ / 2)
 /* RADEON_IB_POOL_SIZE must be a power of 2 */
 #define RADEON_IB_POOL_SIZE16
-#define RADEON_DEBUGFS_MAX_NUM_FILES   32
+#define RADEON_DEBUGFS_MAX_COMPONENTS  32
 #define RADEONFB_CONN_LIMIT4
 #define RADEON_BIOS_NUM_SCRATCH8

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index b51e157..31b1f4b 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -981,7 +981,7 @@ struct radeon_debugfs {
struct drm_info_list*files;
unsignednum_files;
 };
-static struct radeon_debugfs _radeon_debugfs[RADEON_DEBUGFS_MAX_NUM_FILES];
+static struct radeon_debugfs _radeon_debugfs[RADEON_DEBUGFS_MAX_COMPONENTS];
 static unsigned _radeon_debugfs_count = 0;

 int radeon_debugfs_add_files(struct radeon_device *rdev,
@@ -996,14 +996,17 @@ int radeon_debugfs_add_files(struct radeon_device *rdev,
return 0;
}
}
-   if ((_radeon_debugfs_count + nfiles) > RADEON_DEBUGFS_MAX_NUM_FILES) {
-   DRM_ERROR("Reached maximum number of debugfs files.\n");
-   DRM_ERROR("Report so we increase 
RADEON_DEBUGFS_MAX_NUM_FILES.\n");
+
+   i = _radeon_debugfs_count + 1;
+   if (i > RADEON_DEBUGFS_MAX_COMPONENTS) {
+   DRM_ERROR("Reached maximum number of debugfs components.\n");
+   DRM_ERROR("Report so we increase "
+ "RADEON_DEBUGFS_MAX_COMPONENTS.\n");
return -EINVAL;
}
_radeon_debugfs[_radeon_debugfs_count].files = files;
_radeon_debugfs[_radeon_debugfs_count].num_files = nfiles;
-   _radeon_debugfs_count++;
+   _radeon_debugfs_count = i;
 #if defined(CONFIG_DEBUG_FS)
drm_debugfs_create_files(files, nfiles,
 rdev->ddev->control->debugfs_root,
-- 
1.7.6.409.ge7a85

[PATCH] DRM: bug: RADEON_DEBUGFS_MAX_{NUM_FILES = COMPONENTS}

[Michael Witten]

Date: Fri, 16 Sep 2011 20:45:30 +

The value of RADEON_DEBUGFS_MAX_NUM_FILES has been used to
specify the size of an array, each element of which looks
like this:

  struct radeon_debugfs {
  struct drm_info_list*files;
  unsignednum_files;
  };

Consequently, the number of debugfs files may be much greater
than RADEON_DEBUGFS_MAX_NUM_FILES, something that the current
code ignores:

  if ((_radeon_debugfs_count + nfiles)  RADEON_DEBUGFS_MAX_NUM_FILES) {
  DRM_ERROR(Reached maximum number of debugfs files.\n);
  DRM_ERROR(Report so we increase RADEON_DEBUGFS_MAX_NUM_FILES.\n);
  return -EINVAL;
  }

This commit fixes this mistake, and accordingly renames:

  RADEON_DEBUGFS_MAX_NUM_FILES

to:

  RADEON_DEBUGFS_MAX_COMPONENTS

Signed-off-by: Michael Witten mfwit...@gmail.com
---
 drivers/gpu/drm/radeon/radeon.h|2 +-
 drivers/gpu/drm/radeon/radeon_device.c |   13 -
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index c1e056b..dd7bab9 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -102,7 +102,7 @@ extern int radeon_pcie_gen2;
 #define RADEON_FENCE_JIFFIES_TIMEOUT   (HZ / 2)
 /* RADEON_IB_POOL_SIZE must be a power of 2 */
 #define RADEON_IB_POOL_SIZE16
-#define RADEON_DEBUGFS_MAX_NUM_FILES   32
+#define RADEON_DEBUGFS_MAX_COMPONENTS  32
 #define RADEONFB_CONN_LIMIT4
 #define RADEON_BIOS_NUM_SCRATCH8
 
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index b51e157..31b1f4b 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -981,7 +981,7 @@ struct radeon_debugfs {
struct drm_info_list*files;
unsignednum_files;
 };
-static struct radeon_debugfs _radeon_debugfs[RADEON_DEBUGFS_MAX_NUM_FILES];
+static struct radeon_debugfs _radeon_debugfs[RADEON_DEBUGFS_MAX_COMPONENTS];
 static unsigned _radeon_debugfs_count = 0;
 
 int radeon_debugfs_add_files(struct radeon_device *rdev,
@@ -996,14 +996,17 @@ int radeon_debugfs_add_files(struct radeon_device *rdev,
return 0;
}
}
-   if ((_radeon_debugfs_count + nfiles)  RADEON_DEBUGFS_MAX_NUM_FILES) {
-   DRM_ERROR(Reached maximum number of debugfs files.\n);
-   DRM_ERROR(Report so we increase 
RADEON_DEBUGFS_MAX_NUM_FILES.\n);
+
+   i = _radeon_debugfs_count + 1;
+   if (i  RADEON_DEBUGFS_MAX_COMPONENTS) {
+   DRM_ERROR(Reached maximum number of debugfs components.\n);
+   DRM_ERROR(Report so we increase 
+ RADEON_DEBUGFS_MAX_COMPONENTS.\n);
return -EINVAL;
}
_radeon_debugfs[_radeon_debugfs_count].files = files;
_radeon_debugfs[_radeon_debugfs_count].num_files = nfiles;
-   _radeon_debugfs_count++;
+   _radeon_debugfs_count = i;
 #if defined(CONFIG_DEBUG_FS)
drm_debugfs_create_files(files, nfiles,
 rdev-ddev-control-debugfs_root,
-- 
1.7.6.409.ge7a85

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

Curious experiences with a Radeon on the fritz

[Michael Witten]

On Mon, Sep 26, 2011 at 21:51, Tormod Volden  wrote:
> On Wed, Sep 21, 2011 at 8:52 PM, Michael Witten wrote:
>> Because my hardware does appear to be malfunctioning due to a corrupt
>> video BIOS, it seems prudent to salvage as much as possible from
>> its output, so that it is possible to figure out which other values
>> need to be hardcoded in case of further corruption.
>>
>> To do this, I did 2 things:
>>
>> ?* Export the video BIOS data via debugfs, so that it can be
>> ? ?easily backed up in secondary storage.
>>
>> ?* Hack the existing Radeon driver code to log information
>> ? ?about which values are being read from the video BIOS
>> ? ?data and from which offsets these values are being read.
>>
>> I first wrote the following patch to export the video BIOS via debugfs
>> (I wrote a little more than necessary; it should be generally applicable):
>
> Is there any reason to use your debugfs patch instead of reading the
> BIOS the "classic" way?
>
> (as root)
> (use lspci to get the bus id)
> cd /sys/bus/pci/devices/
> echo 1 > rom
> cat rom > /tmp/vbios.rom
> echo 0 > rom

Most certainly there is a reason: One doesn't yet know it's possible
to read the BIOS the "classic" way. :-D

Of course, in general, the files:

  drivers/gpu/drm/drm_platform.c
  drivers/gpu/drm/drm_usb.c

suggest that it's unwise to rely on PCI. Similarly, things like the function:

  radeon_atrm_get_bios()

suggest that accessing the video BIOS may require the higher-level
access that my patch provides.

Anyway, thanks for the heads-up.

[PATCH 0/7] DRM/Radeon Cleanup

[Michael Witten]

On Wed, 21 Sep 2011 22:50:57 -, Michael Witten wrote:

> Whilst working on my failing Radeon GPU:
>
>   Subject: Re: Curious experiences with a Radeon on the fritz
>   Date: Wed, 21 Sep 2011 18:52:19 -
>   Message-ID: 
>   http://lists.freedesktop.org/archives/dri-devel/2011-September/014506.html
>
> I made the following trivial improvements to the DRM/Radeon code
> along the way ([6] fixes a bug):
>
>   [1] DRM: comment: drm_crtc{=>_helper}_set_mode
>   [2] DRM: comment: halve -> half
>   [3] DRM: cleanup: Remove unused `gamma_size'
>   [4] DRM: comment: gdm_proc_lists -> drm_proc_lists
>   [5] DRM: cleanup: `size == 0' is never true
>   [6] DRM: bug: RADEON_DEBUGFS_MAX_{NUM_FILES => COMPONENTS}
>   [7] DRM: cleanup: Remove unsused `tmp'
>
> Here is the overall difference:
>
>  drivers/gpu/drm/drm_crtc_helper.c   |2 +-
>  drivers/gpu/drm/drm_fb_helper.c |3 ---
>  drivers/gpu/drm/drm_irq.c   |4 ++--
>  drivers/gpu/drm/drm_proc.c  |2 +-
>  drivers/gpu/drm/radeon/radeon.h |2 +-
>  drivers/gpu/drm/radeon/radeon_bios.c|2 +-
>  drivers/gpu/drm/radeon/radeon_combios.c |2 +-
>  drivers/gpu/drm/radeon/radeon_device.c  |   13 -
>  8 files changed, 15 insertions(+), 15 deletions(-)

When you get the chance, David, please apply all but [4] and [7].

  * Patch [4] is not really helpful, because it poorly changes a
comment in what is deprecated, probably erroneous code anyway.

  * [7] was a mistake on my part.

Re: Curious experiences with a Radeon on the fritz

[Michael Witten]

On Mon, Sep 26, 2011 at 21:51, Tormod Volden lists.tor...@gmail.com wrote:
 On Wed, Sep 21, 2011 at 8:52 PM, Michael Witten wrote:
 Because my hardware does appear to be malfunctioning due to a corrupt
 video BIOS, it seems prudent to salvage as much as possible from
 its output, so that it is possible to figure out which other values
 need to be hardcoded in case of further corruption.

 To do this, I did 2 things:

  * Export the video BIOS data via debugfs, so that it can be
    easily backed up in secondary storage.

  * Hack the existing Radeon driver code to log information
    about which values are being read from the video BIOS
    data and from which offsets these values are being read.

 I first wrote the following patch to export the video BIOS via debugfs
 (I wrote a little more than necessary; it should be generally applicable):

 Is there any reason to use your debugfs patch instead of reading the
 BIOS the classic way?

 (as root)
 (use lspci to get the bus id)
 cd /sys/bus/pci/devices/pci bus id
 echo 1  rom
 cat rom  /tmp/vbios.rom
 echo 0  rom

Most certainly there is a reason: One doesn't yet know it's possible
to read the BIOS the classic way. :-D

Of course, in general, the files:

  drivers/gpu/drm/drm_platform.c
  drivers/gpu/drm/drm_usb.c

suggest that it's unwise to rely on PCI. Similarly, things like the function:

  radeon_atrm_get_bios()

suggest that accessing the video BIOS may require the higher-level
access that my patch provides.

Anyway, thanks for the heads-up.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 7/7] DRM: cleanup: Remove unsused `tmp'

[Michael Witten]

2011/9/22 Michel D?nzer :
> On Mit, 2011-09-21 at 22:50 +0000, Michael Witten wrote:
>> Date: Wed, 21 Sep 2011 02:10:43 +
>>
>> Signed-off-by: Michael Witten 
>> ---
>> ?drivers/gpu/drm/radeon/radeon_combios.c | ? ?2 +-
>> ?1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
>> b/drivers/gpu/drm/radeon/radeon_combios.c
>> index 6367524..b0549aa 100644
>> --- a/drivers/gpu/drm/radeon/radeon_combios.c
>> +++ b/drivers/gpu/drm/radeon/radeon_combios.c
>> @@ -1227,7 +1227,7 @@ struct radeon_encoder_lvds 
>> *radeon_combios_get_lvds_info(struct radeon_encoder
>> ? ? ? uint16_t lcd_info;
>> ? ? ? uint32_t panel_setup;
>> ? ? ? char stmp[30];
>> - ? ? int tmp, i;
>> + ? ? int i;
>> ? ? ? struct radeon_encoder_lvds *lvds = NULL;
>>
>> ? ? ? lcd_info = combios_get_table_offset(dev, COMBIOS_LCD_INFO_TABLE);
>
> It's not unused here. Maybe it is for you because you disabled reading
> some values from the VBIOS?

Woops! :-P

You are correct.

Re: [PATCH 7/7] DRM: cleanup: Remove unsused `tmp'

[Michael Witten]

2011/9/22 Michel Dänzer mic...@daenzer.net:
 On Mit, 2011-09-21 at 22:50 +, Michael Witten wrote:
 Date: Wed, 21 Sep 2011 02:10:43 +

 Signed-off-by: Michael Witten mfwit...@gmail.com
 ---
  drivers/gpu/drm/radeon/radeon_combios.c |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
 b/drivers/gpu/drm/radeon/radeon_combios.c
 index 6367524..b0549aa 100644
 --- a/drivers/gpu/drm/radeon/radeon_combios.c
 +++ b/drivers/gpu/drm/radeon/radeon_combios.c
 @@ -1227,7 +1227,7 @@ struct radeon_encoder_lvds 
 *radeon_combios_get_lvds_info(struct radeon_encoder
       uint16_t lcd_info;
       uint32_t panel_setup;
       char stmp[30];
 -     int tmp, i;
 +     int i;
       struct radeon_encoder_lvds *lvds = NULL;

       lcd_info = combios_get_table_offset(dev, COMBIOS_LCD_INFO_TABLE);

 It's not unused here. Maybe it is for you because you disabled reading
 some values from the VBIOS?

Woops! :-P

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

[PATCH 0/7] DRM/Radeon Cleanup

[Michael Witten]

Whilst working on my failing Radeon GPU:

  Subject: Re: Curious experiences with a Radeon on the fritz
  Date: Wed, 21 Sep 2011 18:52:19 -
  Message-ID: 
  http://lists.freedesktop.org/archives/dri-devel/2011-September/014506.html

I made the following trivial improvements to the DRM/Radeon code
along the way ([6] fixes a bug):

  [1] DRM: comment: drm_crtc{=>_helper}_set_mode
  [2] DRM: comment: halve -> half
  [3] DRM: cleanup: Remove unused `gamma_size'
  [4] DRM: comment: gdm_proc_lists -> drm_proc_lists
  [5] DRM: cleanup: `size == 0' is never true
  [6] DRM: bug: RADEON_DEBUGFS_MAX_{NUM_FILES => COMPONENTS}
  [7] DRM: cleanup: Remove unsused `tmp'

Here is the overall difference:

 drivers/gpu/drm/drm_crtc_helper.c   |2 +-
 drivers/gpu/drm/drm_fb_helper.c |3 ---
 drivers/gpu/drm/drm_irq.c   |4 ++--
 drivers/gpu/drm/drm_proc.c  |2 +-
 drivers/gpu/drm/radeon/radeon.h |2 +-
 drivers/gpu/drm/radeon/radeon_bios.c|2 +-
 drivers/gpu/drm/radeon/radeon_combios.c |2 +-
 drivers/gpu/drm/radeon/radeon_device.c  |   13 -
 8 files changed, 15 insertions(+), 15 deletions(-)

Sincerely,
Michael Witten

-- 
1.7.6.409.ge7a85

[PATCH 7/7] DRM: cleanup: Remove unsused `tmp'

[Michael Witten]

Date: Wed, 21 Sep 2011 02:10:43 +

Signed-off-by: Michael Witten 
---
 drivers/gpu/drm/radeon/radeon_combios.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
b/drivers/gpu/drm/radeon/radeon_combios.c
index 6367524..b0549aa 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -1227,7 +1227,7 @@ struct radeon_encoder_lvds 
*radeon_combios_get_lvds_info(struct radeon_encoder
uint16_t lcd_info;
uint32_t panel_setup;
char stmp[30];
-   int tmp, i;
+   int i;
struct radeon_encoder_lvds *lvds = NULL;

lcd_info = combios_get_table_offset(dev, COMBIOS_LCD_INFO_TABLE);
-- 
1.7.6.409.ge7a85

[PATCH 4/7] DRM: comment: gdm_proc_lists -> drm_proc_lists

[Michael Witten]

Date: Thu, 15 Sep 2011 14:43:00 +

Signed-off-by: Michael Witten 
---
 drivers/gpu/drm/drm_proc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
index 9e5b07e..13df242 100644
--- a/drivers/gpu/drm/drm_proc.c
+++ b/drivers/gpu/drm/drm_proc.c
@@ -87,7 +87,7 @@ static const struct file_operations drm_proc_fops = {
  * \return Zero on success, non-zero on failure
  *
  * Create a given set of proc files represented by an array of
- * gdm_proc_lists in the given root directory.
+ * drm_proc_lists in the given root directory.
  */
 int drm_proc_create_files(struct drm_info_list *files, int count,
  struct proc_dir_entry *root, struct drm_minor *minor)
-- 
1.7.6.409.ge7a85

[PATCH 5/7] DRM: cleanup: `size == 0' is never true

[Michael Witten]

Date: Fri, 16 Sep 2011 20:09:22 +

Signed-off-by: Michael Witten 
---
 drivers/gpu/drm/radeon/radeon_bios.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_bios.c 
b/drivers/gpu/drm/radeon/radeon_bios.c
index 229a20f..af62082 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -59,7 +59,7 @@ static bool igp_read_bios_from_vram(struct radeon_device 
*rdev)
return false;
}

-   if (size == 0 || bios[0] != 0x55 || bios[1] != 0xaa) {
+   if (bios[0] != 0x55 || bios[1] != 0xaa) {
iounmap(bios);
return false;
}
-- 
1.7.6.409.ge7a85

[PATCH 6/7] DRM: bug: RADEON_DEBUGFS_MAX_{NUM_FILES => COMPONENTS}

[Michael Witten]

Date: Fri, 16 Sep 2011 20:45:30 +

The value of RADEON_DEBUGFS_MAX_NUM_FILES has been used to
specify the size of an array, each element of which looks
like this:

  struct radeon_debugfs {
  struct drm_info_list*files;
  unsignednum_files;
  };

Consequently, the number of debugfs files may be much greater
than RADEON_DEBUGFS_MAX_NUM_FILES, something that the current
code ignores:

  if ((_radeon_debugfs_count + nfiles) > RADEON_DEBUGFS_MAX_NUM_FILES) {
  DRM_ERROR("Reached maximum number of debugfs files.\n");
  DRM_ERROR("Report so we increase RADEON_DEBUGFS_MAX_NUM_FILES.\n");
  return -EINVAL;
  }

This commit fixes this make, and accordingly renames:

  RADEON_DEBUGFS_MAX_NUM_FILES

to:

  RADEON_DEBUGFS_MAX_COMPONENTS

Signed-off-by: Michael Witten 
---
 drivers/gpu/drm/radeon/radeon.h|2 +-
 drivers/gpu/drm/radeon/radeon_device.c |   13 -
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index c1e056b..dd7bab9 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -102,7 +102,7 @@ extern int radeon_pcie_gen2;
 #define RADEON_FENCE_JIFFIES_TIMEOUT   (HZ / 2)
 /* RADEON_IB_POOL_SIZE must be a power of 2 */
 #define RADEON_IB_POOL_SIZE16
-#define RADEON_DEBUGFS_MAX_NUM_FILES   32
+#define RADEON_DEBUGFS_MAX_COMPONENTS  32
 #define RADEONFB_CONN_LIMIT4
 #define RADEON_BIOS_NUM_SCRATCH8

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index b51e157..31b1f4b 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -981,7 +981,7 @@ struct radeon_debugfs {
struct drm_info_list*files;
unsignednum_files;
 };
-static struct radeon_debugfs _radeon_debugfs[RADEON_DEBUGFS_MAX_NUM_FILES];
+static struct radeon_debugfs _radeon_debugfs[RADEON_DEBUGFS_MAX_COMPONENTS];
 static unsigned _radeon_debugfs_count = 0;

 int radeon_debugfs_add_files(struct radeon_device *rdev,
@@ -996,14 +996,17 @@ int radeon_debugfs_add_files(struct radeon_device *rdev,
return 0;
}
}
-   if ((_radeon_debugfs_count + nfiles) > RADEON_DEBUGFS_MAX_NUM_FILES) {
-   DRM_ERROR("Reached maximum number of debugfs files.\n");
-   DRM_ERROR("Report so we increase 
RADEON_DEBUGFS_MAX_NUM_FILES.\n");
+
+   i = _radeon_debugfs_count + 1;
+   if (i > RADEON_DEBUGFS_MAX_COMPONENTS) {
+   DRM_ERROR("Reached maximum number of debugfs components.\n");
+   DRM_ERROR("Report so we increase "
+ "RADEON_DEBUGFS_MAX_COMPONENTS.\n");
return -EINVAL;
}
_radeon_debugfs[_radeon_debugfs_count].files = files;
_radeon_debugfs[_radeon_debugfs_count].num_files = nfiles;
-   _radeon_debugfs_count++;
+   _radeon_debugfs_count = i;
 #if defined(CONFIG_DEBUG_FS)
drm_debugfs_create_files(files, nfiles,
 rdev->ddev->control->debugfs_root,
-- 
1.7.6.409.ge7a85

[PATCH 3/7] DRM: cleanup: Remove unused `gamma_size'

[Michael Witten]

Date: Thu, 15 Sep 2011 21:12:19 +

Signed-off-by: Michael Witten 
---
 drivers/gpu/drm/drm_fb_helper.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f7c6854..9a9107a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -760,7 +760,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper 
*fb_helper,
int i;
struct fb_info *info;
struct drm_fb_helper_surface_size sizes;
-   int gamma_size = 0;

memset(, 0, sizeof(struct drm_fb_helper_surface_size));
sizes.surface_depth = 24;
@@ -810,8 +809,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper 
*fb_helper,
desired_mode = fb_helper->crtc_info[i].desired_mode;

if (desired_mode) {
-   if (gamma_size == 0)
-   gamma_size = 
fb_helper->crtc_info[i].mode_set.crtc->gamma_size;
if (desired_mode->hdisplay < sizes.fb_width)
sizes.fb_width = desired_mode->hdisplay;
if (desired_mode->vdisplay < sizes.fb_height)
-- 
1.7.6.409.ge7a85

[PATCH 2/7] DRM: comment: halve -> half

[Michael Witten]

Date: Thu, 15 Sep 2011 21:07:26 +

Signed-off-by: Michael Witten 
---
 drivers/gpu/drm/drm_irq.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 3830e9e..61cb85d 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -493,8 +493,8 @@ void drm_calc_timestamping_constants(struct drm_crtc *crtc)
/* Dot clock in Hz: */
dotclock = (u64) crtc->hwmode.clock * 1000;

-   /* Fields of interlaced scanout modes are only halve a frame duration.
-* Double the dotclock to get halve the frame-/line-/pixelduration.
+   /* Fields of interlaced scanout modes are only half a frame duration.
+* Double the dotclock to get half the frame-/line-/pixelduration.
 */
if (crtc->hwmode.flags & DRM_MODE_FLAG_INTERLACE)
dotclock *= 2;
-- 
1.7.6.409.ge7a85

[PATCH 1/7] DRM: comment: drm_crtc{=>_helper}_set_mode

[Michael Witten]

Date: Thu, 15 Sep 2011 21:06:24 +

Signed-off-by: Michael Witten 
---
 drivers/gpu/drm/drm_crtc_helper.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index f88a9b2..8ec3447 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -303,19 +303,19 @@ drm_crtc_prepare_encoders(struct drm_device *dev)
 }

 /**
- * drm_crtc_set_mode - set a mode
+ * drm_crtc_helper_set_mode - set a mode
  * @crtc: CRTC to program
  * @mode: mode to use
  * @x: width of mode
  * @y: height of mode
  *
  * LOCKING:
  * Caller must hold mode config lock.
  *
  * Try to set @mode on @crtc.  Give @crtc and its associated connectors a 
chance
  * to fixup or reject the mode prior to trying to set it.
  *
  * RETURNS:
  * True if the mode was set successfully, or false otherwise.
  */
 bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
-- 
1.7.6.409.ge7a85

Curious experiences with a Radeon on the fritz

[Michael Witten]

On Mon, 12 Sep 2011 18:13:46 -, Michael Witten wrote:

> I hope you find this adventure interesting, and I hope you
> provide me with some insight.
>
> Recently, I booted my computer, a Dell Latitude D810 that has a
> Radeon Mobility x600 (R300); all systems were waking up as normal:
>
>   * The Dell logo popped up in some ancient VGA mode.
>   * The GRUB menu appeared for 3 seconds as instructed.
>   * Linux loaded and started spewing out log messages.
>
> and then:
>
> BAM!
>
> At around:
>
>   2011-09-09 20:27:07 +
>
> the Darkness overcame me; my laptop's LCD panel went black with nary
> a sign of life. After poking around a bit via ssh, I couldn't figure
> out what was going on; I had been running all the relevant code
> without trouble for some time now, so it just didn't make sense, and
> I began suspecting hardware failure.
>
> I strolled on over to freenode/#radeon, where I explained that I was
> still getting graphics at early boot time, but that it was dying
> shortly after Linux loaded. A one named Tari suggested that I boot
> with `nomodeset' in order to avoid anything more complicated than
> the standards of the Ancients.
>
> And Lo! With that very kernel command line parameter, the boot
> process did indeed land me safely in a working, albeit cramped
> VGA-backed virtual console.
>
> Searching the logs a bit more revealed the following:
>
>   [drm:drm_calc_timestamping_constants] *ERROR* crtc 10: Can't
>   calculate constants, dotclock = 0!
>
> Then (skipping a few interesting adventures), I ultimately discovered
> this kernel message:
>
>   [drm] Panel Size 1920x4095
>
> which is curious indeed!, because my laptop's panel size should be
> `1920x1200'. I booted into the computer's BIOS only to find that
> it too was being fooled into thinking that the display dimensions
> are `1920x4095'.
>
> Why might this have happened? Are bits stuck? Did something get fried?
>
> Naturally, I set off to hardcode the right values into the DRM/KMS
> Radeon driver, and after overturning stones, scraping away ivy,
> digging tunnels, and wading through forgotten moats, I managed to
> make my way to the beginning of that labyrinthine beast, where I
> could successfully exert my will:
>
>   diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
> b/drivers/gpu/drm/radeon/radeon_combios.c
>   index 6367524..9119dd6 100644
>   --- a/drivers/gpu/drm/radeon/radeon_combios.c
>   +++ b/drivers/gpu/drm/radeon/radeon_combios.c
>   @@ -1245,7 +1245,7 @@ struct radeon_encoder_lvds 
> *radeon_combios_get_lvds_info(struct radeon_encoder
>   DRM_INFO("Panel ID String: %s\n", stmp);
>
>   lvds->native_mode.hdisplay = RBIOS16(lcd_info + 0x19);
>   -   lvds->native_mode.vdisplay = RBIOS16(lcd_info + 0x1b);
>   +   lvds->native_mode.vdisplay = 1200; /*RBIOS16(lcd_info + 0x1b);*/
>
>   DRM_INFO("Panel Size %dx%d\n", lvds->native_mode.hdisplay,
>lvds->native_mode.vdisplay);
>
> With that small change, the driver in question loaded none the wiser,
> yielding a KMS-driven frame-buffer-backed virtual console as desired:
>
>   [drm] radeon defaulting to kernel modesetting.
>   [drm] radeon kernel modesetting enabled.
>   ...
>   [drm] Panel Size 1920x1200
>   ...
>   [drm] fb depth is 24
>   [drm]pitch is 7680
>   fbcon: radeondrmfb (fb0) is primary device
>   Console: switching to colour frame buffer device 240x75
>   fb0: radeondrmfb frame buffer device
>
> Unfortunately, X marks the spot where things get hairy again.
>
> Most noticeably, when I run:
>
>   startx
>
> I get an Xorg.log that looks unblemished, yet X clearly renders the
> screen based on an erroneous DPI. In fact, even though Xorg.log
> clearly shows:
>
>   (**) RADEON(0): Display dimensions: (331, 207) mm
>   (**) RADEON(0): DPI set to (147, 147)
>
> I end up getting the following from xdpyinfo:
>
>   dimensions:1920x1200 pixels (507x317 millimeters)
>   resolution:96x96 dots per inch
>
> Why is this the case?
>
> Fortunately, I can solve the DPI issue by specifying the desired
> value directly on the command line:
>
>   startx -- -dpi 147
>
> Why does this work when xorg.conf does not? (especially given that
> xorg.conf alone used to be enough to achieve the desired effect).
>
> Unfortunately, the troubles do not end there. Rudimentary benchmarking
> (playing 720p H.264 videos, running glxgears, etc.) indicates by low
> CPU usage that hardware acceleration is indeed enabled, which is in
> agreement with all the logs and diagnostics:
>
>   Linux:
>
> [drm

Re: Curious experiences with a Radeon on the fritz

[Michael Witten]

On Mon, 12 Sep 2011 18:13:46 -, Michael Witten wrote:

 I hope you find this adventure interesting, and I hope you
 provide me with some insight.

 Recently, I booted my computer, a Dell Latitude D810 that has a
 Radeon Mobility x600 (R300); all systems were waking up as normal:

   * The Dell logo popped up in some ancient VGA mode.
   * The GRUB menu appeared for 3 seconds as instructed.
   * Linux loaded and started spewing out log messages.

 and then:

 BAM!

 At around:

   2011-09-09 20:27:07 +

 the Darkness overcame me; my laptop's LCD panel went black with nary
 a sign of life. After poking around a bit via ssh, I couldn't figure
 out what was going on; I had been running all the relevant code
 without trouble for some time now, so it just didn't make sense, and
 I began suspecting hardware failure.

 I strolled on over to freenode/#radeon, where I explained that I was
 still getting graphics at early boot time, but that it was dying
 shortly after Linux loaded. A one named Tari suggested that I boot
 with `nomodeset' in order to avoid anything more complicated than
 the standards of the Ancients.

 And Lo! With that very kernel command line parameter, the boot
 process did indeed land me safely in a working, albeit cramped
 VGA-backed virtual console.

 Searching the logs a bit more revealed the following:

   [drm:drm_calc_timestamping_constants] *ERROR* crtc 10: Can't
   calculate constants, dotclock = 0!

 Then (skipping a few interesting adventures), I ultimately discovered
 this kernel message:

   [drm] Panel Size 1920x4095

 which is curious indeed!, because my laptop's panel size should be
 `1920x1200'. I booted into the computer's BIOS only to find that
 it too was being fooled into thinking that the display dimensions
 are `1920x4095'.

 Why might this have happened? Are bits stuck? Did something get fried?

 Naturally, I set off to hardcode the right values into the DRM/KMS
 Radeon driver, and after overturning stones, scraping away ivy,
 digging tunnels, and wading through forgotten moats, I managed to
 make my way to the beginning of that labyrinthine beast, where I
 could successfully exert my will:

   diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
 b/drivers/gpu/drm/radeon/radeon_combios.c
   index 6367524..9119dd6 100644
   --- a/drivers/gpu/drm/radeon/radeon_combios.c
   +++ b/drivers/gpu/drm/radeon/radeon_combios.c
   @@ -1245,7 +1245,7 @@ struct radeon_encoder_lvds 
 *radeon_combios_get_lvds_info(struct radeon_encoder
   DRM_INFO(Panel ID String: %s\n, stmp);

   lvds-native_mode.hdisplay = RBIOS16(lcd_info + 0x19);
   -   lvds-native_mode.vdisplay = RBIOS16(lcd_info + 0x1b);
   +   lvds-native_mode.vdisplay = 1200; /*RBIOS16(lcd_info + 0x1b);*/

   DRM_INFO(Panel Size %dx%d\n, lvds-native_mode.hdisplay,
lvds-native_mode.vdisplay);

 With that small change, the driver in question loaded none the wiser,
 yielding a KMS-driven frame-buffer-backed virtual console as desired:

   [drm] radeon defaulting to kernel modesetting.
   [drm] radeon kernel modesetting enabled.
   ...
   [drm] Panel Size 1920x1200
   ...
   [drm] fb depth is 24
   [drm]pitch is 7680
   fbcon: radeondrmfb (fb0) is primary device
   Console: switching to colour frame buffer device 240x75
   fb0: radeondrmfb frame buffer device

 Unfortunately, X marks the spot where things get hairy again.

 Most noticeably, when I run:

   startx

 I get an Xorg.log that looks unblemished, yet X clearly renders the
 screen based on an erroneous DPI. In fact, even though Xorg.log
 clearly shows:

   (**) RADEON(0): Display dimensions: (331, 207) mm
   (**) RADEON(0): DPI set to (147, 147)

 I end up getting the following from xdpyinfo:

   dimensions:1920x1200 pixels (507x317 millimeters)
   resolution:96x96 dots per inch

 Why is this the case?

 Fortunately, I can solve the DPI issue by specifying the desired
 value directly on the command line:

   startx -- -dpi 147

 Why does this work when xorg.conf does not? (especially given that
 xorg.conf alone used to be enough to achieve the desired effect).

 Unfortunately, the troubles do not end there. Rudimentary benchmarking
 (playing 720p H.264 videos, running glxgears, etc.) indicates by low
 CPU usage that hardware acceleration is indeed enabled, which is in
 agreement with all the logs and diagnostics:

   Linux:

 [drm] radeon: 128M of VRAM memory ready
 [drm] radeon: 512M of GTT memory ready.
 ...
 [drm] radeon: 1 quad pipes, 1 Z pipes initialized.
 [drm] PCIE GART of 512M enabled (table at 0xD004).

   Xorg:

 (II) [KMS] Kernel modesetting enabled.
 ...
 (==) RADEON(0): Depth 24, (--) framebuffer bpp 32
 (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
 (==) RADEON(0): Default visual is TrueColor
 (==) RADEON(0): RGB weight 888
 (II) RADEON(0): Using 8 bits per RGB (8 bit DAC

[PATCH 0/7] DRM/Radeon Cleanup

[Michael Witten]

Whilst working on my failing Radeon GPU:

  Subject: Re: Curious experiences with a Radeon on the fritz
  Date: Wed, 21 Sep 2011 18:52:19 -
  Message-ID: c0efd8527ff34853a23f1d706be29c67-mfwit...@gmail.com
  http://lists.freedesktop.org/archives/dri-devel/2011-September/014506.html

I made the following trivial improvements to the DRM/Radeon code
along the way ([6] fixes a bug):

  [1] DRM: comment: drm_crtc{=_helper}_set_mode
  [2] DRM: comment: halve - half
  [3] DRM: cleanup: Remove unused `gamma_size'
  [4] DRM: comment: gdm_proc_lists - drm_proc_lists
  [5] DRM: cleanup: `size == 0' is never true
  [6] DRM: bug: RADEON_DEBUGFS_MAX_{NUM_FILES = COMPONENTS}
  [7] DRM: cleanup: Remove unsused `tmp'

Here is the overall difference:

 drivers/gpu/drm/drm_crtc_helper.c   |2 +-
 drivers/gpu/drm/drm_fb_helper.c |3 ---
 drivers/gpu/drm/drm_irq.c   |4 ++--
 drivers/gpu/drm/drm_proc.c  |2 +-
 drivers/gpu/drm/radeon/radeon.h |2 +-
 drivers/gpu/drm/radeon/radeon_bios.c|2 +-
 drivers/gpu/drm/radeon/radeon_combios.c |2 +-
 drivers/gpu/drm/radeon/radeon_device.c  |   13 -
 8 files changed, 15 insertions(+), 15 deletions(-)

Sincerely,
Michael Witten

-- 
1.7.6.409.ge7a85

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

[PATCH 1/7] DRM: comment: drm_crtc{=_helper}_set_mode

[Michael Witten]

Date: Thu, 15 Sep 2011 21:06:24 +

Signed-off-by: Michael Witten mfwit...@gmail.com
---
 drivers/gpu/drm/drm_crtc_helper.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index f88a9b2..8ec3447 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -303,19 +303,19 @@ drm_crtc_prepare_encoders(struct drm_device *dev)
 }
 
 /**
- * drm_crtc_set_mode - set a mode
+ * drm_crtc_helper_set_mode - set a mode
  * @crtc: CRTC to program
  * @mode: mode to use
  * @x: width of mode
  * @y: height of mode
  *
  * LOCKING:
  * Caller must hold mode config lock.
  *
  * Try to set @mode on @crtc.  Give @crtc and its associated connectors a 
chance
  * to fixup or reject the mode prior to trying to set it.
  *
  * RETURNS:
  * True if the mode was set successfully, or false otherwise.
  */
 bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
-- 
1.7.6.409.ge7a85

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

[PATCH 2/7] DRM: comment: halve - half

[Michael Witten]

Date: Thu, 15 Sep 2011 21:07:26 +

Signed-off-by: Michael Witten mfwit...@gmail.com
---
 drivers/gpu/drm/drm_irq.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 3830e9e..61cb85d 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -493,8 +493,8 @@ void drm_calc_timestamping_constants(struct drm_crtc *crtc)
/* Dot clock in Hz: */
dotclock = (u64) crtc-hwmode.clock * 1000;
 
-   /* Fields of interlaced scanout modes are only halve a frame duration.
-* Double the dotclock to get halve the frame-/line-/pixelduration.
+   /* Fields of interlaced scanout modes are only half a frame duration.
+* Double the dotclock to get half the frame-/line-/pixelduration.
 */
if (crtc-hwmode.flags  DRM_MODE_FLAG_INTERLACE)
dotclock *= 2;
-- 
1.7.6.409.ge7a85

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

[PATCH 3/7] DRM: cleanup: Remove unused `gamma_size'

[Michael Witten]

Date: Thu, 15 Sep 2011 21:12:19 +

Signed-off-by: Michael Witten mfwit...@gmail.com
---
 drivers/gpu/drm/drm_fb_helper.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f7c6854..9a9107a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -760,7 +760,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper 
*fb_helper,
int i;
struct fb_info *info;
struct drm_fb_helper_surface_size sizes;
-   int gamma_size = 0;
 
memset(sizes, 0, sizeof(struct drm_fb_helper_surface_size));
sizes.surface_depth = 24;
@@ -810,8 +809,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper 
*fb_helper,
desired_mode = fb_helper-crtc_info[i].desired_mode;
 
if (desired_mode) {
-   if (gamma_size == 0)
-   gamma_size = 
fb_helper-crtc_info[i].mode_set.crtc-gamma_size;
if (desired_mode-hdisplay  sizes.fb_width)
sizes.fb_width = desired_mode-hdisplay;
if (desired_mode-vdisplay  sizes.fb_height)
-- 
1.7.6.409.ge7a85

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

[PATCH 4/7] DRM: comment: gdm_proc_lists - drm_proc_lists

[Michael Witten]

Date: Thu, 15 Sep 2011 14:43:00 +

Signed-off-by: Michael Witten mfwit...@gmail.com
---
 drivers/gpu/drm/drm_proc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
index 9e5b07e..13df242 100644
--- a/drivers/gpu/drm/drm_proc.c
+++ b/drivers/gpu/drm/drm_proc.c
@@ -87,7 +87,7 @@ static const struct file_operations drm_proc_fops = {
  * \return Zero on success, non-zero on failure
  *
  * Create a given set of proc files represented by an array of
- * gdm_proc_lists in the given root directory.
+ * drm_proc_lists in the given root directory.
  */
 int drm_proc_create_files(struct drm_info_list *files, int count,
  struct proc_dir_entry *root, struct drm_minor *minor)
-- 
1.7.6.409.ge7a85

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

[PATCH 5/7] DRM: cleanup: `size == 0' is never true

[Michael Witten]

Date: Fri, 16 Sep 2011 20:09:22 +

Signed-off-by: Michael Witten mfwit...@gmail.com
---
 drivers/gpu/drm/radeon/radeon_bios.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_bios.c 
b/drivers/gpu/drm/radeon/radeon_bios.c
index 229a20f..af62082 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -59,7 +59,7 @@ static bool igp_read_bios_from_vram(struct radeon_device 
*rdev)
return false;
}
 
-   if (size == 0 || bios[0] != 0x55 || bios[1] != 0xaa) {
+   if (bios[0] != 0x55 || bios[1] != 0xaa) {
iounmap(bios);
return false;
}
-- 
1.7.6.409.ge7a85

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

[PATCH 6/7] DRM: bug: RADEON_DEBUGFS_MAX_{NUM_FILES = COMPONENTS}

[Michael Witten]

Date: Fri, 16 Sep 2011 20:45:30 +

The value of RADEON_DEBUGFS_MAX_NUM_FILES has been used to
specify the size of an array, each element of which looks
like this:

  struct radeon_debugfs {
  struct drm_info_list*files;
  unsignednum_files;
  };

Consequently, the number of debugfs files may be much greater
than RADEON_DEBUGFS_MAX_NUM_FILES, something that the current
code ignores:

  if ((_radeon_debugfs_count + nfiles)  RADEON_DEBUGFS_MAX_NUM_FILES) {
  DRM_ERROR(Reached maximum number of debugfs files.\n);
  DRM_ERROR(Report so we increase RADEON_DEBUGFS_MAX_NUM_FILES.\n);
  return -EINVAL;
  }

This commit fixes this make, and accordingly renames:

  RADEON_DEBUGFS_MAX_NUM_FILES

to:

  RADEON_DEBUGFS_MAX_COMPONENTS

Signed-off-by: Michael Witten mfwit...@gmail.com
---
 drivers/gpu/drm/radeon/radeon.h|2 +-
 drivers/gpu/drm/radeon/radeon_device.c |   13 -
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index c1e056b..dd7bab9 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -102,7 +102,7 @@ extern int radeon_pcie_gen2;
 #define RADEON_FENCE_JIFFIES_TIMEOUT   (HZ / 2)
 /* RADEON_IB_POOL_SIZE must be a power of 2 */
 #define RADEON_IB_POOL_SIZE16
-#define RADEON_DEBUGFS_MAX_NUM_FILES   32
+#define RADEON_DEBUGFS_MAX_COMPONENTS  32
 #define RADEONFB_CONN_LIMIT4
 #define RADEON_BIOS_NUM_SCRATCH8
 
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index b51e157..31b1f4b 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -981,7 +981,7 @@ struct radeon_debugfs {
struct drm_info_list*files;
unsignednum_files;
 };
-static struct radeon_debugfs _radeon_debugfs[RADEON_DEBUGFS_MAX_NUM_FILES];
+static struct radeon_debugfs _radeon_debugfs[RADEON_DEBUGFS_MAX_COMPONENTS];
 static unsigned _radeon_debugfs_count = 0;
 
 int radeon_debugfs_add_files(struct radeon_device *rdev,
@@ -996,14 +996,17 @@ int radeon_debugfs_add_files(struct radeon_device *rdev,
return 0;
}
}
-   if ((_radeon_debugfs_count + nfiles)  RADEON_DEBUGFS_MAX_NUM_FILES) {
-   DRM_ERROR(Reached maximum number of debugfs files.\n);
-   DRM_ERROR(Report so we increase 
RADEON_DEBUGFS_MAX_NUM_FILES.\n);
+
+   i = _radeon_debugfs_count + 1;
+   if (i  RADEON_DEBUGFS_MAX_COMPONENTS) {
+   DRM_ERROR(Reached maximum number of debugfs components.\n);
+   DRM_ERROR(Report so we increase 
+ RADEON_DEBUGFS_MAX_COMPONENTS.\n);
return -EINVAL;
}
_radeon_debugfs[_radeon_debugfs_count].files = files;
_radeon_debugfs[_radeon_debugfs_count].num_files = nfiles;
-   _radeon_debugfs_count++;
+   _radeon_debugfs_count = i;
 #if defined(CONFIG_DEBUG_FS)
drm_debugfs_create_files(files, nfiles,
 rdev-ddev-control-debugfs_root,
-- 
1.7.6.409.ge7a85

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

[PATCH 7/7] DRM: cleanup: Remove unsused `tmp'

[Michael Witten]

Date: Wed, 21 Sep 2011 02:10:43 +

Signed-off-by: Michael Witten mfwit...@gmail.com
---
 drivers/gpu/drm/radeon/radeon_combios.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
b/drivers/gpu/drm/radeon/radeon_combios.c
index 6367524..b0549aa 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -1227,7 +1227,7 @@ struct radeon_encoder_lvds 
*radeon_combios_get_lvds_info(struct radeon_encoder
uint16_t lcd_info;
uint32_t panel_setup;
char stmp[30];
-   int tmp, i;
+   int i;
struct radeon_encoder_lvds *lvds = NULL;
 
lcd_info = combios_get_table_offset(dev, COMBIOS_LCD_INFO_TABLE);
-- 
1.7.6.409.ge7a85

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

Curious experiences with a Radeon on the fritz

[Michael Witten]

On Thu, Sep 15, 2011 at 22:25, Alex Deucher  wrote:
> On Mon, Sep 12, 2011 at 2:13 PM, Michael Witten  wrote:
>> I hope you find this adventure interesting, and I hope you
>> provide me with some insight.
>>
>> Recently, I booted my computer, a Dell Latitude D810 that has a
>> Radeon Mobility x600 (R300); all systems were waking up as normal:
>>
>>  * The Dell logo popped up in some ancient VGA mode.
>>  * The GRUB menu appeared for 3 seconds as instructed.
>>  * Linux loaded and started spewing out log messages.
>>
>> and then:
>>
>>BAM!
>>
>> At around:
>>
>>  2011-09-09 20:27:07 +
>>
>> the Darkness overcame me; my laptop's LCD panel went black with nary
>> a sign of life. After poking around a bit via ssh, I couldn't figure
>> out what was going on; I had been running all the relevant code
>> without trouble for some time now, so it just didn't make sense, and
>> I began suspecting hardware failure.
>>
>> I strolled on over to freenode/#radeon, where I explained that I was
>> still getting graphics at early boot time, but that it was dying
>> shortly after Linux loaded. A one named Tari suggested that I boot
>> with `nomodeset' in order to avoid anything more complicated than
>> the standards of the Ancients.
>>
>> And Lo! With that very kernel command line parameter, the boot
>> process did indeed land me safely in a working, albeit cramped
>> VGA-backed virtual console.
>>
>> Searching the logs a bit more revealed the following:
>>
>>  [drm:drm_calc_timestamping_constants] *ERROR* crtc 10: Can't
>>  calculate constants, dotclock = 0!
>>
>> Then (skipping a few interesting adventures), I ultimately discovered
>> this kernel message:
>>
>>  [drm] Panel Size 1920x4095
>>
>> which is curious indeed!, because my laptop's panel size should be
>> `1920x1200'. I booted into the computer's BIOS only to find that
>> it too was being fooled into thinking that the display dimensions
>> are `1920x4095'.
>>
>> Why might this have happened? Are bits stuck? Did something get fried?
>
> Looks like your bios got corrupted somehow.  All of the vertical
> timing in your panel modeline is bogus.  You'll need to patch up all
> the vertical timing values the same way you patched up the vdisplay in
> radeon_combios.c.  You'll have to try and find the native mode timing
> for your panel.  Note that other data that the driver uses from the
> vbios may also be corrupt.
>
> The xserver defaults to 96dpi because there are too many broken EDIDs
> out there and no good way to deal with different DPIs across different
> monitors in multi-head desktops.  Also, a lot of users expect 96 dpi
> and file bugs when it's something else.

Thanks for the reply.

I did indeed end up hardcoding modeline values in that same function,
which basically solved the problem for the time being; I plan[ned] on
posting a follow-up email sometime soon (including my attempts to
thwart future corruption).

Thanks again.

Re: Curious experiences with a Radeon on the fritz

[Michael Witten]

On Thu, Sep 15, 2011 at 22:25, Alex Deucher alexdeuc...@gmail.com wrote:
 On Mon, Sep 12, 2011 at 2:13 PM, Michael Witten mfwit...@gmail.com wrote:
 I hope you find this adventure interesting, and I hope you
 provide me with some insight.

 Recently, I booted my computer, a Dell Latitude D810 that has a
 Radeon Mobility x600 (R300); all systems were waking up as normal:

  * The Dell logo popped up in some ancient VGA mode.
  * The GRUB menu appeared for 3 seconds as instructed.
  * Linux loaded and started spewing out log messages.

 and then:

BAM!

 At around:

  2011-09-09 20:27:07 +

 the Darkness overcame me; my laptop's LCD panel went black with nary
 a sign of life. After poking around a bit via ssh, I couldn't figure
 out what was going on; I had been running all the relevant code
 without trouble for some time now, so it just didn't make sense, and
 I began suspecting hardware failure.

 I strolled on over to freenode/#radeon, where I explained that I was
 still getting graphics at early boot time, but that it was dying
 shortly after Linux loaded. A one named Tari suggested that I boot
 with `nomodeset' in order to avoid anything more complicated than
 the standards of the Ancients.

 And Lo! With that very kernel command line parameter, the boot
 process did indeed land me safely in a working, albeit cramped
 VGA-backed virtual console.

 Searching the logs a bit more revealed the following:

  [drm:drm_calc_timestamping_constants] *ERROR* crtc 10: Can't
  calculate constants, dotclock = 0!

 Then (skipping a few interesting adventures), I ultimately discovered
 this kernel message:

  [drm] Panel Size 1920x4095

 which is curious indeed!, because my laptop's panel size should be
 `1920x1200'. I booted into the computer's BIOS only to find that
 it too was being fooled into thinking that the display dimensions
 are `1920x4095'.

 Why might this have happened? Are bits stuck? Did something get fried?

 Looks like your bios got corrupted somehow.  All of the vertical
 timing in your panel modeline is bogus.  You'll need to patch up all
 the vertical timing values the same way you patched up the vdisplay in
 radeon_combios.c.  You'll have to try and find the native mode timing
 for your panel.  Note that other data that the driver uses from the
 vbios may also be corrupt.

 The xserver defaults to 96dpi because there are too many broken EDIDs
 out there and no good way to deal with different DPIs across different
 monitors in multi-head desktops.  Also, a lot of users expect 96 dpi
 and file bugs when it's something else.

Thanks for the reply.

I did indeed end up hardcoding modeline values in that same function,
which basically solved the problem for the time being; I plan[ned] on
posting a follow-up email sometime soon (including my attempts to
thwart future corruption).

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

Curious experiences with a Radeon on the fritz

[Michael Witten]

9 831 -hsync +vsync (49.7 kHz)
(II) RADEON(0): Modeline "1280x720"x59.9   74.50  1280 1344 1472 1664  720 
723 728 748 -hsync +vsync (44.8 kHz)
(II) RADEON(0): Modeline "1152x768"x59.8   71.75  1152 1216 1328 1504  768 
771 781 798 -hsync +vsync (47.7 kHz)
(II) RADEON(0): Modeline "1024x768"x59.9   63.50  1024 1072 1176 1328  768 
771 775 798 -hsync +vsync (47.8 kHz)
(II) RADEON(0): Modeline "800x600"x59.9   38.25  800 832 912 1024  600 603 
607 624 -hsync +vsync (37.4 kHz)
(II) RADEON(0): Modeline "848x480"x59.7   31.50  848 872 952 1056  480 483 
493 500 -hsync +vsync (29.8 kHz)
(II) RADEON(0): Modeline "720x480"x59.7   26.75  720 744 808 896  480 483 
493 500 -hsync +vsync (29.9 kHz)
(II) RADEON(0): Modeline "640x480"x59.4   23.75  640 664 720 800  480 483 
487 500 -hsync +vsync (29.7 kHz)
...
(II) RADEON(0): Output LVDS using initial mode 1920x1200

  xrandr:

1920x1200 (0x55)  162.0MHz +preferred
  h: width  1920 start 2016 end 2072 total 2160 skew0 clock   
75.0KHz
  v: height 1200 start 49753 end 49756 total 7985   clock
9.4Hz
1920x1080 (0x56)  173.0MHz -HSync +VSync
  h: width  1920 start 2048 end 2248 total 2576 skew0 clock   
67.2KHz
  v: height 1080 start 1083 end 1088 total 1120   clock   60.0Hz
1600x1200 (0x57)  161.0MHz -HSync +VSync
  h: width  1600 start 1712 end 1880 total 2160 skew0 clock   
74.5KHz
  v: height 1200 start 1203 end 1207 total 1245   clock   59.9Hz
1680x1050 (0x58)  146.2MHz -HSync +VSync
  h: width  1680 start 1784 end 1960 total 2240 skew0 clock   
65.3KHz
  v: height 1050 start 1053 end 1059 total 1089   clock   60.0Hz
1400x1050 (0x59)  121.8MHz -HSync +VSync
  h: width  1400 start 1488 end 1632 total 1864 skew0 clock   
65.3KHz
  v: height 1050 start 1053 end 1057 total 1089   clock   60.0Hz
1280x1024 (0x5a)  109.0MHz -HSync +VSync
  h: width  1280 start 1368 end 1496 total 1712 skew0 clock   
63.7KHz
  v: height 1024 start 1027 end 1034 total 1063   clock   59.9Hz
1440x900 (0x5b)  106.5MHz -HSync +VSync
  h: width  1440 start 1528 end 1672 total 1904 skew0 clock   
55.9KHz
  v: height  900 start  903 end  909 total  934   clock   59.9Hz
1280x960 (0x5c)  101.2MHz -HSync +VSync
  h: width  1280 start 1360 end 1488 total 1696 skew0 clock   
59.7KHz
  v: height  960 start  963 end  967 total  996   clock   59.9Hz
1280x854 (0x5d)   89.2MHz -HSync +VSync
  h: width  1280 start 1352 end 1480 total 1680 skew0 clock   
53.1KHz
  v: height  854 start  857 end  867 total  887   clock   59.9Hz
1280x800 (0x5e)   83.5MHz -HSync +VSync
  h: width  1280 start 1352 end 1480 total 1680 skew0 clock   
49.7KHz
  v: height  800 start  803 end  809 total  831   clock   59.8Hz
1280x720 (0x5f)   74.5MHz -HSync +VSync
  h: width  1280 start 1344 end 1472 total 1664 skew0 clock   
44.8KHz
  v: height  720 start  723 end  728 total  748   clock   59.9Hz
1152x768 (0x60)   71.8MHz -HSync +VSync
  h: width  1152 start 1216 end 1328 total 1504 skew0 clock   
47.7KHz
  v: height  768 start  771 end  781 total  798   clock   59.8Hz
1024x768 (0x61)   63.5MHz -HSync +VSync
  h: width  1024 start 1072 end 1176 total 1328 skew0 clock   
47.8KHz
  v: height  768 start  771 end  775 total  798   clock   59.9Hz
800x600 (0x62)   38.2MHz -HSync +VSync
  h: width   800 start  832 end  912 total 1024 skew0 clock   
37.4KHz
  v: height  600 start  603 end  607 total  624   clock   59.9Hz
848x480 (0x63)   31.5MHz -HSync +VSync
  h: width   848 start  872 end  952 total 1056 skew0 clock   
29.8KHz
  v: height  480 start  483 end  493 total  500   clock   59.7Hz
720x480 (0x64)   26.8MHz -HSync +VSync
  h: width   720 start  744 end  808 total  896 skew0 clock   
29.9KHz
  v: height  480 start  483 end  493 total  500   clock   59.7Hz
640x480 (0x65)   23.8MHz -HSync +VSync
  h: width   640 start  664 end  720 total  800 skew0 clock   
29.7KHz
  v: height  480 start  483 end  487 total  500   clock   59.4Hz

However, switching to one of these other modes or defining my own
through xorg.conf does nothing to fix the troubles; while the
resolution does change, the flickering and striation remain, and
glxgears continues to report the same 19+ FPS.

Is there anything that can be done to work around these last
troubles?

Sincerely,
Michael Witten

P.S.

I'm running i686 Linux 3.1.0-rc5, specifically this commit
(with my patch):

  473e2bc9d3649e072d0a1bff84afa95b072d056b

and:

  X.Org X Server 1.10.3.901 (1.10.4 RC 1)
  Release Date: 2011-07-29
  X Protocol Version 11, Revision 0
  Kernel command line: root=/dev/sda2 ro 3
  Build Date: 08 August 2011  08:28:07AM
  Current version of pixman: 0.22.2

Curious experiences with a Radeon on the fritz

[Michael Witten]

 1152x768x59.8   71.75  1152 1216 1328 1504  768 
771 781 798 -hsync +vsync (47.7 kHz)
(II) RADEON(0): Modeline 1024x768x59.9   63.50  1024 1072 1176 1328  768 
771 775 798 -hsync +vsync (47.8 kHz)
(II) RADEON(0): Modeline 800x600x59.9   38.25  800 832 912 1024  600 603 
607 624 -hsync +vsync (37.4 kHz)
(II) RADEON(0): Modeline 848x480x59.7   31.50  848 872 952 1056  480 483 
493 500 -hsync +vsync (29.8 kHz)
(II) RADEON(0): Modeline 720x480x59.7   26.75  720 744 808 896  480 483 
493 500 -hsync +vsync (29.9 kHz)
(II) RADEON(0): Modeline 640x480x59.4   23.75  640 664 720 800  480 483 
487 500 -hsync +vsync (29.7 kHz)
...
(II) RADEON(0): Output LVDS using initial mode 1920x1200

  xrandr:

1920x1200 (0x55)  162.0MHz +preferred
  h: width  1920 start 2016 end 2072 total 2160 skew0 clock   
75.0KHz
  v: height 1200 start 49753 end 49756 total 7985   clock
9.4Hz
1920x1080 (0x56)  173.0MHz -HSync +VSync
  h: width  1920 start 2048 end 2248 total 2576 skew0 clock   
67.2KHz
  v: height 1080 start 1083 end 1088 total 1120   clock   60.0Hz
1600x1200 (0x57)  161.0MHz -HSync +VSync
  h: width  1600 start 1712 end 1880 total 2160 skew0 clock   
74.5KHz
  v: height 1200 start 1203 end 1207 total 1245   clock   59.9Hz
1680x1050 (0x58)  146.2MHz -HSync +VSync
  h: width  1680 start 1784 end 1960 total 2240 skew0 clock   
65.3KHz
  v: height 1050 start 1053 end 1059 total 1089   clock   60.0Hz
1400x1050 (0x59)  121.8MHz -HSync +VSync
  h: width  1400 start 1488 end 1632 total 1864 skew0 clock   
65.3KHz
  v: height 1050 start 1053 end 1057 total 1089   clock   60.0Hz
1280x1024 (0x5a)  109.0MHz -HSync +VSync
  h: width  1280 start 1368 end 1496 total 1712 skew0 clock   
63.7KHz
  v: height 1024 start 1027 end 1034 total 1063   clock   59.9Hz
1440x900 (0x5b)  106.5MHz -HSync +VSync
  h: width  1440 start 1528 end 1672 total 1904 skew0 clock   
55.9KHz
  v: height  900 start  903 end  909 total  934   clock   59.9Hz
1280x960 (0x5c)  101.2MHz -HSync +VSync
  h: width  1280 start 1360 end 1488 total 1696 skew0 clock   
59.7KHz
  v: height  960 start  963 end  967 total  996   clock   59.9Hz
1280x854 (0x5d)   89.2MHz -HSync +VSync
  h: width  1280 start 1352 end 1480 total 1680 skew0 clock   
53.1KHz
  v: height  854 start  857 end  867 total  887   clock   59.9Hz
1280x800 (0x5e)   83.5MHz -HSync +VSync
  h: width  1280 start 1352 end 1480 total 1680 skew0 clock   
49.7KHz
  v: height  800 start  803 end  809 total  831   clock   59.8Hz
1280x720 (0x5f)   74.5MHz -HSync +VSync
  h: width  1280 start 1344 end 1472 total 1664 skew0 clock   
44.8KHz
  v: height  720 start  723 end  728 total  748   clock   59.9Hz
1152x768 (0x60)   71.8MHz -HSync +VSync
  h: width  1152 start 1216 end 1328 total 1504 skew0 clock   
47.7KHz
  v: height  768 start  771 end  781 total  798   clock   59.8Hz
1024x768 (0x61)   63.5MHz -HSync +VSync
  h: width  1024 start 1072 end 1176 total 1328 skew0 clock   
47.8KHz
  v: height  768 start  771 end  775 total  798   clock   59.9Hz
800x600 (0x62)   38.2MHz -HSync +VSync
  h: width   800 start  832 end  912 total 1024 skew0 clock   
37.4KHz
  v: height  600 start  603 end  607 total  624   clock   59.9Hz
848x480 (0x63)   31.5MHz -HSync +VSync
  h: width   848 start  872 end  952 total 1056 skew0 clock   
29.8KHz
  v: height  480 start  483 end  493 total  500   clock   59.7Hz
720x480 (0x64)   26.8MHz -HSync +VSync
  h: width   720 start  744 end  808 total  896 skew0 clock   
29.9KHz
  v: height  480 start  483 end  493 total  500   clock   59.7Hz
640x480 (0x65)   23.8MHz -HSync +VSync
  h: width   640 start  664 end  720 total  800 skew0 clock   
29.7KHz
  v: height  480 start  483 end  487 total  500   clock   59.4Hz

However, switching to one of these other modes or defining my own
through xorg.conf does nothing to fix the troubles; while the
resolution does change, the flickering and striation remain, and
glxgears continues to report the same 19+ FPS.

Is there anything that can be done to work around these last
troubles?

Sincerely,
Michael Witten

P.S.

I'm running i686 Linux 3.1.0-rc5, specifically this commit
(with my patch):

  473e2bc9d3649e072d0a1bff84afa95b072d056b

and:

  X.Org X Server 1.10.3.901 (1.10.4 RC 1)
  Release Date: 2011-07-29
  X Protocol Version 11, Revision 0
  Kernel command line: root=/dev/sda2 ro 3
  Build Date: 08 August 2011  08:28:07AM
  Current version of pixman: 0.22.2