[Bug 59521] [Serious Sam 3] Missing textures with R600g

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

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

--- Comment #11 from John Bridgman  ---
Thanks. First thought is that maybe Mesa is executing precompiled shader
programs from Catalyst (you mentioned switching back and forth) but it seems
unlikely that would work even enough to be "missing textures" ;)

-- 
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/20130403/0d54a398/attachment.html>

UVD fails to init on rv790

[Dieter Nützel]

Am 2013-04-03 15:21, schrieb Alex Deucher:
> On Wed, Apr 3, 2013 at 7:29 AM, Christian K?nig 
>  wrote:
>> Hi Andy,
>> 
>> crap! I feared that something like this would happen. IIRC we never 
>> tested
>> UVD on an rv790, and this hardware isn't easy to get any more.
>> 
>> RV770/RV790 have a separate UVD hardware generation (that's why they 
>> have
>> their own firmware) and there possible is some bug or something like 
>> this
>> that we haven't implemented. You couldn't give me SSH access to that 
>> system?
> 
> I tested on an RV770 earlier in development and it was working ok at
> the time I think.  I'll give it another try today.
> 
> Alex


Hello Alex,

time goes by so fast --- wife, home, 2 children...

but what do I need:
I'll test it on my 2 HD4650/RV730 AGP (!) low speed Duron and dual 
Athlon MP.

git:// drm-fixes kernel
git:// mesa
patches

R700_rlc.bin
RV710_uvd.bin

BTW Any hints for libvdpau_r600.so.1.0.0?
I get wrong colors (red is like blue, blue is like yellow, etc.)

Thank you very much for all your GREAT work!
UVD - What a big day!

Regards,
   Dieter

--
The Voodoo5 5000 Dieter...-)
Anyone want's it? - I have the original package etc.

[Bug 63090] New: mesa 9.2git: qvdpautest fails to work with UVD but also fails with shader decoding

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

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

  Priority: medium
Bug ID: 63090
  Assignee: dri-devel at lists.freedesktop.org
   Summary: mesa 9.2git: qvdpautest fails to work with UVD but
also fails with shader decoding
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: arekm at maven.pl
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Tried to test vdpau using
https://github.com/robertmassaioli/qvdpautest

but it failed with:
qvdpautest 0.5.2
AMD E-350 Processor
Unknown GPU

VDPAU API version : 1
VDPAU implementation : G3DVL VDPAU Driver Shared Library version 1.0

FATAL: get_bits failed : No backend implementation could be loaded.!!

and very bad framerate (MPEG DECODING (1920x1080): 53 frames/s)

"No backend implementation could be loaded" happened with shaders decoding and
also with UVD decoding (while mplayer -vo vdpau worked fine on both cases)

"No backend implementation could be loaded" is mesa
VDP_STATUS_NO_IMPLEMENTATION



Test environment:
- kernel from drm-fixes + radeon UVD patches
(http://lists.freedesktop.org/archives/dri-devel/2013-April/036766.html +
http://paste.debian.net/247063/)

- mesa 9.2 from master as of 302df7cc85b0e2ce47c40048f30bd116b0d692fc + patches
http://comments.gmane.org/gmane.comp.video.mesa3d.devel/55622 and
http://lists.freedesktop.org/archives/mesa-dev/2013-April/037089.html

- E350 AMD APU with [AMD] nee ATI Wrestler [Radeon HD 6310] GPU

- vdpauinfo with shaders: http://pastebin.com/UV2CAX9F
- vdpauinfo with UVD working: http://pastebin.com/FjpLyMqr

-- 
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/20130403/58f6acaf/attachment-0001.html>

[v3.8 Regression] Merge tag 'v3.7-rc2' into drm-intel-next-queued

[Daniel Vetter]

On Wed, Apr 3, 2013 at 9:08 PM, Joseph Salisbury <
joseph.salisbury at canonical.com> wrote:

> Hi Daniel,
>
> A bug was opened against the Ubuntu kernel[0].  After a kernel bisect, it
> was found the following was the first bad commit:
>
>
> commit c2fb7916927e989ea424e61ce5fe61**7e54878827
> Merge: 29de6ce 6f0c058
> Author: Daniel Vetter 
> Date:   Mon Oct 22 14:34:51 2012 +0200
>
> Merge tag 'v3.7-rc2' into drm-intel-next-queued
>
>
>
> The regression was introduced as of v3.8-rc1.  However, further testing
> also shows this bug is now fixed in v3.9-rc4.
>
> I see that you are the author of this patch, so I wanted see if I can get
> your feedback.  Do you happen to have an idea what may have fixed this in
> v3.9-rc4, so we can send a request to stable, if not already done?
>  Otherwise, I can perform a reverse bisect to see which commit fixed this.
>

So apparently it's an oops somewhere in the nouveau setup code, which
bisected to a backmerge which has _only_ conflicts in drm/i915 driver code.

I have no idea what blew up here, sorry.
-Daniel



>
>
> Thanks,
>
> Joe
>
> [0] http://pad.lv/1109309
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130403/e2cf3bef/attachment.html>

[PATCH] drm/radeon: UVD support for RV710-SI

[Andreas Boll]

Could you bump drm minor version?

Then we could check for UVD in userspace [1]

Thanks for the great work!

Andreas.

[1] http://lists.freedesktop.org/archives/mesa-dev/2013-April/037089.html


2013/4/3 Christian K?nig 

> Hi everyone,
>
> the following patchset implements the kernel side of UVD support for the
> radeon hardware generations RV710-SI.
>
> The R6xx and RS780/RS880 chipset generations are currently not supported,
> but might be added in the future.
>
> The newest firmware can be found here: from
> http://people.freedesktop.org/~agd5f/radeon_ucode/
>
> A matching patch implementing the necessary userspace side will follow in
> just a minute on the mesa devel list.
>
> Cheers,
> Christian.
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130403/6889c3a4/attachment.html>

[PATCH v4 0/2] Enhance EDID quirks to allow forcing a mode

[Jani Nikula]

On Wed, 03 Apr 2013, Dylan Semler  wrote:
> Version 3 was Acked by Daniel Vetter[1].  Any chance ajax can give his
> comments?
>
> [1] http://lists.freedesktop.org/archives/dri-devel/2013-March/036457.html

FWIW,

Reviewed-by: Jani Nikula 

gma500: Other things that I could work on

[Patrik Jakobsson]

On Wed, Apr 3, 2013 at 5:21 PM, Kero  wrote:
> Hi,
>
> I would not mind improving use of my Asus EeePC X101CH with Cedar View / 
> gma3600
> a bit more. But a barrier is knowledge of the hardware. Meddling with 
> existing (initialization)
> code is possible, but for point 1 and 3 below that is not going to cut, it, I 
> expect.

It would be very useful if you could help out with cedarview. Even if it's just
by testing patches. A big problem for me is that I don't have the hardware so
it's easy to break things without even knowing about it.

>
> Does anyone have pointers? Who should I talk to about specifications?
> I know Intel is not forthcoming with documentation, yet several people have
> made contributions for poulsbo and later versions of the hardware.
> How did you get the required knowledge?

Most of the mode setting stuff are variations of Intel hardware. You can find
specifications at https://01.org/linuxgraphics/ and it's also useful to look at
the Intel i915 drm driver for reference. It is quite a mix so you need to look
at bits and pieces from several of the Intel generations and try to match them
together.

For the non-Intel parts there are some drivers that never made it into mainline
but is still available online. Some parts are open and some are closed.

There is also a fair amount of guessing and probing needed.

>
> Things I might, in order of personal preference, in due time (after holiday), 
> take a look at:
> 1) would be nice to have the full 1024x600 on the external VGA and HDMI
>I had a chance to try another monitor over HDMI, same result: only 800x600 
> visible.
> 2) booting with either VGA or HDMI plugged in, yields two black screens: both 
> the laptop
>and the monitor. Un- + re-plugging has no visible effect.
> 3) the Fn keys for the backlight induce a response in the backlight, but only 
> with
>tiny results; /sys/class/backlight/psb-bl/brightness works fine, though
> 4) when using modules, initialization from hibernation is not good enough:
>my screen stays black; without using modules, the kernel boots normally, 
> and everything is fine.
> 5) initialization from suspend is not good enough: my Asus stays in
>some text mode (80x25?), but shows garbage (possibly data from the desired 
> console or
>graphics mode, since sometimes there are reactions correlated to actions)
>Switching tty or using `chvt` do not improve anything.
>NB: hibernating and booting solves this.

There are quite a few issues that needs to be addressed and code that needs to
be refactored. I suggest you just dig in and get your hands dirty.

-Patrik

[Bug 62756] Rendering errors on rv790 with llvm and unigine heaven 3.0

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

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

--- Comment #8 from Andy Furniss  ---
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > No, I don't receive mail from bugzilla until someone add me manually to 
> > > the
> > > cc list (dont know what to do to fix that though)
> > 
> > drivers/gallium/r600 bugs get sent to the dri-devel list.
> 
> Ok, I always looked on mesa-dev for bugs, thank for pointing me this.
> 
> Does the "big" regression still occur with at least revision r178667 for
> llvm and commit
> http://cgit.freedesktop.org/mesa/mesa/commit/
> ?id=159d9340662a70df3dcc9da1681f5b0a8e7650cf for mesa ?

Yes, it's the same with those.

-- 
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/20130403/d20bc943/attachment.html>

radeonsi tiling dilema

[Michel Dänzer]

On Mit, 2013-04-03 at 09:57 -0400, Jerome Glisse wrote: 
> On Wed, Apr 3, 2013 at 5:37 AM, Michel D?nzer 
> wrote:
> On Die, 2013-04-02 at 14:13 -0400, Jerome Glisse wrote:
> >
> > Some might argue that we could just export the table content
> to
> > userspace, but that would loose information and possibly
> froze the
> > tile mode table forever as API.

The current index scheme already is de facto part of the API.


> The information we loose is what index
> > match to prefered surface format/type combination.

How so? We can add descriptive names for the existing indices.


> And the tile mode
> > might be considered API as if kernel ever change what
> userspace expect
> > then we might break some userspace.

Not sure how that could happen if the purpose of each index is clearly
defined.


> Maybe I'm missing the problem, but if libdrm_radeon were to
> get the
> tiling mode index chosen by radeonsi, and could retrieve the
> tiling
> parameters for each index from the kernel, it should be able
> to
> calculate things properly, shouldn't it?
> 
> 
> 
> Let's not discuss about who/where the index is pick. No matter where
> it happens the question is do we want to hardcode tile index and make
> it api or do we want to hide it behind symbolic name allowing change
> in tile array (given that right now 4 value are already frozen). You
> can look at my kernel patch to see what i mean.

The layer of indirection for the indices seems like overengineering at
this point. Even if the fixed indices stop being good enough for some
reason in the future, how can we be sure now the layer of indirection
will be good enough? So I think we shouldn't worry about that until that
day may come.


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

[PATCH 02/10] drm/radeon: UVD bringup v7

[Christian König]

Am 03.04.2013 16:53, schrieb Jerome Glisse:
> On Wed, Apr 03, 2013 at 01:18:31AM +0200, Christian K?nig wrote:
>> [SNIP]
>>
>>   /* hardcode those limit for now */
>>   #define RADEON_VA_IB_OFFSET(1 << 20)
>>   #define RADEON_VA_RESERVED_SIZE(8 << 20)
>> @@ -357,8 +360,9 @@ struct radeon_bo_list {
>>  struct ttm_validate_buffer tv;
>>  struct radeon_bo*bo;
>>  uint64_tgpu_offset;
>> -unsignedrdomain;
>> -unsignedwdomain;
>> +boolwritten;
>> +unsigneddomain;
>> +unsignedalt_domain;
>>  u32 tiling_flags;
>>   };
> I think that the change to the rdomain/wdomain should be in a patch
> of its own. I think the change is fine but we had issue with change
> that touched that part previously, would make bisecting and
> understanding the change implication easier.

Agree, I actually planed to do so, but for the whole IP review stuff we 
needed to maintain a more or less stable patch base. Long story, but I'm 
going to change it.

>>   
>> @@ -826,7 +830,6 @@ struct radeon_cs_reloc {
>>  struct radeon_bo*robj;
>>  struct radeon_bo_list   lobj;
>>  uint32_thandle;
>> -uint32_tflags;
>>   };
> Why removing the flags ? iirc it's not really use right now but i
> remember plan to use it.

Ups, just a rebasing artifact. But when it's unused we should remove it, 
probably just not in this patch.

>>   
>> [SNIP]
>>
>> +static int radeon_uvd_cs_reloc(struct radeon_cs_parser *p, int data0, int 
>> data1)
>> +{
>> +struct radeon_cs_chunk *relocs_chunk;
>> +struct radeon_cs_reloc *reloc;
>> +unsigned idx, cmd;
>> +uint64_t start, end;
>> +
>> +relocs_chunk = >chunks[p->chunk_relocs_idx];
>> +idx = radeon_get_ib_value(p, data1);
>> +if (idx >= relocs_chunk->length_dw) {
>> +DRM_ERROR("Relocs at %d after relocations chunk end %d !\n",
>> +  idx, relocs_chunk->length_dw);
>> +return -EINVAL;
>> +}
>> +
>> +reloc = p->relocs_ptr[(idx / 4)];
>> +start = reloc->lobj.gpu_offset;
>> +end = start + radeon_bo_size(reloc->robj);
>> +start += radeon_get_ib_value(p, data0);
> I am assuming there is no way for you to know the size that the uvd engine 
> will write to ?
> You are not checking anything on uvd possibly overwritting after the bo end.

Yeah that gave me headache for a quite long time, too. The problem is to 
figure out how much is actually written you need to keep track of the 
whole lot of informations including the UVD session, 
create/decode/destroy messages and allot of fiddling with the codec 
specific parameters.

And if I understand the UVD internals correctly even if we check 
everything there is no guarantee that a special crafted bitstream could 
not let UVD to write over the end of the buffer

Is it ok if we but a big TODO on it for the initial patch?

Cheers,
Christian.

radeonsi tiling dilema

[Christian König]

Am 03.04.2013 15:57, schrieb Jerome Glisse:
> On Wed, Apr 3, 2013 at 5:37 AM, Michel D?nzer  wrote:
>
>> On Die, 2013-04-02 at 14:13 -0400, Jerome Glisse wrote:
>>> So i am facing a dilema regarding tiling on radeonsi. Given that we
>>> now have a fixed table of tiling mode this put more pressure on the
>>> kernel userspace api. I see either 2 solutions.
>>>
>>>
>>> Enforce kernel to set at fixed index in the table best tiling mode for
>>> given gpu for given format, such as DEPTH32_2D_4AA at index 4, or
>>> COLOR_SCANOUT_2D at index 13 ... that way kernel can still adapt the
>>> tile mode array value. Note that this match the design behind the tile
>>> mode index being that there is a limited number of useful tile mode
>>> combination and for each surface format  (depth/color/macro
>>> tile/micro/tile) there is a best one.
>>>
>>>
>>> Second solution is to add an ioctl to compute mipmap information in
>>> kernel (pitch alignment slice size ...) based on format, size of the
>>> surface.
>>>
>>>
>>> Some might argue that we could just export the table content to
>>> userspace, but that would loose information and possibly froze the
>>> tile mode table forever as API. The information we loose is what index
>>> match to prefered surface format/type combination. And the tile mode
>>> might be considered API as if kernel ever change what userspace expect
>>> then we might break some userspace.
>> Maybe I'm missing the problem, but if libdrm_radeon were to get the
>> tiling mode index chosen by radeonsi, and could retrieve the tiling
>> parameters for each index from the kernel, it should be able to
>> calculate things properly, shouldn't it?
>>
>>
> Let's not discuss about who/where the index is pick. No matter where it
> happens the question is do we want to hardcode tile index and make it api
> or do we want to hide it behind symbolic name allowing change in tile array
> (given that right now 4 value are already frozen). You can look at my
> kernel patch to see what i mean.

Just as a side node: If I understood it correctly the hardware isn't 
completely capable to use those indexes interchangeable, e.g. only a 
certain range can be used for the DB, and another rule matters for AA 
indexes etc...

I don't know those rules exactly and I don't know how strict they are, 
but as far as I understood it even the closed source driver didn't need 
to mess with it. So I'm something like 90% sure that hardcoding them is 
ok, but well on the other hand it just doesn't feels good to do so...

Christian.

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

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130403/a3924aea/attachment-0001.html>

[Bug 59521] [Serious Sam 3] Missing textures with R600g

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

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

--- Comment #10 from Laurent carlier  ---
Probably the crash is related to some cache feature that SS3 uses (it was
reproducable when switching between catalyst and mesa).

Overriding GL_ARB_get_program_binary make the game working properly otherwise
all the textures are missing.

-- 
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/20130403/1d372d4d/attachment-0001.html>

[PATCH 01/10] drm/radeon: UVD doesn't needs VM on SI

[Christian König]

Am 03.04.2013 16:42, schrieb Jerome Glisse:
> On Wed, Apr 03, 2013 at 01:18:30AM +0200, Christian K?nig wrote:
>> Signed-off-by: Christian K?nig 
>> ---
>>   drivers/gpu/drm/radeon/radeon_cs.c |   10 +-
>>   1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
>> b/drivers/gpu/drm/radeon/radeon_cs.c
>> index 70d3824..7d66e01 100644
>> --- a/drivers/gpu/drm/radeon/radeon_cs.c
>> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
>> @@ -241,15 +241,15 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, 
>> void *data)
>>  return -EINVAL;
>>  }
>>   
>> +if (radeon_cs_get_ring(p, ring, priority))
>> +return -EINVAL;
>> +
>>  /* we only support VM on SI+ */
>> -if ((p->rdev->family >= CHIP_TAHITI) &&
>> -((p->cs_flags & RADEON_CS_USE_VM) == 0)) {
>> +if ((p->rdev->asic->ring[p->ring].cs_parse == NULL) &&
>> +   ((p->cs_flags & RADEON_CS_USE_VM) == 0)) {
>>  DRM_ERROR("VM required on SI+!\n");
>>  return -EINVAL;
> What about updating the error message to something more appropriate like
> ring %d require virtual memory

Good point, going to change it.

Christian.

> Cheers,
> Jerome
>
>>  }
>> -
>> -if (radeon_cs_get_ring(p, ring, priority))
>> -return -EINVAL;
>>  }
>>   
>>  /* deal with non-vm */
>> -- 
>> 1.7.9.5
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: Add no-lvds quirk for Fujitsu Esprimo Q900

[Daniel Vetter]

On Wed, Apr 03, 2013 at 02:34:11PM +0200, Christian Lamparter wrote:
> The "Mobile Sandy Bridge CPUs" in the Fujitsu Esprimo Q900
> mini desktop PCs are probably misleading the LVDS detection
> code in intel_lvds_supported. Nothing is connected to the
> LVDS ports in these systems.
> 
> Signed-off-by: Christian Lamparter 

So despite that snb has a bit who's _only_ purpose is to allow the bios to
tell the driver whether there's an lvds output or not, someone screwed it
finally up :( We just can't win against the firmware ...

Queued for -next with cc: stable, thanks for the patch.
-Daniel
> ---
>  drivers/gpu/drm/i915/intel_lvds.c |8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
> b/drivers/gpu/drm/i915/intel_lvds.c
> index 3d1d974..65893b0 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -850,6 +850,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
>   DMI_MATCH(DMI_PRODUCT_NAME, "X7SPA-H"),
>   },
>   },
> + {
> + .callback = intel_no_lvds_dmi_callback,
> + .ident = "Fujitsu Esprimo Q900",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "ESPRIMO Q900"),
> + },
> + },
>  
>   { } /* terminating entry */
>  };
> -- 
> 1.7.10.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/radeon: add si tile mode array query

[j.gli...@gmail.com]

From: Jerome Glisse 

