date:20121026

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

--- Comment #2 from Andy Furniss  ---
I saw this yesterday after rebuilding Mesa and running nexuiz.
Running again worked without error. 
This is the second time I've seen it, the first was a couple of weeks ago,
again after a rebuild of mesa this time with etqw.

I couldn't reproduce, but did get more output -

LLVM ERROR: Cannot select: target intrinsic %llvm.AMDIL.mad
Stack dump:
0.  Running pass 'Function Pass Manager' on module 'tgsi'.
1.  Running pass 'AMDGPU DAG->DAG Pattern Instruction Selection' on
function '@main'

I am using llvm 3.1 on HD4890.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121026/faa6b82b/attachment.html>

[PATCH 1/1] media: Entities with sink pads must have at least one enabled link

2012-10-26 Thread Sakari Ailus

If an entity has sink pads, at least one of them must be connected to
another pad with an enabled link. If a driver with multiple sink pads has
more strict requirements the check should be done in the driver itself.

Just requiring one sink pad is connected with an enabled link is enough
API-wise: entities with sink pads with only disabled links should not be
allowed to stream in the first place, but also in a different operation mode
a device might require only one of its pads connected with an active link.

If an entity has an ability to function as a source entity another logical
entity connected to the aforementioned one should be used for the purpose.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-entity.c |   16 +---
 1 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index e1cd132..8846ea7 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -227,6 +227,7 @@ __must_check int media_entity_pipeline_start(struct 
media_entity *entity,
media_entity_graph_walk_start(, entity);

while ((entity = media_entity_graph_walk_next())) {
+   bool has_sink = false, active_sink = false;
unsigned int i;

entity->stream_count++;
@@ -243,18 +244,27 @@ __must_check int media_entity_pipeline_start(struct 
media_entity *entity,
for (i = 0; i < entity->num_links; i++) {
struct media_link *link = >links[i];

+   /* Are we the sink or not? */
+   if (link->sink->entity != entity)
+   continue;
+
+   has_sink = true;
+
/* Is this pad part of an enabled link? */
if (!(link->flags & MEDIA_LNK_FL_ENABLED))
continue;

-   /* Are we the sink or not? */
-   if (link->sink->entity != entity)
-   continue;
+   active_sink = true;

ret = entity->ops->link_validate(link);
if (ret < 0 && ret != -ENOIOCTLCMD)
goto error;
}
+
+   if (has_sink && !active_sink) {
+   ret = -EPIPE;
+   goto error;
+   }
}

mutex_unlock(>graph_mutex);
-- 
1.7.2.5

Linux 3.7-rc1 (nouveau_bios_score oops).

2012-10-26 Thread Paweł Sikora

On Thursday 25 of October 2012 20:06:54 Heinz Diehl wrote:
> On 25.10.2012, Pawe? Sikora wrote: 
> 
> > what is the reason of loading nouveau driver for laptops 
> > with nvidia optimus and enabling vga switcheroo
> > which doesn't work in such (optimus) cases.
> 
> You can safely compile a kernel without nouveau, your Nvidia 
> card will not be used at all since neither Linux nor the 
> proprietary nvidia driver does support optimus at this time
> (and frankly, I won't buy any further machines with opticrap).
> So having nouveau compiled and loaded seems like a waste of ressources
> in this case.

i've bought this asus laptop mostly for a developer's workstation replacement
(quad-core-i7-avx cpu with integrated gpu, with 12GB ram and 2x500GB hdd).
nvidia's addon is an optional crap :)

> For me it's important to have nouveau working, because I try/use
> Bumblebee and optirun: 
> 
> http://bumblebee-project.org/
> https://fedoraproject.org/wiki/Bumblebee

i'll try to use transformers too :-)

[Bug 56405] Distorted graphics on Radeon HD 6620G

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

--- Comment #6 from Alex Deucher  ---
You can just checkout a commit on master around the time 8.0 was branched.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121026/061f8522/attachment.html>

[Bug 56405] Distorted graphics on Radeon HD 6620G

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

--- Comment #5 from mdrslmr at t-online.de ---
And the bug still exists when using the top of the
master branch:
b78b62497f1e5cc64eb924c64e4685fe5d814fd7

I'm not so sure what commits I should start the bisecting with since
8.0 and 9.0 are split. It is not a linear history.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121026/eefbd1d8/attachment.html>

3.7-rc2: corrupted image on Radeon HD 7800 after restarting X

2012-10-26 Thread Frederik Himpe

When I restart my display manager (GDM) from tty0, I get a corrupted 
image where parts of the X display before I restarted GDM become visible 
on both the newly started X server instance as on tty0. When moving the 
mouse in X, the current (correct) image around the cursor is replaced by 
the image which was shown before X was started.

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] 
nee ATI PITCAIRN PRO [Radeon HD 7800 Series] [1002:6819] (prog-if 00 [VGA 
controller])
Subsystem: PC Partner Limited Device [174b:e218]
Flags: bus master, fast devsel, latency 0, IRQ 48
Memory at e000 (64-bit, prefetchable) [size=256M]
Memory at f7d0 (64-bit, non-prefetchable) [size=256K]
I/O ports at e000 [size=256]
Expansion ROM at f7d4 [disabled] [size=128K]
Capabilities: [48] Vendor Specific Information: Len=08 
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 
Len=010 
Capabilities: [150] Advanced Error Reporting
Capabilities: [270] #19
Capabilities: [2b0] Address Translation Service (ATS)
Capabilities: [2c0] #13
Capabilities: [2d0] #1b
Kernel driver in use: radeon

dmesg, .config, lspci and a picture showing a tty0 with parts of the 
image corrupted by the image of the GDM screen before it was restarted, 
can be found at http://artipc10.vub.ac.be/~frederik/linux-3.7-rc2/

-- 
Frederik Himpe

[Bug 56405] Distorted graphics on Radeon HD 6620G

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

--- Comment #4 from mdrslmr at t-online.de ---
The dmesg and xorg log files are done with the top of the 9.0 branch
5fe5aa8e55a8db0b80f6ff9838bad47ce0406fd0

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121026/5066e9b7/attachment.html>

[Bug 56405] Distorted graphics on Radeon HD 6620G

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

--- Comment #3 from mdrslmr at t-online.de ---
Created attachment 69133
  --> https://bugs.freedesktop.org/attachment.cgi?id=69133=edit
Xorg.0.log

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121026/15c09c73/attachment.html>

[Bug 56405] Distorted graphics on Radeon HD 6620G

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

--- Comment #2 from mdrslmr at t-online.de ---
Created attachment 69132
  --> https://bugs.freedesktop.org/attachment.cgi?id=69132=edit
dmesg

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121026/3de3245d/attachment.html>

[Bug 56437] LLVM ERROR: Cannot select: target intrinsic %llvm.AMDIL.mad when running Heaven

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

--- Comment #1 from maxijac at free.fr ---
I was unclear about LLVM:
I am using the llvm glsl backend when I trigger this error.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121026/f7ff4a15/attachment.html>

[Bug 56437] LLVM ERROR: Cannot select: target intrinsic %llvm.AMDIL.mad when running Heaven

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

maxijac at free.fr changed:

   What|Removed |Added

 OS|All |Linux (All)
Version|unspecified |git

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121026/6a739bee/attachment.html>

[Bug 56437] New: LLVM ERROR: Cannot select: target intrinsic %llvm.AMDIL.mad when running Heaven

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

Priority: medium
Bug ID: 56437
Assignee: dri-devel at lists.freedesktop.org
Summary: LLVM ERROR: Cannot select: target intrinsic
%llvm.AMDIL.mad when running Heaven
Severity: normal
Classification: Unclassified
OS: All
Reporter: maxijac at free.fr
Hardware: Other
Status: NEW
Version: unspecified
Component: Drivers/Gallium/r600
Product: Mesa

Heaven sometimes crashes when loading with an error output :
LLVM ERROR: Cannot select: target intrinsic %llvm.AMDIL.mad

I can partially reproduce this bug.
It happens from time to time on Heaven start.

To reproduce it I use the Heaven launcher (using Archlinux AUR package), just
untick fullscreen checkbox and choose 1024x768 and click run.
If the crash is not triggered I close the unigine render window and just click
once again "Run" and so on.

It happens about once every 10 runs when I test. (I know it's not convenient at
all to reproduce it but it is a very rare bug...) I also had it once with
Heroes of Newerth.

using R600_LLVM=0, radeon seems to be not hit by this problem.

Using git head and r600g on BARTS HD6870.

I might also add that I use these env vars (some are probably outdated...)
R600_ENABLE_S3TC=1
R600_GLSL130=1
R600_STREAMOUT=1

Using Xorg 1.13 and linux 3.6.3

--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121026/4e28a9df/attachment.html>

[PATCH] drm: platform: Don't initialize driver-private data

2012-10-26 Thread Laurent Pinchart

Hi Thierry,

Thank you for the patch, and sorry for the late reply.

On Monday 15 October 2012 20:03:42 Thierry Reding wrote:
> Platform device drivers usually use the driver-private data for their
> own purposes. Having it overwritten by drm_platform_init() is confusing
> and error-prone.

If you want to push drivers that way, you should get rid of the 
pci_set_drvdata() call in core DRM as well. This would push device driver data 
handling down to all drivers, so I'm not convinced it would actually make 
things simpler.

> Signed-off-by: Thierry Reding 

Tested-by: Laurent Pinchart 

But I'm not convinced by the patch, as explained above.

> ---
> Note that I don't have any hardware to test the shmobile changes on so
> it would be good to get a Tested-by for that.
> 
>  drivers/gpu/drm/drm_platform.c   |  1 -
>  drivers/gpu/drm/shmobile/shmob_drm_drv.c | 12 +---
>  2 files changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
> index aaeb6f8..b8a282e 100644
> --- a/drivers/gpu/drm/drm_platform.c
> +++ b/drivers/gpu/drm/drm_platform.c
> @@ -64,7 +64,6 @@ int drm_get_platform_dev(struct platform_device *platdev,
>   }
> 
>   if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> - dev_set_drvdata(>dev, dev);
>   ret = drm_get_minor(dev, >control, DRM_MINOR_CONTROL);
>   if (ret)
>   goto err_g1;
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> b/drivers/gpu/drm/shmobile/shmob_drm_drv.c index c71d493..1c350fc 100644
> --- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> @@ -201,6 +201,8 @@ static int shmob_drm_load(struct drm_device *dev,
> unsigned long flags) goto done;
>   }
> 
> + platform_set_drvdata(pdev, sdev);
> +
>  done:
>   if (ret)
>   shmob_drm_unload(dev);
> @@ -299,11 +301,9 @@ static struct drm_driver shmob_drm_driver = {
>  #if CONFIG_PM_SLEEP
>  static int shmob_drm_pm_suspend(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct drm_device *ddev = platform_get_drvdata(pdev);
> - struct shmob_drm_device *sdev = ddev->dev_private;
> + struct shmob_drm_device *sdev = dev_get_drvdata(dev);
> 
> - drm_kms_helper_poll_disable(ddev);
> + drm_kms_helper_poll_disable(sdev->ddev);
>   shmob_drm_crtc_suspend(>crtc);
> 
>   return 0;
> @@ -311,9 +311,7 @@ static int shmob_drm_pm_suspend(struct device *dev)
> 
>  static int shmob_drm_pm_resume(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct drm_device *ddev = platform_get_drvdata(pdev);
> - struct shmob_drm_device *sdev = ddev->dev_private;
> + struct shmob_drm_device *sdev = dev_get_drvdata(dev);
> 
>   mutex_lock(>ddev->mode_config.mutex);
>   shmob_drm_crtc_resume(>crtc);

-- 
Regards,

Laurent Pinchart

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #68760|0   |1
is obsolete||

--- Comment #5 from Alex Deucher  ---
Created attachment 69113
  --> https://bugs.freedesktop.org/attachment.cgi?id=69113=edit
possible fix

(In reply to comment #4)
> the bug appeared. So it seems blanking the display controllers with for(i =
> 0; i < rdev->num_crtc; i++) is not equivalent to the code that it replaces.
> The original code first wrote in the EVERGREEN_CRTC_UPDATE_LOCK registers,
> before setting EVERGREEN_CRTC_CONTROL registers and writing again in the
> EVERGREEN_CRTC_UPDATE_LOCK registers. On the other hand, the new code
> doesn't write in the EVERGREEN_CRTC_UPDATE_LOCK neither before nor after
> setting EVERGREEN_CRTC_CONTROL.

It should be equivalent.  CRTC_UPDATE_LOCK turns off double buffering in the
crtc which makes register updates atomic.  The new code waits for the frame
count to increase (the double buffered updates happen at vblank) so it should
be equivalent.  That said, it shouldn't hurt to take the lock.  Does this patch
help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121026/729bd063/attachment.html>

[drm:i915_hangcheck_hung] ERROR Hangcheck timer elapsed... GPU hung

2012-10-26 Thread Justin P. Mattock

On 10/26/2012 01:05 AM, Daniel Vetter wrote:
> On Fri, Oct 26, 2012 at 6:43 AM, Justin P. Mattock
>  wrote:
>>>
>>> No worries, it is another ILK hang similar to the ones reported earlier
>>> - it just seems the ring stops advancing. Hopefully it is a missing w/a
>>> from http://cgit.freedesktop.org/~danvet/drm/log/?h=ilk-wa-pile
>>> -Chris
>>>
>>
>> well if this means building libdrm etc.. then thats not a problem, more time
>> consuming if anything. perhaps an *.rpm that I can test to see?
>
> It's not libdrm, the above is just a kernel git tree with a bunch of
> ironlake workarounds.
> -Daniel
>


nice..

:~/drm> git clone git://people.freedesktop.org/~danvet/drm
Cloning into 'drm'...
remote: Counting objects: 2728390, done.
remote: Compressing objects: 100% (418606/418606), done.
remote: Total 2728390 (delta 2293727), reused 2717443 (delta 2282880)
Receiving objects: 100% (2728390/2728390), 637.95 MiB | 599 KiB/s, done.
Resolving deltas: 100% (2293727/2293727), done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.


so now I have to go on a witch hunt for 600MB's in my system.

Justin P. Mattock

[Bug 49531] Powering down inactive GPU while running X causes NULL pointer dereference

2012-10-26 Thread bugzilla-dae...@bugzilla.kernel.org

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





--- Comment #6 from Igor Murzov   2012-10-26 12:22:10 ---
Created an attachment (id=84961)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=84961)
full dmesg output for v3.7.0-rc2+

The kernel is not from the origin/master, it's the drm-fixes-3.7 from the
git://people.freedesktop.org/~agd5f/linux.

-- 
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 3/3] drm/i915/dp: change eDP default scaling mode to respect aspect ratio

From: Yuly Novikov 

Signed-off-by: Yuly Novikov 
[Jani: ripped this change separate from the scaling mode change support]
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dp.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 30314c0..a1b9fc13 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2547,8 +2547,8 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct 
drm_connector *connect
drm_connector_attach_property(
connector,
connector->dev->mode_config.scaling_mode_property,
-   DRM_MODE_SCALE_FULLSCREEN);
-   intel_connector->panel.fitting_mode = DRM_MODE_SCALE_FULLSCREEN;
+   DRM_MODE_SCALE_ASPECT);
+   intel_connector->panel.fitting_mode = DRM_MODE_SCALE_ASPECT;
}
 }

