[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=42373

--- Comment #25 from Alex Deucher  2012-08-16 21:59:05 UTC 
---
You might try the 5 patches starting with this one:
http://lists.freedesktop.org/archives/dri-devel/2012-August/026498.html

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

[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=42373

--- Comment #24 from Erik Hardesty  2012-08-16 21:44:57 
UTC ---
I am also experiencing complete display corruption with KMS and my Radeon 6450
HD.
Building an updated kernel with the following commit did not help:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=81ee8fb6b52ec69eeed37fe7943446af1dccecc5

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

[PATCH 1/2] drm/radeon: implement ACPI VFCT vbios fetch (v2)

[David Lamparter]

On Thu, Aug 16, 2012 at 03:13:46PM -0400, alexdeucher at gmail.com wrote:
> From: David L 
From: David Lamparter <equi...@diac24.net>

There are still two rough edges left in here, I didn't get around to
clean it up, other stuff came up -- sorry...

> This is required for pure UEFI systems.  The vbios is stored
> in ACPI rather than at the legacy vga location.
> 
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=26891
> 
> V2: fix #ifdefs as per Greg's comments
> 
> Signed-off-by: Alex Deucher 
> Cc: stable at vger.kernel.org
> ---
[...]
> + struct acpi_table_header *hdr;
> + /* acpi_get_table_with_size is not exported :( */
> + acpi_size tbl_size = 0x7fff;

I was using acpi_get_table_with_size, but that needs an export, with
0x7fff all the tests below are kinda useless because they always
succeed.  I think it'd be useful to keep the length checks in case some
vendor breaks their ACPI tables, so this needs an EXPORT_SYMBOL.

> + UEFI_ACPI_VFCT *vfct;
> + GOP_VBIOS_CONTENT *vbios;
> + VFCT_IMAGE_HEADER *vhdr;
> +
> + if (!ACPI_SUCCESS(acpi_get_table("VFCT", 1, )))
> + return false;
> + if (tbl_size < sizeof(UEFI_ACPI_VFCT)) {
> + DRM_ERROR("ACPI VFCT table present but broken (too short 
> #1)\n");
> + goto out_unmap;
> + }
> +
> + vfct = (UEFI_ACPI_VFCT *)hdr;
> + if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) > tbl_size) {
> + DRM_ERROR("ACPI VFCT table present but broken (too short 
> #2)\n");
> + goto out_unmap;
> + }
> +
> + vbios = (GOP_VBIOS_CONTENT *)((char *)hdr + vfct->VBIOSImageOffset);
> + vhdr = >VbiosHeader;
> + DRM_INFO("ACPI VFCT contains a BIOS for %02x:%02x.%d %04x:%04x, size 
> %d\n",
> + vhdr->PCIBus, vhdr->PCIDevice, vhdr->PCIFunction,
> + vhdr->VendorID, vhdr->DeviceID, vhdr->ImageLength);
> +
> + if (vhdr->PCIBus != rdev->pdev->bus->number ||
> + vhdr->PCIDevice != PCI_SLOT(rdev->pdev->devfn) ||
> + vhdr->PCIFunction != PCI_FUNC(rdev->pdev->devfn) ||
> + vhdr->VendorID != rdev->pdev->vendor ||
> + vhdr->DeviceID != rdev->pdev->device) {
> + DRM_INFO("ACPI VFCT table is not for this card\n");
> + goto out_unmap;
> + };
> +
> + if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) + 
> vhdr->ImageLength > tbl_size) {
> + DRM_ERROR("ACPI VFCT image truncated\n");
> + goto out_unmap;
> + }
> +
> + rdev->bios = kmemdup(>VbiosContent, vhdr->ImageLength, 
> GFP_KERNEL);
> + ret = !!rdev->bios;
> +
> +out_unmap:
> + /* uh, no idea what to do here... */

So, er, I had no clue how to clean up the return value of acpi_get_table
- does this actually need to be cleaned up?  Or do you just get a
pointer straight to the "real" ACPI table?