Allow userspace to query for the tile mode array so userspace can properly
compute surface pitch and alignment requirement depending on tiling.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/radeon.h |   1 +
 drivers/gpu/drm/radeon/radeon_drv.c |   3 +-
 drivers/gpu/drm/radeon/radeon_kms.c | 158 +++-
 drivers/gpu/drm/radeon/si.c |   2 +
 include/uapi/drm/radeon_drm.h   |  20 +
 5 files changed, 109 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 8263af3..961659e 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1443,6 +1443,7 @@ struct si_asic {
unsigned multi_gpu_tile_size;

unsigned tile_config;
+   uint32_t tile_mode_array[32];
 };

 union radeon_asic_config {
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 66a7f0f..1e48ab6 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -71,9 +71,10 @@
  *   2.28.0 - r600-eg: Add MEM_WRITE packet support
  *   2.29.0 - R500 FP16 color clear registers
  *   2.30.0 - fix for FMASK texturing
+ *   2.31.0 - Add SI tiling mode array query
  */
 #define KMS_DRIVER_MAJOR   2
-#define KMS_DRIVER_MINOR   30
+#define KMS_DRIVER_MINOR   31
 #define KMS_DRIVER_PATCHLEVEL  0
 int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
 int radeon_driver_unload_kms(struct drm_device *dev);
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index c75cb2c..8076434 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -176,80 +176,65 @@ int radeon_info_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
struct radeon_device *rdev = dev->dev_private;
struct drm_radeon_info *info = data;
struct radeon_mode_info *minfo = >mode_info;
-   uint32_t value, *value_ptr;
-   uint64_t value64, *value_ptr64;
+   uint32_t *value, value_tmp, *value_ptr, value_size;
+   uint64_t value64;
struct drm_crtc *crtc;
int i, found;

-   /* TIMESTAMP is a 64-bit value, needs special handling. */
-   if (info->request == RADEON_INFO_TIMESTAMP) {
-   if (rdev->family >= CHIP_R600) {
-   value_ptr64 = (uint64_t*)((unsigned long)info->value);
-   value64 = radeon_get_gpu_clock_counter(rdev);
-
-   if (DRM_COPY_TO_USER(value_ptr64, , 
sizeof(value64))) {
-   DRM_ERROR("copy_to_user %s:%u\n", __func__, 
__LINE__);
-   return -EFAULT;
-   }
-   return 0;
-   } else {
-   DRM_DEBUG_KMS("timestamp is r6xx+ only!\n");
-   return -EINVAL;
-   }
-   }
-
value_ptr = (uint32_t *)((unsigned long)info->value);
-   if (DRM_COPY_FROM_USER(, value_ptr, sizeof(value))) {
-   DRM_ERROR("copy_from_user %s:%u\n", __func__, __LINE__);
-   return -EFAULT;
-   }
+   value = _tmp;
+   value_size = sizeof(uint32_t);

switch (info->request) {
case RADEON_INFO_DEVICE_ID:
-   value = dev->pci_device;
+   *value = dev->pci_device;
break;
case RADEON_INFO_NUM_GB_PIPES:
-   value = rdev->num_gb_pipes;
+   *value = rdev->num_gb_pipes;
break;
case RADEON_INFO_NUM_Z_PIPES:
-   value = rdev->num_z_pipes;
+   *value = rdev->num_z_pipes;
break;
case RADEON_INFO_ACCEL_WORKING:
/* xf86-video-ati 6.13.0 relies on this being false for 
evergreen */
if ((rdev->family >= CHIP_CEDAR) && (rdev->family <= 
CHIP_HEMLOCK))
-   value = false;
+   *value = false;
else
-   value = rdev->accel_working;
+   *value = rdev->accel_working;
break;
case RADEON_INFO_CRTC_FROM_ID:
+   if (DRM_COPY_FROM_USER(value, value_ptr, sizeof(uint32_t))) {
+   DRM_ERROR("copy_from_user %s:%u\n", __func__, __LINE__);
+   return -EFAULT;
+   }
for (i = 0, found = 0; i < rdev->num_crtc; i++) {
crtc = (struct drm_crtc *)minfo->crtcs[i];
-   if (crtc && crtc->base.id == value) {
+   if (crtc && crtc->base.id == *value) {
struct radeon_crtc *radeon_crtc = 
to_radeon_crtc(crtc);
-   value = radeon_crtc->crtc_id;
+   *value = radeon_crtc->crtc_id;

[PATCH] radeon: add si tiling support

[j.gli...@gmail.com]

From: Jerome Glisse 

Signed-off-by: Jerome Glisse 
---
 include/drm/radeon_drm.h |  61 +
 radeon/radeon_surface.c  | 663 +++
 radeon/radeon_surface.h  |  30 +++
 3 files changed, 709 insertions(+), 45 deletions(-)

diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 00d66b3..ff3ce3a 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -509,6 +509,7 @@ typedef struct {
 #define DRM_RADEON_GEM_SET_TILING  0x28
 #define DRM_RADEON_GEM_GET_TILING  0x29
 #define DRM_RADEON_GEM_BUSY0x2a
+#define DRM_RADEON_GEM_VA  0x2b

 #define DRM_IOCTL_RADEON_CP_INITDRM_IOW( DRM_COMMAND_BASE + 
DRM_RADEON_CP_INIT, drm_radeon_init_t)
 #define DRM_IOCTL_RADEON_CP_START   DRM_IO(  DRM_COMMAND_BASE + 
DRM_RADEON_CP_START)
@@ -550,6 +551,7 @@ typedef struct {
 #define DRM_IOCTL_RADEON_SET_TILINGDRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_SET_TILING, struct drm_radeon_gem_set_tiling)
 #define DRM_IOCTL_RADEON_GET_TILINGDRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_GET_TILING, struct drm_radeon_gem_get_tiling)
 #define DRM_IOCTL_RADEON_GEM_BUSY  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_BUSY, struct drm_radeon_gem_busy)
+#define DRM_IOCTL_RADEON_GEM_VADRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_VA, struct drm_radeon_gem_va)

 typedef struct drm_radeon_init {
enum {
@@ -882,6 +884,27 @@ struct drm_radeon_gem_pwrite {
uint64_t data_ptr;
 };

+#define RADEON_VA_MAP  1
+#define RADEON_VA_UNMAP2
+
+#define RADEON_VA_RESULT_OK0
+#define RADEON_VA_RESULT_ERROR 1
+#define RADEON_VA_RESULT_VA_EXIST  2
+
+#define RADEON_VM_PAGE_VALID   (1 << 0)
+#define RADEON_VM_PAGE_READABLE(1 << 1)
+#define RADEON_VM_PAGE_WRITEABLE   (1 << 2)
+#define RADEON_VM_PAGE_SYSTEM  (1 << 3)
+#define RADEON_VM_PAGE_SNOOPED (1 << 4)
+
+struct drm_radeon_gem_va {
+   uint32_thandle;
+   uint32_toperation;
+   uint32_tvm_id;
+   uint32_tflags;
+   uint64_toffset;
+};
+
 #define RADEON_CHUNK_ID_RELOCS 0x01
 #define RADEON_CHUNK_ID_IB 0x02

@@ -916,6 +939,26 @@ struct drm_radeon_cs {
 #define RADEON_INFO_ACCEL_WORKING2 0x05
 #define RADEON_INFO_TILING_CONFIG  0x06
 #define RADEON_INFO_WANT_HYPERZ0x07
+#define RADEON_INFO_WANT_CMASK 0x08 /* get access to CMASK on r300 */
+#define RADEON_INFO_CLOCK_CRYSTAL_FREQ 0x09 /* clock crystal frequency */
+#define RADEON_INFO_NUM_BACKENDS   0x0a /* DB/backends for r600+ - need 
for OQ */
+#define RADEON_INFO_NUM_TILE_PIPES 0x0b /* tile pipes for r600+ */
+#define RADEON_INFO_FUSION_GART_WORKING0x0c /* fusion writes to GTT 
were broken before this */
+#define RADEON_INFO_BACKEND_MAP0x0d /* pipe to backend map, 
needed by mesa */
+/* virtual address start, va < start are reserved by the kernel */
+#define RADEON_INFO_VA_START   0x0e
+/* maximum size of ib using the virtual memory cs */
+#define RADEON_INFO_IB_VM_MAX_SIZE 0x0f
+/* max pipes - needed for compute shaders */
+#define RADEON_INFO_MAX_PIPES  0x10
+/* timestamp for GL_ARB_timer_query (OpenGL), returns the current GPU clock */
+#define RADEON_INFO_TIMESTAMP  0x11
+/* max shader engines (SE) - needed for geometry shaders, etc. */
+#define RADEON_INFO_MAX_SE 0x12
+/* max SH per SE */
+#define RADEON_INFO_MAX_SH_PER_SE  0x13
+/* SI tile mode array */
+#define RADEON_INFO_SI_TILE_MODE_ARRAY 0x14

 struct drm_radeon_info {
uint32_trequest;
@@ -923,4 +966,22 @@ struct drm_radeon_info {
uint64_tvalue;
 };

+/* Those correspond to the tile index to use, this is to explicitly state
+ * the API that is implicitly defined by the tile mode array.
+ */
+#define SI_TILE_MODE_COLOR_LINEAR_ALIGNED  8
+#define SI_TILE_MODE_COLOR_1D  13
+#define SI_TILE_MODE_COLOR_1D_SCANOUT  9
+#define SI_TILE_MODE_COLOR_2D_8BPP 14
+#define SI_TILE_MODE_COLOR_2D_16BPP15
+#define SI_TILE_MODE_COLOR_2D_32BPP16
+#define SI_TILE_MODE_COLOR_2D_64BPP17
+#define SI_TILE_MODE_COLOR_2D_SCANOUT_16BPP11
+#define SI_TILE_MODE_COLOR_2D_SCANOUT_32BPP12
+#define SI_TILE_MODE_DEPTH_STENCIL_1D  4
+#define SI_TILE_MODE_DEPTH_STENCIL_2D  0
+#define SI_TILE_MODE_DEPTH_STENCIL_2D_2AA  3
+#define SI_TILE_MODE_DEPTH_STENCIL_2D_4AA  3
+#define SI_TILE_MODE_DEPTH_STENCIL_2D_8AA  2
+
 #endif
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 5935c23..dfdcbbc 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -83,12 +83,15 @@ typedef int (*hw_best_surface_t)(struct 
radeon_surface_manager *surf_man,

 struct radeon_hw_info {
 /* apply to 

gma500: Other things that I could work on

[Kero]

Hi,

I would not mind improving use of my Asus EeePC X101CH with Cedar View / gma3600
a bit more. But a barrier is knowledge of the hardware. Meddling with existing 
(initialization)
code is possible, but for point 1 and 3 below that is not going to cut, it, I 
expect.

Does anyone have pointers? Who should I talk to about specifications?
I know Intel is not forthcoming with documentation, yet several people have
made contributions for poulsbo and later versions of the hardware.
How did you get the required knowledge?

Things I might, in order of personal preference, in due time (after holiday), 
take a look at:
1) would be nice to have the full 1024x600 on the external VGA and HDMI
   I had a chance to try another monitor over HDMI, same result: only 800x600 
visible.
2) booting with either VGA or HDMI plugged in, yields two black screens: both 
the laptop
   and the monitor. Un- + re-plugging has no visible effect.
3) the Fn keys for the backlight induce a response in the backlight, but only 
with
   tiny results; /sys/class/backlight/psb-bl/brightness works fine, though
4) when using modules, initialization from hibernation is not good enough:
   my screen stays black; without using modules, the kernel boots normally, and 
everything is fine.
5) initialization from suspend is not good enough: my Asus stays in
   some text mode (80x25?), but shows garbage (possibly data from the desired 
console or
   graphics mode, since sometimes there are reactions correlated to actions)
   Switching tty or using `chvt` do not improve anything.
   NB: hibernating and booting solves this.

> Your patch has been applied to:
> https://github.com/patjak/drm-gma500.git gma500-next

Thanks!

> We might also consider polling if this causes problems for people, but for now
> this is fine.

Agreed;
The Display Port was already hotpluggable; the Asus has no such connector,
but is not bothered by polling (status is and remains 'disconnected').
That makes me hopeful that hardware without VGA or HDMI connectors will not be
negatively affected. But given the 5 points above, there's no guarantee.

> No biggie, but your tabs where converted to spaces so I recommend
> running checkpatch.pl before submitting.

woops, my mistake. will run checkpatch.pl next time.

Bye,
Kero.

-- 
Are you master of your time here?
Are you master of your own fate?
   -- Deep Inside -- Exile -- To-Mera

[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

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

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

--- Comment #8 from Alexandre Demers  ---
(In reply to comment #7)
> (In reply to comment #6)
> > > DISPLAY=:0 python2 piglit-run.py ...
> > 
> > I meant that some tests are skipped when run remotely, but tested when run
> > locally. ;)
> 
> Something would be wrong then. If you're doing it right, piglit is running
> just as locally, only its terminal output is visible elsewhere.

Noted. I'll look at it when I'll get home tonight.

-- 
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/20130403/5de9897e/attachment.html>

UVD fails to init on rv790

[Alex Deucher]

On Wed, Apr 3, 2013 at 4:45 PM, Dieter N?tzel  wrote:
> Am 2013-04-03 15:21, schrieb Alex Deucher:
>
>> On Wed, Apr 3, 2013 at 7:29 AM, Christian K?nig 
>> wrote:
>>>
>>> Hi Andy,
>>>
>>> crap! I feared that something like this would happen. IIRC we never
>>> tested
>>> UVD on an rv790, and this hardware isn't easy to get any more.
>>>
>>> RV770/RV790 have a separate UVD hardware generation (that's why they have
>>> their own firmware) and there possible is some bug or something like this
>>> that we haven't implemented. You couldn't give me SSH access to that
>>> system?
>>
>>
>> I tested on an RV770 earlier in development and it was working ok at
>> the time I think.  I'll give it another try today.
>>
>> Alex
>
>
>
> Hello Alex,
>
> time goes by so fast --- wife, home, 2 children...
>
> but what do I need:
> I'll test it on my 2 HD4650/RV730 AGP (!) low speed Duron and dual Athlon
> MP.
>
> git:// drm-fixes kernel
> git:// mesa
> patches
>
> R700_rlc.bin
> RV710_uvd.bin
>
> BTW Any hints for libvdpau_r600.so.1.0.0?
> I get wrong colors (red is like blue, blue is like yellow, etc.)
>

What are you testing with?  The adobe flash vdpau implementation
reverses the channels.  IIRC, newer versions of libvdpau have a
workaround for it.  I've generally been testing with mplayer.  mplayer
-vo vdpau -vc ffh264vdpau 

Alex

[Bug 62756] Rendering errors on rv790 with llvm and unigine heaven 3.0

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

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

--- Comment #7 from vincent  ---
(In reply to comment #6)
> (In reply to comment #5)
> > No, I don't receive mail from bugzilla until someone add me manually to the
> > cc list (dont know what to do to fix that though)
> 
> drivers/gallium/r600 bugs get sent to the dri-devel list.

Ok, I always looked on mesa-dev for bugs, thank for pointing me this.

Does the "big" regression still occur with at least revision r178667 for llvm
and commit
http://cgit.freedesktop.org/mesa/mesa/commit/?id=159d9340662a70df3dcc9da1681f5b0a8e7650cf
for mesa ?

-- 
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/20130403/2895c24e/attachment.html>

[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor

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

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

--- Comment #13 from Michel D?nzer  ---
(In reply to comment #12)
> [309092.861665] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

This means some rendering was dropped on the floor because the kernel ran out
of memory. Not sure that can explain it though, unless this keeps repeating it
should continue rendering again.

-- 
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/20130403/049e4d34/attachment.html>

[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

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

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

--- Comment #7 from Michel D?nzer  ---
(In reply to comment #6)
> > DISPLAY=:0 python2 piglit-run.py ...
> 
> I meant that some tests are skipped when run remotely, but tested when run
> locally. ;)

Something would be wrong then. If you're doing it right, piglit is running just
as locally, only its terminal output is visible elsewhere.

-- 
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/20130403/49aebaf4/attachment.html>

[PATCH] drivers/gpu/drm/nouveau: remove erroneous semicolon

[Chen Gang]

Hello maintainers:

  when you have time, please help to check this patch whether is OK.

  thanks.

gchen.


On 2013?03?27? 15:23, Chen Gang wrote:
> 
>   need remove semicolon, or always return true.
> 
> Signed-off-by: Chen Gang 
> ---
>  drivers/gpu/drm/nouveau/nv50_display.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
> b/drivers/gpu/drm/nouveau/nv50_display.c
> index 7f0e6c3..1ddc03e 100644
> --- a/drivers/gpu/drm/nouveau/nv50_display.c
> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
> @@ -479,7 +479,7 @@ nv50_display_flip_wait(void *data)
>  {
>   struct nv50_display_flip *flip = data;
>   if (nouveau_bo_rd32(flip->disp->sync, flip->chan->addr / 4) ==
> -   flip->chan->data);
> +   flip->chan->data)
>   return true;
>   usleep_range(1, 2);
>   return false;
> 


-- 
Chen Gang

Asianux Corporation

[v3.8 Regression] Merge tag 'v3.7-rc2' into drm-intel-next-queued

[Joseph Salisbury]

On 04/03/2013 03:16 PM, Daniel Vetter wrote:
> On Wed, Apr 3, 2013 at 9:08 PM, Joseph Salisbury 
>  > wrote:
>
> Hi Daniel,
>
> A bug was opened against the Ubuntu kernel[0].  After a kernel
> bisect, it was found the following was the first bad commit:
>
>
> commit c2fb7916927e989ea424e61ce5fe617e54878827
> Merge: 29de6ce 6f0c058
> Author: Daniel Vetter  >
> Date:   Mon Oct 22 14:34:51 2012 +0200
>
> Merge tag 'v3.7-rc2' into drm-intel-next-queued
>
>
>
> The regression was introduced as of v3.8-rc1.  However, further
> testing also shows this bug is now fixed in v3.9-rc4.
>
> I see that you are the author of this patch, so I wanted see if I
> can get your feedback.  Do you happen to have an idea what may
> have fixed this in v3.9-rc4, so we can send a request to stable,
> if not already done?  Otherwise, I can perform a reverse bisect to
> see which commit fixed this.
>
>
> So apparently it's an oops somewhere in the nouveau setup code, which 
> bisected to a backmerge which has _only_ conflicts in drm/i915 driver 
> code.
>
> I have no idea what blew up here, sorry.
> -Daniel

Thanks for the info, Daniel.  I'll go the reverse bisect route.

>
>
>
>
> Thanks,
>
> Joe
>
> [0] http://pad.lv/1109309
>
>
>
>
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 59521] [Serious Sam 3] Missing textures with R600g

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

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

--- Comment #9 from John Bridgman  ---
Sorry, hit "save" too soon. Your post on the steam forum suggested that there
might be a crash related to use of precompiled shader binaries so I'm wondering
if your comment here refers to fixing a crash or fixing the textures. 

Thanks...

-- 
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/20130403/3f906e03/attachment.html>

[Bug 59521] [Serious Sam 3] Missing textures with R600g

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

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

--- Comment #8 from John Bridgman  ---
(In reply to comment #7)
> using MESA_EXTENSION_OVERRIDE="-GL_ARB_get_program_binary" make it works
> properly

Just checking, do you mean "using  eliminates the missing textures ?

-- 
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/20130403/73197e8a/attachment.html>

[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor

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

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

--- Comment #12 from Alexander von Gluck  ---
The only dmesg errors are these:

[309092.861665] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
[309099.062192] radeon :01:00.0: bo 8803fc4cb400 don't has a mapping in
vm 8803f406b580
[309099.063303] radeon :01:00.0: bo 8803fc4cf400 don't has a mapping in
vm 8803f406b580
[309099.064403] radeon :01:00.0: bo 8803fc4c9800 don't has a mapping in
vm 8803f406b580
[309099.065457] radeon :01:00.0: bo 8803fc4cc800 don't has a mapping in
vm 8803f406b580
[309099.066560] radeon :01:00.0: bo 8803fc4cb800 don't has a mapping in
vm 8803f406b580
[309099.067664] radeon :01:00.0: bo 8803fc4c9c00 don't has a mapping in
vm 8803f406b580


agd5f mentioned that those are normal though. (well, not *normal* but can be
ignored)

-- 
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/20130403/339e1a93/attachment.html>

[v3.8 Regression] Merge tag 'v3.7-rc2' into drm-intel-next-queued

[Joseph Salisbury]

Hi Daniel,

A bug was opened against the Ubuntu kernel[0].  After a kernel bisect, 
it was found the following was the first bad commit:


commit c2fb7916927e989ea424e61ce5fe617e54878827
Merge: 29de6ce 6f0c058
Author: Daniel Vetter 
Date:   Mon Oct 22 14:34:51 2012 +0200

 Merge tag 'v3.7-rc2' into drm-intel-next-queued



The regression was introduced as of v3.8-rc1.  However, further testing 
also shows this bug is now fixed in v3.9-rc4.

I see that you are the author of this patch, so I wanted see if I can 
get your feedback.  Do you happen to have an idea what may have fixed 
this in v3.9-rc4, so we can send a request to stable, if not already 
done?  Otherwise, I can perform a reverse bisect to see which commit 
fixed this.


Thanks,

Joe

[0] http://pad.lv/1109309

UVD fails to init on rv790

[Andy Furniss]

Christian K?nig wrote:
> Hi Andy,
>
> crap! I feared that something like this would happen. IIRC we never
> tested UVD on an rv790, and this hardware isn't easy to get any more.
>
> RV770/RV790 have a separate UVD hardware generation (that's why they
> have their own firmware) and there possible is some bug or something
> like this that we haven't implemented. You couldn't give me SSH access
> to that system?

I can if you still need it this evening.

My stupid ISP has taken to blocking lots of things for their home users 
like git:// svn and nntp and I suspect it maybe the same for ssh.

The blocks are lifted at 20:00 local time (19:00 UTC) so I can mail you 
off list around then.

In the meantime I'll remember how to use iptables :-) and also repeat 
UVD patching/testing on a different boot in case I messed up.

[PATCH] drm/i915: Add no-lvds quirk for Fujitsu Esprimo Q900

[Christian Lamparter]

The "Mobile Sandy Bridge CPUs" in the Fujitsu Esprimo Q900
mini desktop PCs are probably misleading the LVDS detection
code in intel_lvds_supported. Nothing is connected to the
LVDS ports in these systems.

Signed-off-by: Christian Lamparter 
---
 drivers/gpu/drm/i915/intel_lvds.c |8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 3d1d974..65893b0 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -850,6 +850,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "X7SPA-H"),
},
},
+   {
+   .callback = intel_no_lvds_dmi_callback,
+   .ident = "Fujitsu Esprimo Q900",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "ESPRIMO Q900"),
+   },
+   },

{ } /* terminating entry */
 };
-- 
1.7.10.4

linux-next: manual merge of the drm-intel tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_panel.c between commit b1289371fcd5 ("Revert
"drm/i915: write backlight harder"") from Linus' tree and commit
31ad8ec6a614 ("drm/i915: group backlight related stuff into a struct")
from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au

diff --cc drivers/gpu/drm/i915/intel_panel.c
index bee8cb6,0e7e873..000
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@@ -318,9 -321,16 +321,13 @@@ void intel_panel_enable_backlight(struc
  {
struct drm_i915_private *dev_priv = dev->dev_private;

-   if (dev_priv->backlight_level == 0)
-   dev_priv->backlight_level = intel_panel_get_max_backlight(dev);
+   if (dev_priv->backlight.level == 0) {
+   dev_priv->backlight.level = intel_panel_get_max_backlight(dev);
+   if (dev_priv->backlight.device)
+   dev_priv->backlight.device->props.brightness =
+   dev_priv->backlight.level;
+   }

 -  dev_priv->backlight.enabled = true;
 -  intel_panel_actually_set_backlight(dev, dev_priv->backlight.level);
 -
if (INTEL_INFO(dev)->gen >= 4) {
uint32_t reg, tmp;

@@@ -356,12 -366,12 +363,12 @@@
}

  set_level:
 -  /* Check the current backlight level and try to set again if it's zero.
 -   * On some machines, BLC_PWM_CPU_CTL is cleared to zero automatically
 -   * when BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1 are written.
 +  /* Call below after setting BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1.
 +   * BLC_PWM_CPU_CTL may be cleared to zero automatically when these
 +   * registers are set.
 */
-   dev_priv->backlight_enabled = true;
-   intel_panel_actually_set_backlight(dev, dev_priv->backlight_level);
 -  if (!intel_panel_get_backlight(dev))
 -  intel_panel_actually_set_backlight(dev, 
dev_priv->backlight.level);
++  dev_priv->backlight.enabled = true;
++  intel_panel_actually_set_backlight(dev, dev_priv->backlight.level);
  }

  static void intel_panel_init_backlight(struct drm_device *dev)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130403/06356eba/attachment.pgp>

[Bug 43655] Latest radeon dri driver on HD6950 with GRUB set "GRUB_GFXPAYLOAD_LINUX=keep" put the display in a flickering state

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

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

Alexandre Demers  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=57567

-- 
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/20130403/3a7141cc/attachment.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

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

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

Alexandre Demers  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=43655

-- 
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/20130403/6cdefc47/attachment.html>

[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

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

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

--- Comment #6 from Alexandre Demers  ---
(In reply to comment #5)
> It's perfectly normal that some tests are skipped, but you obviously do need
> to set the DISPLAY environment variable appropriately for the piglit run.
> Something like
> 
> DISPLAY=:0 python2 piglit-run.py ...

I meant that some tests are skipped when run remotely, but tested when run
locally. ;) I'll try your suggestion.

-- 
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/20130403/f5247501/attachment.html>

[patch] drm/nouveau: off by one in nouveau_drm_vblank_enable()

[Maarten Lankhorst]

Op 03-04-13 10:05, Dan Carpenter schreef:
> The test here should be ">= ARRAY_SIZE()" instead of "> ARRAY_SIZE()".
>
> Signed-off-by: Dan Carpenter 
Acked-by: Maarten Lankhorst 
> ---
> This was introduced in git://git.freedesktop.org/git/nouveau/linux-2.6 
> drm-nouveau-fixes-3.9
> It hadn't hit linux-next yet yesterday.
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index c95decf..e11f8e4 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -86,7 +86,7 @@ nouveau_drm_vblank_enable(struct drm_device *dev, int head)
>   struct nouveau_drm *drm = nouveau_drm(dev);
>   struct nouveau_disp *pdisp = nouveau_disp(drm->device);
>  
> - if (WARN_ON_ONCE(head > ARRAY_SIZE(drm->vblank)))
> + if (WARN_ON_ONCE(head >= ARRAY_SIZE(drm->vblank)))
>   return -EIO;
>   WARN_ON_ONCE(drm->vblank[head].func);
>   drm->vblank[head].func = nouveau_drm_vblank_handler;
>

UVD fails to init on rv790

[Christian König]

Hi Andy,

crap! I feared that something like this would happen. IIRC we never 
tested UVD on an rv790, and this hardware isn't easy to get any more.

RV770/RV790 have a separate UVD hardware generation (that's why they 
have their own firmware) and there possible is some bug or something 
like this that we haven't implemented. You couldn't give me SSH access 
to that system?

Christian.

Am 03.04.2013 11:51, schrieb Andy Furniss:
> Thanks AMD for getting this out :-)
>
> I have an issue, though.
>
> On HD4890 drm-fixes kernel (before yesterdays updates) got the new
>
> R700_rlc.bin
> RV770_uvd.bin
>
> but on boot I get -
>
> [drm] radeon kernel modesetting enabled.
> [drm] initializing kernel modesetting (RV770 0x1002:0x9460 
> 0x1682:0x2700).
> [drm] register mmio base: 0xFE6F
> [drm] register mmio size: 65536
> ATOM BIOS: Wekiva
> radeon :01:00.0: VRAM: 1024M 0x - 
> 0x3FFF (1024M used)
> radeon :01:00.0: GTT: 512M 0x4000 - 0x5FFF
> [drm] Detected VRAM RAM=1024M, BAR=256M
> [drm] RAM width 256bits DDR
> [TTM] Zone  kernel: Available graphics memory: 436936 kiB
> [TTM] Zone highmem: Available graphics memory: 1685484 kiB
> [TTM] Initializing pool allocator
> [drm] radeon: 1024M of VRAM memory ready
> [drm] radeon: 512M of GTT memory ready.
> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [drm] Driver supports precise vblank timestamp query.
> radeon :01:00.0: irq 51 for MSI/MSI-X
> radeon :01:00.0: radeon: using MSI.
> [drm] radeon: irq initialized.
> [drm] GART: num cpu pages 131072, num gpu pages 131072
> [drm] probing gen 2 caps for device 1022:9603 = 300d02/0
> [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
> [drm] Loading RV770 Microcode
> [drm] PCIE GART of 512M enabled (table at 0x00257000).
> radeon :01:00.0: WB enabled
> radeon :01:00.0: fence driver on ring 0 use gpu addr 
> 0x4c00 and cpu addr 0xff893c00
> radeon :01:00.0: fence driver on ring 3 use gpu addr 
> 0x4c0c and cpu addr 0xff893c0c
> radeon :01:00.0: fence driver on ring 5 use gpu addr 
> 0x0005632c and cpu addr 0xfbb9632c
> [drm] ring test on 0 succeeded in 1 usecs
> [drm] ring test on 3 succeeded in 1 usecs
> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the 
> VCPU!!!
> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the 
> VCPU!!!
> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the 
> VCPU!!!
> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the 
> VCPU!!!
> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the 
> VCPU!!!
> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the 
> VCPU!!!
> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the 
> VCPU!!!
> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the 
> VCPU!!!
> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the 
> VCPU!!!
> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the 
> VCPU!!!
> [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!!
> [drm:rv770_startup] *ERROR* radeon: failed initializing UVD (-1).
> [drm] Enabling audio support
> [drm] ib test on ring 0 succeeded in 0 usecs
> [drm] ib test on ring 3 succeeded in 0 usecs
> ALSA sound/pci/hda/hda_eld.c:334 HDMI: ELD buf size is 0, force 128
> ALSA sound/pci/hda/hda_eld.c:351 HDMI: invalid ELD data byte 0
> [drm] Radeon Display Connectors
> [drm] Connector 0:
> [drm]   DVI-I-1
> [drm]   HPD2
> [drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
> [drm]   Encoders:
> [drm] DFP1: INTERNAL_UNIPHY
> [drm] CRT2: INTERNAL_KLDSCP_DAC2
> [drm] Connector 1:
> [drm]   DIN-1
> [drm]   Encoders:
> [drm] TV1: INTERNAL_KLDSCP_DAC2
> [drm] Connector 2:
> [drm]   DVI-I-2
> [drm]   HPD1
> [drm]   DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c
> [drm]   Encoders:
> [drm] CRT1: INTERNAL_KLDSCP_DAC1
> [drm] DFP2: INTERNAL_KLDSCP_LVTMA
> [drm] Internal thermal controller with fan control
> [drm] radeon: power management initialized
> [drm] fb mappable at 0xD0359000
> [drm] vram apper at 0xD000
> [drm] size 8294400
> [drm] fb depth is 24
> [drm]pitch is 7680
> fbcon: radeondrmfb (fb0) is primary device
> Console: switching to colour frame buffer device 240x67
> radeon :01:00.0: fb0: radeondrmfb frame buffer device
> radeon :01:00.0: registered panic notifier
> [drm] Initialized radeon 2.30.0 20080528 for :01:00.0 on minor 0
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

UVD fails to init on rv790

[K. Schnass]

> Thanks AMD for getting this out :-)
+1

> I have an issue, though.
;( +1

Exactly the same problem but on a RV770! Noticed that the RV710_uvd.bin is 
some 20kb bigger than the RV770 one so maybe that is the problem?

lspci -nnv:
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI 
RV770 [Radeon HD 4850] [1002:9442] (prog-if 00 [VGA controller])
Subsystem: PC Partner Limited Device [174b:e104]
Flags: bus master, fast devsel, latency 0, IRQ 43
Memory at d000 (64-bit, prefetchable) [size=256M]
Memory at feaf (64-bit, non-prefetchable) [size=64K]
I/O ports at d000 [size=256]
Expansion ROM at feac [disabled] [size=128K]
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 

Kernel driver in use: radeon

[Bug 57567] 3.7 radeonfb broken on efivga screens

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

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

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

Does this kernel patch (against 3.9) 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/20130403/b461a491/attachment.html>

[PATCH 02/10] drm/radeon: UVD bringup v7

[Jerome Glisse]

On Wed, Apr 03, 2013 at 05:53:55PM +0200, Christian K?nig wrote:
> Am 03.04.2013 16:53, schrieb Jerome Glisse:
> >On Wed, Apr 03, 2013 at 01:18:31AM +0200, Christian K?nig wrote:
> >>[SNIP]
> >>
> >>  /* hardcode those limit for now */
> >>  #define RADEON_VA_IB_OFFSET   (1 << 20)
> >>  #define RADEON_VA_RESERVED_SIZE   (8 << 20)
> >>@@ -357,8 +360,9 @@ struct radeon_bo_list {
> >>struct ttm_validate_buffer tv;
> >>struct radeon_bo*bo;
> >>uint64_tgpu_offset;
> >>-   unsignedrdomain;
> >>-   unsignedwdomain;
> >>+   boolwritten;
> >>+   unsigneddomain;
> >>+   unsignedalt_domain;
> >>u32 tiling_flags;
> >>  };
> >I think that the change to the rdomain/wdomain should be in a patch
> >of its own. I think the change is fine but we had issue with change
> >that touched that part previously, would make bisecting and
> >understanding the change implication easier.
> 
> Agree, I actually planed to do so, but for the whole IP review stuff
> we needed to maintain a more or less stable patch base. Long story,
> but I'm going to change it.
> 
> >>@@ -826,7 +830,6 @@ struct radeon_cs_reloc {
> >>struct radeon_bo*robj;
> >>struct radeon_bo_list   lobj;
> >>uint32_thandle;
> >>-   uint32_tflags;
> >>  };
> >Why removing the flags ? iirc it's not really use right now but i
> >remember plan to use it.
> 
> Ups, just a rebasing artifact. But when it's unused we should remove
> it, probably just not in this patch.
> 
> >>[SNIP]
> >>
> >>+static int radeon_uvd_cs_reloc(struct radeon_cs_parser *p, int data0, int 
> >>data1)
> >>+{
> >>+   struct radeon_cs_chunk *relocs_chunk;
> >>+   struct radeon_cs_reloc *reloc;
> >>+   unsigned idx, cmd;
> >>+   uint64_t start, end;
> >>+
> >>+   relocs_chunk = >chunks[p->chunk_relocs_idx];
> >>+   idx = radeon_get_ib_value(p, data1);
> >>+   if (idx >= relocs_chunk->length_dw) {
> >>+   DRM_ERROR("Relocs at %d after relocations chunk end %d !\n",
> >>+ idx, relocs_chunk->length_dw);
> >>+   return -EINVAL;
> >>+   }
> >>+
> >>+   reloc = p->relocs_ptr[(idx / 4)];
> >>+   start = reloc->lobj.gpu_offset;
> >>+   end = start + radeon_bo_size(reloc->robj);
> >>+   start += radeon_get_ib_value(p, data0);
> >I am assuming there is no way for you to know the size that the uvd engine 
> >will write to ?
> >You are not checking anything on uvd possibly overwritting after the bo end.
> 
> Yeah that gave me headache for a quite long time, too. The problem
> is to figure out how much is actually written you need to keep track
> of the whole lot of informations including the UVD session,
> create/decode/destroy messages and allot of fiddling with the codec
> specific parameters.
> 
> And if I understand the UVD internals correctly even if we check
> everything there is no guarantee that a special crafted bitstream
> could not let UVD to write over the end of the buffer
> 
> Is it ok if we but a big TODO on it for the initial patch?
> 
> Cheers,
> Christian.

I think i only need one assurance and i think for uvd this will be the case.
If UVD block write past bo end can you be sure that no matter what it will
overwritte to address > start ie it could not overwritte to begining of VRAM.

I have big doubt on that given the 256M window, i fear that it might go back
to writting to begining of memory where the page table is.

Note that i think that now that we have cp dma pagetable entry update we can
probably just move the pagetable to end of vram on 90% GPU with UVD this will
be > 256M which seems like a zone where UVD can never write.

If we can have such assurance i guess we can make uvd as an option and make
a very explicit comment stating that UVD engine can be use as an exploit
vector path.

Cheers,
Jerome

[PATCH v4 04/21] modetest: Add a command line parameter to select the driver

[Ville Syrjälä]

On Tue, Mar 19, 2013 at 03:55:45PM +0100, Laurent Pinchart wrote:
> If the -M parameter is specified, modetest will use the requested device
> name instead of trying its builtin list of device names.
> 
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Jani Nikula 
> ---
>  tests/modetest/modetest.c | 41 -
>  1 file changed, 28 insertions(+), 13 deletions(-)
> 
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index 1d1f49d..91dabfc 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -908,6 +908,9 @@ static void usage(char *name)
>   fprintf(stderr, "\t-s [@]:[@]\tset 
> a mode\n");
>   fprintf(stderr, "\t-v\ttest vsynced page flipping\n");
>  
> + fprintf(stderr, "\n Generic options:\n\n");
> + fprintf(stderr, "\t-M module\tuse the given driver\n");

You didn't add it to the "usage: ..." line. Same goes for patch 05/21.

> +
>   fprintf(stderr, "\n\tDefault is to dump all info.\n");
>   exit(0);
>  }
> @@ -935,7 +938,7 @@ static int page_flipping_supported(void)
>  #endif
>  }
>  
> -static char optstr[] = "cefmP:ps:v";
> +static char optstr[] = "cefM:mP:ps:v";
>  
>  int main(int argc, char **argv)
>  {
> @@ -943,6 +946,7 @@ int main(int argc, char **argv)
>   int encoders = 0, connectors = 0, crtcs = 0, planes = 0, framebuffers = 
> 0;
>   int test_vsync = 0;
>   const char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", 
> "omapdrm", "exynos" };
> + char *module = NULL;
>   unsigned int i;
>   int count = 0, plane_count = 0;
>   struct connector con_args[2];
> @@ -960,6 +964,9 @@ int main(int argc, char **argv)
>   case 'f':
>   framebuffers = 1;
>   break;
> + case 'M':
> + module = optarg;
> + break;
>   case 'm':
>   modes = 1;
>   break;
> @@ -989,14 +996,27 @@ int main(int argc, char **argv)
>   if (argc == 1)
>   encoders = connectors = crtcs = planes = modes = framebuffers = 
> 1;
>  
> - for (i = 0; i < ARRAY_SIZE(modules); i++) {
> - printf("trying to load module %s...", modules[i]);
> - fd = drmOpen(modules[i], NULL);
> + if (module) {
> + fd = drmOpen(module, NULL);
>   if (fd < 0) {
> - printf("failed.\n");
> - } else {
> - printf("success.\n");
> - break;
> + fprintf(stderr, "failed to open device '%s'.\n", 
> module);
> + return 1;
> + }
> + } else {
> + for (i = 0; i < ARRAY_SIZE(modules); i++) {
> + printf("trying to open device '%s'...", modules[i]);
> + fd = drmOpen(modules[i], NULL);
> + if (fd < 0) {
> + printf("failed.\n");
> + } else {
> + printf("success.\n");
> + break;
> + }
> + }
> +
> + if (fd < 0) {
> + fprintf(stderr, "no device found.\n");
> + return 1;
>   }
>   }
>  
> @@ -1005,11 +1025,6 @@ int main(int argc, char **argv)
>   return -1;
>   }
>  
> - if (i == ARRAY_SIZE(modules)) {
> - fprintf(stderr, "failed to load any modules, aborting.\n");
> - return -1;
> - }
> -
>   resources = drmModeGetResources(fd);
>   if (!resources) {
>   fprintf(stderr, "drmModeGetResources failed: %s\n",
> -- 
> 1.8.1.5
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrj?l?
Intel OTC

radeonsi tiling dilema

[Jerome Glisse]

On Wed, Apr 03, 2013 at 06:11:26PM +0200, Michel D?nzer wrote:
> On Mit, 2013-04-03 at 09:57 -0400, Jerome Glisse wrote: 
> > On Wed, Apr 3, 2013 at 5:37 AM, Michel D?nzer 
> > wrote:
> > On Die, 2013-04-02 at 14:13 -0400, Jerome Glisse wrote:
> > >
> > > Some might argue that we could just export the table content
> > to
> > > userspace, but that would loose information and possibly
> > froze the
> > > tile mode table forever as API.
> 
> The current index scheme already is de facto part of the API.

Only index 4,8,9,13 are part of current API no of the other are use.

> 
> > The information we loose is what index
> > > match to prefered surface format/type combination.
> 
> How so? We can add descriptive names for the existing indices.

Look at my kernel patch, for instance i define :
RADEON_TILE_MODE_COLOR_2D_32BPP

You can then query the kernel with RADEON_TILE_MODE_COLOR_2D_32BPP which
gave you corresponding tile index and also correspond gb tile config.

http://people.freedesktop.org/~glisse/si2d-sol1/0001-drm-radeon-add-tile-mode-ioctl.patch

> 
> > And the tile mode
> > > might be considered API as if kernel ever change what
> > userspace expect
> > > then we might break some userspace.
> 
> Not sure how that could happen if the purpose of each index is clearly
> defined.

Well that's the question, are we happy, confident that we will never shuffle
around the tile mode array. If so then we need to hard code tile index with
a meaning and call it API. It's already the case for index 4,8,9,13

> 
> 
> > Maybe I'm missing the problem, but if libdrm_radeon were to
> > get the
> > tiling mode index chosen by radeonsi, and could retrieve the
> > tiling
> > parameters for each index from the kernel, it should be able
> > to
> > calculate things properly, shouldn't it?
> > 
> > 
> > 
> > Let's not discuss about who/where the index is pick. No matter where
> > it happens the question is do we want to hardcode tile index and make
> > it api or do we want to hide it behind symbolic name allowing change
> > in tile array (given that right now 4 value are already frozen). You
> > can look at my kernel patch to see what i mean.
> 
> The layer of indirection for the indices seems like overengineering at
> this point. Even if the fixed indices stop being good enough for some
> reason in the future, how can we be sure now the layer of indirection
> will be good enough? So I think we shouldn't worry about that until that
> day may come.
>

Well i am fine with that but i just want to make sure everybody understand
the implications.

Cheers,
Jerome

[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

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

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

--- Comment #5 from Michel D?nzer  ---
It's perfectly normal that some tests are skipped, but you obviously do need to
set the DISPLAY environment variable appropriately for the piglit run.
Something like

DISPLAY=:0 python2 piglit-run.py ...

-- 
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/20130403/4c9f5f7b/attachment.html>

[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

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

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

--- Comment #4 from Alexandre Demers  ---
(In reply to comment #3)
> If you run piglit with --no-concurrency from a remote shell, you should see
> in the terminal output which test is running when it hangs.

Many tests seems to skip when they are run remotely via an ssh session. Is this
expected or should I set a parameter about the display?

-- 
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/20130403/501295c1/attachment.html>

[PATCH RESEND] drm: fix drm_local_map allocation size

[Jani Nikula]

ping

On Tue, 12 Feb 2013, Jani Nikula  wrote:
> list->map is struct drm_local_map *, not struct drm_map_list *.
>
> Signed-off-by: Jani Nikula 
>
> ---
>
> Found this small snippet laying around, I guess it fell between the cracks.
> ---
>  drivers/gpu/drm/drm_gem.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 24efae4..6337edd 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -343,7 +343,7 @@ drm_gem_create_mmap_offset(struct drm_gem_object *obj)
>  
>   /* Set the object up for mmap'ing */
>   list = >map_list;
> - list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
> + list->map = kzalloc(sizeof(*list->map), GFP_KERNEL);
>   if (!list->map)
>   return -ENOMEM;
>  
> -- 
> 1.7.9.5

radeonsi tiling dilema

[Alex Deucher]

On Wed, Apr 3, 2013 at 11:48 AM, Christian K?nig
 wrote:
> Am 03.04.2013 15:57, schrieb Jerome Glisse:
>
> On Wed, Apr 3, 2013 at 5:37 AM, Michel D?nzer  wrote:
>
> On Die, 2013-04-02 at 14:13 -0400, Jerome Glisse wrote:
>
> So i am facing a dilema regarding tiling on radeonsi. Given that we
> now have a fixed table of tiling mode this put more pressure on the
> kernel userspace api. I see either 2 solutions.
>
>
> Enforce kernel to set at fixed index in the table best tiling mode for
> given gpu for given format, such as DEPTH32_2D_4AA at index 4, or
> COLOR_SCANOUT_2D at index 13 ... that way kernel can still adapt the
> tile mode array value. Note that this match the design behind the tile
> mode index being that there is a limited number of useful tile mode
> combination and for each surface format  (depth/color/macro
> tile/micro/tile) there is a best one.
>
>
> Second solution is to add an ioctl to compute mipmap information in
> kernel (pitch alignment slice size ...) based on format, size of the
> surface.
>
>
> Some might argue that we could just export the table content to
> userspace, but that would loose information and possibly froze the
> tile mode table forever as API. The information we loose is what index
> match to prefered surface format/type combination. And the tile mode
> might be considered API as if kernel ever change what userspace expect
> then we might break some userspace.
>
> Maybe I'm missing the problem, but if libdrm_radeon were to get the
> tiling mode index chosen by radeonsi, and could retrieve the tiling
> parameters for each index from the kernel, it should be able to
> calculate things properly, shouldn't it?
>
>
> Let's not discuss about who/where the index is pick. No matter where it
> happens the question is do we want to hardcode tile index and make it api
> or do we want to hide it behind symbolic name allowing change in tile array
> (given that right now 4 value are already frozen). You can look at my
> kernel patch to see what i mean.
>
>
> Just as a side node: If I understood it correctly the hardware isn't
> completely capable to use those indexes interchangeable, e.g. only a certain
> range can be used for the DB, and another rule matters for AA indexes etc...
>
> I don't know those rules exactly and I don't know how strict they are, but
> as far as I understood it even the closed source driver didn't need to mess
> with it. So I'm something like 90% sure that hardcoding them is ok, but well
> on the other hand it just doesn't feels good to do so...

The DB_[Z|STENCIL]_INFO.TILE_MODE_INDEX is only 3 bits so all of the
depth formats have to be within the first 8 slots.  The CB and texture
blocks support 5 bits for the index.  That's why the indices are laid
out like they are with the depth formats first.

Alex

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

radeonsi tiling dilema

[Michel Dänzer]

On Die, 2013-04-02 at 14:13 -0400, Jerome Glisse wrote: 
> So i am facing a dilema regarding tiling on radeonsi. Given that we
> now have a fixed table of tiling mode this put more pressure on the
> kernel userspace api. I see either 2 solutions.
> 
> 
> Enforce kernel to set at fixed index in the table best tiling mode for
> given gpu for given format, such as DEPTH32_2D_4AA at index 4, or
> COLOR_SCANOUT_2D at index 13 ... that way kernel can still adapt the
> tile mode array value. Note that this match the design behind the tile
> mode index being that there is a limited number of useful tile mode
> combination and for each surface format  (depth/color/macro
> tile/micro/tile) there is a best one.
> 
> 
> Second solution is to add an ioctl to compute mipmap information in
> kernel (pitch alignment slice size ...) based on format, size of the
> surface.
> 
> 
> Some might argue that we could just export the table content to
> userspace, but that would loose information and possibly froze the
> tile mode table forever as API. The information we loose is what index
> match to prefered surface format/type combination. And the tile mode
> might be considered API as if kernel ever change what userspace expect
> then we might break some userspace.

Maybe I'm missing the problem, but if libdrm_radeon were to get the
tiling mode index chosen by radeonsi, and could retrieve the tiling
parameters for each index from the kernel, it should be able to
calculate things properly, shouldn't it? 

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

[patch] drm/nouveau: off by one in nouveau_drm_vblank_enable()

[Dan Carpenter]

The test here should be ">= ARRAY_SIZE()" instead of "> ARRAY_SIZE()".

Signed-off-by: Dan Carpenter 
---
This was introduced in git://git.freedesktop.org/git/nouveau/linux-2.6 
drm-nouveau-fixes-3.9
It hadn't hit linux-next yet yesterday.

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index c95decf..e11f8e4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -86,7 +86,7 @@ nouveau_drm_vblank_enable(struct drm_device *dev, int head)
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_disp *pdisp = nouveau_disp(drm->device);

-   if (WARN_ON_ONCE(head > ARRAY_SIZE(drm->vblank)))
+   if (WARN_ON_ONCE(head >= ARRAY_SIZE(drm->vblank)))
return -EIO;
WARN_ON_ONCE(drm->vblank[head].func);
drm->vblank[head].func = nouveau_drm_vblank_handler;

[PATCH 02/10] drm/radeon: UVD bringup v7

[Jerome Glisse]

On Wed, Apr 03, 2013 at 01:18:31AM +0200, Christian K?nig wrote:
> Just everything needed to decode videos using UVD.
> 
> v6: just all the bugfixes and support for R7xx-SI merged in one patch
> v7: UVD_CGC_GATE is a write only register, lockup detection fix
> 
> Signed-off-by: Christian K?nig 
> ---
>  drivers/gpu/drm/radeon/Makefile|2 +-
>  drivers/gpu/drm/radeon/evergreen.c |   40 ++-
>  drivers/gpu/drm/radeon/evergreend.h|7 +
>  drivers/gpu/drm/radeon/ni.c|   49 +++
>  drivers/gpu/drm/radeon/nid.h   |9 +
>  drivers/gpu/drm/radeon/r600.c  |  291 ++
>  drivers/gpu/drm/radeon/r600d.h |   61 
>  drivers/gpu/drm/radeon/radeon.h|   47 ++-
>  drivers/gpu/drm/radeon/radeon_asic.c   |   63 
>  drivers/gpu/drm/radeon/radeon_asic.h   |   19 ++
>  drivers/gpu/drm/radeon/radeon_cs.c |   27 +-
>  drivers/gpu/drm/radeon/radeon_fence.c  |   23 +-
>  drivers/gpu/drm/radeon/radeon_kms.c|1 +
>  drivers/gpu/drm/radeon/radeon_object.c |   12 +-
>  drivers/gpu/drm/radeon/radeon_object.h |2 +-
>  drivers/gpu/drm/radeon/radeon_ring.c   |   24 +-
>  drivers/gpu/drm/radeon/radeon_test.c   |   72 +++--
>  drivers/gpu/drm/radeon/radeon_uvd.c|  521 
> 
>  drivers/gpu/drm/radeon/rv770.c |  134 
>  drivers/gpu/drm/radeon/rv770d.h|   14 +
>  drivers/gpu/drm/radeon/si.c|   32 ++
>  drivers/gpu/drm/radeon/sid.h   |6 +
>  include/uapi/drm/radeon_drm.h  |1 +
>  23 files changed, 1400 insertions(+), 57 deletions(-)
>  create mode 100644 drivers/gpu/drm/radeon/radeon_uvd.c
> 
> diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
> index bf17252..86c5e36 100644
> --- a/drivers/gpu/drm/radeon/Makefile
> +++ b/drivers/gpu/drm/radeon/Makefile
> @@ -76,7 +76,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
>   evergreen.o evergreen_cs.o evergreen_blit_shaders.o 
> evergreen_blit_kms.o \
>   evergreen_hdmi.o radeon_trace_points.o ni.o cayman_blit_shaders.o \
>   atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o si.o \
> - si_blit_shaders.o radeon_prime.o
> + si_blit_shaders.o radeon_prime.o radeon_uvd.o
>  
>  radeon-$(CONFIG_COMPAT) += radeon_ioc32.o
>  radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
> b/drivers/gpu/drm/radeon/evergreen.c
> index 305a657..18b66ff 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -3360,6 +3360,9 @@ restart_ih:
>   DRM_ERROR("Unhandled interrupt: %d %d\n", 
> src_id, src_data);
>   break;
>   }
> + case 124: /* UVD */
> + DRM_DEBUG("IH: UVD int: 0x%08x\n", src_data);
> + radeon_fence_process(rdev, R600_RING_TYPE_UVD_INDEX);
>   break;
>   case 146:
>   case 147:
> @@ -3571,7 +3574,7 @@ int evergreen_copy_dma(struct radeon_device *rdev,
>  
>  static int evergreen_startup(struct radeon_device *rdev)
>  {
> - struct radeon_ring *ring = >ring[RADEON_RING_TYPE_GFX_INDEX];
> + struct radeon_ring *ring;
>   int r;
>  
>   /* enable pcie gen2 link */
> @@ -3638,6 +3641,17 @@ static int evergreen_startup(struct radeon_device 
> *rdev)
>   return r;
>   }
>  
> + r = rv770_uvd_resume(rdev);
> + if (!r) {
> + r = radeon_fence_driver_start_ring(rdev,
> +R600_RING_TYPE_UVD_INDEX);
> + if (r)
> + dev_err(rdev->dev, "UVD fences init error (%d).\n", r);
> + }
> +
> + if (r)
> + rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_size = 0;
> +
>   /* Enable IRQ */
>   r = r600_irq_init(rdev);
>   if (r) {
> @@ -3647,6 +3661,7 @@ static int evergreen_startup(struct radeon_device *rdev)
>   }
>   evergreen_irq_set(rdev);
>  
> + ring = >ring[RADEON_RING_TYPE_GFX_INDEX];
>   r = radeon_ring_init(rdev, ring, ring->ring_size, 
> RADEON_WB_CP_RPTR_OFFSET,
>R600_CP_RB_RPTR, R600_CP_RB_WPTR,
>0, 0xf, RADEON_CP_PACKET2);
> @@ -3670,6 +3685,19 @@ static int evergreen_startup(struct radeon_device 
> *rdev)
>   if (r)
>   return r;
>  
> + ring = >ring[R600_RING_TYPE_UVD_INDEX];
> + if (ring->ring_size) {
> + r = radeon_ring_init(rdev, ring, ring->ring_size,
> +  R600_WB_UVD_RPTR_OFFSET,
> +  UVD_RBC_RB_RPTR, UVD_RBC_RB_WPTR,
> +  0, 0xf, RADEON_CP_PACKET2);
> + if (!r)
> + r = r600_uvd_init(rdev);
> +
> + if (r)
> + DRM_ERROR("radeon: error initializing UVD 

UVD fails to init on rv790

[Andy Furniss]

Thanks AMD for getting this out :-)

I have an issue, though.

On HD4890 drm-fixes kernel (before yesterdays updates) got the new

R700_rlc.bin
RV770_uvd.bin

but on boot I get -

[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RV770 0x1002:0x9460 0x1682:0x2700).
[drm] register mmio base: 0xFE6F
[drm] register mmio size: 65536
ATOM BIOS: Wekiva
radeon :01:00.0: VRAM: 1024M 0x - 0x3FFF 
(1024M used)
radeon :01:00.0: GTT: 512M 0x4000 - 0x5FFF
[drm] Detected VRAM RAM=1024M, BAR=256M
[drm] RAM width 256bits DDR
[TTM] Zone  kernel: Available graphics memory: 436936 kiB
[TTM] Zone highmem: Available graphics memory: 1685484 kiB
[TTM] Initializing pool allocator
[drm] radeon: 1024M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
radeon :01:00.0: irq 51 for MSI/MSI-X
radeon :01:00.0: radeon: using MSI.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] probing gen 2 caps for device 1022:9603 = 300d02/0
[drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
[drm] Loading RV770 Microcode
[drm] PCIE GART of 512M enabled (table at 0x00257000).
radeon :01:00.0: WB enabled
radeon :01:00.0: fence driver on ring 0 use gpu addr 
0x4c00 and cpu addr 0xff893c00
radeon :01:00.0: fence driver on ring 3 use gpu addr 
0x4c0c and cpu addr 0xff893c0c
radeon :01:00.0: fence driver on ring 5 use gpu addr 
0x0005632c and cpu addr 0xfbb9632c
[drm] ring test on 0 succeeded in 1 usecs
[drm] ring test on 3 succeeded in 1 usecs
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!!
[drm:rv770_startup] *ERROR* radeon: failed initializing UVD (-1).
[drm] Enabling audio support
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 0 usecs
ALSA sound/pci/hda/hda_eld.c:334 HDMI: ELD buf size is 0, force 128
ALSA sound/pci/hda/hda_eld.c:351 HDMI: invalid ELD data byte 0
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   DVI-I-1
[drm]   HPD2
[drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
[drm]   Encoders:
[drm] DFP1: INTERNAL_UNIPHY
[drm] CRT2: INTERNAL_KLDSCP_DAC2
[drm] Connector 1:
[drm]   DIN-1
[drm]   Encoders:
[drm] TV1: INTERNAL_KLDSCP_DAC2
[drm] Connector 2:
[drm]   DVI-I-2
[drm]   HPD1
[drm]   DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c
[drm]   Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] DFP2: INTERNAL_KLDSCP_LVTMA
[drm] Internal thermal controller with fan control
[drm] radeon: power management initialized
[drm] fb mappable at 0xD0359000
[drm] vram apper at 0xD000
[drm] size 8294400
[drm] fb depth is 24
[drm]pitch is 7680
fbcon: radeondrmfb (fb0) is primary device
Console: switching to colour frame buffer device 240x67
radeon :01:00.0: fb0: radeondrmfb frame buffer device
radeon :01:00.0: registered panic notifier
[drm] Initialized radeon 2.30.0 20080528 for :01:00.0 on minor 0

[PATCH 01/10] drm/radeon: UVD doesn't needs VM on SI

[Jerome Glisse]

On Wed, Apr 03, 2013 at 01:18:30AM +0200, Christian K?nig wrote:
> Signed-off-by: Christian K?nig 
> ---
>  drivers/gpu/drm/radeon/radeon_cs.c |   10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index 70d3824..7d66e01 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> @@ -241,15 +241,15 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, 
> void *data)
>   return -EINVAL;
>   }
>  
> + if (radeon_cs_get_ring(p, ring, priority))
> + return -EINVAL;
> +
>   /* we only support VM on SI+ */
> - if ((p->rdev->family >= CHIP_TAHITI) &&
> - ((p->cs_flags & RADEON_CS_USE_VM) == 0)) {
> + if ((p->rdev->asic->ring[p->ring].cs_parse == NULL) &&
> +((p->cs_flags & RADEON_CS_USE_VM) == 0)) {
>   DRM_ERROR("VM required on SI+!\n");
>   return -EINVAL;

What about updating the error message to something more appropriate like
ring %d require virtual memory

Cheers,
Jerome

>   }
> -
> - if (radeon_cs_get_ring(p, ring, priority))
> - return -EINVAL;
>   }
>  
>   /* deal with non-vm */
> -- 
> 1.7.9.5
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: UVD support for RV710-SI

[Jerome Glisse]

On Wed, Apr 03, 2013 at 01:18:29AM +0200, Christian K?nig wrote:
> Hi everyone,
> 
> the following patchset implements the kernel side of UVD support for the 
> radeon hardware generations RV710-SI.
> 
> The R6xx and RS780/RS880 chipset generations are currently not supported, but 
> might be added in the future.
> 
> The newest firmware can be found here: from 
> http://people.freedesktop.org/~agd5f/radeon_ucode/
> 
> A matching patch implementing the necessary userspace side will follow in 
> just a minute on the mesa devel list.
> 
> Cheers,
> Christian.

For all patch i don't comment on (all patch but first one and second one iirc) 
you got my
Reviewed-by: Jerome Glisse 

Cheers,
Jerome

linux-next: manual merge of the drm-intel tree with Linus' tree

[Daniel Vetter]

On Wed, Apr 03, 2013 at 01:43:49PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the drm-intel tree got a conflict in
> drivers/gpu/drm/i915/intel_panel.c between commit b1289371fcd5 ("Revert
> "drm/i915: write backlight harder"") from Linus' tree and commit
> 31ad8ec6a614 ("drm/i915: group backlight related stuff into a struct")
> from the drm-intel tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks good, I carry the same merge resolution locally.
-Daniel

> 
> -- 
> Cheers,
> Stephen Rothwellsfr at canb.auug.org.au
> 
> diff --cc drivers/gpu/drm/i915/intel_panel.c
> index bee8cb6,0e7e873..000
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@@ -318,9 -321,16 +321,13 @@@ void intel_panel_enable_backlight(struc
>   {
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   
> - if (dev_priv->backlight_level == 0)
> - dev_priv->backlight_level = intel_panel_get_max_backlight(dev);
> + if (dev_priv->backlight.level == 0) {
> + dev_priv->backlight.level = intel_panel_get_max_backlight(dev);
> + if (dev_priv->backlight.device)
> + dev_priv->backlight.device->props.brightness =
> + dev_priv->backlight.level;
> + }
>   
>  -dev_priv->backlight.enabled = true;
>  -intel_panel_actually_set_backlight(dev, dev_priv->backlight.level);
>  -
>   if (INTEL_INFO(dev)->gen >= 4) {
>   uint32_t reg, tmp;
>   
> @@@ -356,12 -366,12 +363,12 @@@
>   }
>   
>   set_level:
>  -/* Check the current backlight level and try to set again if it's zero.
>  - * On some machines, BLC_PWM_CPU_CTL is cleared to zero automatically
>  - * when BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1 are written.
>  +/* Call below after setting BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1.
>  + * BLC_PWM_CPU_CTL may be cleared to zero automatically when these
>  + * registers are set.
>*/
> - dev_priv->backlight_enabled = true;
> - intel_panel_actually_set_backlight(dev, dev_priv->backlight_level);
>  -if (!intel_panel_get_backlight(dev))
>  -intel_panel_actually_set_backlight(dev, 
> dev_priv->backlight.level);
> ++dev_priv->backlight.enabled = true;
> ++intel_panel_actually_set_backlight(dev, dev_priv->backlight.level);
>   }
>   
>   static void intel_panel_init_backlight(struct drm_device *dev)



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

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

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

--- Comment #3 from Michel D?nzer  ---
If you run piglit with --no-concurrency from a remote shell, you should see in
the terminal output which test is running when it hangs.

-- 
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/20130403/aa396710/attachment.html>

[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor

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

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

--- Comment #11 from Michel D?nzer  ---
(In reply to comment #8)
> It seems like Gnome 3.6 won't work unless color tiling is enabled. I double
> checked the gnome session logs and don't see the previously mentioned error
> anymore.. just a blank desktop wallpaper across both monitors.

Weird. GNOME 3.6 was and 3.8 still is working fine for me with ColorTiling
disabled (on a 7770), and I'm not sure how this could be directly related. Is
there anything in dmesg about GPU lockups, or is gnome-shell getting stuck
somehwere, or something like that?

-- 
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/20130403/30fb5fcb/attachment-0001.html>

radeonsi tiling dilema

[Jerome Glisse]

On Wed, Apr 3, 2013 at 5:37 AM, Michel D?nzer  wrote:

> On Die, 2013-04-02 at 14:13 -0400, Jerome Glisse wrote:
> > So i am facing a dilema regarding tiling on radeonsi. Given that we
> > now have a fixed table of tiling mode this put more pressure on the
> > kernel userspace api. I see either 2 solutions.
> >
> >
> > Enforce kernel to set at fixed index in the table best tiling mode for
> > given gpu for given format, such as DEPTH32_2D_4AA at index 4, or
> > COLOR_SCANOUT_2D at index 13 ... that way kernel can still adapt the
> > tile mode array value. Note that this match the design behind the tile
> > mode index being that there is a limited number of useful tile mode
> > combination and for each surface format  (depth/color/macro
> > tile/micro/tile) there is a best one.
> >
> >
> > Second solution is to add an ioctl to compute mipmap information in
> > kernel (pitch alignment slice size ...) based on format, size of the
> > surface.
> >
> >
> > Some might argue that we could just export the table content to
> > userspace, but that would loose information and possibly froze the
> > tile mode table forever as API. The information we loose is what index
> > match to prefered surface format/type combination. And the tile mode
> > might be considered API as if kernel ever change what userspace expect
> > then we might break some userspace.
>
> Maybe I'm missing the problem, but if libdrm_radeon were to get the
> tiling mode index chosen by radeonsi, and could retrieve the tiling
> parameters for each index from the kernel, it should be able to
> calculate things properly, shouldn't it?
>
>
Let's not discuss about who/where the index is pick. No matter where it
happens the question is do we want to hardcode tile index and make it api
or do we want to hide it behind symbolic name allowing change in tile array
(given that right now 4 value are already frozen). You can look at my
kernel patch to see what i mean.

Cheers,
Jerome
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130403/b58c20cd/attachment-0001.html>

[PATCH v4 0/2] Enhance EDID quirks to allow forcing a mode

[Dylan Semler]

On Mon, Mar 25, 2013 at 5:58 PM, Dylan Semler 
wrote:
>
> Changes in this version
>  * rename do_force_quirk_modes() -> do_force_quirk_mode()
>  * use list_for_each_entry() instead of list_for_each_entry_safe() in
>do_force_quirk_mode()
>  * remove num_modes from do_force_quirk_mode(), just return 1 or 0 as
>appropriate
>  * remove unused quirks argument from add_force_quirk_modes()
>  * fixes to allow cases of forcing multiple modes
>  * adjusted comments to adhere closer to style guides
>
> Changes in version 3
>  * Uses drm_cvt_mode() instead of drm_gtf_mode() to build modeline
>  * Adds bool to specify reduced blanking to edid_quirk_force_mode
>  * Removes preferred bit from all other modes
>
> Changes in version 2
>  * none
>
> There is at least one monitor that doesn't report its native resolution
> in its EDID block.  This enhancement extends the EDID quirk logic to
> make monitors like this "just work".
>
> The first patch in this series sets up a new quirk list where monitors'
> correct width, height, refresh rate, and reduced blanking parameters are
> specified.  When a matching monitor is attached the full mode is
> calculated with drm_cvt_mode() and added to the connector.  The
> DRM_MODE_TYPE_PREFERRED bit is set on the new mode and unset from all
> other modes.
>
> The first patch also defines a new quirk bit: EDID_QUIRK_FORCE_MODE.
> This bit needs to be set for the new quirk list described above to be
> checked.
>
> The second patch adds the offending monitor to the quirk lists.
>
> Dylan Semler (2):
>   drm: Enhance EDID quirks to explicitly set a mode
>   drm: Add EDID force quirk for MMT Monitor2Go HD+
>
>  drivers/gpu/drm/drm_edid.c | 89
++
>  1 file changed, 89 insertions(+)
>
> --
> 1.7.11.7
>

Version 3 was Acked by Daniel Vetter[1].  Any chance ajax can give his
comments?

[1] http://lists.freedesktop.org/archives/dri-devel/2013-March/036457.html
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130403/d150444a/attachment.html>

UVD fails to init on rv790

[Alex Deucher]

On Wed, Apr 3, 2013 at 7:29 AM, Christian K?nig  
wrote:
> Hi Andy,
>
> crap! I feared that something like this would happen. IIRC we never tested
> UVD on an rv790, and this hardware isn't easy to get any more.
>
> RV770/RV790 have a separate UVD hardware generation (that's why they have
> their own firmware) and there possible is some bug or something like this
> that we haven't implemented. You couldn't give me SSH access to that system?

I tested on an RV770 earlier in development and it was working ok at
the time I think.  I'll give it another try today.

Alex

>
> Christian.
>
> Am 03.04.2013 11:51, schrieb Andy Furniss:
>
>> Thanks AMD for getting this out :-)
>>
>> I have an issue, though.
>>
>> On HD4890 drm-fixes kernel (before yesterdays updates) got the new
>>
>> R700_rlc.bin
>> RV770_uvd.bin
>>
>> but on boot I get -
>>
>> [drm] radeon kernel modesetting enabled.
>> [drm] initializing kernel modesetting (RV770 0x1002:0x9460 0x1682:0x2700).
>> [drm] register mmio base: 0xFE6F
>> [drm] register mmio size: 65536
>> ATOM BIOS: Wekiva
>> radeon :01:00.0: VRAM: 1024M 0x - 0x3FFF
>> (1024M used)
>> radeon :01:00.0: GTT: 512M 0x4000 - 0x5FFF
>> [drm] Detected VRAM RAM=1024M, BAR=256M
>> [drm] RAM width 256bits DDR
>> [TTM] Zone  kernel: Available graphics memory: 436936 kiB
>> [TTM] Zone highmem: Available graphics memory: 1685484 kiB
>> [TTM] Initializing pool allocator
>> [drm] radeon: 1024M of VRAM memory ready
>> [drm] radeon: 512M of GTT memory ready.
>> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>> [drm] Driver supports precise vblank timestamp query.
>> radeon :01:00.0: irq 51 for MSI/MSI-X
>> radeon :01:00.0: radeon: using MSI.
>> [drm] radeon: irq initialized.
>> [drm] GART: num cpu pages 131072, num gpu pages 131072
>> [drm] probing gen 2 caps for device 1022:9603 = 300d02/0
>> [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
>> [drm] Loading RV770 Microcode
>> [drm] PCIE GART of 512M enabled (table at 0x00257000).
>> radeon :01:00.0: WB enabled
>> radeon :01:00.0: fence driver on ring 0 use gpu addr
>> 0x4c00 and cpu addr 0xff893c00
>> radeon :01:00.0: fence driver on ring 3 use gpu addr
>> 0x4c0c and cpu addr 0xff893c0c
>> radeon :01:00.0: fence driver on ring 5 use gpu addr
>> 0x0005632c and cpu addr 0xfbb9632c
>> [drm] ring test on 0 succeeded in 1 usecs
>> [drm] ring test on 3 succeeded in 1 usecs
>> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
>> VCPU!!!
>> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
>> VCPU!!!
>> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
>> VCPU!!!
>> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
>> VCPU!!!
>> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
>> VCPU!!!
>> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
>> VCPU!!!
>> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
>> VCPU!!!
>> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
>> VCPU!!!
>> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
>> VCPU!!!
>> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
>> VCPU!!!
>> [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!!
>> [drm:rv770_startup] *ERROR* radeon: failed initializing UVD (-1).
>> [drm] Enabling audio support
>> [drm] ib test on ring 0 succeeded in 0 usecs
>> [drm] ib test on ring 3 succeeded in 0 usecs
>> ALSA sound/pci/hda/hda_eld.c:334 HDMI: ELD buf size is 0, force 128
>> ALSA sound/pci/hda/hda_eld.c:351 HDMI: invalid ELD data byte 0
>> [drm] Radeon Display Connectors
>> [drm] Connector 0:
>> [drm]   DVI-I-1
>> [drm]   HPD2
>> [drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
>> [drm]   Encoders:
>> [drm] DFP1: INTERNAL_UNIPHY
>> [drm] CRT2: INTERNAL_KLDSCP_DAC2
>> [drm] Connector 1:
>> [drm]   DIN-1
>> [drm]   Encoders:
>> [drm] TV1: INTERNAL_KLDSCP_DAC2
>> [drm] Connector 2:
>> [drm]   DVI-I-2
>> [drm]   HPD1
>> [drm]   DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c
>> [drm]   Encoders:
>> [drm] CRT1: INTERNAL_KLDSCP_DAC1
>> [drm] DFP2: INTERNAL_KLDSCP_LVTMA
>> [drm] Internal thermal controller with fan control
>> [drm] radeon: power management initialized
>> [drm] fb mappable at 0xD0359000
>> [drm] vram apper at 0xD000
>> [drm] size 8294400
>> [drm] fb depth is 24
>> [drm]pitch is 7680
>> fbcon: radeondrmfb (fb0) is primary device
>> Console: switching to colour frame buffer device 240x67
>> radeon :01:00.0: fb0: radeondrmfb frame buffer device
>> radeon :01:00.0: registered panic notifier
>> [drm] Initialized radeon 2.30.0 20080528 for :01:00.0 on minor 0
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> 

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

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

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

--- Comment #60 from Austin Lund  ---
It does look like commit 547b52463 did introduce the problem (tho I didn't
finish bisecting).

The patch set does fix the issue for me.

-- 
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/20130403/540e177e/attachment-0001.html>

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

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

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

--- Comment #59 from Alex Deucher  ---
Possibly fixed by this patch set:
https://patchwork.kernel.org/patch/2344041/

-- 
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/20130403/43d5c77d/attachment.html>

[Bug 43655] Latest radeon dri driver on HD6950 with GRUB set "GRUB_GFXPAYLOAD_LINUX=keep" put the display in a flickering state

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

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

Alexandre Demers  changed:

   What|Removed |Added

  Attachment #77348|0   |1
is obsolete||

--- Comment #29 from Alexandre Demers  ---
Created attachment 77350
  --> https://bugs.freedesktop.org/attachment.cgi?id=77350=edit
3.9-rc5 with patch and drm.debug=14

With more debug info

-- 
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/20130403/50207c3f/attachment.html>

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

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

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

--- Comment #58 from Austin Lund  ---
This still doesn't work for 3.9-rc5.

-- 
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/20130403/08fb64e5/attachment.html>

[PATCH 10/10] drm/radeon: add UVD tiling addr config v2

[Christian König]

v2: set UVD tiling config for rv730

Signed-off-by: Christian K?nig 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/evergreen.c  |3 +++
 drivers/gpu/drm/radeon/evergreend.h |3 +++
 drivers/gpu/drm/radeon/ni.c |3 +++
 drivers/gpu/drm/radeon/nid.h|3 +++
 drivers/gpu/drm/radeon/rv770.c  |5 +
 drivers/gpu/drm/radeon/rv770d.h |5 +
 drivers/gpu/drm/radeon/si.c |3 +++
 drivers/gpu/drm/radeon/sid.h|3 +++
 8 files changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index a6e7186..c6d8017 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2269,6 +2269,9 @@ static void evergreen_gpu_init(struct radeon_device *rdev)
WREG32(DMIF_ADDR_CONFIG, gb_addr_config);
WREG32(HDP_ADDR_CONFIG, gb_addr_config);
WREG32(DMA_TILING_CONFIG, gb_addr_config);
+   WREG32(UVD_UDEC_ADDR_CONFIG, gb_addr_config);
+   WREG32(UVD_UDEC_DB_ADDR_CONFIG, gb_addr_config);
+   WREG32(UVD_UDEC_DBW_ADDR_CONFIG, gb_addr_config);

if ((rdev->config.evergreen.max_backends == 1) &&
(rdev->flags & RADEON_IS_IGP)) {
diff --git a/drivers/gpu/drm/radeon/evergreend.h 
b/drivers/gpu/drm/radeon/evergreend.h
index 43e7d3f..eabf92a 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -1033,6 +1033,9 @@
 /*
  * UVD
  */
+#define UVD_UDEC_ADDR_CONFIG   0xef4c
+#define UVD_UDEC_DB_ADDR_CONFIG0xef50
+#define UVD_UDEC_DBW_ADDR_CONFIG   0xef54
 #define UVD_RBC_RB_RPTR0xf690
 #define UVD_RBC_RB_WPTR0xf694

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index ac944f5..9ed0571 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -624,6 +624,9 @@ static void cayman_gpu_init(struct radeon_device *rdev)
WREG32(HDP_ADDR_CONFIG, gb_addr_config);
WREG32(DMA_TILING_CONFIG + DMA0_REGISTER_OFFSET, gb_addr_config);
WREG32(DMA_TILING_CONFIG + DMA1_REGISTER_OFFSET, gb_addr_config);
+   WREG32(UVD_UDEC_ADDR_CONFIG, gb_addr_config);
+   WREG32(UVD_UDEC_DB_ADDR_CONFIG, gb_addr_config);
+   WREG32(UVD_UDEC_DBW_ADDR_CONFIG, gb_addr_config);

if ((rdev->config.cayman.max_backends_per_se == 1) &&
(rdev->flags & RADEON_IS_IGP)) {
diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h
index 3731f6c..358187a 100644
--- a/drivers/gpu/drm/radeon/nid.h
+++ b/drivers/gpu/drm/radeon/nid.h
@@ -491,6 +491,9 @@
 #define UVD_SEMA_ADDR_LOW  0xEF00
 #define UVD_SEMA_ADDR_HIGH 0xEF04
 #define UVD_SEMA_CMD   0xEF08
+#define UVD_UDEC_ADDR_CONFIG   0xEF4C
+#define UVD_UDEC_DB_ADDR_CONFIG0xEF50
+#define UVD_UDEC_DBW_ADDR_CONFIG   0xEF54
 #define UVD_RBC_RB_RPTR0xF690
 #define UVD_RBC_RB_WPTR0xF694

diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 8149219..111d716 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -868,6 +868,11 @@ static void rv770_gpu_init(struct radeon_device *rdev)
WREG32(HDP_TILING_CONFIG, (gb_tiling_config & 0x));
WREG32(DMA_TILING_CONFIG, (gb_tiling_config & 0x));
WREG32(DMA_TILING_CONFIG2, (gb_tiling_config & 0x));
+   if (rdev->family == CHIP_RV730) {
+   WREG32(UVD_UDEC_DB_TILING_CONFIG, (gb_tiling_config & 0x));
+   WREG32(UVD_UDEC_DBW_TILING_CONFIG, (gb_tiling_config & 0x));
+   WREG32(UVD_UDEC_TILING_CONFIG, (gb_tiling_config & 0x));
+   }

WREG32(CGTS_SYS_TCC_DISABLE, 0);
WREG32(CGTS_TCC_DISABLE, 0);
diff --git a/drivers/gpu/drm/radeon/rv770d.h b/drivers/gpu/drm/radeon/rv770d.h
index 162b177..6a52b20 100644
--- a/drivers/gpu/drm/radeon/rv770d.h
+++ b/drivers/gpu/drm/radeon/rv770d.h
@@ -136,6 +136,11 @@
 #define DMA_TILING_CONFIG   0x3ec8
 #define DMA_TILING_CONFIG2  0xd0b8

+/* RV730 only */
+#define UVD_UDEC_TILING_CONFIG  0xef40
+#define UVD_UDEC_DB_TILING_CONFIG   0xef44
+#define UVD_UDEC_DBW_TILING_CONFIG  0xef48
+
 #defineGC_USER_SHADER_PIPE_CONFIG  0x8954
 #defineINACTIVE_QD_PIPES(x)((x) << 
8)
 #defineINACTIVE_QD_PIPES_MASK  
0xFF00
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 472d9fb..34ffbcb 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ 

[PATCH 09/10] drm/radeon: init UVD clocks to sane defaults

[Christian König]

Just until we get proper DPM for that.

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

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 8ab7bb9..768d8f5 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -193,6 +193,8 @@ int radeon_uvd_resume(struct radeon_device *rdev)

radeon_bo_unreserve(rdev->uvd.vcpu_bo);

+   radeon_set_uvd_clocks(rdev, 53300, 4);
+
return 0;
 }

-- 
1.7.9.5

[PATCH 08/10] drm/radeon: add set_uvd_clocks callback for r7xx v3

[Christian König]

v2: avoid 64bit divide
v3: rv740 uses the evegreen upll configuration

Signed-off-by: Christian K?nig 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_asic.c |1 +
 drivers/gpu/drm/radeon/radeon_asic.h |1 +
 drivers/gpu/drm/radeon/rv770.c   |  156 ++
 drivers/gpu/drm/radeon/rv770d.h  |   24 ++
 4 files changed, 182 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index 03228cb..19bf122 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1183,6 +1183,7 @@ static struct radeon_asic rv770_asic = {
.get_pcie_lanes = _get_pcie_lanes,
.set_pcie_lanes = _set_pcie_lanes,
.set_clock_gating = _atom_set_clock_gating,
+   .set_uvd_clocks = _set_uvd_clocks,
},
.pflip = {
.pre_page_flip = _pre_page_flip,
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index 365c964..2add526 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -424,6 +424,7 @@ int rv770_copy_dma(struct radeon_device *rdev,
   struct radeon_fence **fence);
 u32 rv770_get_xclk(struct radeon_device *rdev);
 int rv770_uvd_resume(struct radeon_device *rdev);
+int rv770_set_uvd_clocks(struct radeon_device *rdev, u32 vclk, u32 dclk);

 /*
  * evergreen
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 5a78cce..8149219 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -42,6 +42,162 @@
 static void rv770_gpu_init(struct radeon_device *rdev);
 void rv770_fini(struct radeon_device *rdev);
 static void rv770_pcie_gen2_enable(struct radeon_device *rdev);
+int evergreen_set_uvd_clocks(struct radeon_device *rdev, u32 vclk, u32 dclk);
+
+static int rv770_uvd_calc_post_div(unsigned target_freq,
+  unsigned vco_freq,
+  unsigned *div)
+{
+   /* Fclk = Fvco / PDIV */
+   *div = vco_freq / target_freq;
+
+   /* we alway need a frequency less than or equal the target */
+   if ((vco_freq / *div) > target_freq)
+   *div += 1;
+
+   /* out of range ? */
+   if (*div > 30)
+   return -1; /* forget it */
+
+   *div -= 1;
+   return vco_freq / (*div + 1);
+}
+
+static int rv770_uvd_send_upll_ctlreq(struct radeon_device *rdev)
+{
+   unsigned i;
+
+   /* assert UPLL_CTLREQ */
+   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_CTLREQ_MASK, ~UPLL_CTLREQ_MASK);
+
+   /* wait for CTLACK and CTLACK2 to get asserted */
+   for (i = 0; i < 100; ++i) {
+   uint32_t mask = UPLL_CTLACK_MASK | UPLL_CTLACK2_MASK;
+   if ((RREG32(CG_UPLL_FUNC_CNTL) & mask) == mask)
+   break;
+   mdelay(10);
+   }
+   if (i == 100)
+   return -ETIMEDOUT;
+
+   /* deassert UPLL_CTLREQ */
+   WREG32_P(CG_UPLL_FUNC_CNTL, 0, ~UPLL_CTLREQ_MASK);
+
+   return 0;
+}
+
+int rv770_set_uvd_clocks(struct radeon_device *rdev, u32 vclk, u32 dclk)
+{
+   /* start off with something large */
+   int optimal_diff_score = 0x7FF;
+   unsigned optimal_fb_div = 0, optimal_vclk_div = 0;
+   unsigned optimal_dclk_div = 0, optimal_vco_freq = 0;
+   unsigned vco_freq, vco_min = 5, vco_max = 16;
+   unsigned ref_freq = rdev->clock.spll.reference_freq;
+   int r;
+
+   /* RV740 uses evergreen uvd clk programming */
+   if (rdev->family == CHIP_RV740)
+   return evergreen_set_uvd_clocks(rdev, vclk, dclk);
+
+   /* loop through vco from low to high */
+   vco_min = max(max(vco_min, vclk), dclk);
+   for (vco_freq = vco_min; vco_freq <= vco_max; vco_freq += 500) {
+   uint64_t fb_div = (uint64_t)vco_freq * 43663;
+   int calc_clk, diff_score, diff_vclk, diff_dclk;
+   unsigned vclk_div, dclk_div;
+
+   do_div(fb_div, ref_freq);
+   fb_div |= 1;
+
+   /* fb div out of range ? */
+   if (fb_div > 0x03FF)
+   break; /* it can oly get worse */
+
+   /* calc vclk with current vco freq. */
+   calc_clk = rv770_uvd_calc_post_div(vclk, vco_freq, _div);
+   if (calc_clk == -1)
+   break; /* vco is too big, it has to stop. */
+   diff_vclk = vclk - calc_clk;
+
+   /* calc dclk with current vco freq. */
+   calc_clk = rv770_uvd_calc_post_div(dclk, vco_freq, _div);
+   if (calc_clk == -1)
+   break; /* vco is too big, it has to stop. */
+   diff_dclk = dclk - calc_clk;
+
+   /* determine if this vco setting is better than current optimal 
settings */
+   diff_score = abs(diff_vclk) + 

[PATCH 07/10] drm/radeon: add set_uvd_clocks callback for SI

[Christian König]

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon_asic.c |1 +
 drivers/gpu/drm/radeon/radeon_asic.h |1 +
 drivers/gpu/drm/radeon/si.c  |  167 ++
 drivers/gpu/drm/radeon/sid.h |   29 ++
 4 files changed, 198 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index a65312c..03228cb 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1887,6 +1887,7 @@ static struct radeon_asic si_asic = {
.get_pcie_lanes = NULL,
.set_pcie_lanes = NULL,
.set_clock_gating = NULL,
+   .set_uvd_clocks = _set_uvd_clocks,
},
.pflip = {
.pre_page_flip = _pre_page_flip,
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index 54a7ef7..365c964 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -545,5 +545,6 @@ int si_copy_dma(struct radeon_device *rdev,
 void si_dma_vm_flush(struct radeon_device *rdev, int ridx, struct radeon_vm 
*vm);
 u32 si_get_xclk(struct radeon_device *rdev);
 uint64_t si_get_gpu_clock_counter(struct radeon_device *rdev);
+int si_set_uvd_clocks(struct radeon_device *rdev, u32 vclk, u32 dclk);

 #endif
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index cc9fe39..472d9fb 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -4666,3 +4666,170 @@ uint64_t si_get_gpu_clock_counter(struct radeon_device 
*rdev)
mutex_unlock(>gpu_clock_mutex);
return clock;
 }
+
+static int si_uvd_calc_post_div(unsigned target_freq,
+   unsigned vco_freq,
+   unsigned *div)
+{
+   /* target larger than vco frequency ? */
+   if (vco_freq < target_freq)
+   return -1; /* forget it */
+
+   /* Fclk = Fvco / PDIV */
+   *div = vco_freq / target_freq;
+
+   /* we alway need a frequency less than or equal the target */
+   if ((vco_freq / *div) > target_freq)
+   *div += 1;
+
+   /* dividers above 5 must be even */
+   if (*div > 5 && *div % 2)
+   *div += 1;
+
+   /* out of range ? */
+   if (*div >= 128)
+   return -1; /* forget it */
+
+   return vco_freq / *div;
+}
+
+static int si_uvd_send_upll_ctlreq(struct radeon_device *rdev)
+{
+   unsigned i;
+
+   /* assert UPLL_CTLREQ */
+   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_CTLREQ_MASK, ~UPLL_CTLREQ_MASK);
+
+   /* wait for CTLACK and CTLACK2 to get asserted */
+   for (i = 0; i < 100; ++i) {
+   uint32_t mask = UPLL_CTLACK_MASK | UPLL_CTLACK2_MASK;
+   if ((RREG32(CG_UPLL_FUNC_CNTL) & mask) == mask)
+   break;
+   mdelay(10);
+   }
+   if (i == 100)
+   return -ETIMEDOUT;
+
+   /* deassert UPLL_CTLREQ */
+   WREG32_P(CG_UPLL_FUNC_CNTL, 0, ~UPLL_CTLREQ_MASK);
+
+   return 0;
+}
+
+int si_set_uvd_clocks(struct radeon_device *rdev, u32 vclk, u32 dclk)
+{
+   /* start off with something large */
+   int optimal_diff_score = 0x7FF;
+   unsigned optimal_fb_div = 0, optimal_vclk_div = 0;
+   unsigned optimal_dclk_div = 0, optimal_vco_freq = 0;
+   unsigned vco_freq;
+   int r;
+
+   /* loop through vco from low to high */
+   for (vco_freq = 125000; vco_freq <= 25; vco_freq += 100) {
+   unsigned fb_div = vco_freq / rdev->clock.spll.reference_freq * 
16384;
+   int calc_clk, diff_score, diff_vclk, diff_dclk;
+   unsigned vclk_div, dclk_div;
+
+   /* fb div out of range ? */
+   if (fb_div > 0x03FF)
+   break; /* it can oly get worse */
+
+   /* calc vclk with current vco freq. */
+   calc_clk = si_uvd_calc_post_div(vclk, vco_freq, _div);
+   if (calc_clk == -1)
+   break; /* vco is too big, it has to stop. */
+   diff_vclk = vclk - calc_clk;
+
+   /* calc dclk with current vco freq. */
+   calc_clk = si_uvd_calc_post_div(dclk, vco_freq, _div);
+   if (calc_clk == -1)
+   break; /* vco is too big, it has to stop. */
+   diff_dclk = dclk - calc_clk;
+
+   /* determine if this vco setting is better than current optimal 
settings */
+   diff_score = abs(diff_vclk) + abs(diff_dclk);
+   if (diff_score < optimal_diff_score) {
+   optimal_fb_div = fb_div;
+   optimal_vclk_div = vclk_div;
+   optimal_dclk_div = dclk_div;
+   optimal_vco_freq = vco_freq;
+   optimal_diff_score = diff_score;
+   if (optimal_diff_score == 0)
+

[PATCH 06/10] drm/radeon: add set_uvd_clocks callback for evergreen

[Christian König]

From: Alex Deucher 

v2: remove unneeded register definitions

Signed-off-by: Alex Deucher 
Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/evergreen.c   |  164 ++
 drivers/gpu/drm/radeon/evergreend.h  |   27 ++
 drivers/gpu/drm/radeon/radeon_asic.c |3 +
 drivers/gpu/drm/radeon/radeon_asic.h |1 +
 4 files changed, 195 insertions(+)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index bdd3d34..a6e7186 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -131,6 +131,170 @@ done:
return r;
 }

+static int evergreen_uvd_calc_post_div(unsigned target_freq,
+  unsigned vco_freq,
+  unsigned *div)
+{
+   /* target larger than vco frequency ? */
+   if (vco_freq < target_freq)
+   return -1; /* forget it */
+
+   /* Fclk = Fvco / PDIV */
+   *div = vco_freq / target_freq;
+
+   /* we alway need a frequency less than or equal the target */
+   if ((vco_freq / *div) > target_freq)
+   *div += 1;
+
+   /* dividers above 5 must be even */
+   if (*div > 5 && *div % 2)
+   *div += 1;
+
+   /* out of range ? */
+   if (*div >= 128)
+   return -1; /* forget it */
+
+   return vco_freq / *div;
+}
+
+static int evergreen_uvd_send_upll_ctlreq(struct radeon_device *rdev)
+{
+   unsigned i;
+
+   /* assert UPLL_CTLREQ */
+   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_CTLREQ_MASK, ~UPLL_CTLREQ_MASK);
+
+   /* wait for CTLACK and CTLACK2 to get asserted */
+   for (i = 0; i < 100; ++i) {
+   uint32_t mask = UPLL_CTLACK_MASK | UPLL_CTLACK2_MASK;
+   if ((RREG32(CG_UPLL_FUNC_CNTL) & mask) == mask)
+   break;
+   mdelay(10);
+   }
+   if (i == 100)
+   return -ETIMEDOUT;
+
+   /* deassert UPLL_CTLREQ */
+   WREG32_P(CG_UPLL_FUNC_CNTL, 0, ~UPLL_CTLREQ_MASK);
+
+   return 0;
+}
+
+int evergreen_set_uvd_clocks(struct radeon_device *rdev, u32 vclk, u32 dclk)
+{
+   /* start off with something large */
+   int optimal_diff_score = 0x7FF;
+   unsigned optimal_fb_div = 0, optimal_vclk_div = 0;
+   unsigned optimal_dclk_div = 0, optimal_vco_freq = 0;
+   unsigned vco_freq;
+   int r;
+
+   /* loop through vco from low to high */
+   for (vco_freq = 125000; vco_freq <= 25; vco_freq += 100) {
+   unsigned fb_div = vco_freq / rdev->clock.spll.reference_freq * 
16384;
+   int calc_clk, diff_score, diff_vclk, diff_dclk;
+   unsigned vclk_div, dclk_div;
+
+   /* fb div out of range ? */
+   if (fb_div > 0x03FF)
+   break; /* it can oly get worse */
+
+   /* calc vclk with current vco freq. */
+   calc_clk = evergreen_uvd_calc_post_div(vclk, vco_freq, 
_div);
+   if (calc_clk == -1)
+   break; /* vco is too big, it has to stop. */
+   diff_vclk = vclk - calc_clk;
+
+   /* calc dclk with current vco freq. */
+   calc_clk = evergreen_uvd_calc_post_div(dclk, vco_freq, 
_div);
+   if (calc_clk == -1)
+   break; /* vco is too big, it has to stop. */
+   diff_dclk = dclk - calc_clk;
+
+   /* determine if this vco setting is better than current optimal 
settings */
+   diff_score = abs(diff_vclk) + abs(diff_dclk);
+   if (diff_score < optimal_diff_score) {
+   optimal_fb_div = fb_div;
+   optimal_vclk_div = vclk_div;
+   optimal_dclk_div = dclk_div;
+   optimal_vco_freq = vco_freq;
+   optimal_diff_score = diff_score;
+   if (optimal_diff_score == 0)
+   break; /* it can't get better than this */
+   }
+   }
+
+   /* set VCO_MODE to 1 */
+   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_VCO_MODE_MASK, ~UPLL_VCO_MODE_MASK);
+
+   /* toggle UPLL_SLEEP to 1 then back to 0 */
+   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_SLEEP_MASK, ~UPLL_SLEEP_MASK);
+   WREG32_P(CG_UPLL_FUNC_CNTL, 0, ~UPLL_SLEEP_MASK);
+
+   /* deassert UPLL_RESET */
+   WREG32_P(CG_UPLL_FUNC_CNTL, 0, ~UPLL_RESET_MASK);
+
+   mdelay(1);
+
+   /* bypass vclk and dclk with bclk */
+   WREG32_P(CG_UPLL_FUNC_CNTL_2,
+   VCLK_SRC_SEL(1) | DCLK_SRC_SEL(1),
+   ~(VCLK_SRC_SEL_MASK | DCLK_SRC_SEL_MASK));
+
+   /* put PLL in bypass mode */
+   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_BYPASS_EN_MASK, ~UPLL_BYPASS_EN_MASK);
+
+   r = evergreen_uvd_send_upll_ctlreq(rdev);
+   if (r)
+   return r;
+
+   /* assert UPLL_RESET again */
+   

[PATCH 05/10] drm/radeon: add set_uvd_clocks callback for ON/LN/TN (v4)

[Christian König]

From: Alex Deucher 

v2: write clk registers only once!
v3: update cg scratch register properly
v4: add TN support

Signed-off-by: Alex Deucher 
Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/evergreen.c   |   47 ++
 drivers/gpu/drm/radeon/evergreend.h  |   10 
 drivers/gpu/drm/radeon/radeon_asic.c |2 ++
 drivers/gpu/drm/radeon/radeon_asic.h |1 +
 4 files changed, 60 insertions(+)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 18b66ff..bdd3d34 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -84,6 +84,53 @@ void evergreen_tiling_fields(unsigned tiling_flags, unsigned 
*bankw,
}
 }

+static int sumo_set_uvd_clock(struct radeon_device *rdev, u32 clock,
+ u32 cntl_reg, u32 status_reg)
+{
+   int r, i;
+   struct atom_clock_dividers dividers;
+
+r = radeon_atom_get_clock_dividers(rdev, COMPUTE_ENGINE_PLL_PARAM,
+  clock, false, );
+   if (r)
+   return r;
+
+   WREG32_P(cntl_reg, dividers.post_div, 
~(DCLK_DIR_CNTL_EN|DCLK_DIVIDER_MASK));
+
+   for (i = 0; i < 100; i++) {
+   if (RREG32(status_reg) & DCLK_STATUS)
+   break;
+   mdelay(10);
+   }
+   if (i == 100)
+   return -ETIMEDOUT;
+
+   return 0;
+}
+
+int sumo_set_uvd_clocks(struct radeon_device *rdev, u32 vclk, u32 dclk)
+{
+   int r = 0;
+   u32 cg_scratch = RREG32(CG_SCRATCH1);
+
+   r = sumo_set_uvd_clock(rdev, vclk, CG_VCLK_CNTL, CG_VCLK_STATUS);
+   if (r)
+   goto done;
+   cg_scratch &= 0x;
+   cg_scratch |= vclk / 100; /* Mhz */
+
+   r = sumo_set_uvd_clock(rdev, dclk, CG_DCLK_CNTL, CG_DCLK_STATUS);
+   if (r)
+   goto done;
+   cg_scratch &= 0x;
+   cg_scratch |= (dclk / 100) << 16; /* Mhz */
+
+done:
+   WREG32(CG_SCRATCH1, cg_scratch);
+
+   return r;
+}
+
 void evergreen_fix_pci_max_read_req_size(struct radeon_device *rdev)
 {
u16 ctl, v;
diff --git a/drivers/gpu/drm/radeon/evergreend.h 
b/drivers/gpu/drm/radeon/evergreend.h
index c5d873e..b6491a3 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -53,6 +53,16 @@
 #define RCU_IND_INDEX  0x100
 #define RCU_IND_DATA   0x104

+/* fusion uvd clocks */
+#define CG_DCLK_CNTL0x610
+#   define DCLK_DIVIDER_MASK0x7f
+#   define DCLK_DIR_CNTL_EN (1 << 8)
+#define CG_DCLK_STATUS  0x614
+#   define DCLK_STATUS  (1 << 0)
+#define CG_VCLK_CNTL0x618
+#define CG_VCLK_STATUS  0x61c
+#defineCG_SCRATCH1 0x820
+
 #define GRBM_GFX_INDEX 0x802C
 #defineINSTANCE_INDEX(x)   ((x) << 0)
 #defineSE_INDEX(x) ((x) << 16)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index a7a7b2b..d3992d9 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1373,6 +1373,7 @@ static struct radeon_asic sumo_asic = {
.get_pcie_lanes = NULL,
.set_pcie_lanes = NULL,
.set_clock_gating = NULL,
+   .set_uvd_clocks = _set_uvd_clocks,
},
.pflip = {
.pre_page_flip = _pre_page_flip,
@@ -1744,6 +1745,7 @@ static struct radeon_asic trinity_asic = {
.get_pcie_lanes = NULL,
.set_pcie_lanes = NULL,
.set_clock_gating = NULL,
+   .set_uvd_clocks = _set_uvd_clocks,
},
.pflip = {
.pre_page_flip = _pre_page_flip,
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index 515db96..37f28a3 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -459,6 +459,7 @@ extern void evergreen_pm_prepare(struct radeon_device 
*rdev);
 extern void evergreen_pm_finish(struct radeon_device *rdev);
 extern void sumo_pm_init_profile(struct radeon_device *rdev);
 extern void btc_pm_init_profile(struct radeon_device *rdev);
+int sumo_set_uvd_clocks(struct radeon_device *rdev, u32 vclk, u32 dclk);
 extern void evergreen_pre_page_flip(struct radeon_device *rdev, int crtc);
 extern u32 evergreen_page_flip(struct radeon_device *rdev, int crtc, u64 
crtc_base);
 extern void evergreen_post_page_flip(struct radeon_device *rdev, int crtc);
-- 
1.7.9.5

[PATCH 04/10] drm/radeon: add radeon_atom_get_clock_dividers helper

[Christian König]

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon.h  |5 ++
 drivers/gpu/drm/radeon/radeon_atombios.c |  107 ++
 drivers/gpu/drm/radeon/radeon_mode.h |   23 +++
 3 files changed, 135 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index eafb66a6..c1a3c1f 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -205,6 +205,11 @@ void radeon_pm_suspend(struct radeon_device *rdev);
 void radeon_pm_resume(struct radeon_device *rdev);
 void radeon_combios_get_power_modes(struct radeon_device *rdev);
 void radeon_atombios_get_power_modes(struct radeon_device *rdev);
+int radeon_atom_get_clock_dividers(struct radeon_device *rdev,
+  u8 clock_type,
+  u32 clock,
+  bool strobe_mode,
+  struct atom_clock_dividers *dividers);
 void radeon_atom_set_voltage(struct radeon_device *rdev, u16 voltage_level, u8 
voltage_type);
 void rs690_pm_info(struct radeon_device *rdev);
 extern int rv6xx_get_temp(struct radeon_device *rdev);
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index f22eb57..8c1779c 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -2654,6 +2654,113 @@ void radeon_atombios_get_power_modes(struct 
radeon_device *rdev)
rdev->pm.current_vddc = 0;
 }

+union get_clock_dividers {
+   struct _COMPUTE_MEMORY_ENGINE_PLL_PARAMETERS v1;
+   struct _COMPUTE_MEMORY_ENGINE_PLL_PARAMETERS_V2 v2;
+   struct _COMPUTE_MEMORY_ENGINE_PLL_PARAMETERS_V3 v3;
+   struct _COMPUTE_MEMORY_ENGINE_PLL_PARAMETERS_V4 v4;
+   struct _COMPUTE_MEMORY_ENGINE_PLL_PARAMETERS_V5 v5;
+};
+
+int radeon_atom_get_clock_dividers(struct radeon_device *rdev,
+  u8 clock_type,
+  u32 clock,
+  bool strobe_mode,
+  struct atom_clock_dividers *dividers)
+{
+   union get_clock_dividers args;
+   int index = GetIndexIntoMasterTable(COMMAND, ComputeMemoryEnginePLL);
+   u8 frev, crev;
+
+   memset(, 0, sizeof(args));
+   memset(dividers, 0, sizeof(struct atom_clock_dividers));
+
+   if (!atom_parse_cmd_header(rdev->mode_info.atom_context, index, , 
))
+   return -EINVAL;
+
+   switch (crev) {
+   case 1:
+   /* r4xx, r5xx */
+   args.v1.ucAction = clock_type;
+   args.v1.ulClock = cpu_to_le32(clock);   /* 10 khz */
+
+   atom_execute_table(rdev->mode_info.atom_context, index, 
(uint32_t *));
+
+   dividers->post_div = args.v1.ucPostDiv;
+   dividers->fb_div = args.v1.ucFbDiv;
+   dividers->enable_post_div = true;
+   break;
+   case 2:
+   case 3:
+   /* r6xx, r7xx, evergreen, ni */
+   if (rdev->family <= CHIP_RV770) {
+   args.v2.ucAction = clock_type;
+   args.v2.ulClock = cpu_to_le32(clock);   /* 10 khz */
+
+   atom_execute_table(rdev->mode_info.atom_context, index, 
(uint32_t *));
+
+   dividers->post_div = args.v2.ucPostDiv;
+   dividers->fb_div = le16_to_cpu(args.v2.usFbDiv);
+   dividers->ref_div = args.v2.ucAction;
+   if (rdev->family == CHIP_RV770) {
+   dividers->enable_post_div = 
(le32_to_cpu(args.v2.ulClock) & (1 << 24)) ?
+   true : false;
+   dividers->vco_mode = 
(le32_to_cpu(args.v2.ulClock) & (1 << 25)) ? 1 : 0;
+   } else
+   dividers->enable_post_div = (dividers->fb_div & 
1) ? true : false;
+   } else {
+   if (clock_type == COMPUTE_ENGINE_PLL_PARAM) {
+   args.v3.ulClock.ulComputeClockFlag = clock_type;
+   args.v3.ulClock.ulClockFreq = 
cpu_to_le32(clock);   /* 10 khz */
+
+   
atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t *));
+
+   dividers->post_div = args.v3.ucPostDiv;
+   dividers->enable_post_div = (args.v3.ucCntlFlag 
&
+
ATOM_PLL_CNTL_FLAG_PLL_POST_DIV_EN) ? true : false;
+   dividers->enable_dithen = (args.v3.ucCntlFlag &
+  
ATOM_PLL_CNTL_FLAG_FRACTION_DISABLE) ? false : true;
+   dividers->fb_div = 
le16_to_cpu(args.v3.ulFbDiv.usFbDiv);
+   dividers->frac_fb_div 

[PATCH 03/10] drm/radeon: add pm callback for setting uvd clocks

[Christian König]

From: Alex Deucher 

Signed-off-by: Alex Deucher 
Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon.h |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 3f5572d..eafb66a6 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1312,6 +1312,7 @@ struct radeon_asic {
int (*get_pcie_lanes)(struct radeon_device *rdev);
void (*set_pcie_lanes)(struct radeon_device *rdev, int lanes);
void (*set_clock_gating)(struct radeon_device *rdev, int 
enable);
+   int (*set_uvd_clocks)(struct radeon_device *rdev, u32 vclk, u32 
dclk);
} pm;
/* pageflipping */
struct {
@@ -1878,6 +1879,7 @@ void radeon_ring_write(struct radeon_ring *ring, uint32_t 
v);
 #define radeon_get_pcie_lanes(rdev) (rdev)->asic->pm.get_pcie_lanes((rdev))
 #define radeon_set_pcie_lanes(rdev, l) (rdev)->asic->pm.set_pcie_lanes((rdev), 
(l))
 #define radeon_set_clock_gating(rdev, e) 
(rdev)->asic->pm.set_clock_gating((rdev), (e))
+#define radeon_set_uvd_clocks(rdev, v, d) 
(rdev)->asic->pm.set_uvd_clocks((rdev), (v), (d))
 #define radeon_set_surface_reg(rdev, r, f, p, o, s) 
((rdev)->asic->surface.set_reg((rdev), (r), (f), (p), (o), (s)))
 #define radeon_clear_surface_reg(rdev, r) 
((rdev)->asic->surface.clear_reg((rdev), (r)))
 #define radeon_bandwidth_update(rdev) 
(rdev)->asic->display.bandwidth_update((rdev))
-- 
1.7.9.5

[PATCH 02/10] drm/radeon: UVD bringup v7

[Christian König]

Just everything needed to decode videos using UVD.

v6: just all the bugfixes and support for R7xx-SI merged in one patch
v7: UVD_CGC_GATE is a write only register, lockup detection fix

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/Makefile|2 +-
 drivers/gpu/drm/radeon/evergreen.c |   40 ++-
 drivers/gpu/drm/radeon/evergreend.h|7 +
 drivers/gpu/drm/radeon/ni.c|   49 +++
 drivers/gpu/drm/radeon/nid.h   |9 +
 drivers/gpu/drm/radeon/r600.c  |  291 ++
 drivers/gpu/drm/radeon/r600d.h |   61 
 drivers/gpu/drm/radeon/radeon.h|   47 ++-
 drivers/gpu/drm/radeon/radeon_asic.c   |   63 
 drivers/gpu/drm/radeon/radeon_asic.h   |   19 ++
 drivers/gpu/drm/radeon/radeon_cs.c |   27 +-
 drivers/gpu/drm/radeon/radeon_fence.c  |   23 +-
 drivers/gpu/drm/radeon/radeon_kms.c|1 +
 drivers/gpu/drm/radeon/radeon_object.c |   12 +-
 drivers/gpu/drm/radeon/radeon_object.h |2 +-
 drivers/gpu/drm/radeon/radeon_ring.c   |   24 +-
 drivers/gpu/drm/radeon/radeon_test.c   |   72 +++--
 drivers/gpu/drm/radeon/radeon_uvd.c|  521 
 drivers/gpu/drm/radeon/rv770.c |  134 
 drivers/gpu/drm/radeon/rv770d.h|   14 +
 drivers/gpu/drm/radeon/si.c|   32 ++
 drivers/gpu/drm/radeon/sid.h   |6 +
 include/uapi/drm/radeon_drm.h  |1 +
 23 files changed, 1400 insertions(+), 57 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/radeon_uvd.c

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index bf17252..86c5e36 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -76,7 +76,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
evergreen.o evergreen_cs.o evergreen_blit_shaders.o 
evergreen_blit_kms.o \
evergreen_hdmi.o radeon_trace_points.o ni.o cayman_blit_shaders.o \
atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o si.o \
-   si_blit_shaders.o radeon_prime.o
+   si_blit_shaders.o radeon_prime.o radeon_uvd.o

 radeon-$(CONFIG_COMPAT) += radeon_ioc32.o
 radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 305a657..18b66ff 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3360,6 +3360,9 @@ restart_ih:
DRM_ERROR("Unhandled interrupt: %d %d\n", 
src_id, src_data);
break;
}
+   case 124: /* UVD */
+   DRM_DEBUG("IH: UVD int: 0x%08x\n", src_data);
+   radeon_fence_process(rdev, R600_RING_TYPE_UVD_INDEX);
break;
case 146:
case 147:
@@ -3571,7 +3574,7 @@ int evergreen_copy_dma(struct radeon_device *rdev,

 static int evergreen_startup(struct radeon_device *rdev)
 {
-   struct radeon_ring *ring = >ring[RADEON_RING_TYPE_GFX_INDEX];
+   struct radeon_ring *ring;
int r;

/* enable pcie gen2 link */
@@ -3638,6 +3641,17 @@ static int evergreen_startup(struct radeon_device *rdev)
return r;
}

+   r = rv770_uvd_resume(rdev);
+   if (!r) {
+   r = radeon_fence_driver_start_ring(rdev,
+  R600_RING_TYPE_UVD_INDEX);
+   if (r)
+   dev_err(rdev->dev, "UVD fences init error (%d).\n", r);
+   }
+
+   if (r)
+   rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_size = 0;
+
/* Enable IRQ */
r = r600_irq_init(rdev);
if (r) {
@@ -3647,6 +3661,7 @@ static int evergreen_startup(struct radeon_device *rdev)
}
evergreen_irq_set(rdev);

+   ring = >ring[RADEON_RING_TYPE_GFX_INDEX];
r = radeon_ring_init(rdev, ring, ring->ring_size, 
RADEON_WB_CP_RPTR_OFFSET,
 R600_CP_RB_RPTR, R600_CP_RB_WPTR,
 0, 0xf, RADEON_CP_PACKET2);
@@ -3670,6 +3685,19 @@ static int evergreen_startup(struct radeon_device *rdev)
if (r)
return r;

+   ring = >ring[R600_RING_TYPE_UVD_INDEX];
+   if (ring->ring_size) {
+   r = radeon_ring_init(rdev, ring, ring->ring_size,
+R600_WB_UVD_RPTR_OFFSET,
+UVD_RBC_RB_RPTR, UVD_RBC_RB_WPTR,
+0, 0xf, RADEON_CP_PACKET2);
+   if (!r)
+   r = r600_uvd_init(rdev);
+
+   if (r)
+   DRM_ERROR("radeon: error initializing UVD (%d).\n", r);
+   }
+
r = radeon_ib_pool_init(rdev);
if (r) {
dev_err(rdev->dev, "IB initialization failed (%d).\n", r);
@@ -3716,8 +3744,10 @@ int evergreen_resume(struct 

[PATCH] drm/radeon: UVD support for RV710-SI

[Christian König]

Hi everyone,

the following patchset implements the kernel side of UVD support for the radeon 
hardware generations RV710-SI.

The R6xx and RS780/RS880 chipset generations are currently not supported, but 
might be added in the future.

The newest firmware can be found here: from 
http://people.freedesktop.org/~agd5f/radeon_ucode/

A matching patch implementing the necessary userspace side will follow in just 
a minute on the mesa devel list.

Cheers,
Christian.

[Bug 43655] Latest radeon dri driver on HD6950 with GRUB set "GRUB_GFXPAYLOAD_LINUX=keep" put the display in a flickering state

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

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

--- Comment #28 from Alexandre Demers  ---
Created attachment 77348
  --> https://bugs.freedesktop.org/attachment.cgi?id=77348=edit
dmesg from 3.9-rc5 with patch

Et voil?, as asked

-- 
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/20130403/d5c38751/attachment.html>

[Bug 43655] Latest radeon dri driver on HD6950 with GRUB set "GRUB_GFXPAYLOAD_LINUX=keep" put the display in a flickering state

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

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

--- Comment #27 from Alex Deucher  ---
(In reply to comment #26)
> Applied on 3.9-rc5 and it doesn't help.

Can you attach your dmesg output with the patch applied?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 43655] Latest radeon dri driver on HD6950 with GRUB set "GRUB_GFXPAYLOAD_LINUX=keep" put the display in a flickering state

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

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

--- Comment #26 from Alexandre Demers  ---
(In reply to comment #25)
> Created attachment 77332 [details] [review]
> possible fix
> 
> Does this patch help?

Applied on 3.9-rc5 and it doesn't help.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 61182] r600g causes KWin crashes with kernel 3.8

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||rankincj at googlemail.com

--- Comment #26 from Alex Deucher  ---
*** Bug 61822 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[patch] drm/nouveau: off by one in nouveau_drm_vblank_enable()

[Dan Carpenter]

The test here should be = ARRAY_SIZE() instead of  ARRAY_SIZE().

Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
This was introduced in git://git.freedesktop.org/git/nouveau/linux-2.6 
drm-nouveau-fixes-3.9
It hadn't hit linux-next yet yesterday.

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index c95decf..e11f8e4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -86,7 +86,7 @@ nouveau_drm_vblank_enable(struct drm_device *dev, int head)
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_disp *pdisp = nouveau_disp(drm-device);
 
-   if (WARN_ON_ONCE(head  ARRAY_SIZE(drm-vblank)))
+   if (WARN_ON_ONCE(head = ARRAY_SIZE(drm-vblank)))
return -EIO;
WARN_ON_ONCE(drm-vblank[head].func);
drm-vblank[head].func = nouveau_drm_vblank_handler;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: manual merge of the drm-intel tree with Linus' tree

[Daniel Vetter]

On Wed, Apr 03, 2013 at 01:43:49PM +1100, Stephen Rothwell wrote:
 Hi all,
 
 Today's linux-next merge of the drm-intel tree got a conflict in
 drivers/gpu/drm/i915/intel_panel.c between commit b1289371fcd5 (Revert
 drm/i915: write backlight harder) from Linus' tree and commit
 31ad8ec6a614 (drm/i915: group backlight related stuff into a struct)
 from the drm-intel tree.
 
 I fixed it up (see below) and can carry the fix as necessary (no action
 is required).

Looks good, I carry the same merge resolution locally.
-Daniel

 
 -- 
 Cheers,
 Stephen Rothwells...@canb.auug.org.au
 
 diff --cc drivers/gpu/drm/i915/intel_panel.c
 index bee8cb6,0e7e873..000
 --- a/drivers/gpu/drm/i915/intel_panel.c
 +++ b/drivers/gpu/drm/i915/intel_panel.c
 @@@ -318,9 -321,16 +321,13 @@@ void intel_panel_enable_backlight(struc
   {
   struct drm_i915_private *dev_priv = dev-dev_private;
   
 - if (dev_priv-backlight_level == 0)
 - dev_priv-backlight_level = intel_panel_get_max_backlight(dev);
 + if (dev_priv-backlight.level == 0) {
 + dev_priv-backlight.level = intel_panel_get_max_backlight(dev);
 + if (dev_priv-backlight.device)
 + dev_priv-backlight.device-props.brightness =
 + dev_priv-backlight.level;
 + }
   
  -dev_priv-backlight.enabled = true;
  -intel_panel_actually_set_backlight(dev, dev_priv-backlight.level);
  -
   if (INTEL_INFO(dev)-gen = 4) {
   uint32_t reg, tmp;
   
 @@@ -356,12 -366,12 +363,12 @@@
   }
   
   set_level:
  -/* Check the current backlight level and try to set again if it's zero.
  - * On some machines, BLC_PWM_CPU_CTL is cleared to zero automatically
  - * when BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1 are written.
  +/* Call below after setting BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1.
  + * BLC_PWM_CPU_CTL may be cleared to zero automatically when these
  + * registers are set.
*/
 - dev_priv-backlight_enabled = true;
 - intel_panel_actually_set_backlight(dev, dev_priv-backlight_level);
  -if (!intel_panel_get_backlight(dev))
  -intel_panel_actually_set_backlight(dev, 
 dev_priv-backlight.level);
 ++dev_priv-backlight.enabled = true;
 ++intel_panel_actually_set_backlight(dev, dev_priv-backlight.level);
   }
   
   static void intel_panel_init_backlight(struct drm_device *dev)



-- 
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: [PATCH v4 04/21] modetest: Add a command line parameter to select the driver

[Ville Syrjälä]

On Tue, Mar 19, 2013 at 03:55:45PM +0100, Laurent Pinchart wrote:
 If the -M parameter is specified, modetest will use the requested device
 name instead of trying its builtin list of device names.
 
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Reviewed-by: Jani Nikula jani.nik...@intel.com
 ---
  tests/modetest/modetest.c | 41 -
  1 file changed, 28 insertions(+), 13 deletions(-)
 
 diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
 index 1d1f49d..91dabfc 100644
 --- a/tests/modetest/modetest.c
 +++ b/tests/modetest/modetest.c
 @@ -908,6 +908,9 @@ static void usage(char *name)
   fprintf(stderr, \t-s connector_id[@crtc_id]:mode[@format]\tset 
 a mode\n);
   fprintf(stderr, \t-v\ttest vsynced page flipping\n);
  
 + fprintf(stderr, \n Generic options:\n\n);
 + fprintf(stderr, \t-M module\tuse the given driver\n);

You didn't add it to the usage: ... line. Same goes for patch 05/21.

 +
   fprintf(stderr, \n\tDefault is to dump all info.\n);
   exit(0);
  }
 @@ -935,7 +938,7 @@ static int page_flipping_supported(void)
  #endif
  }
  
 -static char optstr[] = cefmP:ps:v;
 +static char optstr[] = cefM:mP:ps:v;
  
  int main(int argc, char **argv)
  {
 @@ -943,6 +946,7 @@ int main(int argc, char **argv)
   int encoders = 0, connectors = 0, crtcs = 0, planes = 0, framebuffers = 
 0;
   int test_vsync = 0;
   const char *modules[] = { i915, radeon, nouveau, vmwgfx, 
 omapdrm, exynos };
 + char *module = NULL;
   unsigned int i;
   int count = 0, plane_count = 0;
   struct connector con_args[2];
 @@ -960,6 +964,9 @@ int main(int argc, char **argv)
   case 'f':
   framebuffers = 1;
   break;
 + case 'M':
 + module = optarg;
 + break;
   case 'm':
   modes = 1;
   break;
 @@ -989,14 +996,27 @@ int main(int argc, char **argv)
   if (argc == 1)
   encoders = connectors = crtcs = planes = modes = framebuffers = 
 1;
  
 - for (i = 0; i  ARRAY_SIZE(modules); i++) {
 - printf(trying to load module %s..., modules[i]);
 - fd = drmOpen(modules[i], NULL);
 + if (module) {
 + fd = drmOpen(module, NULL);
   if (fd  0) {
 - printf(failed.\n);
 - } else {
 - printf(success.\n);
 - break;
 + fprintf(stderr, failed to open device '%s'.\n, 
 module);
 + return 1;
 + }
 + } else {
 + for (i = 0; i  ARRAY_SIZE(modules); i++) {
 + printf(trying to open device '%s'..., modules[i]);
 + fd = drmOpen(modules[i], NULL);
 + if (fd  0) {
 + printf(failed.\n);
 + } else {
 + printf(success.\n);
 + break;
 + }
 + }
 +
 + if (fd  0) {
 + fprintf(stderr, no device found.\n);
 + return 1;
   }
   }
  
 @@ -1005,11 +1025,6 @@ int main(int argc, char **argv)
   return -1;
   }
  
 - if (i == ARRAY_SIZE(modules)) {
 - fprintf(stderr, failed to load any modules, aborting.\n);
 - return -1;
 - }
 -
   resources = drmModeGetResources(fd);
   if (!resources) {
   fprintf(stderr, drmModeGetResources failed: %s\n,
 -- 
 1.8.1.5
 
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor

[bugzilla-daemon]

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

--- Comment #11 from Michel Dänzer mic...@daenzer.net ---
(In reply to comment #8)
 It seems like Gnome 3.6 won't work unless color tiling is enabled. I double
 checked the gnome session logs and don't see the previously mentioned error
 anymore.. just a blank desktop wallpaper across both monitors.

Weird. GNOME 3.6 was and 3.8 still is working fine for me with ColorTiling
disabled (on a 7770), and I'm not sure how this could be directly related. Is
there anything in dmesg about GPU lockups, or is gnome-shell getting stuck
somehwere, or something like that?

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

UVD fails to init on rv790

[Andy Furniss]

Thanks AMD for getting this out :-)

I have an issue, though.

On HD4890 drm-fixes kernel (before yesterdays updates) got the new

R700_rlc.bin
RV770_uvd.bin

but on boot I get -

[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RV770 0x1002:0x9460 0x1682:0x2700).
[drm] register mmio base: 0xFE6F
[drm] register mmio size: 65536
ATOM BIOS: Wekiva
radeon :01:00.0: VRAM: 1024M 0x - 0x3FFF 
(1024M used)

radeon :01:00.0: GTT: 512M 0x4000 - 0x5FFF
[drm] Detected VRAM RAM=1024M, BAR=256M
[drm] RAM width 256bits DDR
[TTM] Zone  kernel: Available graphics memory: 436936 kiB
[TTM] Zone highmem: Available graphics memory: 1685484 kiB
[TTM] Initializing pool allocator
[drm] radeon: 1024M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
radeon :01:00.0: irq 51 for MSI/MSI-X
radeon :01:00.0: radeon: using MSI.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] probing gen 2 caps for device 1022:9603 = 300d02/0
[drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
[drm] Loading RV770 Microcode
[drm] PCIE GART of 512M enabled (table at 0x00257000).
radeon :01:00.0: WB enabled
radeon :01:00.0: fence driver on ring 0 use gpu addr 
0x4c00 and cpu addr 0xff893c00
radeon :01:00.0: fence driver on ring 3 use gpu addr 
0x4c0c and cpu addr 0xff893c0c
radeon :01:00.0: fence driver on ring 5 use gpu addr 
0x0005632c and cpu addr 0xfbb9632c

[drm] ring test on 0 succeeded in 1 usecs
[drm] ring test on 3 succeeded in 1 usecs
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!!
[drm:rv770_startup] *ERROR* radeon: failed initializing UVD (-1).
[drm] Enabling audio support
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 0 usecs
ALSA sound/pci/hda/hda_eld.c:334 HDMI: ELD buf size is 0, force 128
ALSA sound/pci/hda/hda_eld.c:351 HDMI: invalid ELD data byte 0
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   DVI-I-1
[drm]   HPD2
[drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
[drm]   Encoders:
[drm] DFP1: INTERNAL_UNIPHY
[drm] CRT2: INTERNAL_KLDSCP_DAC2
[drm] Connector 1:
[drm]   DIN-1
[drm]   Encoders:
[drm] TV1: INTERNAL_KLDSCP_DAC2
[drm] Connector 2:
[drm]   DVI-I-2
[drm]   HPD1
[drm]   DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c
[drm]   Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] DFP2: INTERNAL_KLDSCP_LVTMA
[drm] Internal thermal controller with fan control
[drm] radeon: power management initialized
[drm] fb mappable at 0xD0359000
[drm] vram apper at 0xD000
[drm] size 8294400
[drm] fb depth is 24
[drm]pitch is 7680
fbcon: radeondrmfb (fb0) is primary device
Console: switching to colour frame buffer device 240x67
radeon :01:00.0: fb0: radeondrmfb frame buffer device
radeon :01:00.0: registered panic notifier
[drm] Initialized radeon 2.30.0 20080528 for :01:00.0 on minor 0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

[bugzilla-daemon]

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

--- Comment #3 from Michel Dänzer mic...@daenzer.net ---
If you run piglit with --no-concurrency from a remote shell, you should see in
the terminal output which test is running when it hangs.

-- 
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: UVD fails to init on rv790

[Christian König]

Hi Andy,

crap! I feared that something like this would happen. IIRC we never 
tested UVD on an rv790, and this hardware isn't easy to get any more.


RV770/RV790 have a separate UVD hardware generation (that's why they 
have their own firmware) and there possible is some bug or something 
like this that we haven't implemented. You couldn't give me SSH access 
to that system?


Christian.

Am 03.04.2013 11:51, schrieb Andy Furniss:

Thanks AMD for getting this out :-)

I have an issue, though.

On HD4890 drm-fixes kernel (before yesterdays updates) got the new

R700_rlc.bin
RV770_uvd.bin

but on boot I get -

[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RV770 0x1002:0x9460 
0x1682:0x2700).

[drm] register mmio base: 0xFE6F
[drm] register mmio size: 65536
ATOM BIOS: Wekiva
radeon :01:00.0: VRAM: 1024M 0x - 
0x3FFF (1024M used)

radeon :01:00.0: GTT: 512M 0x4000 - 0x5FFF
[drm] Detected VRAM RAM=1024M, BAR=256M
[drm] RAM width 256bits DDR
[TTM] Zone  kernel: Available graphics memory: 436936 kiB
[TTM] Zone highmem: Available graphics memory: 1685484 kiB
[TTM] Initializing pool allocator
[drm] radeon: 1024M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
radeon :01:00.0: irq 51 for MSI/MSI-X
radeon :01:00.0: radeon: using MSI.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] probing gen 2 caps for device 1022:9603 = 300d02/0
[drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
[drm] Loading RV770 Microcode
[drm] PCIE GART of 512M enabled (table at 0x00257000).
radeon :01:00.0: WB enabled
radeon :01:00.0: fence driver on ring 0 use gpu addr 
0x4c00 and cpu addr 0xff893c00
radeon :01:00.0: fence driver on ring 3 use gpu addr 
0x4c0c and cpu addr 0xff893c0c
radeon :01:00.0: fence driver on ring 5 use gpu addr 
0x0005632c and cpu addr 0xfbb9632c

[drm] ring test on 0 succeeded in 1 usecs
[drm] ring test on 3 succeeded in 1 usecs
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the 
VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the 
VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the 
VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the 
VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the 
VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the 
VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the 
VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the 
VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the 
VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the 
VCPU!!!

[drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!!
[drm:rv770_startup] *ERROR* radeon: failed initializing UVD (-1).
[drm] Enabling audio support
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 0 usecs
ALSA sound/pci/hda/hda_eld.c:334 HDMI: ELD buf size is 0, force 128
ALSA sound/pci/hda/hda_eld.c:351 HDMI: invalid ELD data byte 0
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   DVI-I-1
[drm]   HPD2
[drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
[drm]   Encoders:
[drm] DFP1: INTERNAL_UNIPHY
[drm] CRT2: INTERNAL_KLDSCP_DAC2
[drm] Connector 1:
[drm]   DIN-1
[drm]   Encoders:
[drm] TV1: INTERNAL_KLDSCP_DAC2
[drm] Connector 2:
[drm]   DVI-I-2
[drm]   HPD1
[drm]   DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c
[drm]   Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] DFP2: INTERNAL_KLDSCP_LVTMA
[drm] Internal thermal controller with fan control
[drm] radeon: power management initialized
[drm] fb mappable at 0xD0359000
[drm] vram apper at 0xD000
[drm] size 8294400
[drm] fb depth is 24
[drm]pitch is 7680
fbcon: radeondrmfb (fb0) is primary device
Console: switching to colour frame buffer device 240x67
radeon :01:00.0: fb0: radeondrmfb frame buffer device
radeon :01:00.0: registered panic notifier
[drm] Initialized radeon 2.30.0 20080528 for :01:00.0 on minor 0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel



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

Re: [patch] drm/nouveau: off by one in nouveau_drm_vblank_enable()

[Maarten Lankhorst]

Op 03-04-13 10:05, Dan Carpenter schreef:
 The test here should be = ARRAY_SIZE() instead of  ARRAY_SIZE().

 Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
Acked-by: Maarten Lankhorst maarten.lankho...@canonical.com
 ---
 This was introduced in git://git.freedesktop.org/git/nouveau/linux-2.6 
 drm-nouveau-fixes-3.9
 It hadn't hit linux-next yet yesterday.

 diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
 b/drivers/gpu/drm/nouveau/nouveau_drm.c
 index c95decf..e11f8e4 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
 @@ -86,7 +86,7 @@ nouveau_drm_vblank_enable(struct drm_device *dev, int head)
   struct nouveau_drm *drm = nouveau_drm(dev);
   struct nouveau_disp *pdisp = nouveau_disp(drm-device);
  
 - if (WARN_ON_ONCE(head  ARRAY_SIZE(drm-vblank)))
 + if (WARN_ON_ONCE(head = ARRAY_SIZE(drm-vblank)))
   return -EIO;
   WARN_ON_ONCE(drm-vblank[head].func);
   drm-vblank[head].func = nouveau_drm_vblank_handler;


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

[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

[bugzilla-daemon]

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

--- Comment #4 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(In reply to comment #3)
 If you run piglit with --no-concurrency from a remote shell, you should see
 in the terminal output which test is running when it hangs.

Many tests seems to skip when they are run remotely via an ssh session. Is this
expected or should I set a parameter about the display?

-- 
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 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

[bugzilla-daemon]

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

--- Comment #5 from Michel Dänzer mic...@daenzer.net ---
It's perfectly normal that some tests are skipped, but you obviously do need to
set the DISPLAY environment variable appropriately for the piglit run.
Something like

DISPLAY=:0 python2 piglit-run.py ...

-- 
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: UVD fails to init on rv790

[Alex Deucher]

On Wed, Apr 3, 2013 at 7:29 AM, Christian König deathsim...@vodafone.de wrote:
 Hi Andy,

 crap! I feared that something like this would happen. IIRC we never tested
 UVD on an rv790, and this hardware isn't easy to get any more.

 RV770/RV790 have a separate UVD hardware generation (that's why they have
 their own firmware) and there possible is some bug or something like this
 that we haven't implemented. You couldn't give me SSH access to that system?

I tested on an RV770 earlier in development and it was working ok at
the time I think.  I'll give it another try today.

Alex


 Christian.

 Am 03.04.2013 11:51, schrieb Andy Furniss:

 Thanks AMD for getting this out :-)

 I have an issue, though.

 On HD4890 drm-fixes kernel (before yesterdays updates) got the new

 R700_rlc.bin
 RV770_uvd.bin

 but on boot I get -

 [drm] radeon kernel modesetting enabled.
 [drm] initializing kernel modesetting (RV770 0x1002:0x9460 0x1682:0x2700).
 [drm] register mmio base: 0xFE6F
 [drm] register mmio size: 65536
 ATOM BIOS: Wekiva
 radeon :01:00.0: VRAM: 1024M 0x - 0x3FFF
 (1024M used)
 radeon :01:00.0: GTT: 512M 0x4000 - 0x5FFF
 [drm] Detected VRAM RAM=1024M, BAR=256M
 [drm] RAM width 256bits DDR
 [TTM] Zone  kernel: Available graphics memory: 436936 kiB
 [TTM] Zone highmem: Available graphics memory: 1685484 kiB
 [TTM] Initializing pool allocator
 [drm] radeon: 1024M of VRAM memory ready
 [drm] radeon: 512M of GTT memory ready.
 [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
 [drm] Driver supports precise vblank timestamp query.
 radeon :01:00.0: irq 51 for MSI/MSI-X
 radeon :01:00.0: radeon: using MSI.
 [drm] radeon: irq initialized.
 [drm] GART: num cpu pages 131072, num gpu pages 131072
 [drm] probing gen 2 caps for device 1022:9603 = 300d02/0
 [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
 [drm] Loading RV770 Microcode
 [drm] PCIE GART of 512M enabled (table at 0x00257000).
 radeon :01:00.0: WB enabled
 radeon :01:00.0: fence driver on ring 0 use gpu addr
 0x4c00 and cpu addr 0xff893c00
 radeon :01:00.0: fence driver on ring 3 use gpu addr
 0x4c0c and cpu addr 0xff893c0c
 radeon :01:00.0: fence driver on ring 5 use gpu addr
 0x0005632c and cpu addr 0xfbb9632c
 [drm] ring test on 0 succeeded in 1 usecs
 [drm] ring test on 3 succeeded in 1 usecs
 [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
 VCPU!!!
 [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
 VCPU!!!
 [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
 VCPU!!!
 [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
 VCPU!!!
 [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
 VCPU!!!
 [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
 VCPU!!!
 [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
 VCPU!!!
 [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
 VCPU!!!
 [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
 VCPU!!!
 [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
 VCPU!!!
 [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!!
 [drm:rv770_startup] *ERROR* radeon: failed initializing UVD (-1).
 [drm] Enabling audio support
 [drm] ib test on ring 0 succeeded in 0 usecs
 [drm] ib test on ring 3 succeeded in 0 usecs
 ALSA sound/pci/hda/hda_eld.c:334 HDMI: ELD buf size is 0, force 128
 ALSA sound/pci/hda/hda_eld.c:351 HDMI: invalid ELD data byte 0
 [drm] Radeon Display Connectors
 [drm] Connector 0:
 [drm]   DVI-I-1
 [drm]   HPD2
 [drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
 [drm]   Encoders:
 [drm] DFP1: INTERNAL_UNIPHY
 [drm] CRT2: INTERNAL_KLDSCP_DAC2
 [drm] Connector 1:
 [drm]   DIN-1
 [drm]   Encoders:
 [drm] TV1: INTERNAL_KLDSCP_DAC2
 [drm] Connector 2:
 [drm]   DVI-I-2
 [drm]   HPD1
 [drm]   DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c
 [drm]   Encoders:
 [drm] CRT1: INTERNAL_KLDSCP_DAC1
 [drm] DFP2: INTERNAL_KLDSCP_LVTMA
 [drm] Internal thermal controller with fan control
 [drm] radeon: power management initialized
 [drm] fb mappable at 0xD0359000
 [drm] vram apper at 0xD000
 [drm] size 8294400
 [drm] fb depth is 24
 [drm]pitch is 7680
 fbcon: radeondrmfb (fb0) is primary device
 Console: switching to colour frame buffer device 240x67
 radeon :01:00.0: fb0: radeondrmfb frame buffer device
 radeon :01:00.0: registered panic notifier
 [drm] Initialized radeon 2.30.0 20080528 for :01:00.0 on minor 0
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel


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

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

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

--- Comment #19 from Alex Deucher ag...@yahoo.com ---
Created attachment 77383
  -- https://bugs.freedesktop.org/attachment.cgi?id=77383action=edit
possible fix

Does this kernel patch (against 3.9) help?

-- 
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 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

[bugzilla-daemon]

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

--- Comment #6 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(In reply to comment #5)
 It's perfectly normal that some tests are skipped, but you obviously do need
 to set the DISPLAY environment variable appropriately for the piglit run.
 Something like
 
 DISPLAY=:0 python2 piglit-run.py ...

I meant that some tests are skipped when run remotely, but tested when run
locally. ;) I'll try your suggestion.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 0/2] Enhance EDID quirks to allow forcing a mode

[Dylan Semler]

On Mon, Mar 25, 2013 at 5:58 PM, Dylan Semler dylan.sem...@gmail.com
wrote:

 Changes in this version
  * rename do_force_quirk_modes() - do_force_quirk_mode()
  * use list_for_each_entry() instead of list_for_each_entry_safe() in
do_force_quirk_mode()
  * remove num_modes from do_force_quirk_mode(), just return 1 or 0 as
appropriate
  * remove unused quirks argument from add_force_quirk_modes()
  * fixes to allow cases of forcing multiple modes
  * adjusted comments to adhere closer to style guides

 Changes in version 3
  * Uses drm_cvt_mode() instead of drm_gtf_mode() to build modeline
  * Adds bool to specify reduced blanking to edid_quirk_force_mode
  * Removes preferred bit from all other modes

 Changes in version 2
  * none

 There is at least one monitor that doesn't report its native resolution
 in its EDID block.  This enhancement extends the EDID quirk logic to
 make monitors like this just work.

 The first patch in this series sets up a new quirk list where monitors'
 correct width, height, refresh rate, and reduced blanking parameters are
 specified.  When a matching monitor is attached the full mode is
 calculated with drm_cvt_mode() and added to the connector.  The
 DRM_MODE_TYPE_PREFERRED bit is set on the new mode and unset from all
 other modes.

 The first patch also defines a new quirk bit: EDID_QUIRK_FORCE_MODE.
 This bit needs to be set for the new quirk list described above to be
 checked.

 The second patch adds the offending monitor to the quirk lists.

 Dylan Semler (2):
   drm: Enhance EDID quirks to explicitly set a mode
   drm: Add EDID force quirk for MMT Monitor2Go HD+

  drivers/gpu/drm/drm_edid.c | 89
++
  1 file changed, 89 insertions(+)

 --
 1.7.11.7


Version 3 was Acked by Daniel Vetter[1].  Any chance ajax can give his
comments?

[1] http://lists.freedesktop.org/archives/dri-devel/2013-March/036457.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43655] Latest radeon dri driver on HD6950 with GRUB set GRUB_GFXPAYLOAD_LINUX=keep put the display in a flickering state

[bugzilla-daemon]

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

Alexandre Demers alexandre.f.dem...@gmail.com changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=57567

-- 
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 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

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

Alexandre Demers alexandre.f.dem...@gmail.com changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=43655

-- 
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: radeonsi tiling dilema

[Jerome Glisse]

On Wed, Apr 3, 2013 at 5:37 AM, Michel Dänzer mic...@daenzer.net wrote:

 On Die, 2013-04-02 at 14:13 -0400, Jerome Glisse wrote:
  So i am facing a dilema regarding tiling on radeonsi. Given that we
  now have a fixed table of tiling mode this put more pressure on the
  kernel userspace api. I see either 2 solutions.
 
 
  Enforce kernel to set at fixed index in the table best tiling mode for
  given gpu for given format, such as DEPTH32_2D_4AA at index 4, or
  COLOR_SCANOUT_2D at index 13 ... that way kernel can still adapt the
  tile mode array value. Note that this match the design behind the tile
  mode index being that there is a limited number of useful tile mode
  combination and for each surface format  (depth/color/macro
  tile/micro/tile) there is a best one.
 
 
  Second solution is to add an ioctl to compute mipmap information in
  kernel (pitch alignment slice size ...) based on format, size of the
  surface.
 
 
  Some might argue that we could just export the table content to
  userspace, but that would loose information and possibly froze the
  tile mode table forever as API. The information we loose is what index
  match to prefered surface format/type combination. And the tile mode
  might be considered API as if kernel ever change what userspace expect
  then we might break some userspace.

 Maybe I'm missing the problem, but if libdrm_radeon were to get the
 tiling mode index chosen by radeonsi, and could retrieve the tiling
 parameters for each index from the kernel, it should be able to
 calculate things properly, shouldn't it?


Let's not discuss about who/where the index is pick. No matter where it
happens the question is do we want to hardcode tile index and make it api
or do we want to hide it behind symbolic name allowing change in tile array
(given that right now 4 value are already frozen). You can look at my
kernel patch to see what i mean.

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

Re: [PATCH] drm/radeon: UVD support for RV710-SI

[Jerome Glisse]

On Wed, Apr 03, 2013 at 01:18:29AM +0200, Christian König wrote:
 Hi everyone,
 
 the following patchset implements the kernel side of UVD support for the 
 radeon hardware generations RV710-SI.
 
 The R6xx and RS780/RS880 chipset generations are currently not supported, but 
 might be added in the future.
 
 The newest firmware can be found here: from 
 http://people.freedesktop.org/~agd5f/radeon_ucode/
 
 A matching patch implementing the necessary userspace side will follow in 
 just a minute on the mesa devel list.
 
 Cheers,
 Christian.

For all patch i don't comment on (all patch but first one and second one iirc) 
you got my
Reviewed-by: Jerome Glisse jgli...@redhat.com

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

Re: [PATCH 01/10] drm/radeon: UVD doesn't needs VM on SI

[Jerome Glisse]

On Wed, Apr 03, 2013 at 01:18:30AM +0200, Christian König wrote:
 Signed-off-by: Christian König deathsim...@vodafone.de
 ---
  drivers/gpu/drm/radeon/radeon_cs.c |   10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
 b/drivers/gpu/drm/radeon/radeon_cs.c
 index 70d3824..7d66e01 100644
 --- a/drivers/gpu/drm/radeon/radeon_cs.c
 +++ b/drivers/gpu/drm/radeon/radeon_cs.c
 @@ -241,15 +241,15 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, 
 void *data)
   return -EINVAL;
   }
  
 + if (radeon_cs_get_ring(p, ring, priority))
 + return -EINVAL;
 +
   /* we only support VM on SI+ */
 - if ((p-rdev-family = CHIP_TAHITI) 
 - ((p-cs_flags  RADEON_CS_USE_VM) == 0)) {
 + if ((p-rdev-asic-ring[p-ring].cs_parse == NULL) 
 +((p-cs_flags  RADEON_CS_USE_VM) == 0)) {
   DRM_ERROR(VM required on SI+!\n);
   return -EINVAL;

What about updating the error message to something more appropriate like
ring %d require virtual memory

Cheers,
Jerome

   }
 -
 - if (radeon_cs_get_ring(p, ring, priority))
 - return -EINVAL;
   }
  
   /* deal with non-vm */
 -- 
 1.7.9.5
 
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor

[bugzilla-daemon]

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

--- Comment #12 from Alexander von Gluck kallis...@unixzen.com ---
The only dmesg errors are these:

[309092.861665] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
[309099.062192] radeon :01:00.0: bo 8803fc4cb400 don't has a mapping in
vm 8803f406b580
[309099.063303] radeon :01:00.0: bo 8803fc4cf400 don't has a mapping in
vm 8803f406b580
[309099.064403] radeon :01:00.0: bo 8803fc4c9800 don't has a mapping in
vm 8803f406b580
[309099.065457] radeon :01:00.0: bo 8803fc4cc800 don't has a mapping in
vm 8803f406b580
[309099.066560] radeon :01:00.0: bo 8803fc4cb800 don't has a mapping in
vm 8803f406b580
[309099.067664] radeon :01:00.0: bo 8803fc4c9c00 don't has a mapping in
vm 8803f406b580


agd5f mentioned that those are normal though. (well, not *normal* but can be
ignored)

-- 
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 59521] [Serious Sam 3] Missing textures with R600g

[bugzilla-daemon]

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

--- Comment #8 from John Bridgman john.bridg...@amd.com ---
(In reply to comment #7)
 using MESA_EXTENSION_OVERRIDE=-GL_ARB_get_program_binary make it works
 properly

Just checking, do you mean using over-ride eliminates the missing textures ?

-- 
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 59521] [Serious Sam 3] Missing textures with R600g

[bugzilla-daemon]

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

--- Comment #9 from John Bridgman john.bridg...@amd.com ---
Sorry, hit save too soon. Your post on the steam forum suggested that there
might be a crash related to use of precompiled shader binaries so I'm wondering
if your comment here refers to fixing a crash or fixing the textures. 

Thanks...

-- 
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] drm/i915: Add no-lvds quirk for Fujitsu Esprimo Q900

[Daniel Vetter]

On Wed, Apr 03, 2013 at 02:34:11PM +0200, Christian Lamparter wrote:
 The Mobile Sandy Bridge CPUs in the Fujitsu Esprimo Q900
 mini desktop PCs are probably misleading the LVDS detection
 code in intel_lvds_supported. Nothing is connected to the
 LVDS ports in these systems.
 
 Signed-off-by: Christian Lamparter chunk...@googlemail.com

So despite that snb has a bit who's _only_ purpose is to allow the bios to
tell the driver whether there's an lvds output or not, someone screwed it
finally up :( We just can't win against the firmware ...

Queued for -next with cc: stable, thanks for the patch.
-Daniel
 ---
  drivers/gpu/drm/i915/intel_lvds.c |8 
  1 file changed, 8 insertions(+)
 
 diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
 b/drivers/gpu/drm/i915/intel_lvds.c
 index 3d1d974..65893b0 100644
 --- a/drivers/gpu/drm/i915/intel_lvds.c
 +++ b/drivers/gpu/drm/i915/intel_lvds.c
 @@ -850,6 +850,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
   DMI_MATCH(DMI_PRODUCT_NAME, X7SPA-H),
   },
   },
 + {
 + .callback = intel_no_lvds_dmi_callback,
 + .ident = Fujitsu Esprimo Q900,
 + .matches = {
 + DMI_MATCH(DMI_SYS_VENDOR, FUJITSU),
 + DMI_MATCH(DMI_PRODUCT_NAME, ESPRIMO Q900),
 + },
 + },
  
   { } /* terminating entry */
  };
 -- 
 1.7.10.4
 

-- 
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: [PATCH 01/10] drm/radeon: UVD doesn't needs VM on SI

[Christian König]

Am 03.04.2013 16:42, schrieb Jerome Glisse:

On Wed, Apr 03, 2013 at 01:18:30AM +0200, Christian König wrote:

Signed-off-by: Christian König deathsim...@vodafone.de
---
  drivers/gpu/drm/radeon/radeon_cs.c |   10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 70d3824..7d66e01 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -241,15 +241,15 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, 
void *data)
return -EINVAL;
}
  
+		if (radeon_cs_get_ring(p, ring, priority))

+   return -EINVAL;
+
/* we only support VM on SI+ */
-   if ((p-rdev-family = CHIP_TAHITI) 
-   ((p-cs_flags  RADEON_CS_USE_VM) == 0)) {
+   if ((p-rdev-asic-ring[p-ring].cs_parse == NULL) 
+  ((p-cs_flags  RADEON_CS_USE_VM) == 0)) {
DRM_ERROR(VM required on SI+!\n);
return -EINVAL;

What about updating the error message to something more appropriate like
ring %d require virtual memory


Good point, going to change it.

Christian.


Cheers,
Jerome


}
-
-   if (radeon_cs_get_ring(p, ring, priority))
-   return -EINVAL;
}
  
  	/* deal with non-vm */

--
1.7.9.5

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


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

Re: radeonsi tiling dilema

[Christian König]

Am 03.04.2013 15:57, schrieb Jerome Glisse:

On Wed, Apr 3, 2013 at 5:37 AM, Michel Dänzer mic...@daenzer.net wrote:


On Die, 2013-04-02 at 14:13 -0400, Jerome Glisse wrote:

So i am facing a dilema regarding tiling on radeonsi. Given that we
now have a fixed table of tiling mode this put more pressure on the
kernel userspace api. I see either 2 solutions.


Enforce kernel to set at fixed index in the table best tiling mode for
given gpu for given format, such as DEPTH32_2D_4AA at index 4, or
COLOR_SCANOUT_2D at index 13 ... that way kernel can still adapt the
tile mode array value. Note that this match the design behind the tile
mode index being that there is a limited number of useful tile mode
combination and for each surface format  (depth/color/macro
tile/micro/tile) there is a best one.


Second solution is to add an ioctl to compute mipmap information in
kernel (pitch alignment slice size ...) based on format, size of the
surface.


Some might argue that we could just export the table content to
userspace, but that would loose information and possibly froze the
tile mode table forever as API. The information we loose is what index
match to prefered surface format/type combination. And the tile mode
might be considered API as if kernel ever change what userspace expect
then we might break some userspace.

Maybe I'm missing the problem, but if libdrm_radeon were to get the
tiling mode index chosen by radeonsi, and could retrieve the tiling
parameters for each index from the kernel, it should be able to
calculate things properly, shouldn't it?



Let's not discuss about who/where the index is pick. No matter where it
happens the question is do we want to hardcode tile index and make it api
or do we want to hide it behind symbolic name allowing change in tile array
(given that right now 4 value are already frozen). You can look at my
kernel patch to see what i mean.


Just as a side node: If I understood it correctly the hardware isn't 
completely capable to use those indexes interchangeable, e.g. only a 
certain range can be used for the DB, and another rule matters for AA 
indexes etc...


I don't know those rules exactly and I don't know how strict they are, 
but as far as I understood it even the closed source driver didn't need 
to mess with it. So I'm something like 90% sure that hardcoding them is 
ok, but well on the other hand it just doesn't feels good to do so...


Christian.


Cheers,
Jerome



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


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