-- 
1.7.9.5

[PATCH 2/3] drm/i915/dp: allow configuring eDP panel fitting scaling mode

From: Yuly Novikov 

LVDS allowed changing panel fitting scaling mode, while eDP didn't. Copied
relevant code from LVDS to eDP.

Signed-off-by: Yuly Novikov 
[Jani: use fitting mode in intel_panel, remove default mode change]
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dp.c |   31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2a9998a..30314c0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -693,7 +693,8 @@ intel_dp_mode_fixup(struct drm_encoder *encoder,
if (is_edp(intel_dp) && intel_connector->panel.fixed_mode) {
intel_fixed_panel_mode(intel_connector->panel.fixed_mode,
   adjusted_mode);
-   intel_pch_panel_fitting(dev, DRM_MODE_SCALE_FULLSCREEN,
+   intel_pch_panel_fitting(dev,
+   intel_connector->panel.fitting_mode,
mode, adjusted_mode);
}

@@ -2359,6 +2360,7 @@ intel_dp_set_property(struct drm_connector *connector,
  uint64_t val)
 {
struct drm_i915_private *dev_priv = connector->dev->dev_private;
+   struct intel_connector *intel_connector = to_intel_connector(connector);
struct intel_dp *intel_dp = intel_attached_dp(connector);
int ret;

@@ -2395,6 +2397,22 @@ intel_dp_set_property(struct drm_connector *connector,
goto done;
}

+   if (is_edp(intel_dp) &&
+   property == connector->dev->mode_config.scaling_mode_property) {
+   if (val == DRM_MODE_SCALE_NONE) {
+   DRM_DEBUG_KMS("no scaling not supported\n");
+   return -EINVAL;
+   }
+
+   if (intel_connector->panel.fitting_mode == val) {
+   /* the eDP scaling property is not changed */
+   return 0;
+   }
+   intel_connector->panel.fitting_mode = val;
+
+   goto done;
+   }
+
return -EINVAL;

 done:
@@ -2519,8 +2537,19 @@ bool intel_dpd_is_edp(struct drm_device *dev)
 static void
 intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector 
*connector)
 {
+   struct intel_connector *intel_connector = to_intel_connector(connector);
+
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
+
+   if (is_edp(intel_dp)) {
+   drm_mode_create_scaling_mode_property(connector->dev);
+   drm_connector_attach_property(
+   connector,
+   connector->dev->mode_config.scaling_mode_property,
+   DRM_MODE_SCALE_FULLSCREEN);
+   intel_connector->panel.fitting_mode = DRM_MODE_SCALE_FULLSCREEN;
+   }
 }

 static void
-- 
1.7.9.5

[PATCH 1/3] drm/i915/lvds: move fitting mode from intel_lvds_connector to intel_panel

Prepare for supporting scaling mode configuration also in eDP.

Includes a drive-by-removal of an outdated comment about fitting mode.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_drv.h  |1 +
 drivers/gpu/drm/i915/intel_lvds.c |   24 ++--
 2 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 81d2020..8839ed5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -165,6 +165,7 @@ struct intel_encoder {

 struct intel_panel {
struct drm_display_mode *fixed_mode;
+   int fitting_mode;
 };

 struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 587ed0f..ffa0051 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -44,7 +44,6 @@ struct intel_lvds_connector {
struct intel_connector base;

struct notifier_block lid_notifier;
-   int fitting_mode;
 };

 struct intel_lvds_encoder {
@@ -253,8 +252,8 @@ static bool intel_lvds_mode_fixup(struct drm_encoder 
*encoder,
struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_lvds_encoder *lvds_encoder = to_lvds_encoder(encoder);
-   struct intel_lvds_connector *lvds_connector =
-   lvds_encoder->attached_connector;
+   struct intel_connector *intel_connector =
+   _encoder->attached_connector->base;
struct intel_crtc *intel_crtc = lvds_encoder->base.new_crtc;
u32 pfit_control = 0, pfit_pgm_ratios = 0, border = 0;
int pipe;
@@ -274,11 +273,12 @@ static bool intel_lvds_mode_fixup(struct drm_encoder 
*encoder,
 * with the panel scaling set up to source from the H/VDisplay
 * of the original mode.
 */
-   intel_fixed_panel_mode(lvds_connector->base.panel.fixed_mode,
+   intel_fixed_panel_mode(intel_connector->panel.fixed_mode,
   adjusted_mode);

if (HAS_PCH_SPLIT(dev)) {
-   intel_pch_panel_fitting(dev, lvds_connector->fitting_mode,
+   intel_pch_panel_fitting(dev,
+   intel_connector->panel.fitting_mode,
mode, adjusted_mode);
return true;
}
@@ -304,7 +304,7 @@ static bool intel_lvds_mode_fixup(struct drm_encoder 
*encoder,

drm_mode_set_crtcinfo(adjusted_mode, 0);

-   switch (lvds_connector->fitting_mode) {
+   switch (intel_connector->panel.fitting_mode) {
case DRM_MODE_SCALE_CENTER:
/*
 * For centered modes, we have to calculate border widths &
@@ -573,7 +573,7 @@ static int intel_lvds_set_property(struct drm_connector 
*connector,
   struct drm_property *property,
   uint64_t value)
 {
-   struct intel_lvds_connector *lvds_connector = 
to_lvds_connector(connector);
+   struct intel_connector *intel_connector = to_intel_connector(connector);
struct drm_device *dev = connector->dev;

if (property == dev->mode_config.scaling_mode_property) {
@@ -584,11 +584,11 @@ static int intel_lvds_set_property(struct drm_connector 
*connector,
return -EINVAL;
}

-   if (lvds_connector->fitting_mode == value) {
+   if (intel_connector->panel.fitting_mode == value) {
/* the LVDS scaling property is not changed */
return 0;
}
-   lvds_connector->fitting_mode = value;
+   intel_connector->panel.fitting_mode = value;

crtc = intel_attached_encoder(connector)->base.crtc;
if (crtc && crtc->enabled) {
@@ -1008,14 +1008,10 @@ bool intel_lvds_init(struct drm_device *dev)

/* create the scaling mode property */
drm_mode_create_scaling_mode_property(dev);
-   /*
-* the initial panel fitting mode will be FULL_SCREEN.
-*/
-
drm_connector_attach_property(_connector->base,
  dev->mode_config.scaling_mode_property,
  DRM_MODE_SCALE_ASPECT);
-   lvds_connector->fitting_mode = DRM_MODE_SCALE_ASPECT;
+   intel_connector->panel.fitting_mode = DRM_MODE_SCALE_ASPECT;
/*
 * LVDS discovery:
 * 1) check for EDID on DDC
-- 
1.7.9.5

[PATCH 0/3] drm/i915: eDP scaling mode change support

[Dropped lkml, added intel-gfx]

Hi Yuly, here's a slightly modified version of your patch, rebased on
drm-intel-next-queued. I kept your authorship, but any new errors are
totally mine...

These are compile tested only; I'd appreciate if you could check it
still does what it says on the box!

BR,
Jani.


Jani Nikula (1):
  drm/i915/lvds: move fitting mode from intel_lvds_connector to
intel_panel

Yuly Novikov (2):
  drm/i915/dp: allow configuring eDP panel fitting scaling mode
  drm/i915/dp: change eDP default scaling mode to respect aspect ratio

 drivers/gpu/drm/i915/intel_dp.c   |   31 ++-
 drivers/gpu/drm/i915/intel_drv.h  |1 +
 drivers/gpu/drm/i915/intel_lvds.c |   24 ++--
 3 files changed, 41 insertions(+), 15 deletions(-)

-- 
1.7.9.5

[Intel-gfx] [PATCH 0/3] drm/i915: eDP scaling mode change support

2012-10-26 Thread Paulo Zanoni

Hi

2012/10/26 Jani Nikula :
> [Dropped lkml, added intel-gfx]
>
> Hi Yuly, here's a slightly modified version of your patch, rebased on
> drm-intel-next-queued. I kept your authorship, but any new errors are
> totally mine...
>
> These are compile tested only; I'd appreciate if you could check it
> still does what it says on the box!

I have nothing to add or remove. Tested on HSW eDP, used "xrandr" to
alternate the property values. Works fine.

Being consistent on the default value between LVDS and eDP is
certainly a nice thing.

For the 3 patches:
Reviewed-by: Paulo Zanoni 
Tested-by: Paulo Zanoni 

>
> BR,
> Jani.
>
>
> Jani Nikula (1):
>   drm/i915/lvds: move fitting mode from intel_lvds_connector to
> intel_panel
>
> Yuly Novikov (2):
>   drm/i915/dp: allow configuring eDP panel fitting scaling mode
>   drm/i915/dp: change eDP default scaling mode to respect aspect ratio
>
>  drivers/gpu/drm/i915/intel_dp.c   |   31 ++-
>  drivers/gpu/drm/i915/intel_drv.h  |1 +
>  drivers/gpu/drm/i915/intel_lvds.c |   24 ++--
>  3 files changed, 41 insertions(+), 15 deletions(-)
>
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Paulo Zanoni

[drm:i915_hangcheck_hung] ERROR Hangcheck timer elapsed... GPU hung

2012-10-26 Thread Justin P. Mattock

On 10/26/2012 01:05 AM, Daniel Vetter wrote:
> On Fri, Oct 26, 2012 at 6:43 AM, Justin P. Mattock
>  wrote:
>>>
>>> No worries, it is another ILK hang similar to the ones reported earlier
>>> - it just seems the ring stops advancing. Hopefully it is a missing w/a
>>> from http://cgit.freedesktop.org/~danvet/drm/log/?h=ilk-wa-pile
>>> -Chris
>>>
>>
>> well if this means building libdrm etc.. then thats not a problem, more time
>> consuming if anything. perhaps an *.rpm that I can test to see?
>
> It's not libdrm, the above is just a kernel git tree with a bunch of
> ironlake workarounds.
> -Daniel
>


hmm.. then in that case maybe I should pull and run that kernel to see 
if the crash occurs, before bisecting(if anything).
will do once I get time to download.

Justin P. Mattock

Breakage in "track dev_mapping in more robust and flexible way"

2012-10-26 Thread Thomas Hellstrom

Hi,

On 10/25/2012 11:27 PM, Ilija Hadzic wrote:
>
> Can you give the attached patch a whirl and let me know if it fixes 
> the problem?
>
> As I indicated in my previous note, vmwgfx should be the only affected 
> driver because it looks at dev_mapping in the open hook (others do it 
> when they create an object, so they are not affected).
>
> I'll probably revise it (and I'll have some general questions about 
> drm_open syscall) before officially send the patch, but I wanted to 
> get something quickly to you to check if it fixes your problem. I hope 
> that your vmwgfx test environment is such that you can reproduce the 
> original
> problem.
>
> thanks,
>
> -- Ilija

Yes, it appears like this patch fixes the problem. It'd be good to have 
it in 3.7 (drm-fixes) with a cc to stable.

/Thomas

[drm:i915_hangcheck_hung] ERROR Hangcheck timer elapsed... GPU hung

2012-10-26 Thread Daniel Vetter

On Fri, Oct 26, 2012 at 6:43 AM, Justin P. Mattock
 wrote:
>>
>> No worries, it is another ILK hang similar to the ones reported earlier
>> - it just seems the ring stops advancing. Hopefully it is a missing w/a
>> from http://cgit.freedesktop.org/~danvet/drm/log/?h=ilk-wa-pile
>> -Chris
>>
>
> well if this means building libdrm etc.. then thats not a problem, more time
> consuming if anything. perhaps an *.rpm that I can test to see?

It's not libdrm, the above is just a kernel git tree with a bunch of
ironlake workarounds.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[patch] drm: potential NULL dereference with debugging enabled

2012-10-26 Thread Dan Carpenter

We check whether this pointer is NULL a few lines later in the function
so probably we should check here too.

Signed-off-by: Dan Carpenter 
---
This is a static checker fix.

diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index d752c96..036253e 100644
--- a/drivers/gpu/drm/drm_lock.c
+++ b/drivers/gpu/drm/drm_lock.c
@@ -68,7 +68,8 @@ int drm_lock(struct drm_device *dev, void *data, struct 
drm_file *file_priv)

DRM_DEBUG("%d (pid %d) requests lock (0x%08x), flags = 0x%08x\n",
  lock->context, task_pid_nr(current),
- master->lock.hw_lock->lock, lock->flags);
+ master->lock.hw_lock ? master->lock.hw_lock->lock : -1,
+ lock->flags);

add_wait_queue(>lock.lock_queue, );
spin_lock_bh(>lock.spinlock);

[PATCHv10 08/26] v4l: vb2-dma-contig: add support for scatterlist in userptr mode

2012-10-26 Thread Pawel Osciak

Hi Tomasz,

On Wed, Oct 10, 2012 at 7:46 AM, Tomasz Stanislawski
 wrote:
> This patch introduces usage of dma_map_sg to map memory behind
> a userspace pointer to a device as dma-contiguous mapping.
>

Perhaps I'm missing something, but I don't understand the purpose of
this patch. If the device can do DMA SG, why use videobuf2-dma-contig
and not videobuf2-dma-sg? What would be the difference design-wise
between them if this patch is merged?

-- 
Best regards,
Pawel Osciak

[Bug 49531] Powering down inactive GPU while running X causes NULL pointer dereference

2012-10-26 Thread bugzilla-dae...@bugzilla.kernel.org

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





--- Comment #5 from Michel D?nzer   2012-10-26 08:21:53 
---
Please attach the full dmesg output showing the drm/radeon initialization
messages.

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

Breakage in "track dev_mapping in more robust and flexible way"

2012-10-26 Thread Ilija Hadzic

On Fri, 26 Oct 2012, Thomas Hellstrom wrote:

> Hi,
>
> On 10/25/2012 11:27 PM, Ilija Hadzic wrote:
>> 
>> Can you give the attached patch a whirl and let me know if it fixes the 
>> problem?
>> 
>> As I indicated in my previous note, vmwgfx should be the only affected 
>> driver because it looks at dev_mapping in the open hook (others do it when 
>> they create an object, so they are not affected).
>> 
>> I'll probably revise it (and I'll have some general questions about 
>> drm_open syscall) before officially send the patch, but I wanted to get 
>> something quickly to you to check if it fixes your problem. I hope that 
>> your vmwgfx test environment is such that you can reproduce the original
>> problem.
>> 
>> thanks,
>> 
>> -- Ilija
>
> Yes, it appears like this patch fixes the problem. It'd be good to have it in 
> 3.7 (drm-fixes) with a cc to stable.
>

OK great. Thanks for testing. Before I send out an "official" patch, I 
have a few questions for those who have been around longer and can 
possibly reflect better than me on the history of drm_open syscall.

Currently, before touching dev->dev_mapping field we grab dev->struct 
mutex. This has been introduced by Dave Airlie a long time ago in 
a2c0a97b784f837300f7b0869c82ab712c600952. I tried to preserve that in all 
patches where I touched dev_open, but looking at the code I don't think 
the mutex is necessary. Namely, drm_open is only set in drm_open, and 
concurrent openers are protected with drm_global_mutex. Other places 
(drivers) where dev->dev_mapping is accessed is read-only and dev_mapping 
is written at first open when there are no file descriptors around to 
issue any other call. Also, it doesn't look to me that any driver locks 
dev->struct_mutex before accessing dev->dev_mapping anyway. So I am 
thinking of dropping the mutex completely, but I would like to hear a 
second thought.

The other issue, I noticed is that of the drm_setup() call fails, the 
open_count counter would remain incremented and I think we need to restore 
it back (or if I am missing something, would someone please enlighten me). 
This was also in the kernel all this time (and I have not noticed until 
now), so I "smuggled" that fix in the patch that I sent you. However, 
wonder if I should cut the separate patch for open_count fix.

Actually, I think that I should cut three patches: one to drop the mutex, 
one to fix the open_count and one to fix your problem with dev_mapping and 
that probably all three should CC stable. Before I do that, I'd like to 
hear opinions of others.

thanks,

Ilija

[Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL

2012-10-26 Thread Dave Airlie

> Unlikely as most of the code I've written belongs to Intel or Red Hat. I
> also have better things to do with life than sue Nvidia and start an all
> out copyright and patent war in Linuxspace.

I forgot to ask, but after your petty G+ trolling, if most of the code
belings to Intel or Red Hat, why do we need to listen to *your*
lawyers advice? It seems like you aren't a major rights holder but a
troll.

Dave.

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

, the new code doesn't
write in the EVERGREEN_CRTC_UPDATE_LOCK neither before nor after setting
EVERGREEN_CRTC_CONTROL.

Could this be a clue?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121026/4c6d325c/attachment.html>

[git pull] drm radeon fixes.

2012-10-26 Thread Dave Airlie


Hi Linus,

Just radeon fixes in this one,
some new PCI IDs,
ATPX regression fix,
async VM regression fixes
some module options fixes.

Dave.

The following changes since commit b8e902f24fdd16c4373ddc37a4e150c4afe9c6db:

  drm/ttm: Fix a theoretical race in ttm_bo_cleanup_refs() (2012-10-23 10:15:21 
+1000)

are available in the git repository at:
  git://people.freedesktop.org/~airlied/linux drm-fixes

Alex Deucher (6):
  drm/radeon: add some new SI PCI ids
  drm/radeon: fix sparse warning
  drm/radeon: give each backlight a unique id
  drm/radeon: add error output if VM CS fails on cayman
  drm/radeon: fix ATPX function documentation
  drm/radeon: fix ATPX regression in acpi rework

Christian K?nig (9):
  drm/radeon: fix PFP sync in vm_flush
  drm/radeon: fix cayman_vm_set_page v2
  drm/radeon: fix si_set_page v2
  drm/radeon: remove set_page check from VM code
  drm/radeon: fix header size estimation in VM code
  drm/radeon: fix and simplify pot argument checks v3
  drm/radeon: use vzalloc for gart pages
  drm/radeon: move size limits to gem_object_create.
  drm/radeon: move the retry to gem_object_create

Dave Airlie (1):
  Merge branch 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes

 drivers/gpu/drm/radeon/atombios_encoders.c  |5 ++-
 drivers/gpu/drm/radeon/evergreen_cs.c   |1 +
 drivers/gpu/drm/radeon/ni.c |   45 ++---
 drivers/gpu/drm/radeon/nid.h|1 +
 drivers/gpu/drm/radeon/radeon_atpx_handler.c|6 +-
 drivers/gpu/drm/radeon/radeon_device.c  |   60 +--
 drivers/gpu/drm/radeon/radeon_gart.c|   22 -
 drivers/gpu/drm/radeon/radeon_gem.c |   18 ++-
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |5 ++-
 drivers/gpu/drm/radeon/radeon_object.c  |   19 ---
 drivers/gpu/drm/radeon/si.c |   47 +++---
 include/drm/drm_pciids.h|3 +
 12 files changed, 122 insertions(+), 110 deletions(-)

[PATCH] DRM/Radeon: Set depth on low mem Radeon cards to 16 instead of 8.

2012-10-26 Thread Egbert Eich

Dave Airlie writes:
 > On Thu, Oct 25, 2012 at 3:07 AM, Alex Deucher  
 > wrote:
 > > On Wed, Oct 24, 2012 at 12:33 PM, Egbert Eich  wrote:
 > >> The Radeon driver reduces the framebuffer resolution to 8bpp if
 > >> a device with less than 32 Mb VRAM is found. This causes the
 > >> framebuffer to run in 8 bit paletted mode. For a text console this
 > >> is not an issue as 256 different colors is more than one gets
 > >> on a VGA text console.
 > >> It is done to give X more memory to work with since the console memory
 > >> is not freed but remains allocated while X is active.
 > >> Still, running the fbdev Xserver driver - which we do during installation
 > >> - will give applications an 8bit pseudo-color visual which doesn't look
 > >> too pretty.
 > >> We therefore limit the framebuffer bpp to 16 when memory is 24MB or lower
 > >> and to 8 only if 8MB or less VRAM is found.
 > >> This should be a reasonable compromise for us.
 > >> This patch will most likely not ever make it upstream.
 > >>
 > >> This works around ugly modes on crappy IPMI cards using ES1000.
 > >
 > > I don't have a strong opinion either way on this one.
 > 
 > Why would you use fbdev? package -modesetting at least if not the real ATI 
 > DDX.
 > 

fbdev is good as a general fallback which works pretty much everywhere - even
if there's no KMS driver available in the kernel (in this case with vesa
fbdev).
I'm not pushing strongly for this patch making it into the mainline kernel,
I need to carry it around for our enterprise product for the time being.
It could well be that it can be tossed once we redesign things for SLE13.

But maybe you may want to repace the '<=' with a '<' so that the code 
matches the comment above ie. that one gets 8bpp only for 16MB and less
which would already help.

Cheers,
Egbert.

[patch] drm: potential NULL dereference with debugging enabled

2012-10-26 Thread Dan Carpenter

We check whether this pointer is NULL a few lines later in the function
so probably we should check here too.

Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
This is a static checker fix.

diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index d752c96..036253e 100644
--- a/drivers/gpu/drm/drm_lock.c
+++ b/drivers/gpu/drm/drm_lock.c
@@ -68,7 +68,8 @@ int drm_lock(struct drm_device *dev, void *data, struct 
drm_file *file_priv)
 
DRM_DEBUG(%d (pid %d) requests lock (0x%08x), flags = 0x%08x\n,
  lock-context, task_pid_nr(current),
- master-lock.hw_lock-lock, lock-flags);
+ master-lock.hw_lock ? master-lock.hw_lock-lock : -1,
+ lock-flags);
 
add_wait_queue(master-lock.lock_queue, entry);
spin_lock_bh(master-lock.spinlock);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm:i915_hangcheck_hung] ERROR Hangcheck timer elapsed... GPU hung

2012-10-26 Thread Daniel Vetter

On Fri, Oct 26, 2012 at 6:43 AM, Justin P. Mattock
justinmatt...@gmail.com wrote:

 No worries, it is another ILK hang similar to the ones reported earlier
 - it just seems the ring stops advancing. Hopefully it is a missing w/a
 from http://cgit.freedesktop.org/~danvet/drm/log/?h=ilk-wa-pile
 -Chris


 well if this means building libdrm etc.. then thats not a problem, more time
 consuming if anything. perhaps an *.rpm that I can test to see?

It's not libdrm, the above is just a kernel git tree with a bunch of
ironlake workarounds.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Breakage in track dev_mapping in more robust and flexible way

2012-10-26 Thread Thomas Hellstrom


Hi,

On 10/25/2012 11:27 PM, Ilija Hadzic wrote:


Can you give the attached patch a whirl and let me know if it fixes 
the problem?


As I indicated in my previous note, vmwgfx should be the only affected 
driver because it looks at dev_mapping in the open hook (others do it 
when they create an object, so they are not affected).


I'll probably revise it (and I'll have some general questions about 
drm_open syscall) before officially send the patch, but I wanted to 
get something quickly to you to check if it fixes your problem. I hope 
that your vmwgfx test environment is such that you can reproduce the 
original

problem.

thanks,

-- Ilija


Yes, it appears like this patch fixes the problem. It'd be good to have 
it in 3.7 (drm-fixes) with a cc to stable.


/Thomas

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

[Bug 49531] Powering down inactive GPU while running X causes NULL pointer dereference

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





--- Comment #5 from Michel Dänzer mic...@daenzer.net  2012-10-26 08:21:53 ---
Please attach the full dmesg output showing the drm/radeon initialization
messages.

-- 
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: Breakage in track dev_mapping in more robust and flexible way

2012-10-26 Thread Ilija Hadzic




On Fri, 26 Oct 2012, Thomas Hellstrom wrote:


Hi,

On 10/25/2012 11:27 PM, Ilija Hadzic wrote:


Can you give the attached patch a whirl and let me know if it fixes the 
problem?


As I indicated in my previous note, vmwgfx should be the only affected 
driver because it looks at dev_mapping in the open hook (others do it when 
they create an object, so they are not affected).


I'll probably revise it (and I'll have some general questions about 
drm_open syscall) before officially send the patch, but I wanted to get 
something quickly to you to check if it fixes your problem. I hope that 
your vmwgfx test environment is such that you can reproduce the original

problem.

thanks,

-- Ilija


Yes, it appears like this patch fixes the problem. It'd be good to have it in 
3.7 (drm-fixes) with a cc to stable.




OK great. Thanks for testing. Before I send out an official patch, I 
have a few questions for those who have been around longer and can 
possibly reflect better than me on the history of drm_open syscall.


Currently, before touching dev-dev_mapping field we grab dev-struct 
mutex. This has been introduced by Dave Airlie a long time ago in 
a2c0a97b784f837300f7b0869c82ab712c600952. I tried to preserve that in all 
patches where I touched dev_open, but looking at the code I don't think 
the mutex is necessary. Namely, drm_open is only set in drm_open, and 
concurrent openers are protected with drm_global_mutex. Other places 
(drivers) where dev-dev_mapping is accessed is read-only and dev_mapping 
is written at first open when there are no file descriptors around to 
issue any other call. Also, it doesn't look to me that any driver locks 
dev-struct_mutex before accessing dev-dev_mapping anyway. So I am 
thinking of dropping the mutex completely, but I would like to hear a 
second thought.


The other issue, I noticed is that of the drm_setup() call fails, the 
open_count counter would remain incremented and I think we need to restore 
it back (or if I am missing something, would someone please enlighten me). 
This was also in the kernel all this time (and I have not noticed until 
now), so I smuggled that fix in the patch that I sent you. However, 
wonder if I should cut the separate patch for open_count fix.


Actually, I think that I should cut three patches: one to drop the mutex, 
one to fix the open_count and one to fix your problem with dev_mapping and 
that probably all three should CC stable. Before I do that, I'd like to 
hear opinions of others.


thanks,

Ilija

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

[PATCH 0/3] drm/i915: eDP scaling mode change support

[Dropped lkml, added intel-gfx]

Hi Yuly, here's a slightly modified version of your patch, rebased on
drm-intel-next-queued. I kept your authorship, but any new errors are
totally mine...

These are compile tested only; I'd appreciate if you could check it
still does what it says on the box!

BR,
Jani.


Jani Nikula (1):
  drm/i915/lvds: move fitting mode from intel_lvds_connector to
intel_panel

Yuly Novikov (2):
  drm/i915/dp: allow configuring eDP panel fitting scaling mode
  drm/i915/dp: change eDP default scaling mode to respect aspect ratio

 drivers/gpu/drm/i915/intel_dp.c   |   31 ++-
 drivers/gpu/drm/i915/intel_drv.h  |1 +
 drivers/gpu/drm/i915/intel_lvds.c |   24 ++--
 3 files changed, 41 insertions(+), 15 deletions(-)

-- 
1.7.9.5

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

[PATCH 1/3] drm/i915/lvds: move fitting mode from intel_lvds_connector to intel_panel

Prepare for supporting scaling mode configuration also in eDP.

Includes a drive-by-removal of an outdated comment about fitting mode.

Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/i915/intel_drv.h  |1 +
 drivers/gpu/drm/i915/intel_lvds.c |   24 ++--
 2 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 81d2020..8839ed5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -165,6 +165,7 @@ struct intel_encoder {
 
 struct intel_panel {
struct drm_display_mode *fixed_mode;
+   int fitting_mode;
 };
 
 struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 587ed0f..ffa0051 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -44,7 +44,6 @@ struct intel_lvds_connector {
struct intel_connector base;
 
struct notifier_block lid_notifier;
-   int fitting_mode;
 };
 
 struct intel_lvds_encoder {
@@ -253,8 +252,8 @@ static bool intel_lvds_mode_fixup(struct drm_encoder 
*encoder,
struct drm_device *dev = encoder-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_lvds_encoder *lvds_encoder = to_lvds_encoder(encoder);
-   struct intel_lvds_connector *lvds_connector =
-   lvds_encoder-attached_connector;
+   struct intel_connector *intel_connector =
+   lvds_encoder-attached_connector-base;
struct intel_crtc *intel_crtc = lvds_encoder-base.new_crtc;
u32 pfit_control = 0, pfit_pgm_ratios = 0, border = 0;
int pipe;
@@ -274,11 +273,12 @@ static bool intel_lvds_mode_fixup(struct drm_encoder 
*encoder,
 * with the panel scaling set up to source from the H/VDisplay
 * of the original mode.
 */
-   intel_fixed_panel_mode(lvds_connector-base.panel.fixed_mode,
+   intel_fixed_panel_mode(intel_connector-panel.fixed_mode,
   adjusted_mode);
 
if (HAS_PCH_SPLIT(dev)) {
-   intel_pch_panel_fitting(dev, lvds_connector-fitting_mode,
+   intel_pch_panel_fitting(dev,
+   intel_connector-panel.fitting_mode,
mode, adjusted_mode);
return true;
}
@@ -304,7 +304,7 @@ static bool intel_lvds_mode_fixup(struct drm_encoder 
*encoder,
 
drm_mode_set_crtcinfo(adjusted_mode, 0);
 
-   switch (lvds_connector-fitting_mode) {
+   switch (intel_connector-panel.fitting_mode) {
case DRM_MODE_SCALE_CENTER:
/*
 * For centered modes, we have to calculate border widths 
@@ -573,7 +573,7 @@ static int intel_lvds_set_property(struct drm_connector 
*connector,
   struct drm_property *property,
   uint64_t value)
 {
-   struct intel_lvds_connector *lvds_connector = 
to_lvds_connector(connector);
+   struct intel_connector *intel_connector = to_intel_connector(connector);
struct drm_device *dev = connector-dev;
 
if (property == dev-mode_config.scaling_mode_property) {
@@ -584,11 +584,11 @@ static int intel_lvds_set_property(struct drm_connector 
*connector,
return -EINVAL;
}
 
-   if (lvds_connector-fitting_mode == value) {
+   if (intel_connector-panel.fitting_mode == value) {
/* the LVDS scaling property is not changed */
return 0;
}
-   lvds_connector-fitting_mode = value;
+   intel_connector-panel.fitting_mode = value;
 
crtc = intel_attached_encoder(connector)-base.crtc;
if (crtc  crtc-enabled) {
@@ -1008,14 +1008,10 @@ bool intel_lvds_init(struct drm_device *dev)
 
/* create the scaling mode property */
drm_mode_create_scaling_mode_property(dev);
-   /*
-* the initial panel fitting mode will be FULL_SCREEN.
-*/
-
drm_connector_attach_property(intel_connector-base,
  dev-mode_config.scaling_mode_property,
  DRM_MODE_SCALE_ASPECT);
-   lvds_connector-fitting_mode = DRM_MODE_SCALE_ASPECT;
+   intel_connector-panel.fitting_mode = DRM_MODE_SCALE_ASPECT;
/*
 * LVDS discovery:
 * 1) check for EDID on DDC
-- 
1.7.9.5

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

[PATCH 2/3] drm/i915/dp: allow configuring eDP panel fitting scaling mode

From: Yuly Novikov ynovi...@chromium.org

LVDS allowed changing panel fitting scaling mode, while eDP didn't. Copied
relevant code from LVDS to eDP.

Signed-off-by: Yuly Novikov ynovi...@chromium.org
[Jani: use fitting mode in intel_panel, remove default mode change]
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |   31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2a9998a..30314c0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -693,7 +693,8 @@ intel_dp_mode_fixup(struct drm_encoder *encoder,
if (is_edp(intel_dp)  intel_connector-panel.fixed_mode) {
intel_fixed_panel_mode(intel_connector-panel.fixed_mode,
   adjusted_mode);
-   intel_pch_panel_fitting(dev, DRM_MODE_SCALE_FULLSCREEN,
+   intel_pch_panel_fitting(dev,
+   intel_connector-panel.fitting_mode,
mode, adjusted_mode);
}
 
@@ -2359,6 +2360,7 @@ intel_dp_set_property(struct drm_connector *connector,
  uint64_t val)
 {
struct drm_i915_private *dev_priv = connector-dev-dev_private;
+   struct intel_connector *intel_connector = to_intel_connector(connector);
struct intel_dp *intel_dp = intel_attached_dp(connector);
int ret;
 
@@ -2395,6 +2397,22 @@ intel_dp_set_property(struct drm_connector *connector,
goto done;
}
 
+   if (is_edp(intel_dp) 
+   property == connector-dev-mode_config.scaling_mode_property) {
+   if (val == DRM_MODE_SCALE_NONE) {
+   DRM_DEBUG_KMS(no scaling not supported\n);
+   return -EINVAL;
+   }
+
+   if (intel_connector-panel.fitting_mode == val) {
+   /* the eDP scaling property is not changed */
+   return 0;
+   }
+   intel_connector-panel.fitting_mode = val;
+
+   goto done;
+   }
+
return -EINVAL;
 
 done:
@@ -2519,8 +2537,19 @@ bool intel_dpd_is_edp(struct drm_device *dev)
 static void
 intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector 
*connector)
 {
+   struct intel_connector *intel_connector = to_intel_connector(connector);
+
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
+
+   if (is_edp(intel_dp)) {
+   drm_mode_create_scaling_mode_property(connector-dev);
+   drm_connector_attach_property(
+   connector,
+   connector-dev-mode_config.scaling_mode_property,
+   DRM_MODE_SCALE_FULLSCREEN);
+   intel_connector-panel.fitting_mode = DRM_MODE_SCALE_FULLSCREEN;
+   }
 }
 
 static void
-- 
1.7.9.5

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

[PATCH 3/3] drm/i915/dp: change eDP default scaling mode to respect aspect ratio

From: Yuly Novikov ynovi...@chromium.org

Signed-off-by: Yuly Novikov ynovi...@chromium.org
[Jani: ripped this change separate from the scaling mode change support]
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 30314c0..a1b9fc13 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2547,8 +2547,8 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct 
drm_connector *connect
drm_connector_attach_property(
connector,
connector-dev-mode_config.scaling_mode_property,
-   DRM_MODE_SCALE_FULLSCREEN);
-   intel_connector-panel.fitting_mode = DRM_MODE_SCALE_FULLSCREEN;
+   DRM_MODE_SCALE_ASPECT);
+   intel_connector-panel.fitting_mode = DRM_MODE_SCALE_ASPECT;
}
 }
 
-- 
1.7.9.5

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

Re: [Intel-gfx] [PATCH 0/3] drm/i915: eDP scaling mode change support

2012-10-26 Thread Paulo Zanoni

Hi

2012/10/26 Jani Nikula jani.nik...@intel.com:
 [Dropped lkml, added intel-gfx]

 Hi Yuly, here's a slightly modified version of your patch, rebased on
 drm-intel-next-queued. I kept your authorship, but any new errors are
 totally mine...

 These are compile tested only; I'd appreciate if you could check it
 still does what it says on the box!

I have nothing to add or remove. Tested on HSW eDP, used xrandr to
alternate the property values. Works fine.

Being consistent on the default value between LVDS and eDP is
certainly a nice thing.

For the 3 patches:
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Tested-by: Paulo Zanoni paulo.r.zan...@intel.com


 BR,
 Jani.


 Jani Nikula (1):
   drm/i915/lvds: move fitting mode from intel_lvds_connector to
 intel_panel

 Yuly Novikov (2):
   drm/i915/dp: allow configuring eDP panel fitting scaling mode
   drm/i915/dp: change eDP default scaling mode to respect aspect ratio

  drivers/gpu/drm/i915/intel_dp.c   |   31 ++-
  drivers/gpu/drm/i915/intel_drv.h  |1 +
  drivers/gpu/drm/i915/intel_lvds.c |   24 ++--
  3 files changed, 41 insertions(+), 15 deletions(-)

 --
 1.7.9.5

 ___
 Intel-gfx mailing list
 intel-...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx



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

Re: [PATCH 1/4] drm/exynos: add ipp subsystem

2012-10-26 Thread Inki Dae

below is quick review.

2012/10/18 Eunchul Kim chulspro@samsung.com:
 IPP stand for Image Post Processing and supports image scaler/rotator
 /crop/flip/csc(color space conversion) and input/output DMA operations using 
 ipp drivers.
 also supports writeback and display output operations.
 ipp driver include FIMC, Rotator, GSC, SC, so on.
 and ipp is integration device driver for each hardware.

 Signed-off-by: Eunchul Kim chulspro@samsung.com
 Signed-off-by: Jinyoung Jeon jy0.j...@samsung.com
 ---
  drivers/gpu/drm/exynos/Kconfig  |6 +
  drivers/gpu/drm/exynos/Makefile |1 +
  drivers/gpu/drm/exynos/exynos_drm_drv.c |   24 +
  drivers/gpu/drm/exynos/exynos_drm_drv.h |7 +
  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 1937 
 +++
  drivers/gpu/drm/exynos/exynos_drm_ipp.h |  268 +
  include/uapi/drm/exynos_drm.h   |  189 +++
  7 files changed, 2432 insertions(+), 0 deletions(-)
  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.c
  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.h

 diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
 index 59a26e5..4c83d0b 100644
 --- a/drivers/gpu/drm/exynos/Kconfig
 +++ b/drivers/gpu/drm/exynos/Kconfig
 @@ -39,3 +39,9 @@ config DRM_EXYNOS_G2D
 depends on DRM_EXYNOS  !VIDEO_SAMSUNG_S5P_G2D
 help
   Choose this option if you want to use Exynos G2D for DRM.
 +
 +config DRM_EXYNOS_IPP
 +   bool Exynos DRM IPP
 +   depends on DRM_EXYNOS
 +   help
 + Choose this option if you want to use IPP feature for DRM.
 diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
 index eb651ca..e748cc7 100644
 --- a/drivers/gpu/drm/exynos/Makefile
 +++ b/drivers/gpu/drm/exynos/Makefile
 @@ -15,5 +15,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)   += exynos_hdmi.o 
 exynos_mixer.o \
exynos_drm_hdmi.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)+= exynos_drm_vidi.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o
 +exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o

  obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 index c4c719b..9e14d61 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 @@ -40,6 +40,7 @@
  #include exynos_drm_vidi.h
  #include exynos_drm_dmabuf.h
  #include exynos_drm_g2d.h
 +#include exynos_drm_ipp.h

  #define DRIVER_NAMEexynos
  #define DRIVER_DESCSamsung SoC DRM
 @@ -232,6 +233,14 @@ static struct drm_ioctl_desc exynos_ioctls[] = {
 exynos_g2d_set_cmdlist_ioctl, DRM_UNLOCKED | 
 DRM_AUTH),
 DRM_IOCTL_DEF_DRV(EXYNOS_G2D_EXEC,
 exynos_g2d_exec_ioctl, DRM_UNLOCKED | DRM_AUTH),
 +   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_PROPERTY,
 +   exynos_drm_ipp_get_property, DRM_UNLOCKED | DRM_AUTH),
 +   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_SET_PROPERTY,
 +   exynos_drm_ipp_set_property, DRM_UNLOCKED | DRM_AUTH),
 +   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_QUEUE_BUF,
 +   exynos_drm_ipp_queue_buf, DRM_UNLOCKED | DRM_AUTH),
 +   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_CMD_CTRL,
 +   exynos_drm_ipp_cmd_ctrl, DRM_UNLOCKED | DRM_AUTH),
  };

  static const struct file_operations exynos_drm_driver_fops = {
 @@ -346,6 +355,12 @@ static int __init exynos_drm_init(void)
 goto out_g2d;
  #endif

 +#ifdef CONFIG_DRM_EXYNOS_IPP
 +   ret = platform_driver_register(ipp_driver);
 +   if (ret  0)
 +   goto out_ipp;
 +#endif
 +
 ret = platform_driver_register(exynos_drm_platform_driver);
 if (ret  0)
 goto out_drm;
 @@ -363,6 +378,11 @@ out:
 platform_driver_unregister(exynos_drm_platform_driver);

  out_drm:
 +#ifdef CONFIG_DRM_EXYNOS_IPP
 +   platform_driver_unregister(ipp_driver);
 +out_ipp:
 +#endif
 +
  #ifdef CONFIG_DRM_EXYNOS_G2D
 platform_driver_unregister(g2d_driver);
  out_g2d:
 @@ -399,6 +419,10 @@ static void __exit exynos_drm_exit(void)

 platform_driver_unregister(exynos_drm_platform_driver);

 +#ifdef CONFIG_DRM_EXYNOS_IPP
 +   platform_driver_unregister(ipp_driver);
 +#endif
 +
  #ifdef CONFIG_DRM_EXYNOS_G2D
 platform_driver_unregister(g2d_driver);
  #endif
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.h
 index 531c991..4033d82 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
 @@ -235,8 +235,14 @@ struct exynos_drm_g2d_private {
 unsigned intgem_nr;
  };

 +struct exynos_drm_ipp_private {
 +   struct device   *dev;
 +   struct list_headevent_list;
 +};
 +
  struct drm_exynos_file_private {
 struct exynos_drm_g2d_private

Re: [drm:i915_hangcheck_hung] ERROR Hangcheck timer elapsed... GPU hung

2012-10-26 Thread Justin P. Mattock


On 10/26/2012 01:05 AM, Daniel Vetter wrote:

On Fri, Oct 26, 2012 at 6:43 AM, Justin P. Mattock
justinmatt...@gmail.com wrote:


No worries, it is another ILK hang similar to the ones reported earlier
- it just seems the ring stops advancing. Hopefully it is a missing w/a
from http://cgit.freedesktop.org/~danvet/drm/log/?h=ilk-wa-pile
-Chris



well if this means building libdrm etc.. then thats not a problem, more time
consuming if anything. perhaps an *.rpm that I can test to see?


It's not libdrm, the above is just a kernel git tree with a bunch of
ironlake workarounds.
-Daniel




hmm.. then in that case maybe I should pull and run that kernel to see 
if the crash occurs, before bisecting(if anything).

will do once I get time to download.

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

[Bug 56437] New: LLVM ERROR: Cannot select: target intrinsic %llvm.AMDIL.mad when running Heaven

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

  Priority: medium
Bug ID: 56437
  Assignee: dri-devel@lists.freedesktop.org
   Summary: LLVM ERROR: Cannot select: target intrinsic
%llvm.AMDIL.mad when running Heaven
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: maxi...@free.fr
  Hardware: Other
Status: NEW
   Version: unspecified
 Component: Drivers/Gallium/r600
   Product: Mesa

Heaven sometimes crashes when loading with an error output :
LLVM ERROR: Cannot select: target intrinsic %llvm.AMDIL.mad

I can partially reproduce this bug.
It happens from time to time on Heaven start.

To reproduce it I use the Heaven launcher (using Archlinux AUR package), just
untick fullscreen checkbox and choose 1024x768 and click run.
If the crash is not triggered I close the unigine render window and just click
once again Run and so on.

It happens about once every 10 runs when I test. (I know it's not convenient at
all to reproduce it but it is a very rare bug...) I also had it once with
Heroes of Newerth.

using R600_LLVM=0, radeon seems to be not hit by this problem.

Using git head and r600g on BARTS HD6870.

I might also add that I use these env vars (some are probably outdated...)
R600_ENABLE_S3TC=1
R600_GLSL130=1
R600_STREAMOUT=1

Using Xorg 1.13 and linux 3.6.3

-- 
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 56437] LLVM ERROR: Cannot select: target intrinsic %llvm.AMDIL.mad when running Heaven

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

maxi...@free.fr changed:

   What|Removed |Added

 OS|All |Linux (All)
Version|unspecified |git

-- 
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 56437] LLVM ERROR: Cannot select: target intrinsic %llvm.AMDIL.mad when running Heaven

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

--- Comment #1 from maxi...@free.fr ---
I was unclear about LLVM:
I am using the llvm glsl backend when I trigger this error.

-- 
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 56405] Distorted graphics on Radeon HD 6620G

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

--- Comment #2 from mdrs...@t-online.de ---
Created attachment 69132
  -- https://bugs.freedesktop.org/attachment.cgi?id=69132action=edit
dmesg

-- 
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 56405] Distorted graphics on Radeon HD 6620G

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

--- Comment #3 from mdrs...@t-online.de ---
Created attachment 69133
  -- https://bugs.freedesktop.org/attachment.cgi?id=69133action=edit
Xorg.0.log

-- 
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 56437] LLVM ERROR: Cannot select: target intrinsic %llvm.AMDIL.mad when running Heaven

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

--- Comment #2 from Andy Furniss li...@andyfurniss.entadsl.com ---
I saw this yesterday after rebuilding Mesa and running nexuiz.
Running again worked without error. 
This is the second time I've seen it, the first was a couple of weeks ago,
again after a rebuild of mesa this time with etqw.

I couldn't reproduce, but did get more output -

LLVM ERROR: Cannot select: target intrinsic %llvm.AMDIL.mad
Stack dump:
0.  Running pass 'Function Pass Manager' on module 'tgsi'.
1.  Running pass 'AMDGPU DAG-DAG Pattern Instruction Selection' on
function '@main'

I am using llvm 3.1 on HD4890.

-- 
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 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)