> + return ret;
> +}
> +#else
> +static bool radeon_acpi_vfct_bios(struct radeon_device *rdev)
> +{
> + return false;
> +}
> +#endif
>  
>  bool radeon_get_bios(struct radeon_device *rdev)
>  {
> @@ -484,6 +544,8 @@ bool radeon_get_bios(struct radeon_device *rdev)
>  
>   r = radeon_atrm_get_bios(rdev);
>   if (r == false)
> + r = radeon_acpi_vfct_bios(rdev);
> + if (r == false)
>   r = igp_read_bios_from_vram(rdev);
>   if (r == false)
>   r = radeon_read_bios(rdev);
> -- 
> 1.7.7.5
> 

Cheers,

-David
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120816/9bc25513/attachment.pgp>

[Bug 45018] [bisected] rendering regression and va conflicts since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #124 from Thomas Rohloff  2012-08-16 21:03:39 
UTC ---
And there are some random rendering issues that wasn't there before the
patches, like using the wrong texture.

Good: http://img713.imageshack.us/img713/492/mcgood.png
Bad: http://img96.imageshack.us/img96/6417/mcbad.png

Also water in the game flashes white (seems to choose the wrong texture
sometimes in the animation, too) and sometimes the whole game screen flashes
blue.

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

[Bug 45018] [bisected] rendering regression and va conflicts since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #123 from Thomas Rohloff  2012-08-16 20:10:32 
UTC ---
(In reply to comment #119)
> (In reply to comment #118)
> 
> Try the Mesa patches from
> http://lists.freedesktop.org/archives/mesa-dev/2012-August/025715.html .

Not sure if this is related or if I should open a new report, but since this
patches I get this when I try to start compiz with GLAMOR acceleration:
http://pastebin.com/WbxMT0V9 - before I got the "conficts with" messages and
without GLAMOR I get (and got) no messages at all but compiz loads slow and the
screen flickers while doing so.

P.S. Also the desktop is corrupted with GLAMOR. This is better since this
patches but still there.

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

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #47 from Varban  2012-08-16 18:59:13 UTC 
---
(In reply to comment #44)
> No, and with the static config above it doesn't make sense. Besides, GPU
> hotplug is not in the current X server.

If the card is separate then I'll probably play around with running two
xservers that share a session, or something like it, so that I can kill one
when I disconnect the media dock.

There do seem to be some issues around hotplugging and thunderbolt that are
causing the USB hub in the media dock not to work but I hope they don't affect
the GPU or they were caused by the GPU audio device crashing.

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

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #46 from Alex Deucher  2012-08-16 18:23:52 UTC 
---
Created attachment 65659
  --> https://bugs.freedesktop.org/attachment.cgi?id=65659
fix for all kernels

Here's the patch broken out which should apply to all recent kernels.

-- 
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/edid: limit printk when facing bad edid

[Jani Nikula]

There's a bug [1] where the faster GMBUS transmissions fail with some
CRTs, and the fix [2] is to fallback to GPIO bit-banging upon errors. As
noted in the bug, the fix still leaves plenty of EDID dumps in dmesg, so
some measures to reduce the EDID error messages would be most welcome.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=45881
[2] http://thread.gmane.org/gmane.linux.kernel/1332810/focus=1341912

On Tue, 14 Aug 2012, Jerome Glisse  wrote:
> On Tue, Aug 14, 2012 at 10:54 AM, Adam Jackson  wrote:
>> On 8/9/12 11:25 AM, j.glisse at gmail.com wrote:
>>>
>>> From: Jerome Glisse 
>>>
>>> Limit printing bad edid information at one time per connector.
>>> Connector that are connected to a bad monitor/kvm will likely
>>> stay connected to the same bad monitor/kvm and it makes no
>>> sense to keep printing the bad edid message.

Do I understand correctly that bad_edid_counter is only reset when you
reboot or reload the module? So if you have a laptop that you connect to
the monitor at home, the monitor at the office, the projector in the
meeting room, and to a TV somewhere else, etc, the message about bad
EDID will only printed once? I don't think that's good. But please do
correct me if I'm wrong.

>>>
>>> Signed-off-by: Jerome Glisse 
>>
>>
>> I guess.  I don't see why we don't just move it into DRM_DEBUG_KMS if we're
>> going to suppress it, but this does what it says on the box.
>>
>> Reviewed-by: Adam Jackson 
>>
>> - ajax
>>
>
> I think there is still value in getting at least once the bad edid.

I think the raw edid dumps should be DEBUG level no matter what. Perhaps
some of the other messages could use WARNING/DEBUG too. And with that,
and my comment above, I not sure there really needs to be all that logic
to count errors and act differently further on.


BR,
Jani.

[PATCH 4/4] drm: edid: Refactor HDMI VSDB detection

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

There are two slightly different pieces of code for HDMI VSDB
detection. Unify the code into a single helper function.

Also fix a bug where drm_detect_hdmi_monitor() would stop looking
for the HDMI VSDB after the first vendor specific block is found,
whether or not that block happened to be the HDMI VSDB. The
standard allows for any number of vendor specific blocks to be
present.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_edid.c |   38 ++
 1 files changed, 22 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 2611ba8..f5c9cea 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1606,6 +1606,21 @@ monitor_name(struct detailed_timing *t, void *data)
*(u8 **)data = t->data.other_data.data.str.str;
 }

+static bool cea_db_is_hdmi_vsdb(const u8 *db)
+{
+   int hdmi_id;
+
+   if (cea_db_tag(db) != VENDOR_BLOCK)
+   return false;
+
+   if (cea_db_payload_len(db) < 5)
+   return false;
+
+   hdmi_id = db[1] | (db[2] << 8) | (db[3] << 16);
+
+   return hdmi_id == HDMI_IDENTIFIER;
+}
+
 /**
  * drm_edid_to_eld - build ELD from EDID
  * @connector: connector corresponding to the HDMI/DP sink
@@ -1678,7 +1693,7 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
break;
case VENDOR_BLOCK:
/* HDMI Vendor-Specific Data Block */
-   if (dbl >= 5 && db[1] == 0x03 && db[2] == 0x0c 
&& db[3] == 0)
+   if (cea_db_is_hdmi_vsdb(db))
parse_hdmi_vsdb(connector, db);
break;
default:
@@ -1763,35 +1778,26 @@ EXPORT_SYMBOL(drm_select_eld);
 bool drm_detect_hdmi_monitor(struct edid *edid)
 {
u8 *edid_ext;
-   int i, hdmi_id;
+   int i;
int start_offset, end_offset;
-   bool is_hdmi = false;

edid_ext = drm_find_cea_extension(edid);
if (!edid_ext)
-   goto end;
+   return false;

if (cea_db_offsets(edid_ext, _offset, _offset))
-   goto end;
+   return false;

/*
 * Because HDMI identifier is in Vendor Specific Block,
 * search it from all data blocks of CEA extension.
 */
for_each_cea_db(edid_ext, i, start_offset, end_offset) {
-   /* Find vendor specific block */
-   if (cea_db_tag(_ext[i]) == VENDOR_BLOCK) {
-   hdmi_id = edid_ext[i + 1] | (edid_ext[i + 2] << 8) |
- edid_ext[i + 3] << 16;
-   /* Find HDMI identifier */
-   if (hdmi_id == HDMI_IDENTIFIER)
-   is_hdmi = true;
-   break;
-   }
+   if (cea_db_is_hdmi_vsdb(_ext[i]))
+   return true;
}

-end:
-   return is_hdmi;
+   return false;
 }
 EXPORT_SYMBOL(drm_detect_hdmi_monitor);

-- 
1.7.8.6

[PATCH 3/4] drm: edid: Add bounds checking to HDMI VSDB parsing

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

The length of HDMI VSDB must be at least 5 bytes. Other than the minimum,
nothing else about the length is specified. Check the length before
accessing any additional field beyond the minimum length.
---
 drivers/gpu/drm/drm_edid.c |   33 +
 1 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index aa28d1c..2611ba8 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1561,19 +1561,28 @@ add_cea_modes(struct drm_connector *connector, struct 
edid *edid)
 }

 static void
-parse_hdmi_vsdb(struct drm_connector *connector, uint8_t *db)
+parse_hdmi_vsdb(struct drm_connector *connector, const u8 *db)
 {
-   connector->eld[5] |= (db[6] >> 7) << 1;  /* Supports_AI */
+   u8 len = cea_db_payload_len(db);

-   connector->dvi_dual = db[6] & 1;
-   connector->max_tmds_clock = db[7] * 5;
-
-   connector->latency_present[0] = db[8] >> 7;
-   connector->latency_present[1] = (db[8] >> 6) & 1;
-   connector->video_latency[0] = db[9];
-   connector->audio_latency[0] = db[10];
-   connector->video_latency[1] = db[11];
-   connector->audio_latency[1] = db[12];
+   if (len >= 6) {
+   connector->eld[5] |= (db[6] >> 7) << 1;  /* Supports_AI */
+   connector->dvi_dual = db[6] & 1;
+   }
+   if (len >= 7)
+   connector->max_tmds_clock = db[7] * 5;
+   if (len >= 8) {
+   connector->latency_present[0] = db[8] >> 7;
+   connector->latency_present[1] = (db[8] >> 6) & 1;
+   }
+   if (len >= 9)
+   connector->video_latency[0] = db[9];
+   if (len >= 10)
+   connector->audio_latency[0] = db[10];
+   if (len >= 11)
+   connector->video_latency[1] = db[11];
+   if (len >= 12)
+   connector->audio_latency[1] = db[12];

DRM_LOG_KMS("HDMI: DVI dual %d, "
"max TMDS clock %d, "
@@ -1669,7 +1678,7 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
break;
case VENDOR_BLOCK:
/* HDMI Vendor-Specific Data Block */
-   if (db[1] == 0x03 && db[2] == 0x0c && db[3] == 
0)
+   if (dbl >= 5 && db[1] == 0x03 && db[2] == 0x0c 
&& db[3] == 0)
parse_hdmi_vsdb(connector, db);
break;
default:
-- 
1.7.8.6

[PATCH 2/4] drm: edid: Add some bounds checking

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

Make sure drm_detect_hdmi_monitor() and drm_detect_monitor_audio() don't
access beyond the extension block.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_edid.c |   99 ---
 1 files changed, 73 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a346b04..aa28d1c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1502,16 +1502,57 @@ do_cea_modes (struct drm_connector *connector, u8 *db, 
u8 len)
 }

 static int
+cea_db_payload_len(const u8 *db)
+{
+   return db[0] & 0x1f;
+}
+
+static int
+cea_db_tag(const u8 *db)
+{
+   return db[0] >> 5;
+}
+
+static int
+cea_revision(const u8 *cea)
+{
+   return cea[1];
+}
+
+static int
+cea_db_offsets(const u8 *cea, int *start, int *end)
+{
+   /* Data block offset in CEA extension block */
+   *start = 4;
+   *end = cea[2];
+   if (*end == 0)
+   *end = 127;
+   if (*end < 4 || *end > 127)
+   return -ERANGE;
+   return 0;
+}
+
+#define for_each_cea_db(cea, i, start, end) \
+   for ((i) = (start); (i) < (end) && (i) + 
cea_db_payload_len(&(cea)[(i)]) < (end); (i) += cea_db_payload_len(&(cea)[(i)]) 
+ 1)
+
+static int
 add_cea_modes(struct drm_connector *connector, struct edid *edid)
 {
u8 * cea = drm_find_cea_extension(edid);
u8 * db, dbl;
int modes = 0;

-   if (cea && cea[1] >= 3) {
-   for (db = cea + 4; db < cea + cea[2]; db += dbl + 1) {
-   dbl = db[0] & 0x1f;
-   if (((db[0] & 0xe0) >> 5) == VIDEO_BLOCK)
+   if (cea && cea_revision(cea) >= 3) {
+   int i, start, end;
+
+   if (cea_db_offsets(cea, , ))
+   return 0;
+
+   for_each_cea_db(cea, i, start, end) {
+   db = [i];
+   dbl = cea_db_payload_len(db);
+
+   if (cea_db_tag(db) == VIDEO_BLOCK)
modes += do_cea_modes (connector, db+1, dbl);
}
}
@@ -1602,19 +1643,29 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
eld[18] = edid->prod_code[0];
eld[19] = edid->prod_code[1];

-   if (cea[1] >= 3)
-   for (db = cea + 4; db < cea + cea[2]; db += dbl + 1) {
-   dbl = db[0] & 0x1f;
-   
-   switch ((db[0] & 0xe0) >> 5) {
+   if (cea_revision(cea) >= 3) {
+   int i, start, end;
+
+   if (cea_db_offsets(cea, , )) {
+   start = 0;
+   end = 0;
+   }
+
+   for_each_cea_db(cea, i, start, end) {
+   db = [i];
+   dbl = cea_db_payload_len(db);
+
+   switch (cea_db_tag(db)) {
case AUDIO_BLOCK:
/* Audio Data Block, contains SADs */
sad_count = dbl / 3;
-   memcpy(eld + 20 + mnl, [1], dbl);
+   if (dbl >= 1)
+   memcpy(eld + 20 + mnl, [1], dbl);
break;
case SPEAKER_BLOCK:
-/* Speaker Allocation Data Block */
-   eld[7] = db[1];
+   /* Speaker Allocation Data Block */
+   if (dbl >= 1)
+   eld[7] = db[1];
break;
case VENDOR_BLOCK:
/* HDMI Vendor-Specific Data Block */
@@ -1625,6 +1676,7 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
break;
}
}
+   }
eld[5] |= sad_count << 4;
eld[2] = (20 + mnl + sad_count * 3 + 3) / 4;

@@ -1710,19 +1762,16 @@ bool drm_detect_hdmi_monitor(struct edid *edid)
if (!edid_ext)
goto end;

-   /* Data block offset in CEA extension block */
-   start_offset = 4;
-   end_offset = edid_ext[2];
+   if (cea_db_offsets(edid_ext, _offset, _offset))
+   goto end;

/*
 * Because HDMI identifier is in Vendor Specific Block,
 * search it from all data blocks of CEA extension.
 */
-   for (i = start_offset; i < end_offset;
-   /* Increased by data block len */
-   i += ((edid_ext[i] & 0x1f) + 1)) {
+   for_each_cea_db(edid_ext, i, start_offset, end_offset) {
/* Find vendor specific block */
-   if ((edid_ext[i] >> 5) == VENDOR_BLOCK) {
+   if (cea_db_tag(_ext[i]) == VENDOR_BLOCK) {
hdmi_id = 

[PATCH 1/4] drm: edid: Add bounds checking to CEA 18 byte descriptor parsing

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

Make sure we don't access beyond the extension block when parsing CEA
detailed timing descriptors.

Signed-off-by: Ville Syrj?l? 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/drm_edid.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5873e48..a346b04 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -551,6 +551,9 @@ cea_for_each_detailed_block(u8 *ext, detailed_cb *cb, void 
*closure)
u8 d = ext[0x02];
u8 *det_base = ext + d;

+   if (d > 127)
+   return;
+
n = (127 - d) / 18;
for (i = 0; i < n; i++)
cb((struct detailed_timing *)(det_base + 18 * i), closure);
-- 
1.7.8.6

[PATCH 0/4] Some long forgotten EDID/CEA fixes

[ville.syrj...@linux.intel.com]

I found these EDID/CEA patches sitting in a branch in my tree. I worked on
them at some point, but forgot about them when something more urgent
came up.

They haven't been tested all that well, mainly because currently there
is no way to test this code, apart from trying on real hardware. If
someone is looking for a good project, this would be one:
1. Split EDID parsing from the rest of the junk in drm_edid.c
2. Make it compile in user space
3. Cook up some regression and fuzz testing framework

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #45 from Alex Deucher  2012-08-16 17:41:59 UTC 
---
(In reply to comment #42)
> Any ideas when this patch will make it in the main line?

I've got it tentatively set for 3.7, but if I have time, I'll try and respin
the patches for stable.

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

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #44 from Alexander E. Patrakov  2012-08-16 
17:39:18 UTC ---
(In reply to comment #42)
> Any ideas when this patch will make it in the main line?

No idea.

> Did you try hotplugging the media dock rather than boot with it attached?

No, and with the static config above it doesn't make sense. Besides, GPU
hotplug is not in the current X server.

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

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #43 from Alexander E. Patrakov  2012-08-16 
17:37:28 UTC ---
The card is a completely separate card. One can create a very old-fashioned
Xinerama-based dual-head setup using this (save as
/etc/X11/xorg.conf.d/60-dualhead.conf):


Section "Device"
Identifier "radeon"
Driver "radeon"
BusID "PCI:22:00:0"
EndSection

Section "Device"
Identifier "intel"
Driver "intel"
BusID "PCI:00:02:0"
EndSection

Section "Screen"
Identifier "Screen0"
Device "radeon"
EndSection

Section "Screen"
Identifier "Screen1"
Device "intel"
EndSection

Section "ServerLayout"
Identifier "DualHead"
Screen "Screen0"
Screen "Screen1" RightOf "Screen0"
Option "Xinerama" "On"
EndSection


This is, however, deprecated, and I'd also like to know the modern way of doing
this :)

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

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #42 from Varban  2012-08-16 17:29:16 UTC 
---
What settings did you use for the X server config or do the additional monitors
just show as part of the intel card?

Any ideas when this patch will make it in the main line?

Did you try hotplugging the media dock rather than boot with it attached?

Thanks for the effort on troubleshooting this!

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

[Bug 44341] Radeon HD6990M: HDMI audio output works now! Kernel gives new warning

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=44341


Christopher Fr?mmel  changed:

   What|Removed |Added

  Attachment #75121|0   |1
is obsolete||




-- 
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 44341] Radeon HD6990M: HDMI audio output works now! Kernel gives new warning

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=44341


Christopher Fr?mmel  changed:

   What|Removed |Added

  Attachment #75091|0   |1
is obsolete||




--- Comment #9 from Christopher Fr?mmel   2012-08-16 
17:25:16 ---
Created an attachment (id=77831)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=77831)
.config 3.5.2

-- 
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 44341] Radeon HD6990M: HDMI audio output works now! Kernel gives new warning

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=44341


Christopher Fr?mmel  changed:

   What|Removed |Added

  Attachment #75081|0   |1
is obsolete||




--- Comment #8 from Christopher Fr?mmel   2012-08-16 
17:24:37 ---
Created an attachment (id=77821)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=77821)
lspci

-- 
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 44341] Radeon HD6990M: HDMI audio output works now! Kernel gives new warning

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=44341


Christopher Fr?mmel  changed:

   What|Removed |Added

  Attachment #75071|0   |1
is obsolete||




--- Comment #7 from Christopher Fr?mmel   2012-08-16 
17:24:02 ---
Created an attachment (id=77811)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=77811)
full dmesg

-- 
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 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

Alexander E. Patrakov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug 44341] Radeon HD6990M: HDMI audio output works now! Kernel gives new warning

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=44341


Christopher Fr?mmel  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Kernel Version|3.5.0-rc6   |3.5.2
 Resolution|OBSOLETE|
 Regression|No  |Yes




--- Comment #6 from Christopher Fr?mmel   2012-08-16 
17:22:13 ---
Warnings again since 3.5.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.

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #41 from Alexander E. Patrakov  2012-08-16 
17:21:59 UTC ---
X works on radeon, too

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

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #40 from Alexander E. Patrakov  2012-08-16 
17:05:27 UTC ---
I have built the kernel from your source tree. It found the card, found the
HDMI-connected monitor and displayed boot text messages over it for some time
(until it decided to move to the inteldrmfb framebuffer). Will test X a bit
later.

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

[Bug 53291] Failed to allocate a buffer at CAYMAN

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=53291

Alex Deucher  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |DUPLICATE

--- Comment #3 from Alex Deucher  2012-08-16 16:59:49 UTC 
---


*** This bug has been marked as a duplicate of bug 45018 ***

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

[Bug 45018] [bisected] rendering regression and va conflicts since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

Alex Deucher  changed:

   What|Removed |Added

 CC||v10lator at myway.de

--- Comment #122 from Alex Deucher  2012-08-16 16:59:49 UTC 
---
*** Bug 53291 has been marked as a duplicate of this bug. ***

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

[PATCH 2/2] drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads

[Daniel Vetter]

On Mon, Aug 13, 2012 at 01:22:35PM +0300, Jani Nikula wrote:
> GMBUS was enabled over bit-banging as the default in commits:
> 
> commit c3dfefa0a6d235bd465309e12f4c56ea16e7
> Author: Daniel Vetter 
> Date:   Tue Feb 14 22:37:25 2012 +0100
> 
> drm/i915: reenable gmbus on gen3+ again
> 
> and
> 
> commit 0fb3f969c8683505fb7323c06bf8a999a5a45a15
> Author: Daniel Vetter 
> Date:   Fri Mar 2 19:38:30 2012 +0100
> 
> drm/i915: enable gmbus on gen2
> 
> Unfortunately, GMBUS seems to fail on some CRT displays. Add a bit-banging
> fallback to CRT EDID reads.
> 
> LKML-Reference: <201207251020.47637.maciej.rutecki at gmail.com>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45881
> Signed-off-by: Jani Nikula 
Patches applied to -fixes with the tested-by result from the bug report.
I've also put a cc: stable on both of them, since the regression is
already in 3.4.

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

[Bug 53291] Failed to allocate a buffer at CAYMAN

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=53291

Thomas Rohloff  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME

--- Comment #2 from Thomas Rohloff  2012-08-16 16:31:53 
UTC ---
I think Alex was right. This seems to be fixed in the newest git version of
Mesa (which includes patches from Michel D?nzer (comment #119 at bug 45018)).

-- 
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/radeon: fence virtual address and free it once idle [3.5] v4

[Greg KH]

On Mon, Aug 06, 2012 at 12:56:04PM -0400, j.glisse at gmail.com wrote:
> From: Jerome Glisse 
> 
> Virtual address need to be fenced to know when we can safely remove it.
> This patch also properly clear the pagetable. Previously it was
> serouisly broken.
> 
> v2: For to update pagetable when unbinding bo (don't bailout if
> bo_va->valid is true).
> v3: Fix compilation warnings
> v4: We need a special version for 3.5 because the locking scheme
> is different btw 3.5 and 3.6. There is no longer cs mutex in
> 3.6 instead there is a global vm mutex.
> 
> This version is for stable 3.5 only.

Is the version that fixes this problem in the 3.6 tree, already in
Linus's tree?  If so, what is the git commit id?  If not, I need to wait
until it gets in there, so please tell me when it does so.

greg k-h

[PATCH 2/2] Expose the OMAP Z-Order property through DRM

[Ville Syrjälä]

On Wed, Aug 15, 2012 at 03:18:02PM -0500, Rob Clark wrote:
> From: Andre Renaud 
> 
> Added support for zorder changes through DRM plane properties
> 
> Signed-off-by: Andre Renaud 
> Signed-off-by: Rob Clark 
> ---
>  drivers/staging/omapdrm/omap_drv.h   |1 +
>  drivers/staging/omapdrm/omap_plane.c |   19 +++
>  2 files changed, 20 insertions(+)
> 
> diff --git a/drivers/staging/omapdrm/omap_drv.h 
> b/drivers/staging/omapdrm/omap_drv.h
> index b103d28..9dc72d1 100644
> --- a/drivers/staging/omapdrm/omap_drv.h
> +++ b/drivers/staging/omapdrm/omap_drv.h
> @@ -62,6 +62,7 @@ struct omap_drm_private {
>  
>   /* properties: */
>   struct drm_property *rotation_prop;
> + struct drm_property *zorder_prop;
>  };
>  
>  /* this should probably be in drm-core to standardize amongst drivers */
> diff --git a/drivers/staging/omapdrm/omap_plane.c 
> b/drivers/staging/omapdrm/omap_plane.c
> index 6931d06..4bde639 100644
> --- a/drivers/staging/omapdrm/omap_plane.c
> +++ b/drivers/staging/omapdrm/omap_plane.c
> @@ -433,6 +433,15 @@ void omap_plane_install_properties(struct drm_plane 
> *plane,
>   priv->rotation_prop = prop;
>   }
>   drm_object_attach_property(obj, prop, 0);
> +
> +prop = priv->zorder_prop;
> +if (!prop) {
> + prop = drm_property_create_range(dev, 0, "zorder", 0, 3);
> + if (prop == NULL)
> + return;
> + priv->zorder_prop = prop;
> + }
> + drm_object_attach_property(obj, prop, 0);
>  }
>  
>  int omap_plane_set_property(struct drm_plane *plane,
> @@ -452,6 +461,16 @@ int omap_plane_set_property(struct drm_plane *plane,
>   ret = omap_plane_dpms(plane, DRM_MODE_DPMS_ON);
>   else
>   ret = 0;
> + } else if (property == priv->zorder_prop) {
> + struct omap_overlay *ovl = omap_plane->ovl;
> +
> + DBG("%s: zorder: %d", ovl->name, (uint32_t)val);
> + omap_plane->info.zorder = val;

What would happen when there's a conflicting assignment between two
planes?

I tried to think of a decent way to do this stuff, but some hardware
can have rather complicated stacking order limitations. One idea I
came up with was to have an enum prop on the crtc, where the individual
enum value names would somehow describe the whole stacking order within
the crtc. That way user space couldn't even try to use an unsupported
configuration. The downside is that user space would need to parse
those strings if it wants to do some automagic stacking order changes,
which means the string format would need some though.

-- 
Ville Syrj?l?
Intel OTC

[PATCH 1/2] drm/radeon: implement ACPI VFCT vbios fetch (v2)

[Alex Deucher]

On Thu, Aug 16, 2012 at 3:40 PM, David Lamparter  wrote:
> On Thu, Aug 16, 2012 at 03:13:46PM -0400, alexdeucher at gmail.com wrote:
>> From: David L 
> From: David Lamparter 
>
> There are still two rough edges left in here, I didn't get around to
> clean it up, other stuff came up -- sorry...
>
>> This is required for pure UEFI systems.  The vbios is stored
>> in ACPI rather than at the legacy vga location.
>>
>> Fixes:
>> https://bugs.freedesktop.org/show_bug.cgi?id=26891
>>
>> V2: fix #ifdefs as per Greg's comments
>>
>> Signed-off-by: Alex Deucher 
>> Cc: stable at vger.kernel.org
>> ---
> [...]
>> + struct acpi_table_header *hdr;
>> + /* acpi_get_table_with_size is not exported :( */
>> + acpi_size tbl_size = 0x7fff;
>
> I was using acpi_get_table_with_size, but that needs an export, with
> 0x7fff all the tests below are kinda useless because they always
> succeed.  I think it'd be useful to keep the length checks in case some
> vendor breaks their ACPI tables, so this needs an EXPORT_SYMBOL.

I guess we could leave it as is for now for -fixes and then switch it
use use the new exported symbol for -next?  Is it ok to export a new
symbol for -fixes?

>
>> + UEFI_ACPI_VFCT *vfct;
>> + GOP_VBIOS_CONTENT *vbios;
>> + VFCT_IMAGE_HEADER *vhdr;
>> +
>> + if (!ACPI_SUCCESS(acpi_get_table("VFCT", 1, )))
>> + return false;
>> + if (tbl_size < sizeof(UEFI_ACPI_VFCT)) {
>> + DRM_ERROR("ACPI VFCT table present but broken (too short 
>> #1)\n");
>> + goto out_unmap;
>> + }
>> +
>> + vfct = (UEFI_ACPI_VFCT *)hdr;
>> + if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) > tbl_size) {
>> + DRM_ERROR("ACPI VFCT table present but broken (too short 
>> #2)\n");
>> + goto out_unmap;
>> + }
>> +
>> + vbios = (GOP_VBIOS_CONTENT *)((char *)hdr + vfct->VBIOSImageOffset);
>> + vhdr = >VbiosHeader;
>> + DRM_INFO("ACPI VFCT contains a BIOS for %02x:%02x.%d %04x:%04x, size 
>> %d\n",
>> + vhdr->PCIBus, vhdr->PCIDevice, vhdr->PCIFunction,
>> + vhdr->VendorID, vhdr->DeviceID, vhdr->ImageLength);
>> +
>> + if (vhdr->PCIBus != rdev->pdev->bus->number ||
>> + vhdr->PCIDevice != PCI_SLOT(rdev->pdev->devfn) ||
>> + vhdr->PCIFunction != PCI_FUNC(rdev->pdev->devfn) ||
>> + vhdr->VendorID != rdev->pdev->vendor ||
>> + vhdr->DeviceID != rdev->pdev->device) {
>> + DRM_INFO("ACPI VFCT table is not for this card\n");
>> + goto out_unmap;
>> + };
>> +
>> + if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) + 
>> vhdr->ImageLength > tbl_size) {
>> + DRM_ERROR("ACPI VFCT image truncated\n");
>> + goto out_unmap;
>> + }
>> +
>> + rdev->bios = kmemdup(>VbiosContent, vhdr->ImageLength, 
>> GFP_KERNEL);
>> + ret = !!rdev->bios;
>> +
>> +out_unmap:
>> + /* uh, no idea what to do here... */
>
> So, er, I had no clue how to clean up the return value of acpi_get_table
> - does this actually need to be cleaned up?  Or do you just get a
> pointer straight to the "real" ACPI table?

Not sure on that.  Anyone know more about the acpi code?

Alex

[PATCH 2/2] drm/radeon: split ATRM support out from the ATPX handler (v3)

[alexdeuc...@gmail.com]

From: Alex Deucher 

There are systems that use ATRM, but not ATPX.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41265

V2: fix #ifdefs as per Greg's comments
V3: fix it harder

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon.h  |   15 -
 drivers/gpu/drm/radeon/radeon_atpx_handler.c |   56 +--
 drivers/gpu/drm/radeon/radeon_bios.c |   80 -
 3 files changed, 77 insertions(+), 74 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 9930419..59a1531 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -142,21 +142,6 @@ struct radeon_device;
 /*
  * BIOS.
  */
-#define ATRM_BIOS_PAGE 4096
-
-#if defined(CONFIG_VGA_SWITCHEROO)
-bool radeon_atrm_supported(struct pci_dev *pdev);
-int radeon_atrm_get_bios_chunk(uint8_t *bios, int offset, int len);
-#else
-static inline bool radeon_atrm_supported(struct pci_dev *pdev)
-{
-   return false;
-}
-
-static inline int radeon_atrm_get_bios_chunk(uint8_t *bios, int offset, int 
len){
-   return -EINVAL;
-}
-#endif
 bool radeon_get_bios(struct radeon_device *rdev);

 /*
diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c 
b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
index 98724fc..2a2cf0b 100644
--- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
+++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
@@ -30,57 +30,8 @@ static struct radeon_atpx_priv {
/* handle for device - and atpx */
acpi_handle dhandle;
acpi_handle atpx_handle;
-   acpi_handle atrm_handle;
 } radeon_atpx_priv;

-/* retrieve the ROM in 4k blocks */
-static int radeon_atrm_call(acpi_handle atrm_handle, uint8_t *bios,
-   int offset, int len)
-{
-   acpi_status status;
-   union acpi_object atrm_arg_elements[2], *obj;
-   struct acpi_object_list atrm_arg;
-   struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL};
-
-   atrm_arg.count = 2;
-   atrm_arg.pointer = _arg_elements[0];
-
-   atrm_arg_elements[0].type = ACPI_TYPE_INTEGER;
-   atrm_arg_elements[0].integer.value = offset;
-
-   atrm_arg_elements[1].type = ACPI_TYPE_INTEGER;
-   atrm_arg_elements[1].integer.value = len;
-
-   status = acpi_evaluate_object(atrm_handle, NULL, _arg, );
-   if (ACPI_FAILURE(status)) {
-   printk("failed to evaluate ATRM got %s\n", 
acpi_format_exception(status));
-   return -ENODEV;
-   }
-
-   obj = (union acpi_object *)buffer.pointer;
-   memcpy(bios+offset, obj->buffer.pointer, obj->buffer.length);
-   len = obj->buffer.length;
-   kfree(buffer.pointer);
-   return len;
-}
-
-bool radeon_atrm_supported(struct pci_dev *pdev)
-{
-   /* get the discrete ROM only via ATRM */
-   if (!radeon_atpx_priv.atpx_detected)
-   return false;
-
-   if (radeon_atpx_priv.dhandle == DEVICE_ACPI_HANDLE(>dev))
-   return false;
-   return true;
-}
-
-
-int radeon_atrm_get_bios_chunk(uint8_t *bios, int offset, int len)
-{
-   return radeon_atrm_call(radeon_atpx_priv.atrm_handle, bios, offset, 
len);
-}
-
 static int radeon_atpx_get_version(acpi_handle handle)
 {
acpi_status status;
@@ -198,7 +149,7 @@ static int radeon_atpx_power_state(enum 
vga_switcheroo_client_id id,

 static bool radeon_atpx_pci_probe_handle(struct pci_dev *pdev)
 {
-   acpi_handle dhandle, atpx_handle, atrm_handle;
+   acpi_handle dhandle, atpx_handle;
acpi_status status;

dhandle = DEVICE_ACPI_HANDLE(>dev);
@@ -209,13 +160,8 @@ static bool radeon_atpx_pci_probe_handle(struct pci_dev 
*pdev)
if (ACPI_FAILURE(status))
return false;

-   status = acpi_get_handle(dhandle, "ATRM", _handle);
-   if (ACPI_FAILURE(status))
-   return false;
-
radeon_atpx_priv.dhandle = dhandle;
radeon_atpx_priv.atpx_handle = atpx_handle;
-   radeon_atpx_priv.atrm_handle = atrm_handle;
return true;
 }

diff --git a/drivers/gpu/drm/radeon/radeon_bios.c 
b/drivers/gpu/drm/radeon/radeon_bios.c
index a32232f..602898d 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -99,16 +99,81 @@ static bool radeon_read_bios(struct radeon_device *rdev)
return true;
 }

+#ifdef CONFIG_ACPI
 /* ATRM is used to get the BIOS on the discrete cards in
  * dual-gpu systems.
  */
+/* retrieve the ROM in 4k blocks */
+#define ATRM_BIOS_PAGE 4096
+/**
+ * radeon_atrm_call - fetch a chunk of the vbios
+ *
+ * @atrm_handle: acpi ATRM handle
+ * @bios: vbios image pointer
+ * @offset: offset of vbios image data to fetch
+ * @len: length of vbios image data to fetch
+ *
+ * Executes ATRM to fetch a chunk of the discrete
+ * vbios image on PX systems (all asics).
+ * Returns the length of the buffer fetched.
+ */
+static int 

[PATCH 1/2] drm/radeon: implement ACPI VFCT vbios fetch (v3)

[alexdeuc...@gmail.com]

From: David Lamparter 

This is required for pure UEFI systems.  The vbios is stored
in ACPI rather than at the legacy vga location.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=26891

V2: fix #ifdefs as per Greg's comments
V3: fix it harder

Signed-off-by: Alex Deucher 
Reviewed-by: Jerome Glisse 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_bios.c |   60 ++
 1 files changed, 60 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_bios.c 
b/drivers/gpu/drm/radeon/radeon_bios.c
index 501f488..a32232f 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -32,6 +32,7 @@

 #include 
 #include 
+#include 
 /*
  * BIOS.
  */
@@ -476,6 +477,63 @@ static bool radeon_read_disabled_bios(struct radeon_device 
*rdev)
return legacy_read_disabled_bios(rdev);
 }

+#ifdef CONFIG_ACPI
+static bool radeon_acpi_vfct_bios(struct radeon_device *rdev)
+{
+   bool ret = false;
+   struct acpi_table_header *hdr;
+   /* acpi_get_table_with_size is not exported :( */
+   acpi_size tbl_size = 0x7fff;
+   UEFI_ACPI_VFCT *vfct;
+   GOP_VBIOS_CONTENT *vbios;
+   VFCT_IMAGE_HEADER *vhdr;
+
+   if (!ACPI_SUCCESS(acpi_get_table("VFCT", 1, )))
+   return false;
+   if (tbl_size < sizeof(UEFI_ACPI_VFCT)) {
+   DRM_ERROR("ACPI VFCT table present but broken (too short 
#1)\n");
+   goto out_unmap;
+   }
+
+   vfct = (UEFI_ACPI_VFCT *)hdr;
+   if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) > tbl_size) {
+   DRM_ERROR("ACPI VFCT table present but broken (too short 
#2)\n");
+   goto out_unmap;
+   }
+
+   vbios = (GOP_VBIOS_CONTENT *)((char *)hdr + vfct->VBIOSImageOffset);
+   vhdr = >VbiosHeader;
+   DRM_INFO("ACPI VFCT contains a BIOS for %02x:%02x.%d %04x:%04x, size 
%d\n",
+   vhdr->PCIBus, vhdr->PCIDevice, vhdr->PCIFunction,
+   vhdr->VendorID, vhdr->DeviceID, vhdr->ImageLength);
+
+   if (vhdr->PCIBus != rdev->pdev->bus->number ||
+   vhdr->PCIDevice != PCI_SLOT(rdev->pdev->devfn) ||
+   vhdr->PCIFunction != PCI_FUNC(rdev->pdev->devfn) ||
+   vhdr->VendorID != rdev->pdev->vendor ||
+   vhdr->DeviceID != rdev->pdev->device) {
+   DRM_INFO("ACPI VFCT table is not for this card\n");
+   goto out_unmap;
+   };
+
+   if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) + 
vhdr->ImageLength > tbl_size) {
+   DRM_ERROR("ACPI VFCT image truncated\n");
+   goto out_unmap;
+   }
+
+   rdev->bios = kmemdup(>VbiosContent, vhdr->ImageLength, 
GFP_KERNEL);
+   ret = !!rdev->bios;
+
+out_unmap:
+   /* uh, no idea what to do here... */
+   return ret;
+}
+#else
+static inline bool radeon_acpi_vfct_bios(struct radeon_device *rdev)
+{
+   return false;
+}
+#endif

 bool radeon_get_bios(struct radeon_device *rdev)
 {
@@ -484,6 +542,8 @@ bool radeon_get_bios(struct radeon_device *rdev)

r = radeon_atrm_get_bios(rdev);
if (r == false)
+   r = radeon_acpi_vfct_bios(rdev);
+   if (r == false)
r = igp_read_bios_from_vram(rdev);
if (r == false)
r = radeon_read_bios(rdev);
-- 
1.7.7.5

[PATCH 1/2] drm/radeon: implement ACPI VFCT vbios fetch (v2)

[Alex Deucher]

On Thu, Aug 16, 2012 at 3:25 PM, Greg KH  wrote:
> On Thu, Aug 16, 2012 at 03:13:46PM -0400, alexdeucher at gmail.com wrote:
>> From: David L 
>>
>> This is required for pure UEFI systems.  The vbios is stored
>> in ACPI rather than at the legacy vga location.
>>
>> Fixes:
>> https://bugs.freedesktop.org/show_bug.cgi?id=26891
>>
>> V2: fix #ifdefs as per Greg's comments
>>
>> Signed-off-by: Alex Deucher 
>> Cc: stable at vger.kernel.org
>> ---
>>  drivers/gpu/drm/radeon/radeon_bios.c |   62 
>> ++
>>  1 files changed, 62 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_bios.c 
>> b/drivers/gpu/drm/radeon/radeon_bios.c
>> index 501f488..bf21f65 100644
>> --- a/drivers/gpu/drm/radeon/radeon_bios.c
>> +++ b/drivers/gpu/drm/radeon/radeon_bios.c
>> @@ -32,6 +32,9 @@
>>
>>  #include 
>>  #include 
>> +#ifdef CONFIG_ACPI
>> +#include 
>> +#endif
>
> You forgot to remove this one :(

Argh!  I squashed that into the wrong patch when I rebased my fixes.

>
>>  /*
>>   * BIOS.
>>   */
>> @@ -476,6 +479,63 @@ static bool radeon_read_disabled_bios(struct 
>> radeon_device *rdev)
>>   return legacy_read_disabled_bios(rdev);
>>  }
>>
>> +#ifdef CONFIG_ACPI
>> +static bool radeon_acpi_vfct_bios(struct radeon_device *rdev)
>> +{
>> + bool ret = false;
>> + struct acpi_table_header *hdr;
>> + /* acpi_get_table_with_size is not exported :( */
>> + acpi_size tbl_size = 0x7fff;
>> + UEFI_ACPI_VFCT *vfct;
>> + GOP_VBIOS_CONTENT *vbios;
>> + VFCT_IMAGE_HEADER *vhdr;
>> +
>> + if (!ACPI_SUCCESS(acpi_get_table("VFCT", 1, )))
>> + return false;
>> + if (tbl_size < sizeof(UEFI_ACPI_VFCT)) {
>> + DRM_ERROR("ACPI VFCT table present but broken (too short 
>> #1)\n");
>> + goto out_unmap;
>> + }
>> +
>> + vfct = (UEFI_ACPI_VFCT *)hdr;
>> + if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) > tbl_size) {
>> + DRM_ERROR("ACPI VFCT table present but broken (too short 
>> #2)\n");
>> + goto out_unmap;
>> + }
>> +
>> + vbios = (GOP_VBIOS_CONTENT *)((char *)hdr + vfct->VBIOSImageOffset);
>> + vhdr = >VbiosHeader;
>> + DRM_INFO("ACPI VFCT contains a BIOS for %02x:%02x.%d %04x:%04x, size 
>> %d\n",
>> + vhdr->PCIBus, vhdr->PCIDevice, vhdr->PCIFunction,
>> + vhdr->VendorID, vhdr->DeviceID, vhdr->ImageLength);
>> +
>> + if (vhdr->PCIBus != rdev->pdev->bus->number ||
>> + vhdr->PCIDevice != PCI_SLOT(rdev->pdev->devfn) ||
>> + vhdr->PCIFunction != PCI_FUNC(rdev->pdev->devfn) ||
>> + vhdr->VendorID != rdev->pdev->vendor ||
>> + vhdr->DeviceID != rdev->pdev->device) {
>> + DRM_INFO("ACPI VFCT table is not for this card\n");
>> + goto out_unmap;
>> + };
>> +
>> + if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) + 
>> vhdr->ImageLength > tbl_size) {
>> + DRM_ERROR("ACPI VFCT image truncated\n");
>> + goto out_unmap;
>> + }
>> +
>> + rdev->bios = kmemdup(>VbiosContent, vhdr->ImageLength, 
>> GFP_KERNEL);
>> + ret = !!rdev->bios;
>> +
>> +out_unmap:
>> + /* uh, no idea what to do here... */
>> + return ret;
>> +}
>> +#else
>> +static bool radeon_acpi_vfct_bios(struct radeon_device *rdev)
>
> Make it inline, and then the compiler is smart enough to just delete the
> whole if () check you make when you call it.
>
> Third time's a charm?

On the way.

Alex

[PATCH V3 2/2] video: drm: exynos: Add device tree support

[Leela Krishna Amudala]

Add device tree based discovery support for DRM-FIMD driver.

Signed-off-by: Leela Krishna Amudala 
---
 Documentation/devicetree/bindings/fb/drm-fimd.txt |   80 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   95 -
 2 files changed, 173 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt

diff --git a/Documentation/devicetree/bindings/fb/drm-fimd.txt 
b/Documentation/devicetree/bindings/fb/drm-fimd.txt
new file mode 100644
index 000..8ad8814
--- /dev/null
+++ b/Documentation/devicetree/bindings/fb/drm-fimd.txt
@@ -0,0 +1,80 @@
+* Samsung Display Controller using DRM frame work
+
+The display controller is used to transfer image data from memory to an
+external LCD driver interface. It supports various color formats such as
+rgb and yuv.
+
+Required properties:
+ - compatible: Should be "samsung,exynos5-drm" for fimd using DRM frame work.
+ - reg: physical base address of the controller and length of memory
+   mapped region.
+ - interrupts: Three interrupts should be specified. The interrupts should be
+   specified in the following order.
+   - VSYNC interrupt
+   - FIFO level interrupt
+   - FIMD System Interrupt
+
+ - samsung,fimd-display: This property should specify the phandle of the
+   display device node which holds the video interface timing with the
+   below mentioned properties.
+
+   - lcd-htiming: Specifies the horizontal timing for the overlay. The
+ horizontal timing includes four parameters in the following order.
+
+ - horizontal back porch (in number of lcd clocks)
+ - horizontal front porch (in number of lcd clocks)
+ - hsync pulse width (in number of lcd clocks)
+ - Display panels X resolution.
+
+   - lcd-vtiming: Specifies the vertical timing for the overlay. The
+ vertical timing includes four parameters in the following order.
+
+ - vertical back porch (in number of lcd lines)
+ - vertical front porch (in number of lcd lines)
+ - vsync pulse width (in number of lcd clocks)
+ - Display panels Y resolution.
+
+
+ - samsung,default-window: Specifies the default window number of the fimd 
controller.
+
+ - samsung,fimd-win-bpp: Specifies the bits per pixel.
+
+Optional properties:
+ - supports-mipi-panel: Specifies the lcd is mipi panel type
+ - samsung,fimd-vidout-rgb: Video output format is RGB.
+ - samsung,fimd-inv-vclk: invert video clock polarity.
+ - samsung,fimd-frame-rate: Number of video frames per second.
+
+Example:
+
+   The following is an example for the fimd controller is split into
+   two portions. The SoC specific portion can be specified in the SoC
+   specific dts file. The board specific portion can be specified in the
+   board specific dts file.
+
+   - SoC Specific portion
+
+   fimd {
+   compatible = "samsung,exynos5-drm";
+   interrupt-parent = <>;
+   reg = <0x1440 0x4>;
+   interrupts = <18 5>, <18 4>, <18 6>;
+   };
+
+   - Board Specific portion
+
+   lcd_fimd0: lcd_panel0 {
+   lcd-htiming = <4 4 4 480>;
+   lcd-vtiming = <4 4 4 320>;
+   supports-mipi-panel;
+   };
+
+   fimd {
+   samsung,fimd-display = <_fimd0>;
+   samsung,fimd-vidout-rgb;
+   samsung,fimd-inv-vclk;
+   samsung,fimd-frame-rate = <60>;
+   samsung,default-window = <0>;
+   samsung,fimd-win-bpp = <32>;
+   };
+
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 8379c59..1753846 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -103,9 +104,18 @@ struct fimd_context {
struct exynos_drm_panel_info *panel;
 };

+static const struct of_device_id drm_fimd_dt_match[];
+
 static inline struct drm_fimd_driver_data *drm_fimd_get_driver_data(
struct platform_device *pdev)
 {
+#ifdef CONFIG_OF
+   if (pdev->dev.of_node) {
+   const struct of_device_id *match;
+   match = of_match_node(drm_fimd_dt_match, pdev->dev.of_node);
+   return (struct drm_fimd_driver_data *)match->data;
+   }
+#endif
return (struct drm_fimd_driver_data *)
platform_get_device_id(pdev)->driver_data;
 }
@@ -821,12 +831,79 @@ static int fimd_power_on(struct fimd_context *ctx, bool 
enable)
return 0;
 }

+#ifdef CONFIG_OF
+static struct exynos_drm_fimd_pdata *drm_fimd_dt_parse_pdata(struct device 
*dev)
+{
+   struct device_node *np = dev->of_node;
+   struct device_node *disp_np;
+   struct exynos_drm_fimd_pdata *pd;
+   u32 data[4];
+
+   pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
+   if (!pd) {
+   dev_err(dev, "memory allocation for 

[PATCH V3 1/2] drm/exynos: add platform_device_id table and driver data for exynos5 drm fimd

[Leela Krishna Amudala]

The name of the exynos drm fimd device is renamed to exynos-drm-fimd
and two device ids are created for exynos4-fb and exynos5-drm-fimd.
Also, added driver data for exynos5 to pick the fimd version at runtime and
to choose the VIDTCON register offsets accordingly.

Signed-off-by: Leela Krishna Amudala 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   56 +++---
 1 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 24c0bd4..8379c59 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -57,6 +57,18 @@

 #define get_fimd_context(dev)  platform_get_drvdata(to_platform_device(dev))

+enum fimd_version_type {
+   VERSION_8, /* FIMD_VERSION8 */
+};
+
+struct drm_fimd_driver_data {
+   enum fimd_version_type fimd_ver;
+};
+
+struct drm_fimd_driver_data exynos5_drm_fimd_driver_data = {
+   .fimd_ver = VERSION_8,
+};
+
 struct fimd_win_data {
unsigned intoffset_x;
unsigned intoffset_y;
@@ -91,6 +103,13 @@ struct fimd_context {
struct exynos_drm_panel_info *panel;
 };

+static inline struct drm_fimd_driver_data *drm_fimd_get_driver_data(
+   struct platform_device *pdev)
+{
+   return (struct drm_fimd_driver_data *)
+   platform_get_device_id(pdev)->driver_data;
+}
+
 static bool fimd_display_is_connected(struct device *dev)
 {
DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -194,32 +213,47 @@ static void fimd_commit(struct device *dev)
struct fimd_context *ctx = get_fimd_context(dev);
struct exynos_drm_panel_info *panel = ctx->panel;
struct fb_videomode *timing = >timing;
+   struct drm_fimd_driver_data *driver_data;
+   struct platform_device *pdev = to_platform_device(dev);
u32 val;

+   driver_data = drm_fimd_get_driver_data(pdev);
if (ctx->suspended)
return;

DRM_DEBUG_KMS("%s\n", __FILE__);

/* setup polarity values from machine code. */
-   writel(ctx->vidcon1, ctx->regs + VIDCON1);
+   if (driver_data->fimd_ver == VERSION_8)
+   writel(ctx->vidcon1, ctx->regs + FIMD_V8_VIDCON1);
+   else
+   writel(ctx->vidcon1, ctx->regs + VIDCON1);

/* setup vertical timing values. */
val = VIDTCON0_VBPD(timing->upper_margin - 1) |
   VIDTCON0_VFPD(timing->lower_margin - 1) |
   VIDTCON0_VSPW(timing->vsync_len - 1);
-   writel(val, ctx->regs + VIDTCON0);
+   if (driver_data->fimd_ver == VERSION_8)
+   writel(val, ctx->regs + FIMD_V8_VIDTCON0);
+   else
+   writel(val, ctx->regs + VIDTCON0);

/* setup horizontal timing values.  */
val = VIDTCON1_HBPD(timing->left_margin - 1) |
   VIDTCON1_HFPD(timing->right_margin - 1) |
   VIDTCON1_HSPW(timing->hsync_len - 1);
-   writel(val, ctx->regs + VIDTCON1);
+   if (driver_data->fimd_ver == VERSION_8)
+   writel(val, ctx->regs + FIMD_V8_VIDTCON1);
+   else
+   writel(val, ctx->regs + VIDTCON1);

/* setup horizontal and vertical display size. */
val = VIDTCON2_LINEVAL(timing->yres - 1) |
   VIDTCON2_HOZVAL(timing->xres - 1);
-   writel(val, ctx->regs + VIDTCON2);
+   if (driver_data->fimd_ver == VERSION_8)
+   writel(val, ctx->regs + FIMD_V8_VIDTCON2);
+   else
+   writel(val, ctx->regs + VIDTCON2);

/* setup clock source, clock divider, enable dma. */
val = ctx->vidcon0;
@@ -982,6 +1016,17 @@ static int fimd_runtime_resume(struct device *dev)
 }
 #endif

+static struct platform_device_id exynos_drm_fimd_driver_ids[] = {
+   {
+   .name   = "exynos4-fb",
+   }, {
+   .name   = "exynos5-drm-fimd",
+   .driver_data= (unsigned long)_drm_fimd_driver_data,
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(platform, exynos_drm_fimd_driver_ids);
+
 static const struct dev_pm_ops fimd_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(fimd_suspend, fimd_resume)
SET_RUNTIME_PM_OPS(fimd_runtime_suspend, fimd_runtime_resume, NULL)
@@ -990,8 +1035,9 @@ static const struct dev_pm_ops fimd_pm_ops = {
 struct platform_driver fimd_driver = {
.probe  = fimd_probe,
.remove = __devexit_p(fimd_remove),
+   .id_table   = exynos_drm_fimd_driver_ids,
.driver = {
-   .name   = "exynos4-fb",
+   .name   = "exynos-drm-fimd",
.owner  = THIS_MODULE,
.pm = _pm_ops,
},
-- 
1.7.0.4

[PATCH V3 0/2] video: drm: Add Device tree support to DRM-FIMD

[Leela Krishna Amudala]

This patch set adds device tree support for DRM-FIMD for Samsung's Exynos5250.
It includes parsing platform data from dts file. Also, adds the driver data
for exynos5 device.

This patchset is based and tested on top of v3.6-rc1
Also depends on below patchset 
http://lists.freedesktop.org/archives/dri-devel/2012-August/026076.html

Changes since V2:
- Added driver data to exynos5-drm-fimd as per Marek Szyprowski 
suggestion

Changes since V1:
- Corrected typo errors and changed compatibility string

Leela Krishna Amudala (2):
  drm/exynos: add platform_device_id table and driver data for exynos5
drm fimd
  video: drm: exynos: Add device tree support

 Documentation/devicetree/bindings/fb/drm-fimd.txt |   80 +++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  151 -
 2 files changed, 224 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt

[Bug 45018] [bisected] rendering regression and va conflicts since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #121 from Alexandre Demers  
2012-08-16 15:35:45 UTC ---
(In reply to comment #120)
> (In reply to comment #119)
> > (In reply to comment #118)
> > 
> > Try the Mesa patches from
> > http://lists.freedesktop.org/archives/mesa-dev/2012-August/025715.html .
> 
> Testing right now.
> 
> May I suggest adding some debug info with an env variable switch to be able to
> track what the vm_mgr is doing, keeping and forgetting if this doesn't fix the
> problem or something similar?

I've been testing to reproduce latest VA issue all evening without being able
to. So if it doesn't finally fix the problem, your patches do help a lot. I'll
continue to test it tonight. Good to know your patches have been commited this
morning.

However, keep in mind I haven't tested anything for the other lockups (piglit
tests and some other OpenGL apps).

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

[Bug 50389] [radeonsi] Unknown type of argument: ../../../../i386-linux-gnu/egl/egl_gallium.so

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=50389

Michel D?nzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Michel D?nzer  2012-08-16 15:18:27 
UTC ---
Commit: 1b11395a36a44a902cfb3e1783758544662df73f
URL:   
http://cgit.freedesktop.org/mesa/mesa/commit/?id=1b11395a36a44a902cfb3e1783758544662df73f

Author: Michel D?nzer 
Date:   Thu Aug 16 10:37:44 2012 +0200

radeonsi: Fix symbol conflicts with r600g.

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

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #39 from Alexander E. Patrakov  2012-08-16 
15:16:18 UTC ---
Unfortunately, your specific patch does not apply to the 3.5 kernel, so I
cannot test this quickly. Now downloading your tree.

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

[PATCH 2/2] drm/radeon: split ATRM support out from the ATPX handler (v2)

[alexdeuc...@gmail.com]

From: Alex Deucher 

There are systems that use ATRM, but not ATPX.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41265

V2: fix #ifdefs as per Greg's comments

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon.h  |   15 -
 drivers/gpu/drm/radeon/radeon_atpx_handler.c |   56 +-
 drivers/gpu/drm/radeon/radeon_bios.c |   82 --
 3 files changed, 77 insertions(+), 76 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 9930419..59a1531 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -142,21 +142,6 @@ struct radeon_device;
 /*
  * BIOS.
  */
-#define ATRM_BIOS_PAGE 4096
-
-#if defined(CONFIG_VGA_SWITCHEROO)
-bool radeon_atrm_supported(struct pci_dev *pdev);
-int radeon_atrm_get_bios_chunk(uint8_t *bios, int offset, int len);
-#else
-static inline bool radeon_atrm_supported(struct pci_dev *pdev)
-{
-   return false;
-}
-
-static inline int radeon_atrm_get_bios_chunk(uint8_t *bios, int offset, int 
len){
-   return -EINVAL;
-}
-#endif
 bool radeon_get_bios(struct radeon_device *rdev);

 /*
diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c 
b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
index 98724fc..2a2cf0b 100644
--- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
+++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
@@ -30,57 +30,8 @@ static struct radeon_atpx_priv {
/* handle for device - and atpx */
acpi_handle dhandle;
acpi_handle atpx_handle;
-   acpi_handle atrm_handle;
 } radeon_atpx_priv;

-/* retrieve the ROM in 4k blocks */
-static int radeon_atrm_call(acpi_handle atrm_handle, uint8_t *bios,
-   int offset, int len)
-{
-   acpi_status status;
-   union acpi_object atrm_arg_elements[2], *obj;
-   struct acpi_object_list atrm_arg;
-   struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL};
-
-   atrm_arg.count = 2;
-   atrm_arg.pointer = _arg_elements[0];
-
-   atrm_arg_elements[0].type = ACPI_TYPE_INTEGER;
-   atrm_arg_elements[0].integer.value = offset;
-
-   atrm_arg_elements[1].type = ACPI_TYPE_INTEGER;
-   atrm_arg_elements[1].integer.value = len;
-
-   status = acpi_evaluate_object(atrm_handle, NULL, _arg, );
-   if (ACPI_FAILURE(status)) {
-   printk("failed to evaluate ATRM got %s\n", 
acpi_format_exception(status));
-   return -ENODEV;
-   }
-
-   obj = (union acpi_object *)buffer.pointer;
-   memcpy(bios+offset, obj->buffer.pointer, obj->buffer.length);
-   len = obj->buffer.length;
-   kfree(buffer.pointer);
-   return len;
-}
-
-bool radeon_atrm_supported(struct pci_dev *pdev)
-{
-   /* get the discrete ROM only via ATRM */
-   if (!radeon_atpx_priv.atpx_detected)
-   return false;
-
-   if (radeon_atpx_priv.dhandle == DEVICE_ACPI_HANDLE(>dev))
-   return false;
-   return true;
-}
-
-
-int radeon_atrm_get_bios_chunk(uint8_t *bios, int offset, int len)
-{
-   return radeon_atrm_call(radeon_atpx_priv.atrm_handle, bios, offset, 
len);
-}
-
 static int radeon_atpx_get_version(acpi_handle handle)
 {
acpi_status status;
@@ -198,7 +149,7 @@ static int radeon_atpx_power_state(enum 
vga_switcheroo_client_id id,

 static bool radeon_atpx_pci_probe_handle(struct pci_dev *pdev)
 {
-   acpi_handle dhandle, atpx_handle, atrm_handle;
+   acpi_handle dhandle, atpx_handle;
acpi_status status;

dhandle = DEVICE_ACPI_HANDLE(>dev);
@@ -209,13 +160,8 @@ static bool radeon_atpx_pci_probe_handle(struct pci_dev 
*pdev)
if (ACPI_FAILURE(status))
return false;

-   status = acpi_get_handle(dhandle, "ATRM", _handle);
-   if (ACPI_FAILURE(status))
-   return false;
-
radeon_atpx_priv.dhandle = dhandle;
radeon_atpx_priv.atpx_handle = atpx_handle;
-   radeon_atpx_priv.atrm_handle = atrm_handle;
return true;
 }

diff --git a/drivers/gpu/drm/radeon/radeon_bios.c 
b/drivers/gpu/drm/radeon/radeon_bios.c
index bf21f65..e97779d 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -32,9 +32,7 @@

 #include 
 #include 
-#ifdef CONFIG_ACPI
 #include 
-#endif
 /*
  * BIOS.
  */
@@ -101,16 +99,81 @@ static bool radeon_read_bios(struct radeon_device *rdev)
return true;
 }

+#ifdef CONFIG_ACPI
 /* ATRM is used to get the BIOS on the discrete cards in
  * dual-gpu systems.
  */
+/* retrieve the ROM in 4k blocks */
+#define ATRM_BIOS_PAGE 4096
+/**
+ * radeon_atrm_call - fetch a chunk of the vbios
+ *
+ * @atrm_handle: acpi ATRM handle
+ * @bios: vbios image pointer
+ * @offset: offset of vbios image data to fetch
+ * @len: length of vbios image data to fetch
+ *
+ * Executes ATRM to fetch a chunk of the discrete
+ * vbios image on PX systems (all asics).
+ 

[PATCH 1/2] drm/radeon: implement ACPI VFCT vbios fetch (v2)

[alexdeuc...@gmail.com]

From: David L 

This is required for pure UEFI systems.  The vbios is stored
in ACPI rather than at the legacy vga location.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=26891

V2: fix #ifdefs as per Greg's comments

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

diff --git a/drivers/gpu/drm/radeon/radeon_bios.c 
b/drivers/gpu/drm/radeon/radeon_bios.c
index 501f488..bf21f65 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -32,6 +32,9 @@

 #include 
 #include 
+#ifdef CONFIG_ACPI
+#include 
+#endif
 /*
  * BIOS.
  */
@@ -476,6 +479,63 @@ static bool radeon_read_disabled_bios(struct radeon_device 
*rdev)
return legacy_read_disabled_bios(rdev);
 }

+#ifdef CONFIG_ACPI
+static bool radeon_acpi_vfct_bios(struct radeon_device *rdev)
+{
+   bool ret = false;
+   struct acpi_table_header *hdr;
+   /* acpi_get_table_with_size is not exported :( */
+   acpi_size tbl_size = 0x7fff;
+   UEFI_ACPI_VFCT *vfct;
+   GOP_VBIOS_CONTENT *vbios;
+   VFCT_IMAGE_HEADER *vhdr;
+
+   if (!ACPI_SUCCESS(acpi_get_table("VFCT", 1, )))
+   return false;
+   if (tbl_size < sizeof(UEFI_ACPI_VFCT)) {
+   DRM_ERROR("ACPI VFCT table present but broken (too short 
#1)\n");
+   goto out_unmap;
+   }
+
+   vfct = (UEFI_ACPI_VFCT *)hdr;
+   if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) > tbl_size) {
+   DRM_ERROR("ACPI VFCT table present but broken (too short 
#2)\n");
+   goto out_unmap;
+   }
+
+   vbios = (GOP_VBIOS_CONTENT *)((char *)hdr + vfct->VBIOSImageOffset);
+   vhdr = >VbiosHeader;
+   DRM_INFO("ACPI VFCT contains a BIOS for %02x:%02x.%d %04x:%04x, size 
%d\n",
+   vhdr->PCIBus, vhdr->PCIDevice, vhdr->PCIFunction,
+   vhdr->VendorID, vhdr->DeviceID, vhdr->ImageLength);
+
+   if (vhdr->PCIBus != rdev->pdev->bus->number ||
+   vhdr->PCIDevice != PCI_SLOT(rdev->pdev->devfn) ||
+   vhdr->PCIFunction != PCI_FUNC(rdev->pdev->devfn) ||
+   vhdr->VendorID != rdev->pdev->vendor ||
+   vhdr->DeviceID != rdev->pdev->device) {
+   DRM_INFO("ACPI VFCT table is not for this card\n");
+   goto out_unmap;
+   };
+
+   if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) + 
vhdr->ImageLength > tbl_size) {
+   DRM_ERROR("ACPI VFCT image truncated\n");
+   goto out_unmap;
+   }
+
+   rdev->bios = kmemdup(>VbiosContent, vhdr->ImageLength, 
GFP_KERNEL);
+   ret = !!rdev->bios;
+
+out_unmap:
+   /* uh, no idea what to do here... */
+   return ret;
+}
+#else
+static bool radeon_acpi_vfct_bios(struct radeon_device *rdev)
+{
+   return false;
+}
+#endif

 bool radeon_get_bios(struct radeon_device *rdev)
 {
@@ -484,6 +544,8 @@ bool radeon_get_bios(struct radeon_device *rdev)

r = radeon_atrm_get_bios(rdev);
if (r == false)
+   r = radeon_acpi_vfct_bios(rdev);
+   if (r == false)
r = igp_read_bios_from_vram(rdev);
if (r == false)
r = radeon_read_bios(rdev);
-- 
1.7.7.5

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #38 from Alex Deucher  2012-08-16 14:31:38 UTC 
---
Please try the acpi_patches branch of my git tree:
http://cgit.freedesktop.org/~agd5f/linux/
Specifically this patch:
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=acpi_patches=6c0775d89cf6a39f4d155c8ad53067a0768e31e0

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

[PATCH 1/2] drm/radeon: implement ACPI VFCT vbios fetch

[Jerome Glisse]

On Thu, Aug 16, 2012 at 1:54 PM,   wrote:
> From: David L 
>
> This is required for pure UEFI systems.  The vbios is stored
> in ACPI rather than at the legacy vga location.
>
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=26891
>
> Signed-off-by: Alex Deucher 

Reviewed-by: Jerome Glisse 

> Cc: stable at vger.kernel.org
> ---
>  drivers/gpu/drm/radeon/radeon_bios.c |   59 
> ++
>  1 files changed, 59 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_bios.c 
> b/drivers/gpu/drm/radeon/radeon_bios.c
> index 501f488..f06494a7 100644
> --- a/drivers/gpu/drm/radeon/radeon_bios.c
> +++ b/drivers/gpu/drm/radeon/radeon_bios.c
> @@ -32,6 +32,9 @@
>
>  #include 
>  #include 
> +#ifdef CONFIG_ACPI
> +#include 
> +#endif
>  /*
>   * BIOS.
>   */
> @@ -476,6 +479,58 @@ static bool radeon_read_disabled_bios(struct 
> radeon_device *rdev)
> return legacy_read_disabled_bios(rdev);
>  }
>
> +#ifdef CONFIG_ACPI
> +static bool radeon_acpi_vfct_bios(struct radeon_device *rdev)
> +{
> +   bool ret = false;
> +   struct acpi_table_header *hdr;
> +   /* acpi_get_table_with_size is not exported :( */
> +   acpi_size tbl_size = 0x7fff;
> +   UEFI_ACPI_VFCT *vfct;
> +   GOP_VBIOS_CONTENT *vbios;
> +   VFCT_IMAGE_HEADER *vhdr;
> +
> +   if (!ACPI_SUCCESS(acpi_get_table("VFCT", 1, )))
> +   return false;
> +   if (tbl_size < sizeof(UEFI_ACPI_VFCT)) {
> +   DRM_ERROR("ACPI VFCT table present but broken (too short 
> #1)\n");
> +   goto out_unmap;
> +   }
> +
> +   vfct = (UEFI_ACPI_VFCT *)hdr;
> +   if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) > tbl_size) {
> +   DRM_ERROR("ACPI VFCT table present but broken (too short 
> #2)\n");
> +   goto out_unmap;
> +   }
> +
> +   vbios = (GOP_VBIOS_CONTENT *)((char *)hdr + vfct->VBIOSImageOffset);
> +   vhdr = >VbiosHeader;
> +   DRM_INFO("ACPI VFCT contains a BIOS for %02x:%02x.%d %04x:%04x, size 
> %d\n",
> +   vhdr->PCIBus, vhdr->PCIDevice, vhdr->PCIFunction,
> +   vhdr->VendorID, vhdr->DeviceID, vhdr->ImageLength);
> +
> +   if (vhdr->PCIBus != rdev->pdev->bus->number ||
> +   vhdr->PCIDevice != PCI_SLOT(rdev->pdev->devfn) ||
> +   vhdr->PCIFunction != PCI_FUNC(rdev->pdev->devfn) ||
> +   vhdr->VendorID != rdev->pdev->vendor ||
> +   vhdr->DeviceID != rdev->pdev->device) {
> +   DRM_INFO("ACPI VFCT table is not for this card\n");
> +   goto out_unmap;
> +   };
> +
> +   if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) + 
> vhdr->ImageLength > tbl_size) {
> +   DRM_ERROR("ACPI VFCT image truncated\n");
> +   goto out_unmap;
> +   }
> +
> +   rdev->bios = kmemdup(>VbiosContent, vhdr->ImageLength, 
> GFP_KERNEL);
> +   ret = !!rdev->bios;
> +
> +out_unmap:
> +   /* uh, no idea what to do here... */
> +   return ret;
> +}
> +#endif
>
>  bool radeon_get_bios(struct radeon_device *rdev)
>  {
> @@ -487,6 +542,10 @@ bool radeon_get_bios(struct radeon_device *rdev)
> r = igp_read_bios_from_vram(rdev);
> if (r == false)
> r = radeon_read_bios(rdev);
> +#ifdef CONFIG_ACPI
> +   if (r == false)
> +   r = radeon_acpi_vfct_bios(rdev);
> +#endif
> if (r == false) {
> r = radeon_read_disabled_bios(rdev);
> }
> --
> 1.7.7.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/radeon: split ATRM support out from the ATPX handler

[alexdeuc...@gmail.com]

From: Alex Deucher 

There are systems that use ATRM, but not ATPX.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41265

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon.h  |   15 -
 drivers/gpu/drm/radeon/radeon_atpx_handler.c |   56 +--
 drivers/gpu/drm/radeon/radeon_bios.c |   79 --
 3 files changed, 75 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index b70ec30..5dbd591 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -142,21 +142,6 @@ struct radeon_device;
 /*
  * BIOS.
  */
-#define ATRM_BIOS_PAGE 4096
-
-#if defined(CONFIG_VGA_SWITCHEROO)
-bool radeon_atrm_supported(struct pci_dev *pdev);
-int radeon_atrm_get_bios_chunk(uint8_t *bios, int offset, int len);
-#else
-static inline bool radeon_atrm_supported(struct pci_dev *pdev)
-{
-   return false;
-}
-
-static inline int radeon_atrm_get_bios_chunk(uint8_t *bios, int offset, int 
len){
-   return -EINVAL;
-}
-#endif
 bool radeon_get_bios(struct radeon_device *rdev);

 /*
diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c 
b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
index 98724fc..2a2cf0b 100644
--- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
+++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
@@ -30,57 +30,8 @@ static struct radeon_atpx_priv {
/* handle for device - and atpx */
acpi_handle dhandle;
acpi_handle atpx_handle;
-   acpi_handle atrm_handle;
 } radeon_atpx_priv;

-/* retrieve the ROM in 4k blocks */
-static int radeon_atrm_call(acpi_handle atrm_handle, uint8_t *bios,
-   int offset, int len)
-{
-   acpi_status status;
-   union acpi_object atrm_arg_elements[2], *obj;
-   struct acpi_object_list atrm_arg;
-   struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL};
-
-   atrm_arg.count = 2;
-   atrm_arg.pointer = _arg_elements[0];
-
-   atrm_arg_elements[0].type = ACPI_TYPE_INTEGER;
-   atrm_arg_elements[0].integer.value = offset;
-
-   atrm_arg_elements[1].type = ACPI_TYPE_INTEGER;
-   atrm_arg_elements[1].integer.value = len;
-
-   status = acpi_evaluate_object(atrm_handle, NULL, _arg, );
-   if (ACPI_FAILURE(status)) {
-   printk("failed to evaluate ATRM got %s\n", 
acpi_format_exception(status));
-   return -ENODEV;
-   }
-
-   obj = (union acpi_object *)buffer.pointer;
-   memcpy(bios+offset, obj->buffer.pointer, obj->buffer.length);
-   len = obj->buffer.length;
-   kfree(buffer.pointer);
-   return len;
-}
-
-bool radeon_atrm_supported(struct pci_dev *pdev)
-{
-   /* get the discrete ROM only via ATRM */
-   if (!radeon_atpx_priv.atpx_detected)
-   return false;
-
-   if (radeon_atpx_priv.dhandle == DEVICE_ACPI_HANDLE(>dev))
-   return false;
-   return true;
-}
-
-
-int radeon_atrm_get_bios_chunk(uint8_t *bios, int offset, int len)
-{
-   return radeon_atrm_call(radeon_atpx_priv.atrm_handle, bios, offset, 
len);
-}
-
 static int radeon_atpx_get_version(acpi_handle handle)
 {
acpi_status status;
@@ -198,7 +149,7 @@ static int radeon_atpx_power_state(enum 
vga_switcheroo_client_id id,

 static bool radeon_atpx_pci_probe_handle(struct pci_dev *pdev)
 {
-   acpi_handle dhandle, atpx_handle, atrm_handle;
+   acpi_handle dhandle, atpx_handle;
acpi_status status;

dhandle = DEVICE_ACPI_HANDLE(>dev);
@@ -209,13 +160,8 @@ static bool radeon_atpx_pci_probe_handle(struct pci_dev 
*pdev)
if (ACPI_FAILURE(status))
return false;

-   status = acpi_get_handle(dhandle, "ATRM", _handle);
-   if (ACPI_FAILURE(status))
-   return false;
-
radeon_atpx_priv.dhandle = dhandle;
radeon_atpx_priv.atpx_handle = atpx_handle;
-   radeon_atpx_priv.atrm_handle = atrm_handle;
return true;
 }

diff --git a/drivers/gpu/drm/radeon/radeon_bios.c 
b/drivers/gpu/drm/radeon/radeon_bios.c
index f06494a7..c36659a 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -101,16 +101,81 @@ static bool radeon_read_bios(struct radeon_device *rdev)
return true;
 }

+#ifdef CONFIG_ACPI
 /* ATRM is used to get the BIOS on the discrete cards in
  * dual-gpu systems.
  */
+/* retrieve the ROM in 4k blocks */
+#define ATRM_BIOS_PAGE 4096
+/**
+ * radeon_atrm_call - fetch a chunk of the vbios
+ *
+ * @atrm_handle: acpi ATRM handle
+ * @bios: vbios image pointer
+ * @offset: offset of vbios image data to fetch
+ * @len: length of vbios image data to fetch
+ *
+ * Executes ATRM to fetch a chunk of the discrete
+ * vbios image on PX systems (all asics).
+ * Returns the length of the buffer fetched.
+ */
+static int radeon_atrm_call(acpi_handle atrm_handle, uint8_t *bios,
+ 

[PATCH 1/2] drm/radeon: implement ACPI VFCT vbios fetch

[alexdeuc...@gmail.com]

From: David L 

This is required for pure UEFI systems.  The vbios is stored
in ACPI rather than at the legacy vga location.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=26891

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

diff --git a/drivers/gpu/drm/radeon/radeon_bios.c 
b/drivers/gpu/drm/radeon/radeon_bios.c
index 501f488..f06494a7 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -32,6 +32,9 @@

 #include 
 #include 
+#ifdef CONFIG_ACPI
+#include 
+#endif
 /*
  * BIOS.
  */
@@ -476,6 +479,58 @@ static bool radeon_read_disabled_bios(struct radeon_device 
*rdev)
return legacy_read_disabled_bios(rdev);
 }

+#ifdef CONFIG_ACPI
+static bool radeon_acpi_vfct_bios(struct radeon_device *rdev)
+{
+   bool ret = false;
+   struct acpi_table_header *hdr;
+   /* acpi_get_table_with_size is not exported :( */
+   acpi_size tbl_size = 0x7fff;
+   UEFI_ACPI_VFCT *vfct;
+   GOP_VBIOS_CONTENT *vbios;
+   VFCT_IMAGE_HEADER *vhdr;
+
+   if (!ACPI_SUCCESS(acpi_get_table("VFCT", 1, )))
+   return false;
+   if (tbl_size < sizeof(UEFI_ACPI_VFCT)) {
+   DRM_ERROR("ACPI VFCT table present but broken (too short 
#1)\n");
+   goto out_unmap;
+   }
+
+   vfct = (UEFI_ACPI_VFCT *)hdr;
+   if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) > tbl_size) {
+   DRM_ERROR("ACPI VFCT table present but broken (too short 
#2)\n");
+   goto out_unmap;
+   }
+
+   vbios = (GOP_VBIOS_CONTENT *)((char *)hdr + vfct->VBIOSImageOffset);
+   vhdr = >VbiosHeader;
+   DRM_INFO("ACPI VFCT contains a BIOS for %02x:%02x.%d %04x:%04x, size 
%d\n",
+   vhdr->PCIBus, vhdr->PCIDevice, vhdr->PCIFunction,
+   vhdr->VendorID, vhdr->DeviceID, vhdr->ImageLength);
+
+   if (vhdr->PCIBus != rdev->pdev->bus->number ||
+   vhdr->PCIDevice != PCI_SLOT(rdev->pdev->devfn) ||
+   vhdr->PCIFunction != PCI_FUNC(rdev->pdev->devfn) ||
+   vhdr->VendorID != rdev->pdev->vendor ||
+   vhdr->DeviceID != rdev->pdev->device) {
+   DRM_INFO("ACPI VFCT table is not for this card\n");
+   goto out_unmap;
+   };
+
+   if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) + 
vhdr->ImageLength > tbl_size) {
+   DRM_ERROR("ACPI VFCT image truncated\n");
+   goto out_unmap;
+   }
+
+   rdev->bios = kmemdup(>VbiosContent, vhdr->ImageLength, 
GFP_KERNEL);
+   ret = !!rdev->bios;
+
+out_unmap:
+   /* uh, no idea what to do here... */
+   return ret;
+}
+#endif

 bool radeon_get_bios(struct radeon_device *rdev)
 {
@@ -487,6 +542,10 @@ bool radeon_get_bios(struct radeon_device *rdev)
r = igp_read_bios_from_vram(rdev);
if (r == false)
r = radeon_read_bios(rdev);
+#ifdef CONFIG_ACPI
+   if (r == false)
+   r = radeon_acpi_vfct_bios(rdev);
+#endif
if (r == false) {
r = radeon_read_disabled_bios(rdev);
}
-- 
1.7.7.5

[PATCH 1/2] drm/radeon: implement ACPI VFCT vbios fetch (v2)

[Greg KH]

On Thu, Aug 16, 2012 at 03:13:46PM -0400, alexdeucher at gmail.com wrote:
> From: David L 
> 
> This is required for pure UEFI systems.  The vbios is stored
> in ACPI rather than at the legacy vga location.
> 
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=26891
> 
> V2: fix #ifdefs as per Greg's comments
> 
> Signed-off-by: Alex Deucher 
> Cc: stable at vger.kernel.org
> ---
>  drivers/gpu/drm/radeon/radeon_bios.c |   62 
> ++
>  1 files changed, 62 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_bios.c 
> b/drivers/gpu/drm/radeon/radeon_bios.c
> index 501f488..bf21f65 100644
> --- a/drivers/gpu/drm/radeon/radeon_bios.c
> +++ b/drivers/gpu/drm/radeon/radeon_bios.c
> @@ -32,6 +32,9 @@
>  
>  #include 
>  #include 
> +#ifdef CONFIG_ACPI
> +#include 
> +#endif

You forgot to remove this one :(

>  /*
>   * BIOS.
>   */
> @@ -476,6 +479,63 @@ static bool radeon_read_disabled_bios(struct 
> radeon_device *rdev)
>   return legacy_read_disabled_bios(rdev);
>  }
>  
> +#ifdef CONFIG_ACPI
> +static bool radeon_acpi_vfct_bios(struct radeon_device *rdev)
> +{
> + bool ret = false;
> + struct acpi_table_header *hdr;
> + /* acpi_get_table_with_size is not exported :( */
> + acpi_size tbl_size = 0x7fff;
> + UEFI_ACPI_VFCT *vfct;
> + GOP_VBIOS_CONTENT *vbios;
> + VFCT_IMAGE_HEADER *vhdr;
> +
> + if (!ACPI_SUCCESS(acpi_get_table("VFCT", 1, )))
> + return false;
> + if (tbl_size < sizeof(UEFI_ACPI_VFCT)) {
> + DRM_ERROR("ACPI VFCT table present but broken (too short 
> #1)\n");
> + goto out_unmap;
> + }
> +
> + vfct = (UEFI_ACPI_VFCT *)hdr;
> + if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) > tbl_size) {
> + DRM_ERROR("ACPI VFCT table present but broken (too short 
> #2)\n");
> + goto out_unmap;
> + }
> +
> + vbios = (GOP_VBIOS_CONTENT *)((char *)hdr + vfct->VBIOSImageOffset);
> + vhdr = >VbiosHeader;
> + DRM_INFO("ACPI VFCT contains a BIOS for %02x:%02x.%d %04x:%04x, size 
> %d\n",
> + vhdr->PCIBus, vhdr->PCIDevice, vhdr->PCIFunction,
> + vhdr->VendorID, vhdr->DeviceID, vhdr->ImageLength);
> +
> + if (vhdr->PCIBus != rdev->pdev->bus->number ||
> + vhdr->PCIDevice != PCI_SLOT(rdev->pdev->devfn) ||
> + vhdr->PCIFunction != PCI_FUNC(rdev->pdev->devfn) ||
> + vhdr->VendorID != rdev->pdev->vendor ||
> + vhdr->DeviceID != rdev->pdev->device) {
> + DRM_INFO("ACPI VFCT table is not for this card\n");
> + goto out_unmap;
> + };
> +
> + if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) + 
> vhdr->ImageLength > tbl_size) {
> + DRM_ERROR("ACPI VFCT image truncated\n");
> + goto out_unmap;
> + }
> +
> + rdev->bios = kmemdup(>VbiosContent, vhdr->ImageLength, 
> GFP_KERNEL);
> + ret = !!rdev->bios;
> +
> +out_unmap:
> + /* uh, no idea what to do here... */
> + return ret;
> +}
> +#else
> +static bool radeon_acpi_vfct_bios(struct radeon_device *rdev)

Make it inline, and then the compiler is smart enough to just delete the
whole if () check you make when you call it.

Third time's a charm?

greg k-h

[PATCH] drm/edid: limit printk when facing bad edid

[Jerome Glisse]

On Thu, Aug 16, 2012 at 11:13 AM, Jani Nikula
 wrote:
>
> There's a bug [1] where the faster GMBUS transmissions fail with some
> CRTs, and the fix [2] is to fallback to GPIO bit-banging upon errors. As
> noted in the bug, the fix still leaves plenty of EDID dumps in dmesg, so
> some measures to reduce the EDID error messages would be most welcome.
>
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=45881
> [2] http://thread.gmane.org/gmane.linux.kernel/1332810/focus=1341912
>
> On Tue, 14 Aug 2012, Jerome Glisse  wrote:
>> On Tue, Aug 14, 2012 at 10:54 AM, Adam Jackson  wrote:
>>> On 8/9/12 11:25 AM, j.glisse at gmail.com wrote:

 From: Jerome Glisse 

 Limit printing bad edid information at one time per connector.
 Connector that are connected to a bad monitor/kvm will likely
 stay connected to the same bad monitor/kvm and it makes no
 sense to keep printing the bad edid message.
>
> Do I understand correctly that bad_edid_counter is only reset when you
> reboot or reload the module? So if you have a laptop that you connect to
> the monitor at home, the monitor at the office, the projector in the
> meeting room, and to a TV somewhere else, etc, the message about bad
> EDID will only printed once? I don't think that's good. But please do
> correct me if I'm wrong.

I wanted to reset the counter any time the connector is connected to
something with good edid but i did not do that in the end. I can do a
patch on top if you think it would be nicer. That way only thing with
bad edid will be printed once and assuming you don't repeatly
alternate btw good and bad edid device you would not get spam.


 Signed-off-by: Jerome Glisse 
>>>
>>>
>>> I guess.  I don't see why we don't just move it into DRM_DEBUG_KMS if we're
>>> going to suppress it, but this does what it says on the box.
>>>
>>> Reviewed-by: Adam Jackson 
>>>
>>> - ajax
>>>
>>
>> I think there is still value in getting at least once the bad edid.
>
> I think the raw edid dumps should be DEBUG level no matter what. Perhaps
> some of the other messages could use WARNING/DEBUG too. And with that,
> and my comment above, I not sure there really needs to be all that logic
> to count errors and act differently further on.
>

No, i do think we want bad edid as normal log at least once per
connector and we definitely don't want to spam bomb the log messages.

Cheers,
Jerome

radeon testing

[Alex Deucher]

I've gathered up the various outstanding radeon patches and put them
up in a tree for testing:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip
Some of these may end up in -fixes, but most of them are -next
material.  I haven't had a chance to go through Christian's last set
of VM patches yet.

Highlights:
- rom fetch fixes (UEFI, thunderbolt docks)
- major ACPI rework
- backlight control for newer asics

Alex

[PATCH 2/2] drm/radeon: split ATRM support out from the ATPX handler

[Greg KH]

On Thu, Aug 16, 2012 at 01:54:56PM -0400, alexdeucher at gmail.com wrote:
> From: Alex Deucher 
> 
> There are systems that use ATRM, but not ATPX.
> 
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=41265

Same #ifdef comments here as for patch 1/2.

thanks,

greg k-h

[PATCH 1/2] drm/radeon: implement ACPI VFCT vbios fetch

[Greg KH]

On Thu, Aug 16, 2012 at 01:54:55PM -0400, alexdeucher at gmail.com wrote:
> From: David L 
> 
> This is required for pure UEFI systems.  The vbios is stored
> in ACPI rather than at the legacy vga location.
> 
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=26891
> 
> Signed-off-by: Alex Deucher 
> Cc: stable at vger.kernel.org
> ---
>  drivers/gpu/drm/radeon/radeon_bios.c |   59 
> ++
>  1 files changed, 59 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_bios.c 
> b/drivers/gpu/drm/radeon/radeon_bios.c
> index 501f488..f06494a7 100644
> --- a/drivers/gpu/drm/radeon/radeon_bios.c
> +++ b/drivers/gpu/drm/radeon/radeon_bios.c
> @@ -32,6 +32,9 @@
>  
>  #include 
>  #include 
> +#ifdef CONFIG_ACPI
> +#include 
> +#endif

This #ifdef should not be needed, right?


> +#ifdef CONFIG_ACPI
> +static bool radeon_acpi_vfct_bios(struct radeon_device *rdev)
> +{
> + bool ret = false;
> + struct acpi_table_header *hdr;
> + /* acpi_get_table_with_size is not exported :( */
> + acpi_size tbl_size = 0x7fff;
> + UEFI_ACPI_VFCT *vfct;
> + GOP_VBIOS_CONTENT *vbios;
> + VFCT_IMAGE_HEADER *vhdr;
> +
> + if (!ACPI_SUCCESS(acpi_get_table("VFCT", 1, )))
> + return false;
> + if (tbl_size < sizeof(UEFI_ACPI_VFCT)) {
> + DRM_ERROR("ACPI VFCT table present but broken (too short 
> #1)\n");
> + goto out_unmap;
> + }
> +
> + vfct = (UEFI_ACPI_VFCT *)hdr;
> + if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) > tbl_size) {
> + DRM_ERROR("ACPI VFCT table present but broken (too short 
> #2)\n");
> + goto out_unmap;
> + }
> +
> + vbios = (GOP_VBIOS_CONTENT *)((char *)hdr + vfct->VBIOSImageOffset);
> + vhdr = >VbiosHeader;
> + DRM_INFO("ACPI VFCT contains a BIOS for %02x:%02x.%d %04x:%04x, size 
> %d\n",
> + vhdr->PCIBus, vhdr->PCIDevice, vhdr->PCIFunction,
> + vhdr->VendorID, vhdr->DeviceID, vhdr->ImageLength);
> +
> + if (vhdr->PCIBus != rdev->pdev->bus->number ||
> + vhdr->PCIDevice != PCI_SLOT(rdev->pdev->devfn) ||
> + vhdr->PCIFunction != PCI_FUNC(rdev->pdev->devfn) ||
> + vhdr->VendorID != rdev->pdev->vendor ||
> + vhdr->DeviceID != rdev->pdev->device) {
> + DRM_INFO("ACPI VFCT table is not for this card\n");
> + goto out_unmap;
> + };
> +
> + if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) + 
> vhdr->ImageLength > tbl_size) {
> + DRM_ERROR("ACPI VFCT image truncated\n");
> + goto out_unmap;
> + }
> +
> + rdev->bios = kmemdup(>VbiosContent, vhdr->ImageLength, 
> GFP_KERNEL);
> + ret = !!rdev->bios;
> +
> +out_unmap:
> + /* uh, no idea what to do here... */
> + return ret;
> +}
> +#endif

Please provide an "empty" function here if the #ifdef is not true, which
then makes the following #ifdef not needed:

> @@ -487,6 +542,10 @@ bool radeon_get_bios(struct radeon_device *rdev)
>   r = igp_read_bios_from_vram(rdev);
>   if (r == false)
>   r = radeon_read_bios(rdev);
> +#ifdef CONFIG_ACPI
> + if (r == false)
> + r = radeon_acpi_vfct_bios(rdev);
> +#endif

See, then that #ifdef isn't needed.

That cleans up the code more, remember, we don't want #ifdefs in .c
files unless we _really_ have to have them.

thanks,

greg k-h

[PATCH V5 13/18] drm: Define SAREA_MAX for Loongson (PageSize = 16KB).

[Huacai Chen]

On Thu, Aug 16, 2012 at 9:58 AM, Matt Turner  wrote:
> On Sat, Aug 11, 2012 at 2:32 AM, Huacai Chen  wrote:
>> Signed-off-by: Huacai Chen 
>> Signed-off-by: Hongliang Tao 
>> Signed-off-by: Hua Yan 
>> Cc: dri-devel at lists.freedesktop.org
>> ---
>>  include/drm/drm_sarea.h |2 ++
>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h
>> index ee5389d..1d1a858 100644
>> --- a/include/drm/drm_sarea.h
>> +++ b/include/drm/drm_sarea.h
>> @@ -37,6 +37,8 @@
>>  /* SAREA area needs to be at least a page */
>>  #if defined(__alpha__)
>>  #define SAREA_MAX   0x2000U
>> +#elif defined(__mips__)
>> +#define SAREA_MAX   0x4000U
>>  #elif defined(__ia64__)
>>  #define SAREA_MAX   0x1U   /* 64kB */
>>  #else
>> --
>> 1.7.7.3
>
> SAREA is a DRI-1 concept. The Radeon drivers you're using is DRI-2, so
> what do you need this for? All the DRI-1 drivers have been removed
> from Mesa, so I think the answer is nothing.

This patch will be drop, thank you.

[Bug 29572] Radeon card reports wrong temperature when switched off

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=29572


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




-- 
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 29372] KMS - radeon (Uhhuh. NMI received for unknown reason)

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=29372


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




--- Comment #3 from Alan   2012-08-16 11:00:21 ---
If this is still seen with a modern (3.2 etc) kernel please updare/re-open
thanks

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

[PATCH 1/3] drm: Add missing static storage class specifiers in drm_proc.c file

[Sachin Kamat]

Hi,

Any comments on this series?

Regards
Sachin

On 1 August 2012 17:15, Sachin Kamat  wrote:
> Fixes the following sparse warning:
> drivers/gpu/drm/drm_proc.c:92:5:
> warning: symbol 'drm_proc_create_files' was not declared. Should it be static?
> drivers/gpu/drm/drm_proc.c:175:5:
> warning: symbol 'drm_proc_remove_files' was not declared. Should it be static?
>
> Signed-off-by: Sachin Kamat 
> ---
>  drivers/gpu/drm/drm_proc.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
> index 371c695..da457b1 100644
> --- a/drivers/gpu/drm/drm_proc.c
> +++ b/drivers/gpu/drm/drm_proc.c
> @@ -89,7 +89,7 @@ static const struct file_operations drm_proc_fops = {
>   * Create a given set of proc files represented by an array of
>   * gdm_proc_lists in the given root directory.
>   */
> -int drm_proc_create_files(struct drm_info_list *files, int count,
> +static int drm_proc_create_files(struct drm_info_list *files, int count,
>   struct proc_dir_entry *root, struct drm_minor 
> *minor)
>  {
> struct drm_device *dev = minor->dev;
> @@ -172,7 +172,7 @@ int drm_proc_init(struct drm_minor *minor, int minor_id,
> return 0;
>  }
>
> -int drm_proc_remove_files(struct drm_info_list *files, int count,
> +static int drm_proc_remove_files(struct drm_info_list *files, int count,
>   struct drm_minor *minor)
>  {
> struct list_head *pos, *q;
> --
> 1.7.4.1
>

[PATCH] drm: Check for invalid cursor flags

[Jakob Bornecrantz]

Signed-off-by: Jakob Bornecrantz 
---
 drivers/gpu/drm/drm_crtc.c |2 +-
 include/drm/drm_mode.h |5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 08a7aa7..6fbfc24 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1981,7 +1981,7 @@ int drm_mode_cursor_ioctl(struct drm_device *dev,
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;

-   if (!req->flags)
+   if (!req->flags || (~DRM_MODE_CURSOR_FLAGS & req->flags))
return -EINVAL;

mutex_lock(>mode_config.mutex);
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 5581980..3d6301b 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -359,8 +359,9 @@ struct drm_mode_mode_cmd {
struct drm_mode_modeinfo mode;
 };

-#define DRM_MODE_CURSOR_BO (1<<0)
-#define DRM_MODE_CURSOR_MOVE   (1<<1)
+#define DRM_MODE_CURSOR_BO 0x01
+#define DRM_MODE_CURSOR_MOVE   0x02
+#define DRM_MODE_CURSOR_FLAGS  0x03

 /*
  * depending on the value in flags different members are used.
-- 
1.7.9.5

[PATCH] drm/i915: implement dma buf begin_cpu_access (v2)

[Dave Airlie]

From: Dave Airlie 

In order for udl vmap to work properly, we need to push the object
into the CPU domain before we start copying the data to the USB device.

This along with the udl change avoids userspace explicit mapping to
be used.

v2: add a flag for userspace to query to know if Intel kernel driver can
deal with the vmap flushing properly. In theory udl would need a flag also,
but I intend to push the patches very close to each other and other drivers
should do the right thing from the start.

I've added a test to my intel-gpu-tools prime branch, however testing
this is a bit messy since the only way to get udl to vmap is to rendering
something. I've tested this with real code as well to make sure it works.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/i915/i915_dma.c|3 +++
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |   17 +
 include/drm/i915_drm.h |1 +
 3 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 36822b9..1a0e112 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1006,6 +1006,9 @@ static int i915_getparam(struct drm_device *dev, void 
*data,
case I915_PARAM_HAS_ALIASING_PPGTT:
value = dev_priv->mm.aliasing_ppgtt ? 1 : 0;
break;
+   case I915_PARAM_HAS_PRIME_VMAP_FLUSH:
+   value = 1;
+   break;
default:
DRM_DEBUG_DRIVER("Unknown parameter %d\n",
 param->param);
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index cf6bdec..ee51c63 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -147,6 +147,22 @@ static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, 
struct vm_area_struct *
return -EINVAL;
 }

+static int i915_gem_begin_cpu_access(struct dma_buf *dma_buf, size_t start, 
size_t length, enum dma_data_direction direction)
+{
+   struct drm_i915_gem_object *obj = dma_buf->priv;
+   struct drm_device *dev = obj->base.dev;
+   int ret;
+   bool write = (direction == DMA_BIDIRECTIONAL || direction == 
DMA_TO_DEVICE);
+
+   ret = i915_mutex_lock_interruptible(dev);
+   if (ret)
+   return ret;
+
+   ret = i915_gem_object_set_to_cpu_domain(obj, write);
+   mutex_unlock(>struct_mutex);
+   return ret;
+}
+
 static const struct dma_buf_ops i915_dmabuf_ops =  {
.map_dma_buf = i915_gem_map_dma_buf,
.unmap_dma_buf = i915_gem_unmap_dma_buf,
@@ -158,6 +174,7 @@ static const struct dma_buf_ops i915_dmabuf_ops =  {
.mmap = i915_gem_dmabuf_mmap,
.vmap = i915_gem_dmabuf_vmap,
.vunmap = i915_gem_dmabuf_vunmap,
+   .begin_cpu_access = i915_gem_begin_cpu_access,
 };

 struct dma_buf *i915_gem_prime_export(struct drm_device *dev,
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index f3f8224..8df848b 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -298,6 +298,7 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_HAS_GEN7_SOL_RESET   16
 #define I915_PARAM_HAS_LLC  17
 #define I915_PARAM_HAS_ALIASING_PPGTT   18
+#define I915_PARAM_HAS_PRIME_VMAP_FLUSH 19

 typedef struct drm_i915_getparam {
int param;
-- 
1.7.10.2

[PATCH 2/3] drm/udl: call begin/end cpu access at more appropriate time

[Daniel Vetter]

On Mon, Jul 30, 2012 at 02:06:55PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> We need to call these before we transfer the damaged areas to the device
> not before/after we setup the long lived vmaps.
> 
> Signed-off-by: Dave Airlie 

As discussed on irc, I've applied this patch here and the corresponding
fix in i915 to make the begin/end_cpu_access stuff work to drm-intel-next.
I've left patch 3 of this series for you to handle.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #37 from gyhor at gmx.de 2012-08-16 10:08:23 UTC ---
I am not sure. In function radeon_atpx_pci_probe_handle() do get the
DEVICE_ACPI_HANDLE:

dhandle = DEVICE_ACPI_HANDLE(>dev);

It fails with 
status = acpi_get_handle(dhandle, "ATPX", _handle);


btw it is kernel 3.5RC7

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

[PATCH v3 1/3] Rename i2f() to int2float(), and make it global so one copy can be removed.

[Michel Dänzer]

On Mit, 2012-08-15 at 15:07 -0700, Steven Fuerst wrote: 
> Remove the copy of i2f() in r600_blit_kms.c
> We rename the function to something longer now that it is a global
> symbol.  This reduces the likelyhood of unintended clashes later.
> 
> This might be a candidate for inclusion inside general drm infrastructure.
> However, at the moment only the radeon driver uses it.
> 
> Signed-off-by: Steven Fuerst 

For the series:

Reviewed-by: Michel D?nzer 


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #36 from Alexander E. Patrakov  2012-08-16 
09:26:59 UTC ---
OK. So the bug is that the Sony BIOS provides ATRM, but not ATPX.

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

[PATCH V5 13/18] drm: Define SAREA_MAX for Loongson (PageSize = 16KB).

[Huacai Chen]

On Thu, Aug 16, 2012 at 5:31 AM, Ralf Baechle  wrote:
> On Sat, Aug 11, 2012 at 05:32:18PM +0800, Huacai Chen wrote:
>
>> Subject: [PATCH V5 13/18] drm: Define SAREA_MAX for Loongson (PageSize = 
>> 16KB).
>
> But your code doesn't define it just for Loongsson as the log message claims
> but rather for all MIPS.
>
>> diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h
>> index ee5389d..1d1a858 100644
>> --- a/include/drm/drm_sarea.h
>> +++ b/include/drm/drm_sarea.h
>> @@ -37,6 +37,8 @@
>>  /* SAREA area needs to be at least a page */
>>  #if defined(__alpha__)
>>  #define SAREA_MAX   0x2000U
>> +#elif defined(__mips__)
>> +#define SAREA_MAX   0x4000U
>
> How about replacing this whole #ifdef mess with something like:
>
> #include 
> #include 
>
> /* Intel 830M driver needs at least 8k SAREA */
> #define SAREA_MAX   max(PAGE_SIZE, 0x2000U)
>
> MIPS also uses 64K page size and your patch as posted would break with 64k
> pages.
Yes, I think this is better. Thank you.
>
>   Ralf

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #35 from gyhor at gmx.de 2012-08-16 08:39:35 UTC ---
Function radeon_atrm_call() would not be called, because 
if (!radeon_atrm_supported(rdev->pdev)) 
returns false.

Thats because this is returns null:
(!radeon_atpx_priv.atpx_detected)

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

[PATCH 2/2] Expose the OMAP Z-Order property through DRM

[Rob Clark]

On Thu, Aug 16, 2012 at 8:00 AM, Ville Syrj?l?
 wrote:
> On Wed, Aug 15, 2012 at 03:18:02PM -0500, Rob Clark wrote:
>> From: Andre Renaud 
>>
>> Added support for zorder changes through DRM plane properties
>>
>> Signed-off-by: Andre Renaud 
>> Signed-off-by: Rob Clark 
>> ---
>>  drivers/staging/omapdrm/omap_drv.h   |1 +
>>  drivers/staging/omapdrm/omap_plane.c |   19 +++
>>  2 files changed, 20 insertions(+)
>>
>> diff --git a/drivers/staging/omapdrm/omap_drv.h 
>> b/drivers/staging/omapdrm/omap_drv.h
>> index b103d28..9dc72d1 100644
>> --- a/drivers/staging/omapdrm/omap_drv.h
>> +++ b/drivers/staging/omapdrm/omap_drv.h
>> @@ -62,6 +62,7 @@ struct omap_drm_private {
>>
>>   /* properties: */
>>   struct drm_property *rotation_prop;
>> + struct drm_property *zorder_prop;
>>  };
>>
>>  /* this should probably be in drm-core to standardize amongst drivers */
>> diff --git a/drivers/staging/omapdrm/omap_plane.c 
>> b/drivers/staging/omapdrm/omap_plane.c
>> index 6931d06..4bde639 100644
>> --- a/drivers/staging/omapdrm/omap_plane.c
>> +++ b/drivers/staging/omapdrm/omap_plane.c
>> @@ -433,6 +433,15 @@ void omap_plane_install_properties(struct drm_plane 
>> *plane,
>>   priv->rotation_prop = prop;
>>   }
>>   drm_object_attach_property(obj, prop, 0);
>> +
>> +prop = priv->zorder_prop;
>> +if (!prop) {
>> + prop = drm_property_create_range(dev, 0, "zorder", 0, 3);
>> + if (prop == NULL)
>> + return;
>> + priv->zorder_prop = prop;
>> + }
>> + drm_object_attach_property(obj, prop, 0);
>>  }
>>
>>  int omap_plane_set_property(struct drm_plane *plane,
>> @@ -452,6 +461,16 @@ int omap_plane_set_property(struct drm_plane *plane,
>>   ret = omap_plane_dpms(plane, DRM_MODE_DPMS_ON);
>>   else
>>   ret = 0;
>> + } else if (property == priv->zorder_prop) {
>> + struct omap_overlay *ovl = omap_plane->ovl;
>> +
>> + DBG("%s: zorder: %d", ovl->name, (uint32_t)val);
>> + omap_plane->info.zorder = val;
>
> What would happen when there's a conflicting assignment between two
> planes?

non-good things.. basically as part of re-working the
omapdss<->omapdrm stuff, I'll have a good point in omapdrm before
setting GO bit(s) where I can calculate the actual z-order from that
is set from userspace.  If two planes had same z-order from userspace,
omapdrm would simply put one in front of the other.  If the planes
aren't overlapping, this is fine.

> I tried to think of a decent way to do this stuff, but some hardware
> can have rather complicated stacking order limitations. One idea I
> came up with was to have an enum prop on the crtc, where the individual
> enum value names would somehow describe the whole stacking order within
> the crtc. That way user space couldn't even try to use an unsupported
> configuration. The downside is that user space would need to parse
> those strings if it wants to do some automagic stacking order changes,
> which means the string format would need some though.

I was thinking about this, but then you run into the same issue if you
move a plane from one CRTC to another without userspace setting the
property again.  In the end if userspace is ambiguous the driver has
to just arbitrarily pick some z-order to keep the hw happy.

BR,
-R

> --
> Ville Syrj?l?
> Intel OTC
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[git pull] more drm fixes

[Dave Airlie]

Just some intel and nouveau ones this time, intel has more edp panel fixes 
for macbooks and nouveau has a suspend/resume regression fix in there.

Dave.

The following changes since commit 7bac6b46607f2f44075cb45dd5b0b4d2e7c80695:

  Merge branch 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2012-08-14 09:25:01 +1000)

are available in the git repository at:


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

for you to fetch changes up to 2e26c73a1e410448fbd2c0fbd34f06d98eaf8e48:

  Merge branch 'drm-nouveau-fixes' of 
git://git.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2012-08-15 
20:31:22 +1000)



Ben Skeggs (2):
  drm/nve0/fifo: add support for the flip completion swmthd
  drm/nouveau/aux: mask off higher bits of auxch index in i2c table entry

Chris Wilson (1):
  drm/i915: Apply post-sync write for pipe control invalidates

Christoph Bumiller (1):
  drm/nvd0/disp: mask off high 16 bit of negative cursor x-coordinate

Daniel Vetter (2):
  drm/i915: ignore eDP bpc settings from vbt
  drm/i915: reorder edp disabling to fix ivb MacBook Air

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

Henrik Rydberg (1):
  drm/nouveau: disable copy engine on NVAF

Jani Nikula (1):
  drm/i915: ensure i2c adapter is all set before adding it

Maarten Lankhorst (1):
  nouveau: fixup scanout enable in nvc0_pm

Maxim Levitsky (1):
  drm/nv86/fifo: suspend fix

Takashi Iwai (1):
  drm/i915: Fix blank panel at reopening lid

 drivers/gpu/drm/i915/intel_display.c|   11 -
 drivers/gpu/drm/i915/intel_dp.c |   14 +--
 drivers/gpu/drm/i915/intel_i2c.c|7 +++---
 drivers/gpu/drm/i915/intel_panel.c  |   13 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.c |   41 +--
 drivers/gpu/drm/nouveau/nouveau_i2c.c   |2 +-
 drivers/gpu/drm/nouveau/nouveau_state.c |1 -
 drivers/gpu/drm/nouveau/nv84_fifo.c |9 +++
 drivers/gpu/drm/nouveau/nvc0_pm.c   |2 +-
 drivers/gpu/drm/nouveau/nvd0_display.c  |2 +-
 drivers/gpu/drm/nouveau/nve0_fifo.c |   37 +---
 11 files changed, 88 insertions(+), 51 deletions(-)

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #34 from Alexander E. Patrakov  2012-08-16 
05:34:28 UTC ---
In the acpidump output, there is ATRM method. I will try to add debug printks
to  radeon_atrm_call() and report back.

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

[Linaro-mm-sig] [PATCH 4/4] dma-buf-mgr: multiple dma-buf synchronization (v3)

[Daniel Vetter]

Hi Maarten,

Ok, here comes the promised review (finally!), but it's rather a
high-level thingy. I've mostly thought about how we could create a neat
api with the following points. For a bit of clarity, I've grouped the
different considerations a bit.

Easy Integration


Where I mean integration of simple dma_buf importers that don't want to
deal with all the hassle of dma_fence (like v4l framegrabbers). Or drivers
where everything interesting needs cpu access anyway (like the udl
driver). The case with explicitly handling dma_fences and going through
the reservation dance should be the explicitly requested special cases.

I'm thinking of adding a new dma_buf_attach_special function which takes
an additional flags parameter (since we might need some other funky
extension later on ...). A new flag ASYNC_ATTACHMENT would indicate that
the driver will use this attachment with the dma_bufmgr and will use
dma_fences to sync with other drivers (which is also stored in a new flag
in the attachment struct).

To ensure we can have mixed attachments we need to ensure that all other
access (and also cpu access) sync up with any dma_fences left behind by
drivers with async attachments (think e.g. nouveau render, but both intel
and udl displaying a buffer). Note that we don't need any exclusion, but
only barriers, i.e. if anyone sneaks in other rendering while an dma
access from a synchronous client is underway, we don't need to care.

The same needs to happen for cpu access obviously.

Since both the cpu access functions (begin/end_cpu_access) and the device
access functions (which atm are on map/unmap_attachment) have a direction
attribute, we can even differentiate between read (i.e. shared) access and
write (i.e. exclusive) access. Note that the dma_fence syncing needs to
happen before we call the exporter's callbacks, otherwise any cache
flushing/invalidation the exporter does might not yet see all rendering.

Imo it would be good to split this up into a separate patch with:
- adding the dma_fence members to struct dma_buf (but with no way yet to
  set them).
- adding a quick helper to wait for fences attached to a dma_buf (either
  shared or exclusive access).
- adding the synchronous bool to the attachment struct, setting it by
  default and wiring, again with no way yet to use async attachments.
- we also need to add the dma_bufmgr_spinlock, since this is what protects
  the fences attached to a dma_buf for read access (at least that's my
  understanding).

Aside: This doesn't make too much sense since most drivers cheat and just
hang onto the attachment mapping (instead of doing map/unmap for each
access as the spec says they should ...). So there's no way actually for
drivers to /simply/ sync up. But the lack of a streaming api (i.e. setting
the coherency domain without map/unmap) is a known lack in the dma_buf
api, so I think I'll follow up with a patch to finally add this. I'm
thinking of something like

int dma_buf_sync_attachment(attachment, enum {BEGIN_DMA, END_DMA},
direction)

The BEGIN_DMA/END_DMA is just to avoid coming up with two nice names -
opposed to the normal dma api we need to differentiate explictly between
begin/end (like for cpu access), since a given importer knows only about
it's own usage (and hence we can't implictly flush the old coherency
domain when we switch to a new coherency domain). Synchronous attachments
would then simply as sync up with any dma_fences attached.

Aside 2: I think for async attachments we need to demand that all the
devices are coherent wrt each another - otherwise we need to allow that
the exporter can do some magic cache flushing in between when one device
signals a fence and everyone else receiving the update that the fence
signaled. If there is any hw out there that would require cache-flushing
at the gart level (i.e. not some caches which are known to the driver), we
should know about it ... (I seriously hope nothing is that brain-dead).

Allowing extensions
===

Like I've said in irc discussion, I think we should aim for the eventual
goal that dma_buf objects are fully evictable. Having a deadlock-free
reservation system is a big step towards that. Afaict two things would be
missing on top of your current bufmgr:

- drivers would also need to be able to reserve their own, not-exported
  buffers (and any other resource objects) with the dma_bufmgr. But they
  don't necessarily want to use dma_fences to sync their private objects
  (for efficiency reasons). So I think it should be possible to embed the
  reservation fields (and only those) into any driver-private struct.

- We'd again need a special attachment mode (hence the flags array, not
  just a bool) to signal that the driver can cope with the exporter
  evicting a dma_buf. Exporters would be free to evict any object (or just
  gart mappings) if all the affected attachments are of the evictable type
  and all the fences attached to a dma_buf have signalled (a bit
  

[PATCH 1/4] drm/i915: fix EDID memory leak in SDVO

[Daniel Vetter]

On Wed, Aug 15, 2012 at 12:32:36PM +0300, Jani Nikula wrote:
> The EDID returned by drm_get_edid() was never freed.
> 
> Signed-off-by: Jani Nikula 
Picked up for -fixes, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH 1/7] drm/i915: Allow VGA on CRTC 2

[Daniel Vetter]

On Mon, Aug 13, 2012 at 09:34:45PM -0700, Keith Packard wrote:
> This is left over from the old PLL sharing code and isn't useful now
> that PLLs are shared when possible.
> 
> Signed-off-by: Keith Packard 
Queued for -next, thanks for the patch. I'll hold off a bit on the others
until it's a bit clearer what's going on/wrong.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Bug 45018] [bisected] rendering regression and va conflicts since added support for virtual address space on cayman v11

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #120 from Alexandre Demers  
2012-08-16 00:38:42 UTC ---
(In reply to comment #119)
> (In reply to comment #118)
> 
> Try the Mesa patches from
> http://lists.freedesktop.org/archives/mesa-dev/2012-August/025715.html .

Testing right now.

May I suggest adding some debug info with an env variable switch to be able to
track what the vm_mgr is doing, keeping and forgetting if this doesn't fix the
problem or something similar?

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

[PATCH V5 13/18] drm: Define SAREA_MAX for Loongson (PageSize = 16KB).

[Ralf Baechle]

On Sat, Aug 11, 2012 at 05:32:18PM +0800, Huacai Chen wrote:

> Subject: [PATCH V5 13/18] drm: Define SAREA_MAX for Loongson (PageSize = 
> 16KB).

But your code doesn't define it just for Loongsson as the log message claims
but rather for all MIPS.

> diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h
> index ee5389d..1d1a858 100644
> --- a/include/drm/drm_sarea.h
> +++ b/include/drm/drm_sarea.h
> @@ -37,6 +37,8 @@
>  /* SAREA area needs to be at least a page */
>  #if defined(__alpha__)
>  #define SAREA_MAX   0x2000U
> +#elif defined(__mips__)
> +#define SAREA_MAX   0x4000U

How about replacing this whole #ifdef mess with something like:

#include 
#include 

/* Intel 830M driver needs at least 8k SAREA */
#define SAREA_MAX   max(PAGE_SIZE, 0x2000U)

MIPS also uses 64K page size and your patch as posted would break with 64k
pages.

  Ralf

[Bug 53512] kernel rejects cs in quake wars

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=53512

--- Comment #2 from Andy Furniss  2012-08-15 
23:21:19 UTC ---
(In reply to comment #0)
> After a while the picture gets totally garbled, and 'kernel rejected CS, see
> dmesg' messages are printed in mass quantity to the console. Nothing in dmesg,
> though. I'm using latest mesa from git, and kernel 3.5.1.
> 
> I have seen the discussion about this in the mesa-dev mailing list, but found
> no burgreport.

Seems to be fixed for me with latest mesa git.

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

[PATCH v3 1/3] Rename i2f() to int2float(), and make it global so one copy can be removed.

[Steven Fuerst]

Remove the copy of i2f() in r600_blit_kms.c
We rename the function to something longer now that it is a global
symbol.  This reduces the likelyhood of unintended clashes later.

This might be a candidate for inclusion inside general drm infrastructure.
However, at the moment only the radeon driver uses it.

Signed-off-by: Steven Fuerst svfue...@gmail.com
---
 drivers/gpu/drm/radeon/r600_blit.c |   66 ++--
 drivers/gpu/drm/radeon/r600_blit_kms.c |   52 +++---
 drivers/gpu/drm/radeon/r600_blit_shaders.h |1 +
 3 files changed, 40 insertions(+), 79 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_blit.c 
b/drivers/gpu/drm/radeon/r600_blit.c
index 3c031a4..ee1b815 100644
--- a/drivers/gpu/drm/radeon/r600_blit.c
+++ b/drivers/gpu/drm/radeon/r600_blit.c
@@ -489,7 +489,7 @@ set_default_state(drm_radeon_private_t *dev_priv)
ADVANCE_RING();
 }
 
-static uint32_t i2f(uint32_t input)
+uint32_t int2float(uint32_t input)
 {
u32 result, i, exponent, fraction;
 
@@ -632,20 +632,20 @@ r600_blit_copy(struct drm_device *dev,
vb = r600_nomm_get_vb_ptr(dev);
}
 
-   vb[0] = i2f(dst_x);
+   vb[0] = int2float(dst_x);
vb[1] = 0;
-   vb[2] = i2f(src_x);
+   vb[2] = int2float(src_x);
vb[3] = 0;
 
-   vb[4] = i2f(dst_x);
-   vb[5] = i2f(h);
-   vb[6] = i2f(src_x);
-   vb[7] = i2f(h);
+   vb[4] = int2float(dst_x);
+   vb[5] = int2float(h);
+   vb[6] = int2float(src_x);
+   vb[7] = int2float(h);
 
-   vb[8] = i2f(dst_x + cur_size);
-   vb[9] = i2f(h);
-   vb[10] = i2f(src_x + cur_size);
-   vb[11] = i2f(h);
+   vb[8] = int2float(dst_x + cur_size);
+   vb[9] = int2float(h);
+   vb[10] = int2float(src_x + cur_size);
+   vb[11] = int2float(h);
 
/* src */
set_tex_resource(dev_priv, FMT_8,
@@ -721,20 +721,20 @@ r600_blit_copy(struct drm_device *dev,
vb = r600_nomm_get_vb_ptr(dev);
}
 
-   vb[0] = i2f(dst_x / 4);
+   vb[0] = int2float(dst_x / 4);
vb[1] = 0;
-   vb[2] = i2f(src_x / 4);
+   vb[2] = int2float(src_x / 4);
vb[3] = 0;
 
-   vb[4] = i2f(dst_x / 4);
-   vb[5] = i2f(h);
-   vb[6] = i2f(src_x / 4);
-   vb[7] = i2f(h);
+   vb[4] = int2float(dst_x / 4);
+   vb[5] = int2float(h);
+   vb[6] = int2float(src_x / 4);
+   vb[7] = int2float(h);
 
-   vb[8] = i2f((dst_x + cur_size) / 4);
-   vb[9] = i2f(h);
-   vb[10] = i2f((src_x + cur_size) / 4);
-   vb[11] = i2f(h);
+   vb[8] = int2float((dst_x + cur_size) / 4);
+   vb[9] = int2float(h);
+   vb[10] = int2float((src_x + cur_size) / 4);
+   vb[11] = int2float(h);
 
/* src */
set_tex_resource(dev_priv, FMT_8_8_8_8,
@@ -804,20 +804,20 @@ r600_blit_swap(struct drm_device *dev,
dx2 = dx + w;
dy2 = dy + h;
 
-   vb[0] = i2f(dx);
-   vb[1] = i2f(dy);
-   vb[2] = i2f(sx);
-   vb[3] = i2f(sy);
+   vb[0] = int2float(dx);
+   vb[1] = int2float(dy);
+   vb[2] = int2float(sx);
+   vb[3] = int2float(sy);
 
-   vb[4] = i2f(dx);
-   vb[5] = i2f(dy2);
-   vb[6] = i2f(sx);
-   vb[7] = i2f(sy2);
+   vb[4] = int2float(dx);
+   vb[5] = int2float(dy2);
+   vb[6] = int2float(sx);
+   vb[7] = int2float(sy2);
 
-   vb[8] = i2f(dx2);
-   vb[9] = i2f(dy2);
-   vb[10] = i2f(sx2);
-   vb[11] = i2f(sy2);
+   vb[8] = int2float(dx2);
+   vb[9] = int2float(dy2);
+   vb[10] = int2float(sx2);
+   vb[11] = int2float(sy2);
 
switch(cpp) {
case 4:
diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c 
b/drivers/gpu/drm/radeon/r600_blit_kms.c
index 2bef854..1c7ed3a 100644
--- a/drivers/gpu/drm/radeon/r600_blit_kms.c
+++ b/drivers/gpu/drm/radeon/r600_blit_kms.c
@@ -455,46 +455,6 @@ set_default_state(struct radeon_device *rdev)
radeon_ring_write(ring, sq_stack_resource_mgmt_2);
 }
 
-#define I2F_MAX_BITS 15
-#define I2F_MAX_INPUT  ((1  I2F_MAX_BITS) - 1)
-#define I2F_SHIFT (24 - I2F_MAX_BITS)
-
-/*
- * Converts unsigned integer into 32-bit 

[PATCH v3 2/3] Replace int2float() with an optimized version.

[Steven Fuerst]

We use __fls() to find the most significant bit.  Using that, the
loop can be avoided.  A second trick is to use the behaviour of the
rotate instructions to expand the range of the unsigned int to float
conversion to the full 32 bits in a branchless way.

The routine is now exact up to 2^24.  Above that, we truncate which
is equivalent to rounding towards zero.

Signed-off-by: Steven Fuerst svfue...@gmail.com
---
 drivers/gpu/drm/radeon/r600_blit.c |   51 
 1 file changed, 28 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_blit.c 
b/drivers/gpu/drm/radeon/r600_blit.c
index ee1b815..7d8ac42 100644
--- a/drivers/gpu/drm/radeon/r600_blit.c
+++ b/drivers/gpu/drm/radeon/r600_blit.c
@@ -489,31 +489,36 @@ set_default_state(drm_radeon_private_t *dev_priv)
ADVANCE_RING();
 }
 
-uint32_t int2float(uint32_t input)
+/* 23 bits of float fractional data */
+#define I2F_FRAC_BITS  23
+#define I2F_MASK ((1  I2F_FRAC_BITS) - 1)
+
+/*
+ * Converts unsigned integer into 32-bit IEEE floating point representation.
+ * Will be exact from 0 to 2^24.  Above that, we round towards zero
+ * as the fractional bits will not fit in a float.  (It would be better to
+ * round towards even as the fpu does, but that is slower.)
+ */
+uint32_t int2float(uint32_t x)
 {
-   u32 result, i, exponent, fraction;
-
-   if ((input  0x3fff) == 0)
-   result = 0; /* 0 is a special case */
-   else {
-   exponent = 140; /* exponent biased by 127; */
-   fraction = (input  0x3fff)  10; /* cheat and only
- handle numbers below 
2^^15 */
-   for (i = 0; i  14; i++) {
-   if (fraction  0x80)
-   break;
-   else {
-   fraction = fraction  1; /* keep
-shifting left 
until top bit = 1 */
-   exponent = exponent - 1;
-   }
-   }
-   result = exponent  23 | (fraction  0x7f); /* mask
-   off top 
bit; assumed 1 */
-   }
-   return result;
-}
+   uint32_t msb, exponent, fraction;
+
+   /* Zero is special */
+   if (!x) return 0;
+
+   /* Get location of the most significant bit */
+   msb = __fls(x);
 
+   /*
+* Use a rotate instead of a shift because that works both leftwards
+* and rightwards due to the mod(32) behaviour.  This means we don't
+* need to check to see if we are above 2^24 or not.
+*/
+   fraction = ror32(x, (msb - I2F_FRAC_BITS)  0x1f)  I2F_MASK;
+   exponent = (127 + msb)  I2F_FRAC_BITS;
+
+   return fraction + exponent;
+}
 
 static int r600_nomm_get_vb(struct drm_device *dev)
 {
-- 
1.7.10.4

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

[PATCH v3 3/3] Annotate int2float() as being a pure function.

[Steven Fuerst]

This allows gcc to fold duplicate calls into a single call.  Since
the current users do actually call it multiple times with the
same arguments, this is an obvious win.

Signed-off-by: Steven Fuerst svfue...@gmail.com
---
 drivers/gpu/drm/radeon/r600_blit.c |2 +-
 drivers/gpu/drm/radeon/r600_blit_shaders.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_blit.c 
b/drivers/gpu/drm/radeon/r600_blit.c
index 7d8ac42..661fec2 100644
--- a/drivers/gpu/drm/radeon/r600_blit.c
+++ b/drivers/gpu/drm/radeon/r600_blit.c
@@ -499,7 +499,7 @@ set_default_state(drm_radeon_private_t *dev_priv)
  * as the fractional bits will not fit in a float.  (It would be better to
  * round towards even as the fpu does, but that is slower.)
  */
-uint32_t int2float(uint32_t x)
+__pure uint32_t int2float(uint32_t x)
 {
uint32_t msb, exponent, fraction;
 
diff --git a/drivers/gpu/drm/radeon/r600_blit_shaders.h 
b/drivers/gpu/drm/radeon/r600_blit_shaders.h
index e17c2cb..2f3ce7a 100644
--- a/drivers/gpu/drm/radeon/r600_blit_shaders.h
+++ b/drivers/gpu/drm/radeon/r600_blit_shaders.h
@@ -35,5 +35,5 @@ extern const u32 r6xx_default_state[];
 extern const u32 r6xx_ps_size, r6xx_vs_size;
 extern const u32 r6xx_default_size, r7xx_default_size;
 
-uint32_t int2float(uint32_t x);
+__pure uint32_t int2float(uint32_t x);
 #endif
-- 
1.7.10.4

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

Re: [PATCH 1/3] drm: Add missing static storage class specifiers in drm_proc.c file

[Sachin Kamat]

Hi,

Any comments on this series?

Regards
Sachin

On 1 August 2012 17:15, Sachin Kamat sachin.ka...@linaro.org wrote:
 Fixes the following sparse warning:
 drivers/gpu/drm/drm_proc.c:92:5:
 warning: symbol 'drm_proc_create_files' was not declared. Should it be static?
 drivers/gpu/drm/drm_proc.c:175:5:
 warning: symbol 'drm_proc_remove_files' was not declared. Should it be static?

 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 ---
  drivers/gpu/drm/drm_proc.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
 index 371c695..da457b1 100644
 --- a/drivers/gpu/drm/drm_proc.c
 +++ b/drivers/gpu/drm/drm_proc.c
 @@ -89,7 +89,7 @@ static const struct file_operations drm_proc_fops = {
   * Create a given set of proc files represented by an array of
   * gdm_proc_lists in the given root directory.
   */
 -int drm_proc_create_files(struct drm_info_list *files, int count,
 +static int drm_proc_create_files(struct drm_info_list *files, int count,
   struct proc_dir_entry *root, struct drm_minor 
 *minor)
  {
 struct drm_device *dev = minor-dev;
 @@ -172,7 +172,7 @@ int drm_proc_init(struct drm_minor *minor, int minor_id,
 return 0;
  }

 -int drm_proc_remove_files(struct drm_info_list *files, int count,
 +static int drm_proc_remove_files(struct drm_info_list *files, int count,
   struct drm_minor *minor)
  {
 struct list_head *pos, *q;
 --
 1.7.4.1

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

Re: [PATCH v3 1/3] Rename i2f() to int2float(), and make it global so one copy can be removed.

[Michel Dänzer]

On Mit, 2012-08-15 at 15:07 -0700, Steven Fuerst wrote: 
 Remove the copy of i2f() in r600_blit_kms.c
 We rename the function to something longer now that it is a global
 symbol.  This reduces the likelyhood of unintended clashes later.
 
 This might be a candidate for inclusion inside general drm infrastructure.
 However, at the moment only the radeon driver uses it.
 
 Signed-off-by: Steven Fuerst svfue...@gmail.com

For the series:

Reviewed-by: Michel Dänzer michel.daen...@amd.com


-- 
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: [PATCH 2/3] drm/udl: call begin/end cpu access at more appropriate time

[Daniel Vetter]

On Mon, Jul 30, 2012 at 02:06:55PM +1000, Dave Airlie wrote:
 From: Dave Airlie airl...@redhat.com
 
 We need to call these before we transfer the damaged areas to the device
 not before/after we setup the long lived vmaps.
 
 Signed-off-by: Dave Airlie airl...@redhat.com

As discussed on irc, I've applied this patch here and the corresponding
fix in i915 to make the begin/end_cpu_access stuff work to drm-intel-next.
I've left patch 3 of this series for you to handle.
-Daniel
-- 
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

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #35 from gy...@gmx.de 2012-08-16 08:39:35 UTC ---
Function radeon_atrm_call() would not be called, because 
if (!radeon_atrm_supported(rdev-pdev)) 
returns false.

Thats because this is returns null:
(!radeon_atpx_priv.atpx_detected)

-- 
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

[PATCH] drm: Check for invalid cursor flags

[Jakob Bornecrantz]

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
 drivers/gpu/drm/drm_crtc.c |2 +-
 include/drm/drm_mode.h |5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 08a7aa7..6fbfc24 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1981,7 +1981,7 @@ int drm_mode_cursor_ioctl(struct drm_device *dev,
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
 
-   if (!req-flags)
+   if (!req-flags || (~DRM_MODE_CURSOR_FLAGS  req-flags))
return -EINVAL;
 
mutex_lock(dev-mode_config.mutex);
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 5581980..3d6301b 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -359,8 +359,9 @@ struct drm_mode_mode_cmd {
struct drm_mode_modeinfo mode;
 };
 
-#define DRM_MODE_CURSOR_BO (10)
-#define DRM_MODE_CURSOR_MOVE   (11)
+#define DRM_MODE_CURSOR_BO 0x01
+#define DRM_MODE_CURSOR_MOVE   0x02
+#define DRM_MODE_CURSOR_FLAGS  0x03
 
 /*
  * depending on the value in flags different members are used.
-- 
1.7.9.5

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

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #36 from Alexander E. Patrakov patra...@gmail.com 2012-08-16 
09:26:59 UTC ---
OK. So the bug is that the Sony BIOS provides ATRM, but not ATPX.

-- 
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 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #37 from gy...@gmx.de 2012-08-16 10:08:23 UTC ---
I am not sure. In function radeon_atpx_pci_probe_handle() do get the
DEVICE_ACPI_HANDLE:

dhandle = DEVICE_ACPI_HANDLE(pdev-dev);

It fails with 
status = acpi_get_handle(dhandle, ATPX, atpx_handle);


btw it is kernel 3.5RC7

-- 
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 29372] KMS - radeon (Uhhuh. NMI received for unknown reason)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=29372


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




--- Comment #3 from Alan a...@lxorguk.ukuu.org.uk  2012-08-16 11:00:21 ---
If this is still seen with a modern (3.2 etc) kernel please updare/re-open
thanks

-- 
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 29572] Radeon card reports wrong temperature when switched off

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=29572


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




-- 
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

Re: [PATCH 2/2] Expose the OMAP Z-Order property through DRM

[Ville Syrjälä]

On Wed, Aug 15, 2012 at 03:18:02PM -0500, Rob Clark wrote:
 From: Andre Renaud an...@bluewatersys.com
 
 Added support for zorder changes through DRM plane properties
 
 Signed-off-by: Andre Renaud an...@bluewatersys.com
 Signed-off-by: Rob Clark r...@ti.com
 ---
  drivers/staging/omapdrm/omap_drv.h   |1 +
  drivers/staging/omapdrm/omap_plane.c |   19 +++
  2 files changed, 20 insertions(+)
 
 diff --git a/drivers/staging/omapdrm/omap_drv.h 
 b/drivers/staging/omapdrm/omap_drv.h
 index b103d28..9dc72d1 100644
 --- a/drivers/staging/omapdrm/omap_drv.h
 +++ b/drivers/staging/omapdrm/omap_drv.h
 @@ -62,6 +62,7 @@ struct omap_drm_private {
  
   /* properties: */
   struct drm_property *rotation_prop;
 + struct drm_property *zorder_prop;
  };
  
  /* this should probably be in drm-core to standardize amongst drivers */
 diff --git a/drivers/staging/omapdrm/omap_plane.c 
 b/drivers/staging/omapdrm/omap_plane.c
 index 6931d06..4bde639 100644
 --- a/drivers/staging/omapdrm/omap_plane.c
 +++ b/drivers/staging/omapdrm/omap_plane.c
 @@ -433,6 +433,15 @@ void omap_plane_install_properties(struct drm_plane 
 *plane,
   priv-rotation_prop = prop;
   }
   drm_object_attach_property(obj, prop, 0);
 +
 +prop = priv-zorder_prop;
 +if (!prop) {
 + prop = drm_property_create_range(dev, 0, zorder, 0, 3);
 + if (prop == NULL)
 + return;
 + priv-zorder_prop = prop;
 + }
 + drm_object_attach_property(obj, prop, 0);
  }
  
  int omap_plane_set_property(struct drm_plane *plane,
 @@ -452,6 +461,16 @@ int omap_plane_set_property(struct drm_plane *plane,
   ret = omap_plane_dpms(plane, DRM_MODE_DPMS_ON);
   else
   ret = 0;
 + } else if (property == priv-zorder_prop) {
 + struct omap_overlay *ovl = omap_plane-ovl;
 +
 + DBG(%s: zorder: %d, ovl-name, (uint32_t)val);
 + omap_plane-info.zorder = val;

What would happen when there's a conflicting assignment between two
planes?

I tried to think of a decent way to do this stuff, but some hardware
can have rather complicated stacking order limitations. One idea I
came up with was to have an enum prop on the crtc, where the individual
enum value names would somehow describe the whole stacking order within
the crtc. That way user space couldn't even try to use an unsupported
configuration. The downside is that user space would need to parse
those strings if it wants to do some automagic stacking order changes,
which means the string format would need some though.

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

Re: [PATCH 2/2] Expose the OMAP Z-Order property through DRM

[Rob Clark]

On Thu, Aug 16, 2012 at 8:00 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
 On Wed, Aug 15, 2012 at 03:18:02PM -0500, Rob Clark wrote:
 From: Andre Renaud an...@bluewatersys.com

 Added support for zorder changes through DRM plane properties

 Signed-off-by: Andre Renaud an...@bluewatersys.com
 Signed-off-by: Rob Clark r...@ti.com
 ---
  drivers/staging/omapdrm/omap_drv.h   |1 +
  drivers/staging/omapdrm/omap_plane.c |   19 +++
  2 files changed, 20 insertions(+)

 diff --git a/drivers/staging/omapdrm/omap_drv.h 
 b/drivers/staging/omapdrm/omap_drv.h
 index b103d28..9dc72d1 100644
 --- a/drivers/staging/omapdrm/omap_drv.h
 +++ b/drivers/staging/omapdrm/omap_drv.h
 @@ -62,6 +62,7 @@ struct omap_drm_private {

   /* properties: */
   struct drm_property *rotation_prop;
 + struct drm_property *zorder_prop;
  };

  /* this should probably be in drm-core to standardize amongst drivers */
 diff --git a/drivers/staging/omapdrm/omap_plane.c 
 b/drivers/staging/omapdrm/omap_plane.c
 index 6931d06..4bde639 100644
 --- a/drivers/staging/omapdrm/omap_plane.c
 +++ b/drivers/staging/omapdrm/omap_plane.c
 @@ -433,6 +433,15 @@ void omap_plane_install_properties(struct drm_plane 
 *plane,
   priv-rotation_prop = prop;
   }
   drm_object_attach_property(obj, prop, 0);
 +
 +prop = priv-zorder_prop;
 +if (!prop) {
 + prop = drm_property_create_range(dev, 0, zorder, 0, 3);
 + if (prop == NULL)
 + return;
 + priv-zorder_prop = prop;
 + }
 + drm_object_attach_property(obj, prop, 0);
  }

  int omap_plane_set_property(struct drm_plane *plane,
 @@ -452,6 +461,16 @@ int omap_plane_set_property(struct drm_plane *plane,
   ret = omap_plane_dpms(plane, DRM_MODE_DPMS_ON);
   else
   ret = 0;
 + } else if (property == priv-zorder_prop) {
 + struct omap_overlay *ovl = omap_plane-ovl;
 +
 + DBG(%s: zorder: %d, ovl-name, (uint32_t)val);
 + omap_plane-info.zorder = val;

 What would happen when there's a conflicting assignment between two
 planes?

non-good things.. basically as part of re-working the
omapdss-omapdrm stuff, I'll have a good point in omapdrm before
setting GO bit(s) where I can calculate the actual z-order from that
is set from userspace.  If two planes had same z-order from userspace,
omapdrm would simply put one in front of the other.  If the planes
aren't overlapping, this is fine.

 I tried to think of a decent way to do this stuff, but some hardware
 can have rather complicated stacking order limitations. One idea I
 came up with was to have an enum prop on the crtc, where the individual
 enum value names would somehow describe the whole stacking order within
 the crtc. That way user space couldn't even try to use an unsupported
 configuration. The downside is that user space would need to parse
 those strings if it wants to do some automagic stacking order changes,
 which means the string format would need some though.

I was thinking about this, but then you run into the same issue if you
move a plane from one CRTC to another without userspace setting the
property again.  In the end if userspace is ambiguous the driver has
to just arbitrarily pick some z-order to keep the hw happy.

BR,
-R

 --
 Ville Syrjälä
 Intel OTC
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #38 from Alex Deucher ag...@yahoo.com 2012-08-16 14:31:38 UTC ---
Please try the acpi_patches branch of my git tree:
http://cgit.freedesktop.org/~agd5f/linux/
Specifically this patch:
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=acpi_patchesid=6c0775d89cf6a39f4d155c8ad53067a0768e31e0

-- 
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 2/2] drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads

[Daniel Vetter]

On Mon, Aug 13, 2012 at 01:22:35PM +0300, Jani Nikula wrote:
 GMBUS was enabled over bit-banging as the default in commits:
 
 commit c3dfefa0a6d235bd465309e12f4c56ea16e7
 Author: Daniel Vetter daniel.vet...@ffwll.ch
 Date:   Tue Feb 14 22:37:25 2012 +0100
 
 drm/i915: reenable gmbus on gen3+ again
 
 and
 
 commit 0fb3f969c8683505fb7323c06bf8a999a5a45a15
 Author: Daniel Vetter daniel.vet...@ffwll.ch
 Date:   Fri Mar 2 19:38:30 2012 +0100
 
 drm/i915: enable gmbus on gen2
 
 Unfortunately, GMBUS seems to fail on some CRT displays. Add a bit-banging
 fallback to CRT EDID reads.
 
 LKML-Reference: 201207251020.47637.maciej.rute...@gmail.com
 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45881
 Signed-off-by: Jani Nikula jani.nik...@intel.com
Patches applied to -fixes with the tested-by result from the bug report.
I've also put a cc: stable on both of them, since the regression is
already in 3.4.

Thanks, Daniel
-- 
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

[PATCH 1/4] drm: edid: Add bounds checking to CEA 18 byte descriptor parsing

[ville . syrjala]

From: Ville Syrjälä ville.syrj...@linux.intel.com

Make sure we don't access beyond the extension block when parsing CEA
detailed timing descriptors.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/drm_edid.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5873e48..a346b04 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -551,6 +551,9 @@ cea_for_each_detailed_block(u8 *ext, detailed_cb *cb, void 
*closure)
u8 d = ext[0x02];
u8 *det_base = ext + d;
 
+   if (d  127)
+   return;
+
n = (127 - d) / 18;
for (i = 0; i  n; i++)
cb((struct detailed_timing *)(det_base + 18 * i), closure);
-- 
1.7.8.6

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

[PATCH 4/4] drm: edid: Refactor HDMI VSDB detection

[ville . syrjala]

From: Ville Syrjälä ville.syrj...@linux.intel.com

There are two slightly different pieces of code for HDMI VSDB
detection. Unify the code into a single helper function.

Also fix a bug where drm_detect_hdmi_monitor() would stop looking
for the HDMI VSDB after the first vendor specific block is found,
whether or not that block happened to be the HDMI VSDB. The
standard allows for any number of vendor specific blocks to be
present.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/drm_edid.c |   38 ++
 1 files changed, 22 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 2611ba8..f5c9cea 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1606,6 +1606,21 @@ monitor_name(struct detailed_timing *t, void *data)
*(u8 **)data = t-data.other_data.data.str.str;
 }
 
+static bool cea_db_is_hdmi_vsdb(const u8 *db)
+{
+   int hdmi_id;
+
+   if (cea_db_tag(db) != VENDOR_BLOCK)
+   return false;
+
+   if (cea_db_payload_len(db)  5)
+   return false;
+
+   hdmi_id = db[1] | (db[2]  8) | (db[3]  16);
+
+   return hdmi_id == HDMI_IDENTIFIER;
+}
+
 /**
  * drm_edid_to_eld - build ELD from EDID
  * @connector: connector corresponding to the HDMI/DP sink
@@ -1678,7 +1693,7 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
break;
case VENDOR_BLOCK:
/* HDMI Vendor-Specific Data Block */
-   if (dbl = 5  db[1] == 0x03  db[2] == 0x0c 
 db[3] == 0)
+   if (cea_db_is_hdmi_vsdb(db))
parse_hdmi_vsdb(connector, db);
break;
default:
@@ -1763,35 +1778,26 @@ EXPORT_SYMBOL(drm_select_eld);
 bool drm_detect_hdmi_monitor(struct edid *edid)
 {
u8 *edid_ext;
-   int i, hdmi_id;
+   int i;
int start_offset, end_offset;
-   bool is_hdmi = false;
 
edid_ext = drm_find_cea_extension(edid);
if (!edid_ext)
-   goto end;
+   return false;
 
if (cea_db_offsets(edid_ext, start_offset, end_offset))
-   goto end;
+   return false;
 
/*
 * Because HDMI identifier is in Vendor Specific Block,
 * search it from all data blocks of CEA extension.
 */
for_each_cea_db(edid_ext, i, start_offset, end_offset) {
-   /* Find vendor specific block */
-   if (cea_db_tag(edid_ext[i]) == VENDOR_BLOCK) {
-   hdmi_id = edid_ext[i + 1] | (edid_ext[i + 2]  8) |
- edid_ext[i + 3]  16;
-   /* Find HDMI identifier */
-   if (hdmi_id == HDMI_IDENTIFIER)
-   is_hdmi = true;
-   break;
-   }
+   if (cea_db_is_hdmi_vsdb(edid_ext[i]))
+   return true;
}
 
-end:
-   return is_hdmi;
+   return false;
 }
 EXPORT_SYMBOL(drm_detect_hdmi_monitor);
 
-- 
1.7.8.6

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

[PATCH 0/4] Some long forgotten EDID/CEA fixes

[ville . syrjala]

I found these EDID/CEA patches sitting in a branch in my tree. I worked on
them at some point, but forgot about them when something more urgent
came up.

They haven't been tested all that well, mainly because currently there
is no way to test this code, apart from trying on real hardware. If
someone is looking for a good project, this would be one:
1. Split EDID parsing from the rest of the junk in drm_edid.c
2. Make it compile in user space
3. Cook up some regression and fuzz testing framework
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/4] drm: edid: Add some bounds checking

[ville . syrjala]

From: Ville Syrjälä ville.syrj...@linux.intel.com

Make sure drm_detect_hdmi_monitor() and drm_detect_monitor_audio() don't
access beyond the extension block.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/drm_edid.c |   99 ---
 1 files changed, 73 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a346b04..aa28d1c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1502,16 +1502,57 @@ do_cea_modes (struct drm_connector *connector, u8 *db, 
u8 len)
 }
 
 static int
+cea_db_payload_len(const u8 *db)
+{
+   return db[0]  0x1f;
+}
+
+static int
+cea_db_tag(const u8 *db)
+{
+   return db[0]  5;
+}
+
+static int
+cea_revision(const u8 *cea)
+{
+   return cea[1];
+}
+
+static int
+cea_db_offsets(const u8 *cea, int *start, int *end)
+{
+   /* Data block offset in CEA extension block */
+   *start = 4;
+   *end = cea[2];
+   if (*end == 0)
+   *end = 127;
+   if (*end  4 || *end  127)
+   return -ERANGE;
+   return 0;
+}
+
+#define for_each_cea_db(cea, i, start, end) \
+   for ((i) = (start); (i)  (end)  (i) + 
cea_db_payload_len((cea)[(i)])  (end); (i) += cea_db_payload_len((cea)[(i)]) 
+ 1)
+
+static int
 add_cea_modes(struct drm_connector *connector, struct edid *edid)
 {
u8 * cea = drm_find_cea_extension(edid);
u8 * db, dbl;
int modes = 0;
 
-   if (cea  cea[1] = 3) {
-   for (db = cea + 4; db  cea + cea[2]; db += dbl + 1) {
-   dbl = db[0]  0x1f;
-   if (((db[0]  0xe0)  5) == VIDEO_BLOCK)
+   if (cea  cea_revision(cea) = 3) {
+   int i, start, end;
+
+   if (cea_db_offsets(cea, start, end))
+   return 0;
+
+   for_each_cea_db(cea, i, start, end) {
+   db = cea[i];
+   dbl = cea_db_payload_len(db);
+
+   if (cea_db_tag(db) == VIDEO_BLOCK)
modes += do_cea_modes (connector, db+1, dbl);
}
}
@@ -1602,19 +1643,29 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
eld[18] = edid-prod_code[0];
eld[19] = edid-prod_code[1];
 
-   if (cea[1] = 3)
-   for (db = cea + 4; db  cea + cea[2]; db += dbl + 1) {
-   dbl = db[0]  0x1f;
-   
-   switch ((db[0]  0xe0)  5) {
+   if (cea_revision(cea) = 3) {
+   int i, start, end;
+
+   if (cea_db_offsets(cea, start, end)) {
+   start = 0;
+   end = 0;
+   }
+
+   for_each_cea_db(cea, i, start, end) {
+   db = cea[i];
+   dbl = cea_db_payload_len(db);
+
+   switch (cea_db_tag(db)) {
case AUDIO_BLOCK:
/* Audio Data Block, contains SADs */
sad_count = dbl / 3;
-   memcpy(eld + 20 + mnl, db[1], dbl);
+   if (dbl = 1)
+   memcpy(eld + 20 + mnl, db[1], dbl);
break;
case SPEAKER_BLOCK:
-/* Speaker Allocation Data Block */
-   eld[7] = db[1];
+   /* Speaker Allocation Data Block */
+   if (dbl = 1)
+   eld[7] = db[1];
break;
case VENDOR_BLOCK:
/* HDMI Vendor-Specific Data Block */
@@ -1625,6 +1676,7 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
break;
}
}
+   }
eld[5] |= sad_count  4;
eld[2] = (20 + mnl + sad_count * 3 + 3) / 4;
 
@@ -1710,19 +1762,16 @@ bool drm_detect_hdmi_monitor(struct edid *edid)
if (!edid_ext)
goto end;
 
-   /* Data block offset in CEA extension block */
-   start_offset = 4;
-   end_offset = edid_ext[2];
+   if (cea_db_offsets(edid_ext, start_offset, end_offset))
+   goto end;
 
/*
 * Because HDMI identifier is in Vendor Specific Block,
 * search it from all data blocks of CEA extension.
 */
-   for (i = start_offset; i  end_offset;
-   /* Increased by data block len */
-   i += ((edid_ext[i]  0x1f) + 1)) {
+   for_each_cea_db(edid_ext, i, start_offset, end_offset) {
/* Find vendor specific block */
-   if ((edid_ext[i]  5) == VENDOR_BLOCK) {
+   if (cea_db_tag(edid_ext[i]) == VENDOR_BLOCK) {
  

[PATCH 3/4] drm: edid: Add bounds checking to HDMI VSDB parsing

[ville . syrjala]

From: Ville Syrjälä ville.syrj...@linux.intel.com

The length of HDMI VSDB must be at least 5 bytes. Other than the minimum,
nothing else about the length is specified. Check the length before
accessing any additional field beyond the minimum length.
---
 drivers/gpu/drm/drm_edid.c |   33 +
 1 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index aa28d1c..2611ba8 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1561,19 +1561,28 @@ add_cea_modes(struct drm_connector *connector, struct 
edid *edid)
 }
 
 static void
-parse_hdmi_vsdb(struct drm_connector *connector, uint8_t *db)
+parse_hdmi_vsdb(struct drm_connector *connector, const u8 *db)
 {
-   connector-eld[5] |= (db[6]  7)  1;  /* Supports_AI */
+   u8 len = cea_db_payload_len(db);
 
-   connector-dvi_dual = db[6]  1;
-   connector-max_tmds_clock = db[7] * 5;
-
-   connector-latency_present[0] = db[8]  7;
-   connector-latency_present[1] = (db[8]  6)  1;
-   connector-video_latency[0] = db[9];
-   connector-audio_latency[0] = db[10];
-   connector-video_latency[1] = db[11];
-   connector-audio_latency[1] = db[12];
+   if (len = 6) {
+   connector-eld[5] |= (db[6]  7)  1;  /* Supports_AI */
+   connector-dvi_dual = db[6]  1;
+   }
+   if (len = 7)
+   connector-max_tmds_clock = db[7] * 5;
+   if (len = 8) {
+   connector-latency_present[0] = db[8]  7;
+   connector-latency_present[1] = (db[8]  6)  1;
+   }
+   if (len = 9)
+   connector-video_latency[0] = db[9];
+   if (len = 10)
+   connector-audio_latency[0] = db[10];
+   if (len = 11)
+   connector-video_latency[1] = db[11];
+   if (len = 12)
+   connector-audio_latency[1] = db[12];
 
DRM_LOG_KMS(HDMI: DVI dual %d, 
max TMDS clock %d, 
@@ -1669,7 +1678,7 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
break;
case VENDOR_BLOCK:
/* HDMI Vendor-Specific Data Block */
-   if (db[1] == 0x03  db[2] == 0x0c  db[3] == 
0)
+   if (dbl = 5  db[1] == 0x03  db[2] == 0x0c 
 db[3] == 0)
parse_hdmi_vsdb(connector, db);
break;
default:
-- 
1.7.8.6

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

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #39 from Alexander E. Patrakov patra...@gmail.com 2012-08-16 
15:16:18 UTC ---
Unfortunately, your specific patch does not apply to the 3.5 kernel, so I
cannot test this quickly. Now downloading your tree.

-- 
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 50389] [radeonsi] Unknown type of argument: ../../../../i386-linux-gnu/egl/egl_gallium.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=50389

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Michel Dänzer mic...@daenzer.net 2012-08-16 15:18:27 UTC 
---
Commit: 1b11395a36a44a902cfb3e1783758544662df73f
URL:   
http://cgit.freedesktop.org/mesa/mesa/commit/?id=1b11395a36a44a902cfb3e1783758544662df73f

Author: Michel Dänzer michel.daen...@amd.com
Date:   Thu Aug 16 10:37:44 2012 +0200

radeonsi: Fix symbol conflicts with r600g.

-- 
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 45018] [bisected] rendering regression and va conflicts since added support for virtual address space on cayman v11

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #121 from Alexandre Demers alexandre.f.dem...@gmail.com 
2012-08-16 15:35:45 UTC ---
(In reply to comment #120)
 (In reply to comment #119)
  (In reply to comment #118)
  
  Try the Mesa patches from
  http://lists.freedesktop.org/archives/mesa-dev/2012-August/025715.html .
 
 Testing right now.
 
 May I suggest adding some debug info with an env variable switch to be able to
 track what the vm_mgr is doing, keeping and forgetting if this doesn't fix the
 problem or something similar?

I've been testing to reproduce latest VA issue all evening without being able
to. So if it doesn't finally fix the problem, your patches do help a lot. I'll
continue to test it tonight. Good to know your patches have been commited this
morning.

However, keep in mind I haven't tested anything for the other lockups (piglit
tests and some other OpenGL apps).

-- 
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

radeon testing

[Alex Deucher]

I've gathered up the various outstanding radeon patches and put them
up in a tree for testing:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip
Some of these may end up in -fixes, but most of them are -next
material.  I haven't had a chance to go through Christian's last set
of VM patches yet.

Highlights:
- rom fetch fixes (UEFI, thunderbolt docks)
- major ACPI rework
- backlight control for newer asics

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

Re: [PATCH] drm/edid: limit printk when facing bad edid

[Jerome Glisse]

On Thu, Aug 16, 2012 at 11:13 AM, Jani Nikula
jani.nik...@linux.intel.com wrote:

 There's a bug [1] where the faster GMBUS transmissions fail with some
 CRTs, and the fix [2] is to fallback to GPIO bit-banging upon errors. As
 noted in the bug, the fix still leaves plenty of EDID dumps in dmesg, so
 some measures to reduce the EDID error messages would be most welcome.

 [1] https://bugzilla.kernel.org/show_bug.cgi?id=45881
 [2] http://thread.gmane.org/gmane.linux.kernel/1332810/focus=1341912

 On Tue, 14 Aug 2012, Jerome Glisse j.gli...@gmail.com wrote:
 On Tue, Aug 14, 2012 at 10:54 AM, Adam Jackson a...@redhat.com wrote:
 On 8/9/12 11:25 AM, j.gli...@gmail.com wrote:

 From: Jerome Glisse jgli...@redhat.com

 Limit printing bad edid information at one time per connector.
 Connector that are connected to a bad monitor/kvm will likely
 stay connected to the same bad monitor/kvm and it makes no
 sense to keep printing the bad edid message.

 Do I understand correctly that bad_edid_counter is only reset when you
 reboot or reload the module? So if you have a laptop that you connect to
 the monitor at home, the monitor at the office, the projector in the
 meeting room, and to a TV somewhere else, etc, the message about bad
 EDID will only printed once? I don't think that's good. But please do
 correct me if I'm wrong.

I wanted to reset the counter any time the connector is connected to
something with good edid but i did not do that in the end. I can do a
patch on top if you think it would be nicer. That way only thing with
bad edid will be printed once and assuming you don't repeatly
alternate btw good and bad edid device you would not get spam.


 Signed-off-by: Jerome Glisse jgli...@redhat.com


 I guess.  I don't see why we don't just move it into DRM_DEBUG_KMS if we're
 going to suppress it, but this does what it says on the box.

 Reviewed-by: Adam Jackson a...@redhat.com

 - ajax


 I think there is still value in getting at least once the bad edid.

 I think the raw edid dumps should be DEBUG level no matter what. Perhaps
 some of the other messages could use WARNING/DEBUG too. And with that,
 and my comment above, I not sure there really needs to be all that logic
 to count errors and act differently further on.


No, i do think we want bad edid as normal log at least once per
connector and we definitely don't want to spam bomb the log messages.

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

[Bug 53291] Failed to allocate a buffer at CAYMAN

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=53291

Thomas Rohloff v10la...@myway.de changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME

--- Comment #2 from Thomas Rohloff v10la...@myway.de 2012-08-16 16:31:53 UTC 
---
I think Alex was right. This seems to be fixed in the newest git version of
Mesa (which includes patches from Michel Dänzer (comment #119 at bug 45018)).

-- 
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